# Enzo-E / Cello Parameters¶

This page documents all current parameters implemented in Enzo-E / Cello. Each parameter is summarized, its type or types are listed, and the default value (if any) is provided. The scope of the parameter is also listed, which is either “Cello” or “Enzo”, depending on whether the parameter is associated with Cello framework or Enzo-E application. Any assumptions associated with a parameter are also listed; for example, a parameter may only be valid if some other parameter is set to a certain value.

If you find any errors in the documentation, or have any specific suggestions, please contact the Enzo Project developers at github.

Adapt parameters define how the mesh hierarchy dynamically adapts to the solution. It is closely related to the Mesh parameters, which defines the root grid size, number of blocks in the root grid, and size of blocks.

Parameter: Adapt : interval Number of cycles between adapt steps integer 1 Cello

The interval parameter is used to set the number of root-level cycles between mesh adaptation. The default is 1.

Parameter: Adapt : max_level Maximum level in the adaptive mesh hierarchy integer 0 Cello

This parameter specifies the level of the most highly refined Block in the mesh hierarchy. The default is 0, meaning there is no refinement past the initial root-level grid.

Parameter: Adapt : min_level Minimum level in the adaptive mesh hierarchy integer 0 Cello

This parameter specifies the coarsest level of “sub-root” Blocks, and must non-positive. This is used primarily for multigrid methods, such as in the “mg0” solver. The default is 0, meaning no sub-root Blocks are created. If multigrid is used, then both Adapt : min_level and Method : <mg-solver> : min_level must be set..

Parameter: Adapt : list List of refinement criteria list ( string ) [] Cello

List of mesh refinement criteria, each of which has its own associated Adapt : <criteria> : parameters. When multiple criteria are used, if all refinement criteria evaluate to “coarsen”, then the block will be tagged to coarsen; if any refinement criteria evaluate as “refine”, then the block will be tagged to refine. (Note that a particular block will coarsen only if it and all other sibling blocks are tagged to coarsen as well.)

The items in the list need not be the same as the (required) Adapt : <criterion> : type parameter; they are solely used to identify and distinguish between different criteria in the simulation. This allows the user to use multiple criteria of the same type but with different parameters, e.g. “mask” with different masks:

Adapt {
list = ["criterion_1", "criterion_2"];
criterion_1 {
type = "shock";
}
criterion_2 {
type = "shear";
}
}


Parameter: Adapt : min_face_rank Minimum rank of Block faces to check for 2:1 refinement restriction integer 0 Cello

Many numerical methods require a 2:1 refinement restriction on adaptive meshes, such that no Block in level i is adjacent to another Block in a level j with |i - j|>1. This assumption may be required across corners and edges as well as 2D faces. This parameter specifies the minimum rank (dimensionality) of Block faces across which to enforce the 2:1 refinement restriction.

Parameter: Adapt : : field_list List of field the refinement criterion is applied to [ string | list ( string ) ] [] ( all fields ) Cello

This parameter specifies the fields that the refinement criteria is applied to. For example, if type = “slope” and field_list = [“density”], then the “refine by slope” refinement criterion is applied to the density field.

Parameter: Adapt : : level_exponent Level exponent parameter float 0.0 Cello is of type “mass”

The level exponent parameter is used in the “mass” refinement criterion type only. It is used as a scaling factor for the refinement criteria for different mesh levels.

Parameter: Adapt : : max_coarsen Cutoff value for coarsening a block [ float | list ( float ) ] 0.5*min_refine Cello

A block may coarsen if the refinement criterion applied to the block is smaller than this value everywhere in the block. A list is used for the “shock” refinement criterion type, in which case the first value is for pressure and the second is for the energy ratio.

Parameter: Adapt : : include_ghosts Whether to include ghost zones when applying the refinement criterion logical false Cello

When applying a mesh refinement criterion, this parameter specifies whether to apply it to ghost zones in the block as well as non-ghost zones.

Parameter: Adapt : : min_refine Cutoff value for refining a block [ float | list ( float ) ] 0.3 Cello

A block must refine if the refinement criterion applied to the block is larger than this value anywhere in the block. A list is used for the “shock” refinement criterion type, in which case the first value is for pressure and the second is for the energy ratio.

Parameter: Adapt : : output Name of a field in which to store the result of the refinement criterion string “” Cello

In addition to evolved field values, one may also output the refinement criteria. This may be useful for example for debugging or for finding appropriate values for :p:max_coarsen and min_refine. A value of -1 specifies coarsening, +1 for refining, and 0 for staying the same.

Parameter: Adapt : : max_level Maximum level to refine using this refinement criterion integer max (integer) Cello

Adapt will not refine past max_level when using this refinement criterion. Note if the global Adapt:max_level is smaller, than that takes precidence; also, another criterion may refine past this if both Adapt:max_level and Adapt : <criterion> : max_level for the other criterion are both larger.

Parameter: Adapt : : type Type of mesh refinement criteria string “unknown” Cello

Type of mesh refinement criteria. This is a required parameter, and must be one of “slope”, “shear”, “mask”, “mass”, “density”, “shock”, “particle_mass”, or “particle_count”.

## Balance¶

Parameters for controlling dynamic load balancing are enclosed within the Balance group. Currently only one Balance parameter is available, which is used to control how frequently load balancing is performed.

Parameter: Balance : schedule Scheduling parameters for dynamic load balancing subgroup none Cello

See the schedule subgroup for parameters used to define when to trigger the dynamic load balancing operation.

## Boundary¶

Boundary group parameters define boundary conditions. For simple (non-mixed) boundary conditions, only the type parameter is required, e.g. Boundary { type = “periodic”; }. For more complicated boundary conditions, the list parameter is used to define Boundary subgroups, where each subgroup specifies boundary conditions for some subset of the domain. The axis and face parameters are available to restrict boundary conditions to a subset of faces, whereas the mask parameter is available for even finer control of mixed boundary conditions, which may be time-dependent. Inflow boundary conditions use the value parameter to specify field values at the boundary.

Parameter: Boundary : list List of boundary condition subgroups [ string | list ( string ) ] [] Cello

For mixed boundary conditions, the list parameter specifies the list of names of subgroups that define boundary conditions on each portion of the domain boundary. Boundary conditions in each subgroup are applied in the order listed. In the example below, two subgroups “one” and “two” are defined, which specify reflecting boundary conditions along the x-axis and outflow boundary conditions along the y-axis:

Boundary {
list = ["one", "two"];
one {
type = "reflecting";
axis = "x";
}
two {
type = "outflow";
axis = "y";
}
}


Parameter: Boundary : : type Type of boundary condition string “undefined” Cello

Boundary conditions in Enzo-E include “reflecting” , “outflow” , “inflow” , and “periodic”. Other boundary condition types can be implemented by either a) modifying the existing EnzoBoundary class or b) creating a new class inherited from the Boundary base class. “inflow” boundary conditions additionally require value and field_list parameters.

Parameter: Boundary : : axis Axis along which boundary conditions are to be enforced string “all” Cello

The axis parameter restricts the boundary conditions to the face orthogonal to the specified axis. axis must be “x” , “y” , “z” or “all”. The axis parameter may be used in conjunction with the face parameter, or by itself.

Parameter: Boundary : : face Face along which boundary conditions are to be enforced string “all” Cello

The face parameter can restrict the boundary conditions to be applied only to the upper or lower faces. face orthogonal to the given face. face must be “upper” , “lower” or “all”. The face parameter may be used in conjunction with the axis parameter, or by itself.

Parameter: Boundary : : mask Subregion in which boundary conditions are to be enforced logical-expr none Cello

The mask parameter specifies the subregion of the boundary on which to apply the boundary conditions. The logical expression may be a function of x, y, z, and t, and boundary conditions are restricted to where (and when) it evaluates to true:

Boundary {
...
OUT {
type = "outflow";
mask = (x >= 4.0) ||
(y >= 1.0 && (x >= 0.744017 + 11.547* t));
}
}


Parameter: Boundary : : value Value for inflow boundary conditions float float-expr list ( float-expr [, logical-expr, float-expr [, … ] ] ) [] Cello

The value parameter is used to specify field values for inflow type boundary conditions. The value parameter is used in conjunction with the field_list parameter. value may be of type float, float-expr, or a list of alternating float-expr and logical-expr types. float-expr may be a function of x, y, z, and t. When a list is specified, the logical-expr is treated as a mask, similar to an ‘if-then-else’ clause

Boundary {
...
VELOCITY_Y {
type = "inflow";
field_list = "velocity_y";
value = [ -8.25*0.5,
((x <= 0.166667) && (y <= 0.0) ) ||
(x <= 0.0) ||
((x < 0.744017 + 11.547*t) && (y >= 1.0))
];
}
}


