Thorn users

For those who used the old version of MoL, this version is unfortunately slightly more effort to use. That is, for most methods you'll now have to set 4 parameters instead of just one.

If you already have a thorn that uses the method of lines, then there are four main parameters that are relevant to change the integration method. The keyword MoL_ODE_Method chooses between the different methods. Currently supported are RK2, RK3, ICN, ICN-Avg and Generic. These are second order Runge-Kutta, third order Runge-Kutta, Iterative Crank Nicholson, Iterative Crank Nicholson with averaging, and the generic Shu-Osher type Runge-Kutta methods. To switch between the different types of generic methods there is also the keyword Generic_Type which is currently restricted to RK for the standard TVD Runge-Kutta methods (first to fourth order) and ICN for the implementation of the Iterative Crank Nicholson method in generic form.

Full descriptions of the currently implemented methods are given in section A10.5.

The parameter MoL_Intermediate_Steps controls the number of intermediate steps for the ODE solver. For the generic Runge-Kutta solvers it controls the order of accuracy of the method. For the ICN methods this parameter controls the number of iterations taken, which does not check for stability. This parameter defaults to 3.

The parameter MoL_Num_Scratch_Levels controls the amount of scratch space used. If this is insufficient for the method selected there will be an error at parameter checking time. This parameter defaults to 0, as no scratch space is required for the efficient ICN and Runge-Kutta 2 and 3 solvers. For the generic solvers this must be at least MoL_Intermediate_Steps - 1.

Another parameter is MoL_Memory_Always_On which switches on memory for the scratch space always if true and only during evolution if false. This defaults to true for speed reasons; the memory gains are likely to be limited unless you're doing something very memory intensive at initialization or analysis.

There is also a parameter MoL_NaN_Check that will check your RHS grid functions for NaNs using the NaNChecker thorn from CactusUtils. This will make certain that you find the exact grid function computing the first NaN; of course, this may not be the real source of your problem.

The parameter disable_prolongation only does anything if you are using mesh refinement, and in particular Carpet. With mesh refinement it may be necessary to disable prolongation in intermediate steps of MoL. This occurs when evolving systems containing second spatial derivatives. This is done by default in MoL. If your system is purely first order in space and time you may wish to set this to "no".

Ideally, initial data thorns should always set initial data at all time levels. However, sometimes initial data thorns fail to do this. In this case you can do one of three things:

• Fix the initial data thorn. This is the best solution.
• If you're using Carpet, it has some facilities to take forward/backward time steps to initialize multiple time levels. See the Carpet parameters init_each_timelevel and init_3_timelevels for details.
• Finally, if you set (the MoL parameter) initial_data_is_crap, MoL will copy the current time level of all variables it knows about (more precisely, using the terminology of section A10.3.2, all evolved, save-and-restore, and constrained variables which have multiple time levels) to all the past time levels. Note that this copies the same data to each past time level; this will be wrong if your spacetime is time-dependent!

  If enabled, the copy happens in the CCTK_POSTINITIAL schedule bin. By default this happens before the MoL_PostStep schedule group; the parameter copy_ID_after_MoL_PostStep can be used to change this to after MoL_PostStep.