Many parameters in the control file that are valid for the HD module
also apply for the MHD module.
A few parameters have somewhat different options for both modules
(hdtimeintegrationscheme
: Sect.7.1.8.2,
hdsplit
: Sect.7.1.8.3,
character reconstruction
: Sect.7.1.8.4).
Several parameters have meanings only
for the HD (see Sect.7.1.9)
or the MHD module (see Sect.7.1.10)
and are ignored in the other one.

None
: The hydrodynamics step is skipped entirely (for test purposes). Note that in this
case some initializations necessary for the generation of the mean file are omitted, too.
Roe
: (default) The standard approximate Riemann solver of Roetype is activated.
This value will be chosen for pure HD simulations without magnetic fields.
RoeMagKin
: The standard Roe solver is extended to transport passively a magnetic field.
This is a test implementation to check if the general magneticfield handling
works. For proper MHD simulations use HLLMHD
instead.
This option is currently deactivated.
RoeMHD
: Use the MHD Roe solver.
This option is currently deactivated.
HLLMHD
: Use the MHD HLL solver (the recommend value for MHD simulations).
Single
: (default for HD Roe) Compute all updates in one single step.
Terms higher order in time are provided by the Roe solver
depending on the order of the reconstruction scheme.
Hancock
: (default for MHD HLLE) Terms of second order in time
are approximated by a Hancock predictor step.
Euler1
: (only for MHD) A single Euler step is used, which is only first order in time.
RungeKutta2
: A twostep (predictorcorrector) RungeKutta step is used.
RungeKutta3
: A threestep RungeKutta step is used.
123
: (default) The standard directional splitting is activated,
where the 1D operators for the individual directions are applied in the given order.
So far, only the order 123
is possible.
unsplit
: The standard solver is applied.
However, the changes from the individual steps are computed from (and applied to)
the same model configuration. The result is an unsplit scheme.
CTU
: Use Colella's "Corner Transport Upwind" scheme ('CTU', see Colella, 1990).
It first computesand stores the changes from hydrodynamics in x1,
x2, and x3 direction. Then (half of) the contributions from the
steps in x1 and x2 direction are used as sort of a predictor step
for the full ('corrector') step in x3 direction (and accordingly
for the two other directions). At the end, the three
correctorstep contributions are added. That means, that
two hydrodynamics steps have to be performed in each direction
with some overhead for copying and adding the contributions.
Still, together with e.g., reconstruction=FRweno
,
there is a significant improvement for convection at small Mach numbers
compared to 123, vanLeer
.
hdscheme=Roe
and hdscheme=HLLMHD
,
although hdscheme=HLLMHD
does not know hdsplit=CTU
.
Constant
: The run of the partial waves inside the cells is assumed to be constant.
A highly dissipative first order scheme results.
This values will usually only be used for test (or comparison) purposes.
Minmod
: Chooses the smallest slope which still results in a secondorder scheme.
It is the most diffusive (and most stable) one in this class.
VanLeer
: (default) The firstorder reconstruction method.
It was recommended and used in various simulations but is now replaced
by a secondorder reconstruction.
Superbee
: The ``most aggressive'' firstorder reconstruction method.
It results in the steepest shocks, which works well in some test cases
but tends to turn smooth gradients into steps and
might be to difficult for the radiation transport module to handle.
PPmimo
: MinMod reconstruction based on boundary values from PP.
PP
: Chooses the piecewise parabolic reconstruction of the PPM scheme
(``Piecewise Parabolic Method'', see Colella & Woodward, 1984).
Results in 3rd order accuracy for the advection.
FRmimo
: MinMod reconstruction based on boundary values from FRmono.
FRmono
: 2ndorder monotonic reconstruction derived from PP, WENO, and MinMod: ``Frankenstein's Method''.
FRmono2
: 2ndorder monotonic reconstruction derived from PP, WENO, and MinMod.
It is identical to FRmono
if c_slopered=0.0
(the usually adopted default choice, see Section. 7.1.9.7).
However, for c_slopered$>$0.0
, it uses Constant
reconstruction
as fallback, instead of Minmod
as FRmono
does.
This is the recommended fallback version for redsupergiant models.
FRweno
: 2ndorder nonmonotonic version of FR. This (or FRweno2
) is now
the recommended value.
FRweno2
: 2ndorder nonmonotonic version of FR.
It is identical to FRweno
if c_slopered=0.0
(the usually adopted default choice, see Section. 7.1.9.7).
However, for c_slopered$>$0.0
, it uses Constant
reconstruction
as fallback, instead of Minmod
as FRweno
does.
This is the recommended version for redsupergiant models.
FRcont
: 2ndorder continuous version of FR, unstable except for low Mach numbers.
HBweno
: Common WENO scheme based on three parabolas in a stencil,
with an additional ``handbrake'' to fall back
to a more stable (monotonic) scheme
if the smoothness of all parabolas is bad.
This scheme is (depending on the parameters) even less diffusive
than FRweno
. It is not strictly monotonic, neither.
VAweno
: Common (``vanilla'') WENO scheme based on three parabolas in a stencil.
This scheme achieves very high resolution if the lack of monotonicity
and general diffusivity can be accepted.
It is identical to HBweno
, but without the ``handbrake''
and therefore even a bit faster.
VanLeer
reconstruction has been a good choice.
If a more stable (and diffusive) scheme was needed, Minmod
could have been used.
However, now the variants of the more recent 2ndorder ``Frankenstein's Method''
are better choices,
if the additional computational cost is acceptable.
Even if it is not strictly monotonic, the FRweno2
scheme
seems to be a good general default for pureHD models computed with the Roe solver.
The PP
reconstruction gives the highest accuracy.
However, there is the possibility that it produces somewhat ``noisy'' models with small wiggles
e.g. in the velocity for extreme cases  solar models look fine with PP
.
The newest options are HBweno
and VAweno
,
which are closer to standard WENO schemes.
Constant
, SuperBee
, and FRcont
are just for testing purposes:
they have either too much, sometimes the wrong sign of, or too little diffusion, respectively.
Constant
)
MinMod
FRmimo
, PPmimo
, vanLeer
FRmono
FRweno
, HBweno
, (Superbee
)
PP
, VAweno
FRcont
).
vanLeer
uses (potentially dangerous) antidiffusion (in contrast to MinMod
)
but needs only a 3point stencil,
whereas PPmimo
and FRmimo
don't have antidiffusion but need a (more expensive)
5point stencil.
FRweno
achieves actually a 2ndorderaccurate reconstruction
also near extrema for reasonably resolved structures (e.g., sufficiently
long wavelengths of sine waves). I.e., it gives up strict monotonicity,
whereas PP
is strictly monotonic and achieves low dissipation from avoiding jumps
at cell boundaries wherever possible. However, it chops off (flattens) extrema
like all TVD schemes and it shows Gibbs wiggles near a jump that is not surrounded
by constant plateaus but lies in a slope. The 2ndorder scheme FRmono
is designed to suppress these wiggles, too.
The highestresolution schemes are PP
(implemented in the MHD module, too)
and VAweno
(HD module only).
0.0
is the default for RungeKuttatype time integration.
The others use 0.5
.
However, a larger value (the maximum is 1.0
) leads to damping
of oscillations in a stratified atmosphere.
This is due to the fact that in a ``normally stratified'' atmosphere 
where the density increases with depth  the density in any given grid cell
usually increases with time during an upward motion (of course, the divergence
of the flow field plays a role, too). Using the density for the
computation of the downwarddirected gravitational acceleration at a slightly
later time increases this value leading to a stronger decceleration of the upward motion.
This works analogously for downward motions.
The parameter is recognized by the HD and the MHD module.
n_hyditer
iterations will (probably) needed.
The parameter can be set e.g. with
1
.
E.g. for brown dwarfs with shorter hydrodynamical time scales
values around 10
may be considered.
Note, that the hydrodynamics iteration works somewhat differently than
the radiation transport iteration:
in the latter case the size of the actual time step can be determined after
computing the fluxes,
whereas the hydrodynamics step is (possibly) of at least second order in time
and the time step has to be known in advance.
In the case of the MHD module, this can reduce the computation time significantly because
the MHD time step is often much smaller than the other timestep limits.
However, this parameter does not determine the nuber of
substeps directly. Instead, the number of substeps is determined by the
requested timestep and the timestep of each MHD substep which is determined by
the standart Courant condition. So, the number of MHD substeps varies during
the simulation. So, the exact value of this parameter has no direct influence
on the number of substeps. If this parameter is set to zero, this features
is turned of. (See also parameter va_max
for speeding up MHD simulations.)
n_hydmaxiter
will either be set to a value somewhat larger
than the recommended number of iterations (n_hyditer
)
or to 0
which disables the check for too many iterations completely.
This can be safely allowed in many cases.
To disable the iteration of the hydrodynamics substep set
n_hyditer
=0
.
In case of the MHD module, this parameter sets the maximum number of MHDsubsteps. If this parameter is set to zero, the number of MHD substeps is not limited.
Keep
: Keep the large temporary structures until the end of the program.
This requires somewhat more memory (which during normal CO5BOLD runs is of no concern)
but can improve the performance slightly, because particulary the deallocation of
large arrays costs time
(new, default).
Delete
: Delete the large temporary structures immediately after they
have been used. This mode can be chosen if memory is a problem
(old).
1200
: Intel Xeon processor
2500
: Intel Pentium III or Core 2 Duo processor
20000
: RISC processor
100000
: Vector machine