Parameter: Boundary : : field_list List of fields to apply boundary conditions to list ( string ) [] Cello

The field_list parameter is used to restrict boundary conditions to the specified fields. An empty list, which is the default, is used to specify all fields.

## Domain¶

Domain parameters specify the lower and upper extents of the computational domain, using the lower and upper parameters.

Parameter: Domain : lower Lower domain extent list ( float ) [0.0, 0.0, 0.0] Cello

Lower extent of the computational domain, [xmin], [ xmin, ymin], or [ xmin, ymin, zmin].

Parameter: Domain : upper Upper domain extent list ( float ) [1.0, 1.0, 1.0] Cello

Upper extent of the computational domain, [xmax], [ xmax, ymax], or [ xmax, ymax, zmax].

## Field¶

Fields and their properties are defined using the Field parameter group. All fields must be explicitly defined using the list Field parameter, and must match the names expected by the respective Methods. Properties include the number of ghost zones, precision, and whether a field is centered or lies on some face, edge, or corner. Some performance-related parameters are available as well, including alignment in memory, and memory padding between fields.

Parameter: Field : list List of fields list ( string ) [] Cello

All fields must be explicitly listed in the list parameter. Field names depend on the Method(s) used; e.g., PPM uses “density”, “velocity_x”, “velocity_y”, “total_energy”, and “internal_energy”.

Parameter: Field : gamma Adiabatic exponent float 5.0 / 3.0 Enzo perhaps move this to a different group, e.g. Physics

gamma specifies the ratio of specific heats for the ideal gas used by the PPM hydrodynamics solver.

Parameter: Field : alignment Force field data on each block to start on alignment bytes integer 8 Cello

Depending on the computer architecture, variables can be accessed from memory faster if they have at least 4-byte or 8-byte alignment. This parameter forces each field block array to have an address evenly divisible by the specified number of bytes.

Parameter: Field : : centering Specify the position of the given field variable within the computational cell. list ( logical ) [ true, true, true ] Cello

By default, variables are centered within a computational cell. Some methods expect some variable, e.g. velocity components, to be positioned on a cell face. The effect of this parameter is to increase the dimension of the field block by one along each axis with a value of “false”. Numerical method implementations like PPML that assume (NX,NY,NZ) sized blocks even for offset variables, as opposed to e.g. (NX+1,NY,NZ), should still define the variable as centered.

Parameter: Field : : group_list Specify a list of groups that the Field belongs to list ( string ) [ ] Cello

Different Fields may belong to any number of different “groups”. For example, Enzo uses “color fields”, which Enzo-E implements as defining color fields to belong to the group “color”.

Parameter: Field : ghost_depth Field ghost zone depths [ integer | list ( integer ) ] [ 0, 0, 0 ] Cello

The default storage patch / block ghost zone depths [gx, gy, gz] along each axis for fields. If an integer, then the same ghost zone depth is used for each axis. Currently this value needs to be 4 for PPM when AMR is used.

Parameter: Field : padding Add padding of the specified number of bytes between fields on each block. integer 0 Cello

If block sizes are large and a power of two, and if the computer’s cache has low associativity, performance can suffer due to cache thrashing. This can be avoided by introducing padding between fields. A value of twice the cache line width is recommended. Since field blocks are usually small, this should not usually be an issue.

Parameter: Field : precision Default field precision string “default” Cello

Default precision for all fields. Supported precisions include “single” (32-bit) and “double” (64-bit). “quadruple” is accepted, but not implemented by most numerical methods (e.g. PPM). “default” is for compatibility with Enzo, and corresponds to either “single” or “double” depending on the CELLO_PREC configuration flag setting. This precision parameter must not conflict with the CELLO_PREC setting.

Parameter: Field : prolong Type of prolongation (interpolation) string “linear” Cello

For adaptive mesh refinement, field values may need to be transferred from coarser to finer blocks, either from coarse neighbor blocks in the refresh phase, or to fine child blocks during refinement in the adapt phase. Valid values include “linear” ; other values accepted but not implemented include “enzo” and “MC1” :e: ; which are unfinished implementations of Enzo’s “InterpolationMethod” functionality.

Parameter: Field : restrict Type of restriction (coarsening) string “linear” Cello

For adaptive mesh refinement, field values may need to be transferred from finer to coarser blocks, either from fine neighbor blocks in the refresh phase, or to the parent block during coarsening in the adapt phase. Valid values include “linear” ; ;other values accepted but not implemented include “enzo”.

Parameter: Field : history How many generations of “old” fields to maintain integer 0 Cello

Many problems may require field values from the previous timestep, e.g. for flux-correction, updating particles, etc. Cello supports this by allowing one or more generations of all fields to be stored and maintained. The default is 0, though 1 may be fairly common, and even more generations are supported if needed.

## Group¶

The Group parameter group is used to differentiate between different types of Field’s and Particles. For example, field groups may include “color” and “temporary”, and particle groups may include “dark_matter” and “star”.

Group {

list = ["color", "temporary"];

color {
field_list = ["species_HI", "species_HII" ];
}

temporary {
field_list = ["pressure", "temperature"];
}

}


Field and Particle groups can analogously be defined in the respective Field and Particle parameter groups:

Field {

list = ["density", "velocity_x", "species_HI"];

species_HI {

group_list = ["temporary"];

}

}


Groups allow Cello applications to differentiate between these different types of fields and particles using the Grouping class (see src/Cello/data_Grouping.?pp).

Parameter: Group : list List of groups list ( string ) [] Cello

This parameter defines all groups.

Parameter: Group : : field_list List of fields belonging to the group list ( string ) [] Cello

This parameter is used to assign fields to a given group.

Parameter: Group : : particle_list List of particle types belonging to the group list ( string ) [] Cello

This parameter is used to assign particle groups to a given group.

## Initial¶

The Initial group is used to specify initial conditions. cycle specifies the initial cycle number (usually 0), list specifies a list of initial conditions, which may include "value" for initializing fields directly, or other problem-specific initial condition generators.

Parameter: Initial : cycle Initial cycle number list ( integer ) 0 Cello

Initial value for the cycle number.

Parameter: Initial : time Initial time float 0.0 Cello

Initial time in code units.

### value¶

Parameter: Initial : value : : Initialize field values list ( float-expr, [ logical-expr, float-expr, [ … ] ] ) [] Cello

This initialization approach allows initializing field values directly. The first element of the list must be a float expression, and may include arithmetic operators, variables “x”, “y”, “z”, and most functions in the POSIX math library /include/math.h. The second optional list element is a logical expression, and serves as a “mask” of the domain. The third float expression parameter is required if a mask is supplied, and serves as the “else” case. Multiple such mask-value pairs may be used. For example:

Initial {

list = ["value"];

value {
density = [ sin ( x + y ), x - y < 0.0, 1.0 ];
}
}


is read as “Set the density field equal to sin ( x + y ) wherever x - y < 0.0 , otherwise set to 1.0 “.

### cloud¶

The cloud Initial subgroup is used to setup a Spherical cloud embedded in a hot wind. The cloud and wind are assumed to be in pressure equilibrium with one another.

The presence of (or lack thereof) the “bfield_x”, “bfield_y”, and “bfield_z” fields indicate whether the setup is purely hydrodynamic or involves magnetic fields. Presently, only uniform magnetic fields are supported if they are constant across the entire domain. The values of the magnetic fields are specified in one of 2 ways:

1. If the uniform_bfield parameter is passed a list of 3 floats, the first, second, and third entries are used to initilize the x, y, and z componentents of a uniform magnetic field. If the “bfieldi_x”, “bfieldi_y”, and “bfieldi_z” face-centered fields are defined, then they will be correctly initialized for use with the VL+CT integrator.
2. (Deprecated) If the uniform_bfield parameter is not specified (or is passed a list containing 0 entries), then the cell-centered magnetic fields are assumed to have been initialized by another Initial subgroup (e.g. value) prior to the call of this subgroup.

The initial density of a cell (from a uniform-resolution mesh) is initialized to $$f_{V} \rho_{\rm cl} \delta + (1 - f_{\rm V})\rho_{\rm w}$$, where $$f_{V}$$ is the fraction of the cell’s volume enclosed by the cloud (estimated by subsampling) and $$\delta$$ is nominally 1. Machinery is provided to optionally produce perturbations to break symmetries in the initial density distribution. When this machinery is used, $$\delta$$ is randomly drawn from a truncated Gaussian with $$\mu=1$$. Pressure equilibria is maintained when this machinery is used.

