namespace: castro
AMR
parameter |
description |
default value |
---|---|---|
|
highest order used in interpolation |
1 |
|
how to do limiting of the state data when interpolating 0: only prevent new extrema 1: preserve linear combinations of state variables 2: preserve linear combinations and prevent new extrema |
0 |
|
do we do the hyperbolic reflux at coarse-fine interfaces? |
1 |
|
whether to re-compute new-time source terms after a reflux Note: this only works for the CTU and simple-SDC time_integration_method drivers |
1 |
|
Castro was originally written assuming dx = dy = dz. This assumption is enforced at runtime. Setting allow_non_unit_aspect_zones = 1 opts out. |
0 |
hydrodynamics
parameter |
description |
default value |
---|---|---|
|
the coefficient of the artificial viscosity |
0.1 |
|
the small density cutoff. Densities below this value will be reset |
-1.e200 |
|
the small temperature cutoff. Temperatures below this value will be reset |
-1.e200 |
|
the small pressure cutoff. Pressures below this value will be reset |
-1.e200 |
|
the small specific internal energy cutoff. Internal energies below this value will be reset |
-1.e200 |
|
permits hydro to be turned on and off for running pure rad problems |
true |
|
how do we advance in time? 0 = CTU + Strang, 1 is not used, 2 = SDC, 3 = simplified-SDC |
0 |
|
do we use a limiter with the fourth-order accurate reconstruction? |
1 |
|
for fourth order, we usually assume that the initialization is done to cell centers and we convert to cell-averages. With this option, we take the initialization as cell- averages (except for T, which we compute to fourth-order through the EOS after initialization). |
0 |
|
should we use a reconstructed version of Gamma_1 in the Riemann solver? or the default zone average (requires SDC integration, since we do not trace) |
0 |
|
if true, define an additional source term |
0 |
|
whether to use the hybrid advection scheme that updates z-angular momentum, cylindrical momentum, and azimuthal momentum (3D only) |
0 |
|
reconstruction type: 0: piecewise linear; 1: classic Colella & Woodward ppm; |
1 |
|
do we limit the ppm parabola? |
1 |
|
For MHD + PLM, do we limit on characteristic or primitive variables |
1 |
|
various methods of giving temperature a larger role in the reconstruction—see Zingale & Katz 2015 |
0 |
|
for piecewise linear, reconstruction order to use 1 = piecewise constant, 2 = piecewise linear |
2 |
|
for piecewise linear, what limiter to use? 1 = 2nd order MC, 2 = 4th order MC |
2 |
|
do we drop from our regular Riemann solver to HLL when we are in shocks to avoid the odd-even decoupling instability? |
0 |
|
which Riemann solver do we use: 0: Colella, Glaz, & Ferguson (a two-shock solver); 1: Colella & Glaz (a two- shock solver) 2: HLLC |
0 |
|
maximum number of iterations to used in the Riemann solver when solving for the star state |
12 |
|
tolerance to use when finding the star stat |
1.0e-5 |
|
for the Colella & Glaz Riemann solver, what to do if we do not converge to a solution for the star state. 0 = do nothing; print iterations and exit 1 = revert to the original guess for p-star 2 = do a bisection search for another 2 * riemann_shock_maxiter iterations. |
2 |
|
flatten the reconstructed profiles around shocks to prevent them from becoming too thin |
1 |
|
after we add the transverse correction to the interface states, replace the predicted pressure with an EOS call (using \(e\) and \(\rho\)). |
0 |
|
if the transverse interface state correction, if the new density is negative, then replace all of the interface quantities with their values without the transverse correction. |
1 |
|
if the interface state for \((\rho e)\) is negative after we add the transverse terms, then replace the interface value of \((\rho e)\) with a value constructed from the \((\rho e)\) evolution equation |
0 |
|
Threshold value of (E - K) / E such that above eta1, the hydrodynamic pressure is derived from E - K; otherwise, we use the internal energy variable UEINT. |
1.0e0 |
|
Threshold value of (E - K) / E such that above eta2, we update the internal energy variable UEINT to match E - K. Below this, UEINT remains unchanged. |
1.0e-4 |
|
for the piecewise linear reconstruction, do we subtract off \((\rho g)\) from the pressure before limiting? This is a well-balanced method that does well with HSE |
0 |
|
for PPM, do we only use the perturbational pressure in the characteristic tracing? This is more indepth than the simple use_pslope approach. |
0 |
|
if we are using pslope, below what density to we turn off the well-balanced reconstruction? |
-1.e20 |
|
Should we limit the density fluxes so that we do not create small densities? |
0 |
|
Enforce the magnitude of the velocity to be no larger than this number (and optionally limit the fluxes as well). Only applies if it is greater than 0. |
0.0 |
|
permits sponge to be turned on and off |
0 |
|
if we are using the sponge, whether to use the implicit solve for it |
1 |
|
if we are using user-defined source terms, are these solved implicitly? |
0 |
|
extrapolate the source terms (gravity and rotation) to \(n+1/2\) timelevel for use in the interface state prediction |
0 |
|
set the flattening parameter to zero to force the reconstructed profiles to be flat, resulting in a first- order method |
0 |
|
if we are doing an external -x boundary condition, who do we interpret it? 1 = HSE |
-1 |
|
if we are doing an external +x boundary condition, who do we interpret it? 1 = HSE |
-1 |
|
if we are doing an external -y boundary condition, who do we interpret it? 1 = HSE |
-1 |
|
if we are doing an external +y boundary condition, who do we interpret it? 1 = HSE |
-1 |
|
if we are doing an external -z boundary condition, who do we interpret it? 1 = HSE |
-1 |
|
if we are doing an external +z boundary condition, who do we interpret it? 1 = HSE |
-1 |
|
if we are doing HSE boundary conditions, do we zero the velocity? |
0 |
|
if we are doing HSE boundary conditions, should we get the temperature via interpolation (constant gradient) or hold it constant? |
0 |
|
if we are doing HSE boundary conditions and holding the temperature constant, then set it to a fixed value at the boundaries (only if positive) |
-1.e200 |
|
if we are doing HSE boundary conditions, how do we treat the velocity? reflect? or outflow? |
0 |
|
fills physical domain boundaries with the ambient state |
0 |
|
which direction do we do ambient BCs? -1 = all, 0 = x, 1 = y, 2 = z |
-1 |
|
in the ambient region, do we do a basic outflow in the normal direction of the velocity (with a min/max to ensure it is outgoing) |
0 |
|
clamps the ambient material to the ambient temperature |
0 |
|
specifies the upper limit, as a multiple of the ambient density, for operations that are applied to ambient material, such as clamping T. |
1.1e0 |
|
density of the ambient material (should default to the same as small_dens) |
-1.e200 |
|
temperature of the ambient material (should default to the same as small_temp) |
-1.e200 |
|
energy of the ambient material (should default to the same as small_ener) |
-1.e200 |
|
integration order for SDC integration valid options are 2 and 4 |
2 |
|
which quadrature type to use with SDC? 0 = Gauss-Lobatto, 1 = Radau |
0 |
|
number of extra SDC iterations to take beyond the order. This only applies for true SDC. |
0 |
|
which SDC nonlinear solver to use? 1 = Newton, 2 = VODE, 3 = VODE for first iter |
1 |
|
Do we include geometry source terms due to local unit vectors in non-Cartesian Coord? We currently support R-Z cylinderical 2D (Bernand-Champmartin) and R-THETA spherical 2D |
1 |
|
for simplified-SDC, do we add the reactive source prediction to the interface states used in the advective source construction? |
1 |
|
In GPU builds, the hydro advance typically results in a large amount of extra temporary memory allocated due to the large tile sizes that are used for computational efficiency. If you want to constrain the code’s GPU memory footprint at the expense of throughput, set the following parameter to some number greater than 0. This controls the ratio of additional extra memory that can be allocated by the hydro relative to the size of the base state (indirectly, by controlling the hydro tile size and then synchronizing each time the amount of currently allocated fab memory reaches the target limit). Choosing a value only slightly larger than 0 means that you want very little additional memory allocated, and you will take a relatively large performance hit, while choosing a value much greater than 1.0 would result in maximum throughput but also maximum memory footprint. You will likely have to experimentally find a good ratio for your use case, but a ratio around 2.0 - 4.0 is likely to yield a reasonable balance between memory footprint and throughput. Note: the first timestep will be very slow when using this option. |
-1.0 |
timestep control
parameter |
description |
default value |
---|---|---|
|
a fixed timestep to use for all steps (negative turns it off) |
-1.0 |
|
the initial timestep (negative uses the step returned from the timestep constraints) |
-1.0 |
|
the smallest valid timestep, as a fraction of the current simulation time. if we go below this, we abort. |
1.e-12 |
|
the largest valid timestep—limit all timesteps to be no larger than this |
1.e200 |
|
the effective Courant number to use—we will not allow the hydrodynamic waves to cross more than this fraction of a zone over a single timestep |
0.8 |
|
a factor by which to reduce the first timestep from that requested by the timestep estimators |
1.0 |
|
the maximum factor by which the timestep can increase or decrease from one step to the next. Must be greater than 1.0—use max_dt to set a cap on the timestep. |
1.1 |
|
whether to check that we will take a valid timestep before the advance |
1 |
|
whether to check that we took a valid timestep after the advance |
1 |
|
enforce that the AMR plot interval must be hit exactly |
0 |
|
enforce that the AMR small plot interval must be hit exactly |
0 |
|
Retry a timestep if it violated the timestep-limiting criteria or other checks (negative density, burn failure) over the course of an advance. The criteria will suggest a new timestep that satisfies the criteria, and we will do subcycled timesteps on the same level until we reach the original target time. |
1 |
|
When performing a retry, the factor to multiply the current timestep by when trying again. |
0.5 |
|
Skip retries for small (or negative) density if the zone’s density prior to the update was below this threshold. |
-1.e200 |
|
Set the threshold for failing the species abundance validity check. |
1.e-2 |
|
Do not abort for invalid species abundances if the zone’s density is below this threshold. |
-1.e200 |
|
Regrid after every timestep. |
0 |
|
Do not permit more subcycled timesteps than this parameter. Set to a negative value to disable this criterion. |
10 |
|
Number of iterations for the simplified SDC advance. |
2 |
|
Field to use for determining whether to stop the simulation. |
“” |
|
Threshold value for determining whether to stop. |
1.e200 |
reactions
parameter |
description |
default value |
---|---|---|
|
Limit the timestep based on how much the burning can change
the internal energy of a zone. The timestep is equal to
|
1.e200 |
|
Limit the timestep based on how much the burning can change
the species mass fractions of a zone. The timestep is equal
to |
1.e200 |
|
If we are using the timestep limiter based on changes in \(X\), set a threshold on the species abundance below which the limiter is not applied. This helps prevent the timestep from becoming very small due to changes in trace species. |
1.e-3 |
|
permits reactions to be turned on and off – mostly for efficiency’s sake |
true |
|
minimum temperature for allowing reactions to occur in a zone |
0.0 |
|
maximum temperature for allowing reactions to occur in a zone |
1.e200 |
|
minimum density for allowing reactions to occur in a zone |
0.0 |
|
maximum density for allowing reactions to occur in a zone |
1.e200 |
|
disable burning inside hydrodynamic shock regions note: requires compiling with USE_SHOCK_VAR=TRUE |
0 |
|
shock detection threshold for grad{P} / P |
0.6666666666666666666666_rt |
|
do we subtract off the hydrostatic pressure when evaluating a shock? |
1 |
|
initial guess for the temperature when inverting the EoS (e.g. when calling eos_input_re) |
1.e8 |
|
if set to 1, we interpolate from the initial model to get the temperature used to call the burner. This prevents reactions from going nonlinear and running away in place before a convective field is established. |
0 |
|
maximum time over which to do the drive_initial_convection procedure |
1.e200 |
|
frequency with which to re-initialize the thermodynamic data while preserving the velocity field during drive_initial_convection |
1.e200 |
diffusion
parameter |
description |
default value |
---|---|---|
|
enable thermal diffusion |
0 |
|
set a cutoff density for diffusion – we zero the term out below this density |
-1.e200 |
|
secondary cutoff density – there will be a linear dropoff in the diffusion coefficient between this and the primary cutoff density. This should be the larger of the two |
-1.e200 |
|
scaling factor for conductivity |
1.0 |
gravity and rotation
parameter |
description |
default value |
---|---|---|
|
permits gravity calculation to be turned on and off |
true |
|
to we recompute the center used for the multipole gravity solve each step? |
0 |
|
determines how the gravitational source term is added to the momentum and energy state variables. |
4 |
|
permits rotation calculation to be turned on and off |
true |
|
the rotation period for the corotating frame |
-1.e200 |
|
permits the centrifugal terms in the rotation to be turned on and off |
1 |
|
permits the Coriolis terms in the rotation to be turned on and off |
1 |
|
determines how the rotation source terms are added to the momentum and energy equations |
4 |
|
we can do a implicit solution of the rotation update to allow for better coupling of the Coriolis terms |
1 |
|
the coordinate axis for the rotation vector For Cartesian: (\(x=1\), \(y=2\), \(z=3\)) For non-Cartesian coordinates, this parameter doesn’t do anything because: For RZ (Cylindrical 2D), it is automatically set to z-axis (rot_axis = 2) For Spherical2D, it is also assumed to be in the z-axis i.e. cos(theta) r_hat - sin(theta) theta_hat in Spherical coordinate. |
3 |
|
include a central point mass |
0 |
|
mass of the point mass |
0.0 |
|
if we have a central point mass, we can prevent mass from building up in the zones adjacent to it by keeping their density constant and adding their mass to the point mass object |
0 |
|
Distance (in kpc) used for calculation of the gravitational wave amplitude (this will be calculated along all three coordinate axes). Only relevant if castro.sum_interval > 0 and if set to a positive number. A standard value in the literature is 10.0 (kpc). |
0.0 |
|
This integer is used to activate parallel plane 1/r**2 gravity. |
0 |
|
0.0 |
sponge
parameter |
description |
default value |
---|---|---|
|
Minimum simulation distance from center to start applying the sponge |
-1.0 |
|
Simulation distance from the center at which the sponge is fully applied |
-1.0 |
|
Minimum density at which to start applying the sponge |
-1.0 |
|
Density at which the sponge is fully applied |
-1.0 |
|
Minimum pressure at which to start applying the sponge |
-1.0 |
|
Pressure at which the sponge is fully applied |
-1.0 |
|
Scaling factor for the sponge below the low end |
0.0 |
|
Scaling factor for the sponge above the high end |
1.0 |
|
Target x-velocity for the sponge to drive to |
0.0 |
|
Target y-velocity for the sponge to drive to |
0.0 |
|
Target z-velocity for the sponge to drive to |
0.0 |
|
Timescale on which the sponge operates |
-1.0 |
parallelization
parameter |
description |
default value |
---|---|---|
|
1 |
embiggening
parameter |
description |
default value |
---|---|---|
|
the factor by which to extend the domain upon restart for embiggening |
1 |
|
used with the embiggening routines to determine how to extend the domain |
true |
self-consistent field initialization
parameter |
description |
default value |
---|---|---|
|
Should we use SCF to construct the initial model? |
0 |
|
Maximum density on the domain when using SCF |
-1.e6 |
|
Equatorial and polar radii of the star constructed by SCF |
-1.e9 |
|
-1.e9 |
|
|
SCF relaxation tolerance |
1.e-3 |
|
Maximum number of SCF iterations |
30 |
refinement
parameter |
description |
default value |
---|---|---|
|
0 |
|
|
Maximum radius from the center (in units of the domain width) where tagging is allowed. The default choice implies no restriction. |
10.0e0 |
diagnostics, I/O
parameter |
description |
default value |
---|---|---|
|
verbosity level (higher numbers mean more output) |
0 |
|
do we dump the old state into the checkpoint files too? |
0 |
|
do we assume the domain is plane parallel when computing some of the derived quantities (e.g. radial velocity). Note: this will always assume that the last spatial dimension is vertical |
0 |
|
display information about updates to the state (how much mass, momentum, energy added) |
(0, 1) |
|
how often (number of coarse timesteps) to compute integral sums (for runtime diagnostics) |
-1 |
|
how often (simulation time) to compute integral sums (for runtime diagnostics) |
-1.0e0 |
|
a string describing the simulation that will be copied into
the plotfile’s |
“Castro” |
|
write a final plotfile and checkpoint upon completion |
1 |
|
Do we want to reset the time in the checkpoint? This ONLY takes effect if amr.regrid_on_restart = 1 and amr.checkpoint_on_restart = 1, (which require that max_step and stop_time be less than the value in the checkpoint) and you set it to value greater than this default value. |
-1.e200 |
|
Do we want to reset the number of steps in the checkpoint? This ONLY takes effect if amr.regrid_on_restart = 1 and amr.checkpoint_on_restart = 1, (which require that max_step and stop_time be less than the value in the checkpoint) and you set it to value greater than this default value. |
-1 |
|
Do we store the species creation rates in the plotfile? Note, if this option is enabled then more memory will be allocated to hold the results of the burn |
0 |
|
Do we store the burn weights as a diagnostic in the plotfile? Note, if this option is enabled then more memory will be allocated to hold the results of the burn |
0 |
|
Do we abort the run if the inputs file specifies a runtime parameter that we don’t know about? Note: this will only take effect for those namespaces where 100% of the runtime parameters are managed by the python scripts. |
0 |
radiation-hydro
parameter |
description |
default value |
---|---|---|
|
do we enable radiation for a radiation-hydrodynamics run? |
true |
particles
parameter |
description |
default value |
---|---|---|
|
permits tracer particle calculation to be turned on and off |
0 |
namespace: diffusion
parameter |
description |
default value |
---|---|---|
|
the level of verbosity for the diffusion solve (higher number means more output) |
0 |
|
Use MLMG as the operator |
4 |
namespace: gravity
parameter |
description |
default value |
---|---|---|
|
what type |
“fillme” |
|
if doing constant gravity, what is the acceleration |
0.0 |
|
Check if the user wants to compute the boundary conditions using the brute force method. Default is false, since this method is slow. |
0 |
|
ratio of dr for monopole gravity binning to grid resolution |
1 |
|
the maximum mulitpole order to use for multipole BCs when doing Poisson gravity |
0 |
|
the level of verbosity for the gravity solve (higher number means more output on the status of the solve / multigrid |
0 |
|
do we perform the synchronization at coarse-fine interfaces? |
0 |
|
should we apply a lagged correction to the potential that gets us closer to the composite solution? This makes the resulting fine grid calculation slightly more accurate, at the cost of an additional Poisson solve per timestep. |
1 |
|
For all gravity types, we can choose a maximum level for explicitly calculating the gravity and associated potential. Above that level, we interpolate from coarser levels. |
MAX_LEV-1 |
|
For non-Poisson gravity, do we want to construct the gravitational acceleration by taking the gradient of the potential, rather than constructing it directly? |
0 |
|
how many FMG cycles? |
0 |
|
Do agglomeration? |
1 |
|
1 |
|
|
Do N-Solve? |
0 |
namespace: particles
parameter |
description |
default value |
---|---|---|
|
the level of verbosity for the tracer particle (0 or 1) |
0 |
|
the name of an input file containing the total particle number and the initial position of each particle. |
“” |
|
the name of a file with new particles at restart |
“” |
|
to restart from a checkpoint that was written with
|
0 |
|
the name of timestamp files. |
“” |
|
the name of a directory in which timestamp files are stored. |
“” |
|
whether the local densities at given positions of particles are stored in output files |
1 |
|
whether the local temperatures at given positions of particles are stored in output files |
0 |
namespace: radiation
parameter |
description |
default value |
---|---|---|
|
0.0 |
|
|
-1.0 |
|
|
are we in a comoving reference frame? |
1 |
|
which closure relation to use 0: f = lambda 1: f = 1/3 2: f = 1 - 2 * lambda 3: f = lambda + (lambda * R)^2 4: f = 1/3 + 2/3 (lambda * R)^2 |
3 |
|
which limiter to use 0: no limiter 2: Lev-Pom limiter 12: Bruenn 22: square root 32: Minerbo |
2 |
|
frequency space advection type |
2 |
|
do we plot the flux limiter lambda? |
0 |
|
do we plot the Planck mean opacity? |
0 |
|
do we plot the Rosseland mean opacity? |
0 |
|
do we plot the lab radiation energy? |
0 |
|
do we plot the lab radiation flux? |
0 |
|
do we plot the comoving frame radiation flux? |
0 |
namespace: radsolve
parameter |
description |
default value |
---|---|---|
|
the linear solver option to use |
1 |
|
0 |
|
|
1.e-10 |
|
|
1.e-10 |
|
|
40 |
|
|
1.0 |
|
|
1.0 |
|
|
0 |