Parameter: Initial : cloud : subsample_n Determines the subsampling resolution integer 0 Enzo

Subsampling is used to initialize the fields in regions of overlap between the cloud and the wind. For cells in this region, the fraction of the volume enclosed by the cloud is estimated by subdividing a cell into $$2^n$$ subcells along each axis (a value of 0, corresponds to no subsampling. The average density of the cells in this region are volume weighted and the average velocities are mass weighted. The total energy in a cell is currently computed by assuming constant internal energy density throughout the grid and using the average velocities and densities (and, if applicable, the magnetic fields).

Parameter: Initial : cloud : cloud_radius Initial radius of the spherical cloud float none Enzo

This must be a positive value.

Parameter: Initial : cloud : cloud_center_x x coordinate of the cloud center float 0.0 Enzo

Parameter: Initial : cloud : cloud_center_y y coordinate of the cloud center float 0.0 Enzo

Parameter: Initial : cloud : cloud_center_z z coordinate of the cloud center float 0.0 Enzo

Parameter: Initial : cloud : cloud_density initial mass density of the cloud float none Enzo

This must be a positive value.

Parameter: Initial : cloud : metal_mass_frac initial fraction of the mass density contributed by metals float 0.0 Enzo

If the  ”metal_density_frac” field exists and is registered as a member of the  ”colour” group, then the field is initialized by multiplying this value by the "density" field (this is done everywhere, regardless of proximity to the cloud center). Under these circumstances, this must have a positive value.

Parameter: Initial : cloud : uniform_bfield initial uniform magnetic field values list ( float ) [ ] Enzo

If specified, provides the values of the components of the initial magnetic field that are uniform throughout the entire domain. When employed this MUST have 3 entries. This will also initialize the face-centered fields magnetic fields (in addition to the cell-centered fields) if the appropriate fields have been defined. When this is not specified (i.e., when this has a list of 0 entries), the magnetic fields are assumed to have been pre-initialized by a separate problem initializer prior to the execution of the cloud initializer.

Parameter: Initial : cloud : wind_density initial mass density of the wind float none Enzo

This must be a positive value.

Parameter: Initial : cloud : wind_velocity initial velocity of the wind along the x-axis float 0.0 Enzo

Parameter: Initial : cloud : wind_total_energy initial specific total energy of the wind float none Enzo

This must be a positive value.

Parameter: Initial : cloud : wind_internal_energy initial specific internal energy of the wind float 0 Enzo

If the "internal_energy" field is defined, then this must be a positive value. In this case, the value is also used to help initialize the "total_energy" field for cells that overlap with the cloud. However, if the "internal_energy" field is not defined, then this must not have a specified value (i.e. it must have a value of 0).

Parameter: Initial : cloud : perturb_standard_deviation standard deviation used for perturbations float 0 Enzo

This must be either 0 or a positive value. In the former case, the perturbation machinery is not used. In the latter case, it gives the standard deviation of the truncated gaussian for truncation (technically, it’s the standard deviation of the gaussian before truncation).

Parameter: Initial : cloud : perturb_truncation_deviation number of deviation where perturbation gaussian is truncated float 0 Enzo

Meaningless unless Initial:cloud:perturb_standard_deviation is positive. This must be either 0 or a positive value. In the former case, the gaussian is not truncated (nominally allowing the possibility of negative values). In the latter case, this determines the number of standard deviations from the mean at which the gaussian should be truncated.

Parameter: Initial : cloud : perturb_seed Seeds the perturbations to cloud density integer 0 Enzo

This must be a zero or larger. Meaningless unless Initial:cloud:perturb_standard_deviation is positive.

Warning

Due to reliance on std::normal_distribution the perturbations are not currently guaranteed to be the same (when the seed is the same) for different compilers or versions of the c++ standard library.

Changes in the grid resolution, domain size, way that mesh is divided across root blocks, or ghost depth will also affect the perturbations.

Parameter: Initial : cloud : wind_total_energy initial specific total energy of the wind float none Enzo

This must be a positive value.

### inclined_wave¶

The inclined_wave Initial subgroup is used to setup a HD or MHD wave at an angle inclined to the simulation domain for testing HD/MHD integrators. If applicable, magnetic fields fields are set to zero when a HD wave is initialized.

The procedure to addopted from Gardiner & Stone (2008) . Specifically, a coordinate system “x0”, “x1”, “x2” is defined and the wave is initialized to travel along “x0”. The transformation between “x”, “y”, “z” and “x0”, “x1”, “x2”, is determined by the values of the alpha and beta parameters. They are explicitly related by

$\begin{split}x &= x_0\cos\alpha\cos\beta - x_1\sin\beta - x_2\sin \alpha \cos \beta \\ y &= x_0\cos\alpha\sin\beta + x_1\cos\beta - x_2\sin \alpha \sin \beta \\ z &= x_0\sin\alpha + x_2 \cos\alpha\end{split}$

As in that paper, non-zero magnetic fields are initialized using the vector potential to ensure that they are divergence-free.

Parameter: Initial : inclined_wave : alpha Angle used to help determine wave inclination float 0 Enzo

The angle is assumed to have units of radians.

Parameter: Initial : inclined_wave : beta Angle used to help determine wave inclination float 0 Enzo

The angle is assumed to have units of radians.

Parameter: Initial : inclined_wave : wave_type Specifies the type of wave to initialize. string alfven Enzo

The values used to initialize hydrodynamical linear waves are taken from the columns of the matrix given in equation B3 of Stone et al. (2008) . Valid hydrodynamical waves include:

• "sound" A linear sound wave.
• "hd_entropy" A linear HD entropy wave with perturbations in v0 (velocity along the “x0”-axis).
• "hd_transv_entropy_v1" A linear HD entropy wave with perturbations in velocity component v1 (transverse to the direction of bulk motion).
• "hd_transv_entropy_v2" A linear HD entropy wave with perturbations in velocity component v2 (transverse to the direction of bulk motion).

Each of the valid MHD waves are described in Gardiner & Stone (2008) . Valid MHD wave types include:

• "alfven" A linear Alfven wave with perturbations to the magnetic field along the “x2”-axis.
• "circ_alfven" A traveling circularly polarized Alfven wave.
• "mhd_entropy" A linear MHD entropy wave.
• "fast" A linear fast magnetosonic wave.
• "slow" A linear slow magnetosonic wave.

Parameter: Initial : inclined_wave : amplitude Sets the amplitudes of the waves. float 1.e-6 Enzo

This must be a positive value. This has no effect for the circularly polarized Alfven wave (for that case, amplitude is fixed at 0.1).

Parameter: Initial : inclined_wave : lambda The wavelength of the wave. float 1. Enzo

This must be a positive value.

Parameter: Initial : inclined_wave : positive_vel Sets the sign of the wave speed. logical true Enzo

This has no effect for the circularly polarized Alfven wave. This is ignored for linear HD entropy waves when Initial:inclined_wave:parallel_vel is specified.

Parameter: Initial : inclined_wave : parallel_vel optionally sets the background velocity for HD waves float none Enzo

This can be used to specify a background velocity along v0 for HD linear waves.

### music¶

The music Initial subgroup is used to read block data from HDF5 files generated by MUSIC initial conditions generator. Parameters are used to specify the HDF5 files to read from, the names of the HDF5 datasets, what type of data the datasets contain ("field" or "particle"), field or particle names, and particle attributes. Additionally, a coords parameter is used to specify the axis ordering used. The music group has its own list parameter, one for each field or particle type and attribute.

The following example reads the "density" field from "GridDensity" file, and the "dark" particle "position_x" attributes from the "ParticleDisplacements_x" file:

Initial {

list = ["music"];
music {

file_list = ["FD","PX"];
FD {
type      = "field";
name      = "density";
coords    = ".zyx";
file      = "GridDensity";
dataset   = "GridDensity";
}
PX {
type      = "particle";
name      = "dark";
coords    = ".zyx";
attribute = "position_x";
file      = "ParticleDisplacements_x";
dataset   = "ParticleDisplacements_x";
}
}
}

Parameter: Initial : music : list Name of the HDF5 to read from string none Enzo

List of file identifiers, one for each field or particle type+attribute.

Parameter: Initial : music : : type Type of data to read in string none Enzo

Type of data to read in, either “field” or “particle”.

Parameter: Initial : music : : file Name of the HDF5 file to read from string none Enzo

Name of the HDF5 file to read from.

Parameter: Initial : music : : dataset Name of the dataset to read from the the HDF5 file string none Enzo

Name of the dataset to read from the the HDF5 file.

Parameter: Initial : music : : name Name of the field or particle type string none Enzo

Name of the field or particle type.

Parameter: Initial : music : : attribute Name of the particle attribute to initialize string none Enzo

Name of the particle attribute to initialize..

Parameter: Initial : music : : coords Ordering of axes in the HDF5 file string “zyx” Enzo

String defining the axis ordering of ‘x’, ‘y’, and ‘z’ in the HDF5 file. For MUSIC initial conditions, which may have 4D datasets, “tzyx” can be used, where “t” is ignored and can be any character other than ‘x’, ‘y’, or ‘z’.

### sedov¶

Parameter: Initial : sedov : array Size of array of Sedov blasts list ( integer ) [ 1, 1, 1 ] Enzo

This parameter defines the size of the array of Sedov blast waves. The default is a single blast.

Parameter: Initial : sedov : radius_relative Initial radius of the Sedov blast float 0.1 Enzo write

Parameter: Initial : sedov : pressure_in Pressure inside the Sedov blast float 1.0 Enzo write

Parameter: Initial : sedov : pressure_out Pressure outside the Sedov blast float 1.0e-5 Enzo write

Parameter: Initial : sedov : density Density for the Sedov blast array problem float 1.0 Enzo write

### shock_tube¶

The shock_tube Initial subgroup is used to setup axis-aligned shock tube test problems.

Generically, a shock tube get’s set up to evolve along an axis given by the value of aligned_ax. The discontinuity is always placed at 0.5 along that axis (typically the domain should extend from 0.0 to 1.0).

Parameter: Initial : shock_tube : setup_name Specifies the name of the shock tube problem to setup. string none Enzo

Valid shock tube problems include:

• "rj2a" An MHD shock tube problem illustrated in Figure 2a of Ryu & Jones (1995) . The initialization assumes that the adiabatic index is 5/3.
• "sod" The hydrodynamical Sod shock tube test problem. The canonical adiabatic is 1.4 (although this is not required).

Parameter: Initial : shock_tube : aligned_ax Specify the axis along which the shock tube evolves along. string x Enzo

Allowed values are "x" , "y" , or "z" .

Parameter: Initial : shock_tube : axis_velocity Value to add to velocity component along aligned_ax float 0. Enzo

This value is added throughout the entire domain.

Parameter: Initial : shock_tube : transverse_velocity Value to add to a velocity component perpendicular to aligned_ax float 0. Enzo

This value is added throughout the entire domain. If aligned_ax is "x" , "y" , or "z" , then this value is added to the "velocity_y" , "velocity_z" , or "velocity_z" field.

Parameter: Initial : shock_tube : flip_initialize Whether to mirror the initial condition across the discontinuity logical false Enzo

When this is "true" the entire setup is mirrored across the discontinuity. Basically the left and right states are swapped AND all components of the magnetic field and velocity (including contributions from axis_velocity and transverse_velocity) are multiplied by -1.

### turbulence¶

Parameter: Initial : turbulence : density Initial density for turbulence initialization and method float 1.0 Enzo

Initial density for initializing the turbulence problem.

Parameter: Initial : turbulence : pressure Initial pressure for turbulence initialization and method float 0.0 Enzo

Initial pressure for initializing the turbulence problem. Default is 0.0, meaning it is not used. Either pressure or temperature should be defined, but not both.

Parameter: Initial : turbulence : temperature Initial temperature for turbulence initialization and method float 0.0 Enzo

Initial temperature for initializing the turbulence problem. Default is 0.0, meaning it is not used. Either pressure or temperature should be defined, but not both.

### vlct_bfield¶

This is used to compute the cell-centered magnetic field for the VL + CT MHD method. This initializer can be utilized in 2 ways:

1. Components of the vector potential ("Ax", "Ay", "Az") can be specified as parameters of the subgroup (functions can be specified for each component in the same way as functions are specified for the value subgroup. The initializer operates in this mode as long as the values for one of the components of the vector potential is specified (any unspecified components are assumed to be zero everywhere). In this mode, both the cell-centered and face-centered magnetic field values get specified.
2. Initialize the cell-centered values of the magnetic fields after after another Initial subgroup (e.g. the value subgroup) has already to specified the face-centered magnetic fields ("bfieldi_x", "bfieldi_y", "bfieldi_z"). The cell-centered value is just the average of the corresponding face-centered component. The initializer operates in this mode if none of the components of the vector potential have specified values. (To properly specify use this mode, specify "vlct_bfield" in the Initial:list parameter list following the name of the Initial subgroup used to setup the face-centered values.

In both modes, the option to update partially initialized "total_energy" fields with the specific magnetic energy computed from the newly computed cell-centered bfields and pre-initialized "density" fields.

It might be nice to eventually generalize this initializer to be able to initialize cell-centered B-fields from vector potentials for MHD integrators that don’t require face-centered B-fields

Parameter: Initial : value : update_etot : update total energy with the initialized magnetic fields logical false Enzo

If true, then the calculated cell-centered magnetic fields are used to update the specific total energy. This requires that the "total_energy" field has already been partially initialized (it just doesn’t include the specific magnetic energy), and that the "density" field has been initialized.

Parameter: Initial : value : Ax : Expression for the x-component of the magnetic vector potential list ( float-expr, [ logical-expr, float-expr, [ … ] ] ) [] Enzo

This parameter allows for the direct specification of the x-component of the magnetic vector potential (which will be used to compute magnetic fields). The arguements for this parameter follow the same sets of rules as the parameters of Initial:value. If this parameter is not specified, but the values of the other components of the magnetic vector potential are, then this component is assumed to be zero everywhere.

Parameter: Initial : value : Ay : Expression for the y-component of the magnetic vector potential list ( float-expr, [ logical-expr, float-expr, [ … ] ] ) [] Enzo

This parameter allows for the direct specification of the y-component of the magnetic vector potential (which will be used to compute magnetic fields). The arguements for this parameter follow the same sets of rules as the parameters of Initial:value. If this parameter is not specified, but the values of the other components of the magnetic vector potential are, then this component is assumed to be zero everywhere.

Parameter: Initial : value : Az : Expression for the z-component of the magnetic vector potential list ( float-expr, [ logical-expr, float-expr, [ … ] ] ) [] Enzo

This parameter allows for the direct specification of the z-component of the magnetic vector potential (which will be used to compute magnetic fields). The arguements for this parameter follow the same sets of rules as the parameters of Initial:value. If this parameter is not specified, but the values of the other components of the magnetic vector potential are, then this component is assumed to be zero everywhere.

## Memory¶

Parameters in the Memory group are used to define the behavior of Cello’s dynamic memory allocation and deallocation.

Parameter: Memory : active Whether to track memory usage logical true Cello

This parameter is used to turn on or off Cello’s build-in memory tracking. By default it is on, meaning it tracks the number and size of memory allocations, including the current number of bytes allocated, the maximum over the simulation, and the maximum over the current cycle. Cello implements this by overloading C’s new, new[], delete, and delete[] operators. This can be problematic on some systems, e.g. if an external library also redefines these operators, in which case this parameter should be set to false. This can be turned off completely by setting “memory = 0” in the top-level “SConstruct” file.

## Mesh¶

Parameter: Mesh : root_blocks Number of Blocks used to tile the coarsest refinement level list ( integer ) [ 1, 1, 1 ] Cello

This parameter specifies the number of Blocks along each axis in the mesh “array”. The product must not be smaller than the number of processors used.

Parameter: Mesh : root_rank Physical dimensionality of the problem integer 0 Cello

Number of physical dimensions in the problem, 1, 2, or 3.

Parameter: Mesh : root_size Coarsest Patch size list ( integer ) [ 1, 1, 1 ] Cello

This parameter specifies the total size of the root-level mesh. For example, [400, 400] specifies a two dimensional root-level discretization of 400 x 400 zones, excluding ghost zones.

## Method¶

Parameter: Method : list Sequence of numerical methods to apply. list ( string ) none Cello

This parameter specifies the list of numerical methods to use, and is analagous to “EvolveLevel” routine in ENZO. Each method in the list is applied in the order specified. Possible methods include:

• “comoving_expansion” adds comoving expansion terms to the physical variables.
• “cosmology” for writing redshift to monitor output.
• “grackle” for heating and cooling methods in the Enzo Grackle library
• “gravity” solves for the gravitational potential given gas and particle density fields.
• “heat” for the forward-Euler heat-equation solver, which is used primarily for demonstrating how new Methods are implemented in Enzo-E
• “pm_deposit” deposits “dark” particle density into “density_particle” field using CIC for “gravity” method.
• “pm_update” moves cosmological “dark” particles based on positions, velocities, and accelerations. This will be phased out in favor of a more general “move_particles” method.
• “ppm” for Enzo-E’s PPM hydrodynamics method. This may be phased out in favor of using a more general “hydro” method instead, with a specific hydro solver specified.
• “ppml” for the PPML ideal MHD solver. This may be phased out in favor of using a more general “mhd” method instead, with a specific mhd solver specified.
• “mhd_vlct” for the VL + CT (van Leer + Constrained Transport) MHD solver.
• “trace” for moving tracer particles. This will be phased out in favor of a more general “move_particles” method.
• “turbulence” computes random forcing for turbulence simulations.

Parameters specific to individual methods are specified in subgroups, e.g.:

Method {
list = ["ppm"];
ppm {
diffusion   = true;
flattening  = 3;
steepening  = true;
dual_energy = false;
}
}


For more detailed documentation on Methods, see Enzo-E Methods

Parameter: Method : courant Global Courant safety factor float 1.0 Cello

The global Courant safety factor is a multiplication factor for the time step applied on top of any Field or Particle specific Courant safety factors.

### flux_correct¶

Parameter: Method : flux_correct : group Name of group of fields to apply flux correction to string “conserved” Cello

Flux correction must be applied to conserved fields in AMR simulations to maintain conserved quantities across mesh resolution jumps. This parameter selects the group of fields to which the “flux_correct” method will be applied.

### gravity¶

Parameter: Method : gravity : solver Name of the linear solver to use string “unknown” Enzo

Identifier for the linear solver to use, which must be included in the “Solver:list” parameter.

Parameter: Method : gravity : grav_const Gravitational constant float 6.67384e-8 Enzo

Gravitational constant used in place of G. The default is G in cgs units.

Parameter: Method : gravity : order Order of accuracy discretization to use for the discrete Laplacian integer 4 Enzo

Second, fourth, and sixth order discretizations of the Laplacian are available; valid values are 2, 4, or 6.

Parameter: Method : gravity : accumulate Whether to add one layer of ghost zones when refreshing particle density logical true Enzo

This should be true for all runs with particles, since particle mass deposited in the “density_particle” field may bleed into the first layer of ghost zones. This parameter ensures that that mass will be included in “density_total”.

### grackle¶

“Grackle is a chemistry and radiative cooling library for astrophysical simulations. It is a generalized and trimmed down version of the chemistry network of the Enzo simulation code.”

Most of the descriptions of the parameters come from the Grackle documentation; for the most up-to-date description of Grackle parameters, see the Grackle parameters section of the website.

Parameter: Method : grackle : density_units Units for the density field float 1.67e-24 (1 m_H/cc) Enzo

Units of density for the Grackle chemistry and cooling solver library.

Parameter: Method : grackle : length_units Units for distance float 3.086e21 (1 kpc) Enzo

Units of length for the Grackle chemistry and cooling solver library.

Parameter: Method : grackle : time_units Units for time float 3.15569e13 (1 Myr) Enzo

Units of time for the Grackle chemistry and cooling solver library.

Parameter: Method : grackle : a_units Units for the cosmological expansion factor float 1.0 Enzo

Units of the cosmological expansion factor for the Grackle chemistry and cooling solver library.

Parameter: Method : grackle : gamma The ratio of specific heats for an ideal gas float 5/3 Enzo

The ratio of specific heats for an ideal gas. A direct calculation for the molecular component is used if primordial_chemistry > 1.

Parameter: Method : grackle : with_radiative_cooling Include radiative cooling logical true Enzo

Flag to include radiative cooling and actually update the thermal energy during the chemistry solver. If off, the chemistry species will still be updated. The most common reason to set this to off is to iterate the chemistry network to an equilibrium state.

Parameter: Method : grackle : primordial_chemistry Flag to control which primordial chemistry network is used logical false Enzo

Flag to control which primordial chemistry network is used.

0: no chemistry network. Radiative cooling for primordial species is solved by interpolating from lookup tables calculated with Cloudy. A simplified set of functions are available (though not required) for use in this mode. For more information, see Pure Tabulated Mode.

1: 6-species atomic H and He. Active species: H, H+, He, He+, ++, e-.

2: 9-species network including atomic species above and species for molecular hydrogen formation. This network includes formation from the H- and H2+ channels, three-body formation ( H + H + H and H + H + H2), H2 rotational transitions, chemical heating, and collision-induced emission (optional). Active species: above + H-, H2, H2+.

3: 12-species network include all above plus HD rotation cooling. Active species: above plus D, D+, HD.

Note: In order to make use of the non-equilibrium chemistry network (primordial_chemistry options 1-3), you must add and advect baryon fields for each of the species used by that particular option.

Parameter: Method : grackle : metal_cooling Flag to enable metal cooling using the Cloudy tables logical false Enzo

Flag to enable metal cooling using the Cloudy tables. If enabled, the cooling table to be used must be specified with the Grackle data_file parameter.

Note: In order to use the metal cooling, you must add and advect a metal density field.

Parameter: Method : grackle : h2_on_dust Flag to enable H2 formation logical false Enzo

Flag to enable H2 formation on dust grains, dust cooling, and dust-gas heat transfer follow Omukai (2000). This assumes that the dust to gas ratio scales with the metallicity.

Parameter: Method : grackle : cmb_temperature_floor Flag to enable an effective CMB temperature floor. logical true Enzo

Flag to enable an effective CMB temperature floor. This is implemented by subtracting the value of the cooling rate at TCMB from the total cooling rate.

Parameter: Method : grackle : data_file Path to the data file containing the metal cooling and UV background tables. string “” Enzo

Path to the data file containing the metal cooling and UV background tables.

Parameter: Method : grackle : three_body_rate Flag to control which three-body H2 formation rate is used. integer 0 Enzo Not accessed

Flag to control which three-body H2 formation rate is used.

These are discussed in Turk et. al. (2011)

Parameter: Method : grackle : cie_cooling Flag to enable |H2| collision-induced emission cooling logical false Enzo

Flag to enable H2 collision-induced emission cooling from Ripamonti & Abel (2004).

Parameter: Method : grackle : h2_optical_depth_approximation Flag to enable |H2| cooling attenuation logical false Enzo

Flag to enable H2 cooling attenuation from Ripamonti & Abel (2004).

Parameter: Method : grackle : photoelectric_heating Enzo

Flag to enable a spatially uniform heating term approximating photo-electric heating from dust from Tasker & Bryan (2008)http://adsabs.harvard.edu/abs/2008ApJ…673..810T.

Parameter: Method : grackle : photoelectric_heating_rate 8.5e-26 Enzo

If photoelectric_heating is enabled, the heating rate in units of erg cm-3 s-1.

Parameter: Method : grackle : UVbackground Enzo write

Parameter: Method : grackle : UVbackground_redshift_on Enzo write Not accessed

Parameter: Method : grackle : UVbackground_redshift_off Enzo write Not accessed

Parameter: Method : grackle : UVbackground_redshift_fullon Enzo write Not accessed

Parameter: Method : grackle : UVbackground_redshift_drop Enzo write Not accessed

Parameter: Method : grackle : Compton_xray_heating 0 Enzo

Flag to enable Compton heating from an X-ray background following Madau & Efstathiou (1999)http://adsabs.harvard.edu/abs/1999ApJ…517L…9M.

Parameter: Method : grackle : LWbackground_intensity 0 Enzo

Intensity of a constant Lyman-Werner H2 photo-dissociating radiation field in units of 10-21 erg s-1 cm-2 Hz-1 sr-1.

Parameter: Method : grackle : LWbackground_sawtooth_suppression 0 Enzo

Flag to enable suppression of Lyman-Werner flux due to Lyman-series absorption (giving a sawtooth pattern), taken from Haiman & Abel, & Rees (2000)http://adsabs.harvard.edu/abs/2000ApJ…534…11H.

Parameter: Method : grackle : HydrogenFractionByMass Enzo write Not accessed

Parameter: Method : grackle : DeuteriumToHydrogenRatio Enzo write Not accessed

Parameter: Method : grackle : SolarMetalFractionByMass Enzo write Not accessed

Parameter: Method : grackle : NumberOfTemperatureBins Enzo write Not accessed

Parameter: Method : grackle : ih2co Enzo write Not accessed

Parameter: Method : grackle : ipiht Enzo write Not accessed

Parameter: Method : grackle : TemperatureStart Enzo write Not accessed

Parameter: Method : grackle : TemperatureEnd Enzo write Not accessed

Parameter: Method : grackle : comp_xray Enzo write Not accessed

Parameter: Method : grackle : temp_xray Enzo write Not accessed

Parameter: Method : grackle : CaseBRecombination Enzo write Not accessed

Parameter: Method : grackle : NumberOfDustTemperatureBins Enzo write Not accessed

Parameter: Method : grackle : DustTemperatureStart Enzo write Not accessed

Parameter: Method : grackle : DustTemperatureEnd Enzo write Not accessed

Parameter: Method : grackle : cloudy_electron_fraction_factor Enzo write Not accessed

### heat¶

Parameter: Method : heat : alpha Parameter for the forward euler heat equation solver float 1.0 Enzo

Thermal diffusivity parameter for the heat equation.

### mhd_vlct¶

Method:mhd_vlct parameters are used to initialize parameters for Enzo-E’s VL (+ CT) (magneto)hydrodynamic integrator.

The Method:mhd_vlct:mhd_choice determines whether the method is used as a pure hydrodynamic integrator or a MHD integrator that uses constrained transport.

Parameter: Method : mhd_vlct : mhd_choice Denotes handling of bfields (or lack thereof) string none Enzo

Denotes how the integrator handles magentic fields. This must be specified. Valid choices include:

• "no_bfield" The integrator acts as a pure hydrodynamical integrator; magnetic fields are ignored entirely.
• "constrained_transport" Magnetic fields are evolved using constrained transport. The primary representation of the magnetic fields are stored in face-centered cello fields and cell-centered cello-fields are used to store a secondary representation.

This may be updated to include additional options in the future. For more details see "mhd_vlct": hydrodynamics/MHD

For debugging purposes, there is technically one last choice, ”unsafe_constant_uniform”. :e:This is NOT meant for science runs. When this option is selected, the magnetic field is treated as a cell-centered conserved quantity and the magnetic fluxes computed in the Riemann solver are directly added to to the magnetic fields (magnetic field values are only stored in cell-centered Cello fields). Outside of very specific cases, this will NOT enforce the divergence-free constrain of the magnetic fields to grow. To use this option, you need to explicitly comment out an error in "enzo_EnzoMethodMHDVlct.cpp".

Parameter: Method : mhd_vlct : density_floor Lower limit on density float none Enzo

Density floor, which must exceed 0. This is applied during reconstruction and quantity updates.

Parameter: Method : mhd_vlct : pressure_floor Lower limit on thermal pressure float none Enzo

Thermal pressure floor, which must exceed 0. This is applied during reconstruction and quantity updates.

Parameter: Method : mhd_vlct : riemann_solver name of the Riemann solver to use string hlld Enzo

Name of the Riemann solver to use. For a list of options, see riemann solvers

Parameter: Method : mhd_vlct : half_dt_reconstruct_method name of the reconstruction method to use for the full timestep string nn Enzo

Name of the interpolation method used to reconstruct face-centered primitives for the first half timestep. "nn" is recommended for this method (problems arise if "plm" or "plm_athena" are used). For a list of options, see reconstruction

Parameter: Method : mhd_vlct : full_dt_reconstruct_method name of the reconstruction method to use for the full timestep string plm Enzo

Name of the interpolation method used to reconstruct face-centered primitives for the full timestep. For a list of options, see reconstruction

Parameter: Method : mhd_vlct : theta_limiter controls the dissipation of certain slope limiters. float 1.5 Enzo

Modifies the disipation of the slope limiter of the "plm"/"plm_enzo" piecewise linear reconstruction algorithm. For more details, see reconstruction

Parameter: Method : mhd_vlct : dual_energy Whether to use dual-energy formalism logical false Enzo

Whether to use the dual-energy formalism.

Parameter: Method : mhd_vlct : dual_energy_eta Dual energy parameter eta float 0.001 Enzo

Dual-energy formalism parameter. For more details, see dual-energy formalism

### null¶

Parameter: Method : null : dt Set the time step for the “null” Method float max (float) Enzo

Sets the time step for the null Method. This is typically used for testing the AMR meshing infrastructure without having to use any specific method. It can also be used to add an additional maximal time step value for other methods.

### pm_deposit¶

Parameter: Method : pm_deposit : alpha Compute potential at time t + alpha*dt float 0.5 Enzo

Sets the factor defining at what time to deposit mass into the density_total field. The default is 0.5, meaning t + 0.5*dt.

### ppm¶

Method:ppm parameters are used to initialize parameters for Enzo-E’s PPM hydrodynamics method.

Parameter: Method : ppm : density_floor Lower limit on density float 1.0e-6 Enzo

Density floor, which replaces Enzo’s “tiny_number”.

Parameter: Method : ppm : diffusion PPM diffusion parameter logical false Enzo

PPM diffusion parameter.

Parameter: Method : ppm : dual_energy Whether to use dual-energy formalism logical false Enzo

Whether to use the dual-energy formalism.

Parameter: Method : ppm : dual_energy_eta_1 Dual energy parameter eta 1 float 0.001 Enzo

First dual-energy formalism parameter.

Parameter: Method : ppm : dual_energy_eta_2 Dual energy parameter eta 2 float 0.1 Enzo

Second dual-energy formalism parameter.

Parameter: Method : ppm : flattening PPM flattening parameter integer 3 Enzo

PPM flattening parameter.

Parameter: Method : ppm : minimum_pressure_support_parameter Enzo’s MinimumPressureSupportParameter integer 100 Enzo

Enzo’s MinimumPressureSupportParameter parameter.

Parameter: Method : ppm : mol_weight Enzo’s Mu parameter float 0.6 Enzo

Enzo’s Mu molecular weight parameter.

Parameter: Method : ppm : number_density_floor Lower limit on number density float 1.0e-6 Enzo

Number density floor, which replaces Enzo’s “tiny_number”.

Parameter: Method : ppm : pressure_floor Lower limit on pressure float 1.0e-6 Enzo

Pressure floor, which replaces Enzo’s “tiny_number”.

Parameter: Method : ppm : pressure_free Pressure-free flag logical false Enzo

Pressure-free flag.

Parameter: Method : ppm : steepening PPM steepening parameter logical false Enzo

PPM steepening parameter.

Parameter: Method : ppm : temperature_floor Lower limit on temperature float 1.0e-6 Enzo

Temperature floor, which replaces Enzo’s “tiny_number”.

Parameter: Method : ppm : use_minimum_pressure_support Minimum pressure support logical false Enzo

Enzo’s UseMinimumPressureSupport parameter.

Parameter: Method : ppm : mol_weight Mean molecular mass float 0.6 Enzo

Mean molecular mass used in computing temperature.

### turbulence¶

Parameter: Method : turbulence : edot Initial value for edot for turbulence Method float -1.0 Enzo write

Parameter: Method : turbulence : mach_number Value for Mach number in turbulence problem float 0.0 Enzo write

## Monitor¶

Parameter: Monitor : debug Whether to display debugging output logical false Cello

If true, then process DEBUG() statements, writing the output to both stderr and appending to files out.debug.<proc>, where <proc> is the (physical) process rank. Note that out.debug.<proc> files are not erased at the start of a run. This parameter is not scalable and is inefficient since output files are continually opened and closed by each process.

Parameter: Monitor : verbose Whether to display “verbose” output logical false Cello

If true, then output requests with Monitor::verbose() will be called. This will generally produce more detailed output, such as which specific Blocks are refining and coarsening, etc.

## Output¶

Output parameters are used to specify what types of disk output to perform and on what schedule.

Parameter: Output : list List of output file sets list ( string ) [] Cello

List of active file sets, each of which has its own associated Output : <file_set> : parameters. Any file set parameters associated with a file set not in the list parameter are ignored.

Parameter: Output : : axis Axis of projections for image output string none Cello is of type “image”

For the “image” output type, the axis along which to project the data for 3D problems. Values are “x”, “y”, :e:or “z”. See the associated type parameter.

Parameter: Output : : schedule Output schedule for the given file set subgroup none Cello

See the schedule subgroup for parameters used to define when to perform output for the given file set.

Parameter: Output : : colormap Color map for image output list ( float ) [] Cello is of type “image”

For the “image” output type, a list of the form [r0, g0, b0, r1, g1, b1, …], where 0.0 ≤ ri,gi,bi1.0 are RGB values.

Parameter: Output : : field_list List of fields to output list ( string ) [] Cello

List of fields for this output file set. For “image” field types, the field list must contain exactly one field.

Parameter: Output : : particle_list List of particle types to output list ( string ) [] Cello

List of particles types for this output file set..

Parameter: Output : : name File names list ( string ) “” Cello is not of type “restart”

This parameter specifies the names of files in the corresponding file_group. The first element is the file name, which may contain printf-style formatting fields. Subsequent values correspond to variables for the formatting fields, which may include “cycle”, “time”, “count” (a counter incremented each time output is performed), “proc” (the process rank), and “flipflop” (alternating 0 and 1, which can be useful for checkpoint directories). The file name should include an appropriate extension, e.g. “.png” for “image” output, and “.h5” or “.h5” for “data” output. Example: [“projection-%04d.png”, “cycle”].

Parameter: Output : : dir Name of the subdirectory for the output file list ( string ) “” Cello

This parameter specifies the subdirectory for the output file. The first element is the file name, which may contain printf-style formatting fields. Subsequent values correspond to variables for the formatting fields, which may include “cycle”, “time”, “count” (a counter incremented each time output is performed), “proc” (the process rank), and “flipflop” (alternating 0 and 1, which can be useful for checkpoint directories). Example: [“Checkpoint-%d”, “flipflop”].

This parameter is required for file groups of type “checkpoint”. While optional for other file types, the behavior is different for groups of type “data”. In that case, two extra files are output: <DIR>.file_list, which contains a list of all data files output, and <DIR>.block_list, which contains a list of all names of Blocks and the corresponding data file containing each Block.

Parameter: Output : : stride_write Subset of processors to perform write integer 1 Cello is of type “data” Broken: see bug # 13

This parameter allows for a strict subset of physical processors to output data, which is especially helpful for large process counts to reduce the load on parallel file systems.

Parameter: Output : : stride_wait Stride for sequencing processor data writes integer 1 Cello is of type “data” Not implemented

This parameter allows for processes to write sequentially to prevent too many processes overloading the file system. A good starting point would be the number of processes in a shared memory node, in which case at most one process per node will be writing at any point in time.

Parameter: Output : : type Type of output files string “unknown” Cello

The type of files to output in this output file set. Supported types include “image” (PNG file of 2D fields, or projection of 3D fields) and “data”. For “image” files, see the associated colormap and axis parameters.

Parameter: Output : : image_min Data value associated with the first color in the colormap float 0.0 Cello is of type “image”

This parameter specifies the Field value associated with the first color in the file set’s colormap.

Parameter: Output : : image_max Data value associated with the last color in the colormap float 0.0 Cello is of type “image”

This parameter specifies the Field value associated with the last color in the file set’s colormap.

Parameter: Output : : image_lower Lower bound on domain to be output in image list ( float ) [min ( float ), min ( float ), min ( float )] Cello is of type “image”

This parameter specifies the lower limit of the domain to include in the image. This can be used for imaging “slices” of 3D data, or zeroing in on interesting region of the domain.

Parameter: Output : : image_upper Upper bound on domain to be output in image list ( float ) [max ( float ), max ( float ), max ( float )] Cello is of type “image”

This parameter specifies the upper limit of the domain to include in the image. This can be used for imaging “slices” of 3D data, or zeroing in on interesting region of the domain.

Parameter: Output : : image_ghost Whether to include ghost zones in the image logical false Cello is of type “image”

Setting the image_ghost to true will include ghost zone values in the image output. This is typically used only when debugging. The default is false.

Parameter: Output : : image_reduce_type How to handle 3D field data orthogonal to the image string “sum” Cello is of type “image”

When images are generated for 3D problems, multiple data values will be associated with each pixel in the image. This parameter defines how to handle these multiple values, including “sum”, “min”, “max”, and, “avg”. For field data the default of “sum” is appropriate, though for images of meshes “max” should be used.

Parameter: Output : : image_face_rank Whether to include neighbor markers in the mesh image output integer 3 Cello is of type “image”

This parameter is primarily used for debugging. Internally, each node in the mesh keeps track of the mesh level of its neighbors. This parameter includes a marker on each face colored according to the neighbor’s level. The value of this parameter specifies the lower limit on the face “rank” (0 for corners, 1 for edges, 2 for faces). The default of 3 means no markers are displayed.

Parameter: Output : : image_size Set the size of the image list ( integer ) [0,0] Cello is of type “image”

Specify the size of the output image. By default it is sized to be one pixel per field value at the finest mesh level. This is useful to keep images from being to big for large problems, or too small for small problems (e.g. for mesh images which could otherwise be too small).

Parameter: Output : : image_log Whether to output the log of the data logical false Cello is of type “image”

If true, then the natural logarithm of the field value is used for mapping values to the colormap, otherwise use the original field value.

Parameter: Output : : image_type Type of image to write string “data” Cello is of type “image”

This parameter is used to control whether field values are used to generate the image, whether it’s an image of the mesh structure, or a combination of both. Valid values are “data”, “mesh”, or “data+mesh”.

Parameter: Output : : image_block_size Number of pixels for fine-level blocks in a mesh image integer 1 Cello is of type “image”

For images of meshes, this parameter defines how many pixels wide each finest-level block is in the image. This parameter and the image_size parameter should not both be set.

Parameter: Output : : image_mesh_color How to color blocks in a mesh image string “level” Cello is of type “image”

By default, blocks in mesh images are colored according to the level of the block. In addition to “level”, other possible ways to assign colors to blocks include “process” and “age”.

## Particle¶

Cello supports any number of particle types–e.g. “dark” for dark matter particles, or “trace” for tracer particles. Each particle type in turn may have any number of attributes–e.g. “x” or “position_x” for position, “vx” or “velocity_x” for velocity, “mass”, “id”, etc. Attributes can have any basic floating-point or integer type.

All particle types must have at least attributes for position, defined using the position parameter. This allows Cello to know whether particles have moved off of a Block, and if so to relocate them to the correct new block.

Particle positions may be defined as integer types instead of floating-point. When a particle position attribute is defined as an integer, then the coordinate value is defined relative to the enclosed Block instead of a global coordinate system. This can be useful both to reduce memory usage, and to simultaneously improve accuracy–it avoids possible catastrophic cancellation errors that are especially large in “deep” Blocks in an AMR hierarchy whose position is far from 0. When positions are defined as integers, 0 is defined to be the center of the block, and [ -min-int / 2 , max-int / 2) are the bounds of the Block, where min-int is the minimum value of the signed integer of the corresponding size. Integer types allowed include “int8”, “int16”, “int32”, and “int64”. Two byte integers “int16” should be sufficient for most simulations: it has a range of [ -16384, 16384 ) within the particle’s containing Block, and ranges [-32768, -16384) and [16384, 32768) on either side of the associated Block.

Particles are allocated and operated on in “batches”. The batch_size parameter defines how many particles are in a batch. By operating on particles in batches, the frequency of memory operations is greatly reduced, and functions operating on particle attributes can be more efficient due to reduced overhead. It should also simplify writing particle methods to be executed on accelerators, such as NVIDIA or AMD GPU’s.

Just as with fields, particle types can be assigned to groups.

Parameter: Particle : list List of particle types list ( string ) [] Cello

Cello allows arbitrary parameter types (dark matter particles, tracer particles, star particles, etc.), each with arbitrary attributes (position, velocity, etc.). The list parameter defines which types of particles to use.

Particle {

list = ["dark", "trace"];

}


Parameter: Particle : batch_size Number of particles in a “batch” of particles integer 1024 Cello

Particles are allocated and operated on in batches. The number of particles in a batch is set using the batch_size parameter. The default batch size is 1024.

Parameter: Particle : particle_type : attributes List of attribute names and data types list ( string ) none Cello

Each particle type can have multiple attributes of varying types, which are defined by the attributes parameter. The attributes parameter is a list of strings, alternating between the name of the parameter, and its type. Names may include “position_x”, “velocity_z”, “mass”, “id”, etc. Types may include “single”, “double”, “quadruple”, “int8”, “int16”, “int32”, or “int64”. Ordering of attributes in memory is as in the attributes parameter.

Parameter {

list = ["trace", "dark"];

trace {

attributes = ["id", "int64",
"x",  "single",
"y",  "single",
"z",  "single"];
}

dark {

attributes = ["id",         "int64",
"mass",       "double",
"velocity_x", "single",
"velocity_y", "single",
"velocity_z", "single",
"position_x", "int16",
"position_y", "int16",
"position_z", "int16"];
}
}


Note that when attributes of multiple sizes are included in the same parameter type, it can be helpful to order the attributes so that larger-sized attributes are listed first, followed by smaller-sized attributes. This can help prevent allocating more memory than necessary, since attributes may be padded with unused bytes for correct memory alignment.

Parameter: Particle : particle_type : interleaved Format of output files logical false Cello

Particle attributes within a batch of particles may be stored in memory either particle-by-particle, or “interleaved” (attribute-by-attribute). If ai,j represents the jth attribute of particle i, then with interleaved = false, attributes would be stored as a0,0 … am,0, a0,1 … am,1 … a0,n … am,n. If, however, interleaved = true, then attributes would be stored as a0,0 … a0,n, a1,0 … a1,n … am,0 … am,n. Non-interleaved particle attributes have array accesses of stride 1 and minimal storage overhead, but may not utilize cache well. Interleaved particle attributes may have improved cache utilization, but will have stride > 1, and may require memory padding for correct alignment of attributes in memory. The default is false.

Parameter: Particle : particle_type : group_list Specify a list of groups that the Particle type belongs to list ( string ) [ ] Cello

Different Particle types may belong to any number of different “groups”, which allows simulation code to loop over multiple related particle types.

Particle {
list = ["trace","dark","star"];

dark { group_list = ["has_mass"]; }
star { group_list = ["has_mass"]; }
}


This example can be rewritten as follows, which is completely equivalent:

Particle
list = ["trace","dark","star"];
}

Group {
list = ["has_mass"];
has_mass {
particle_list = ["dark","star"];
}
}


Parameter: Particle : particle_type : position Format of output files string “” Cello

Cello needs to know which particle attributes represent position, so that it can determine when particles migrate out of a Block and need to be moved to a neighboring Block. This is done using the position parameter:

Particle {

list = ["trace"];

trace {

attributes = ["id",
"x","single",
"y","single",
"z","single"];

position = ["x","y","z"];
}
}


Parameter: Particle : particle_type : velocity Format of output files string “” Cello

Enzo may need to know which particle attributes represent velocity, for example for kick() or drift() operations. This is done using the velocity parameter, whose usage is analogous to the position parameter. While specifying position is required, specifying velocity is optional.

Particle {

list = ["dark"];

trace {

attributes = [ "x","single",   "y","single",   "z","single",
"vx","single",  "vy","single",  "vz","single",
"mass","single"];

velocity = ["vx","vy","vz"];
}
}


## Performance¶

Parameter: Performance : warnings Whether to output performance-related warnings logical true Cello

If calls to the Performance API are incorrect, e.g. if stop_region() is called on a region that has not been started, then this parameter specifies whether or not to display warning messages

Parameter: Performance : papi : counters List of PAPI counters list ( string ) [] Cello

List of PAPI hardware performance counters to trace, e.g. ‘counters = [“PAPI_FP_OPS”, “PAPI_L3_TCA”];’. For a list of available counters, use the PAPI “papi_avail” utility.

## Physics¶

### cosmology¶

Parameter: Physics : cosmology : comoving_box_size Enzo’s CosmologyComovingBoxSize parameter float 64.0 Enzo

Enzo’s CosmologyComovingBoxSize parameter.

Parameter: Physics : cosmology : hubble_constant_now Hubble constant for Z=0 float 0.701 Enzo

Hubble constant for Z=0.

Parameter: Physics : cosmology : initial_redshift Enzo’s CosmologyInitialRedshift parameter. float 20.0 Enzo

Enzo’s CosmologyInitialRedshift parameter.

Parameter: Physics : cosmology : max_expansion_rate Maximum expansion rate float 0.01 Enzo

Maximum expansion rate.

Parameter: Physics : cosmology : omega_lamda_now Omega lambda for Z=0 float 0.721 Enzo

Omega lamda for Z=0.

Parameter: Physics : cosmology : omega_matter_now Omega matter for Z=0 float 0.279 Enzo

Omega matter for Z=0.

## Restart¶

Parameter: Restart : file Parameter file to read on restart string “” Cello

This optional parameter is used to specify the name of a parameter file to read on restart. Its purpose is to allow a simulation to be restarted with slightly different parameter values, e.g. with a smaller courant number. Currently, very few parameters are supported in the restart parameter file, just Field : courant and Testing : time_final.

## schedule¶

“schedule” is a parameter subgroup that defines when to do something, such as perform output, apply a method, or to apply the dynamic load balancer. Schedules can be specified as a list of values, or as an interval of values specified using some subset of start, stop, and step. The associated variable, set using var, can be “cycle”, “time”, or “seconds”. Here “time” refers to simulation time, and “seconds” to wall-clock time. At each cycle, all schedules are checked to see if the cycle number, simulation time or wall-clock seconds match the list or interval of values. If there is a match, the associated output or is performed; otherwise, it is skipped.

Note that when simulation “time” is specified, then the simulation’s time step may be reduced so that the corresponding output occurs exactly at the specified time.

Output {

list = ["check", "dump", "image"];

check {

# **** write a checkpoint every 100.0 seconds ****

schedule {
var = "seconds";
start = 100.0;
step =  100.0;
}
...
}

dump {

# **** perform a data dump every 50 cycles until cycle 1000 ****

schedule {
var = "cycle";
step =   50;
stop = 1000;
}
...
}

image {

# **** write an image at times t = 1.0,  2.0, and 5.0 ****

schedule {
var = "time";
list = [1.0, 2.0, 5.0];
}
...
}
}


Parameter: schedule : var Variable associated with scheduling for the given file set string “none” Cello

The var parameter specifies what value is checked at each cycle, which may be “cycle”, “time”, or “seconds” Here “time” refers to simulation time, and “seconds” to wall-clock time. Note that when simulation “time” is specified, the simulation’s time step may be reduced such that the corresponding output occurs exactly at the specified time.

Parameter: schedule : list List of scheduled values for the specified variable [ list ( integer ) | list ( float ) ] [] Cello

This parameter specifies a list of values to check against for output with respect to cycle, time, or seconds. If the “var” parameter associated with the schedule is “cycle”, then value must be a list of integers; otherwise, value must be a list of float’s The default is an empty list.

Parameter: schedule : start Starting value for scheduled interval [ integer | float ] 0 | 0.0 Cello write

Parameter: schedule : stop Last value for scheduled interval [ integer | float ] max (integer) | max (double) Cello write

Parameter: schedule : step Stepping increment for interval [ integer | float ] 1 | 1.0 Cello write

## Solver¶

Parameter: Solver : solver : iter_max Iteration limit for the CG solver int 100 Enzo

Maximum number of CG iterations to take.

Parameter: Solver : solver : res_tol Residual norm reduction tolerance for the CG solver float 1e-6 Enzo

Stopping tolerance on the 2-norm of the residual relative to the initial residual, i.e. CG is defined to have converged when ||R_i ||2 / ||R_0 ||2 < res_tol.

Parameter: Solver : solver : grav_const Gravitational constant float 6.67384e-8 Enzo

Gravitational constant used in place of G. The default is G in cgs units.

Parameter: Solver : solver : diag_precon Whether to apply diagonal preconditioning logical false Enzo

Whether to diagonally precondition the linear system A*X = B in EnzoSolverGravityCg by 1.0 / (h^2).

Parameter: Solver : solver : monitor_iter How often to display progress integer 1 Enzo

The current iteration, and minimum, current, and maximum relative residuals, are displayed every monitor_iter iterations. If monitor_iter is 0, then only the first and last iteration are displayed.

## Stopping¶

Parameter: Stopping : cycle Stopping cycle integer max ( integer ) Cello

Stopping cycle.

Parameter: Stopping : time Stopping time float max ( double ) Cello

Stopping time.

Parameter: Stopping : seconds Stop after this number of seconds (wall-clock time) float max ( double ) Cello

End the calculation after this many seconds of wall-clock time.

Parameter: Stopping : interval Stopping interval integer 1 Cello

Number of cycles between applying the stopping criteria.

## Testing¶

Parameter: Testing : cycle_final Enzo-E unit test parameter for expected final cycle number integer 0 Cello

Enzo-E unit test parameter for expected final cycle number.

Parameter: Testing : time_final Enzo-E unit test parameter for expected final time float 0.0 Cello

Enzo-E unit test parameter for expected final time.

Parameter: Testing : time_tolerance Tolerance on the absolute error between actual final time and time_final float 1.0e-6 Cello

Enzo-E unit test parameter for tolerance on the expected final time.

## Units¶

Parameter: Units : length Units scaling factor for length double 1.0 Cello

Units scaling factor for length.

Parameter: Units : mass Units scaling factor for mass double 1.0 Cello

Units scaling factor for mass. Only one of mass and density Units parameters can be initialized to ≠ 0.

Parameter: Units : time Units scaling factor for time double 1.0 Cello

Units scaling factor for time.

Parameter: Units : density Units scaling factor for density double 1.0 Cello

Units scaling factor for density. Only one of mass and density Units parameters can be initialized to ≠ 0.