Commits

Daniel Reynolds  committed 0b8266f Merge

merged to tip

  • Participants
  • Parent commits f322bbc, 912ceaa

Comments (0)

Files changed (274)

 
 == RESOURCES ==
 
-Enzo is developed in the open at:
+Enzo's main webpage is:
 
- * http://enzo.googlecode.com/
+ * http://enzo-project.org
+
+Enzo is developed in the open on bitbucket.org:
+
+ * Stable Version: https://bitbucket.org/enzo/enzo-stable
+ * Development Version: https://bitbucket.org/enzo/enzo-dev
 
 Documentation, including instructions for compilation, can be found at:
 
- * http://docs.enzo.googlecode.com/hg/index.html
+ * http://enzo-project.org/docs/2.2/
 
 Please subscribe to the Enzo Users' mailing list at:
 
  * https://mailman.ucsd.edu/mailman/listinfo/enzo-users-l
 
+You can also follow the Enzo Project on google+ at:
+
+ * https://plus.google.com/115923030596894217717
+
 If you have received this source code through an archive, rather than the
 mercurial version control system, we highly encourage you to upgrade to the
 version controlled source, as no support can be provided for archived
 == DEVELOPERS ==
 
 Many people have contributed to the development of Enzo -- here's just a short
-list of the people who have recently contributed.
+list of the people who have recently contributed, in alphabetical order:
    
-   * Greg Bryan      gbryan@astro.columbia.edu
-   * Tom Abel        tabel@stanford.edu
-   * Michael Norman  mlnorman@ucsd.edu
-   * John Wise       jwise@physics.gatech.edu
-   * Dan Reynolds    reynolds@smu.edu
-   * Michael Kuhlen  mqk@astro.berkeley.edu
-   * Matthew Turk    matthewturk@gmail.com
-   * Brian O'Shea    oshea@msu.edu
-   * Robert Harkness harkness@sdsc.edu
-   * Alexei Kritsuk   akritsuk@ucsd.edu
-   * Elizabeth Tasker taskere@mcmaster.ca
-   * Dave Collins    dcollins@physics.ucsd.edu
-   * Britton Smith   brittonsmith@gmail.com
+   * Tom Abel               tabel@stanford.edu
+   * James Bordner          jobordner@ucsd.edu
+   * Greg Bryan             gbryan@astro.columbia.edu
+   * Renyue Cen             cen@astro.princeton.edu
+   * Dave Collins           dcollins@physics.ucsd.edu
+   * Nathan Goldbaum        nathan12343@gmail.com
+   * Robert Harkness        harkness@sdsc.edu
    * Elizabeth Harper-Clark h-clark@astro.utoronto.ca
-   * Peng Wang       pengw@slac.stanford.edu
-   * Fen Zhao        fenzhao@stanford.edu
-   * James Bordner   jobordner@ucsd.edu
-   * Pascal Paschos  ppaschos@minbari.ucsd.edu
-   * Stephen Skory   sskory@physics.ucsd.edu
-   * Rick Wagner     rwagner@physics.ucsd.edu
-   * Renyue Cen      cen@astro.princeton.edu
-   * Alex Razoumov   razoumov@gmail.com
-   * Cameron Hummels chummels@astro.columbia.edu
-   * JS Oishi        jsoishi@gmail.com
-   * Christine Simpson csimpson@astro.columbia.edu
-   * Samuel Skillman samskillman@gmail.com 
+   * Cameron Hummels        chummels@gmail.com
+   * Alexei Kritsuk         akritsuk@ucsd.edu
+   * Michael Kuhlen         mqk@astro.berkeley.edu
+   * Eve Lee                elee@cita.utoronto.ca
+   * Yuan Li                yuan@astro.columbia.edu
+   * Michael Norman         mlnorman@ucsd.edu
+   * JS Oishi               jsoishi@gmail.com
+   * Brian O'Shea           oshea@msu.edu
+   * Pascal Paschos         ppaschos@minbari.ucsd.edu
+   * Alex Razoumov          razoumov@gmail.com
+   * Dan Reynolds           reynolds@smu.edu
+   * Christine Simpson      csimpson@astro.columbia.edu
+   * Samuel Skillman        samskillman@gmail.com 
+   * Stephen Skory          s@skory.us
+   * Britton Smith          brittonsmith@gmail.com
+   * Elizabeth Tasker       tasker@astro1.sci.hokudai.ac.jp
+   * Matthew Turk           matthewturk@gmail.com
+   * Rick Wagner            rwagner@physics.ucsd.edu
+   * Peng Wang              pengw@slac.stanford.edu
+   * John Wise              jwise@physics.gatech.edu
+   * Fen Zhao               fenzhao@stanford.edu
 
+

File doc/manual/source/EnzoParameters.rst

-.. _parameters:
-
-Enzo Parameter List
-===================
-
-The following is a largely complete list of the parameters that Enzo
-understands, and a brief description of what they mean. They are grouped
-roughly by meaning; an alphabetical list is also available. Parameters for
-individual test problems are also listed here.
-
-This parameter list has two purposes. The first is to describe and explain the
-parameters that can be put into the initial parameter file that begins a run.
-The second is to provide a comprehensive list of all parameters that the code
-uses, including those that go into an output file (which contains a complete
-list of all parameters), so that users can better understand these output
-files.
-
-The parameters fall into a number of categories:
-
-**external**
-    These are user parameters in the sense that they can be set in the
-    parameter file, and provide the primary means of communication
-    between Enzo and the user.
-**internal**
-    These are mostly not set in the parameter file (although strictly
-    speaking they can be) and are generally used for program to
-    communicate with itself (via the restart of output files).
-**obsolete**
-    No longer used.
-**reserved**
-    To be used later.
-
-Generally the external parameters are the only ones that are modified or set,
-but the internal parameters can provide useful information and can sometimes be
-modified so I list them here as well. Some parameters are true/false or on/off
-boolean flags.  Eventually, these may be parsed, but in the meantime, we use the
-common convention of 0 meaning false or off and 1 for true or on.
-
-This list includes parameters for the Enzo 2.0 release.
-
-.. highlight:: none
-
-Stopping Parameters
--------------------
-
-``StopTime`` (external)
-    This parameter specifies the time (in code units) when the
-    calculation will halt. For cosmology simulations, this variable is
-    automatically set by ``CosmologyFinalRedshift``. *No default.*
-``StopCycle`` (external)
-    The cycle (top grid timestep) at which the calculation stops. A
-    value of zero indicates that this criterion is not be used.
-    *Default: 100,000*
-``StopFirstTimeAtLevel`` (external)
-    Causes the simulation to immediately stop when a specified level is
-    reached. Default value 0 (off), possible values are levels 1
-    through maximum number of levels in a given simulation.
-``NumberOfOutputsBeforeExit`` (external)
-    After this many datadumps have been written, the code will exit.  If 
-    set to 0 (default), this option will not be used.  Default: 0.
-``StopCPUTime`` (external)
-    Causes the simulation to stop if the wall time exceeds ``StopCPUTime``.
-    The simulation will output if the wall time after the next
-    top-level timestep will exceed ``StopCPUTime``, assuming that the wall
-    time elapsed during a top-level timestep the same as the previous
-    timestep. In units of seconds. Default: 2.592e6 (30 days)
-``ResubmitOn`` (external)
-    If set to 1, the simulation will stop if the wall time will exceed
-    ``StopCPUTime`` within the next top-level timestep and run a shell
-    script defined in ``ResubmitCommand`` that should resubmit the job
-    for the user. Default: 0.
-``ResubmitCommand`` (external)
-    Filename of a shell script that creates a queuing (e.g. PBS)
-    script from two arguments, the number of processors and parameter
-    file.  This script is run by the root processor when stopping with
-    ``ResubmitOn``. An example script can be found in
-    input/resubmit.sh. Default: (null)
-
-Initialization Parameters
--------------------------
-
-``ProblemType`` (external)
-    This integer specifies the type of problem to be run. Its value
-    causes the correct problem initializer to be called to set up the
-    grid, and also may trigger certain boundary conditions or other
-    problem-dependent routines to be called. The possible values are
-    listed below. Default: none. 
-
-For other problem-specific parameters follow the links below.  The problems
-marked with "hydro_rk" originate from the MUSCL solver package in the enzo installation directory
-``src/enzo/hydro_rk``.  For the 4xx radiation hydrodynamics problem types, see
-the user guides in the installation directory ``doc/implicit_fld`` and ``doc/split_fld``.
-
-============ ====================================
-Problem Type Description and Parameter List
-============ ====================================
-1 	     :ref:`shocktube_param`
-2	     :ref:`wavepool_param`
-3 	     :ref:`shockpool_param`
-4 	     :ref:`doublemach_param`
-5 	     :ref:`shockinabox_param`
-6 	     Implosion
-7 	     SedovBlast
-8 	     KH Instability
-9 	     2D/3D Noh Problem
-10 	     :ref:`rotatingcylinder_param`
-11 	     :ref:`radiatingshock_param`
-12 	     :ref:`freeexpansion_param`
-20 	     :ref:`zeldovichpancake_param`
-21 	     :ref:`pressurelesscollapse_param`
-22 	     :ref:`adiabaticexpansion_param`
-23 	     :ref:`testgravity_param`
-24 	     :ref:`sphericalinfall_param`
-25 	     :ref:`testgravitysphere_param`
-26 	     :ref:`gravityequilibriumtest_param`
-27 	     :ref:`collapsetest_param`
-28 	     TestGravityMotion
-29 	     TestOrbit
-30 	     :ref:`cosmologysimulation_param`
-31 	     :ref:`galaxysimulation_param`
-35 	     :ref:`shearingbox_param`
-40 	     :ref:`supernovarestart_param`
-50 	     :ref:`photontest_param`
-60 	     Turbulence Simulation
-61 	     Protostellar Collapse
-62 	     :ref:`coolingtest_param`
-101	     3D Collapse Test (hydro_rk)
-102	     1D Spherical Collapse Test (hydro_rk)
-106	     Hydro and MHD Turbulence Simulation (hydro_rk)
-107 	     Put Sink from restart
-200	     1D MHD Test
-201	     2D MHD Test
-202	     3D MHD Collapse Test
-203	     MHD Turbulent Collapse Test
-207	     Galaxy disk
-208	     AGN disk
-300	     Poisson solver test
-400 	     Radiation-Hydrodynamics test 1 -- constant fields
-401 	     Radiation-Hydrodynamics test 2 -- stream test
-402 	     Radiation-Hydrodynamics test 3 -- pulse test
-403 	     Radiation-Hydrodynamics test 4 -- grey Marshak test
-404/405	     Radiation-Hydrodynamics test 5 -- radiating shock test
-410/411	     Radiation-Hydrodynamics test 10/11 -- Static HI ionization
-412 	     Radiation-Hydrodynamics test 12 -- HI ionization of a clump
-413 	     Radiation-Hydrodynamics test 13 -- HI ionization of a steep region
-414/415	     Radiation-Hydrodynamics test 14/15 -- Cosmological HI ionization
-450-452	     Free-streaming radiation tests
-============ ====================================
-
-.. raw:: html
-
-   <p></p>
-
-``TopGridRank`` (external)
-    This specifies the dimensionality of the root grid and by extension
-    the entire hierarchy. It should be 1,2 or 3. Default: none
-``TopGridDimensions`` (external)
-    This is the dimension of the top or root grid. It should consist of
-    1, 2 or 3 integers separated by spaces. For those familiar with the
-    KRONOS or ZEUS method of specifying dimensions, these values do not
-    include ghost or boundary zones. A dimension cannot be less than 3
-    zones wide and more than ``MAX_ANY_SINGLE_DIRECTION`` -
-    ``NumberOfGhostZones``\*2. ``MAX_ANY_SINGLE_DIRECTION`` is defined in
-    ``fortran.def``. Default: none
-``DomainLeftEdge``, ``DomainRightEdge`` (external)
-    These float values specify the two corners of the problem domain
-    (in code units). The defaults are: 0 0 0 for the left edge and 1 1
-    1 for the right edge.
-``LeftFaceBoundaryCondition``, ``RightFaceBoundaryCondition`` (external)
-    These two parameters each consist of vectors of integers (of length
-    ``TopGridRank``). They specify the boundary conditions for the top grid
-    (and hence the entire hierarchy). The first integer corresponds to
-    the x-direction, the second to the y-direction and the third, the
-    z-direction. The possible values are: 0 - reflecting, 1 - outflow,
-    2 - inflow, 3 - periodic, 4 - shearing. For inflow, the inflow
-    values can be set through the next parameter, or more commonly are
-    controlled by problem-specific code triggered by the ``ProblemType``.
-    For shearing boundaries, the boundary pair in another direction
-    must be periodic. Note that self gravity will not be consistent
-    with shearing boundary conditions. Default: 0 0 0
-``ShearingVelocityDirection`` (external)
-    Select direction of shearing boundary. Default is x direction. Changing this is probably not a good idea.
-``AngularVelocity`` (external)
-    The value of the angular velocity in the shearing boundary.
-    Default: 0.001
-``VelocityGradient`` (external)
-    The value of the per code length gradient in the angular velocity
-    in the shearing boundary. Default: 1.0
-``BoundaryConditionName`` (external)
-    While the above parameters provide an easy way to set an entire
-    side of grid to a given boundary value, the possibility exists to
-    set the boundary conditions on an individual cell basis. This is
-    most often done with problem specific code, but it can also be set
-    by specifying a file which contains the information in the
-    appropriate format. This is too involved to go into here. Default:
-    none
-``InitialTime`` (internal)
-    The time, in code units, of the current step. For cosmology the
-    units are in free-fall times at the initial epoch (see :ref:`EnzoOutputFormats`). Default: generally 0, depending on problem
-``Initialdt`` (internal)
-    The timestep, in code units, for the current step. For cosmology
-    the units are in free-fall times at the initial epoch (see :ref:`EnzoOutputFormats`). Default: generally 0, depending on problem
-
-Simulation Identifiers and UUIDs
---------------------------------
-
-These parameters help to track, identify and group datasets. For reference,
-`Universally Unique Identifiers
-<http://en.wikipedia.org/wiki/Universally_Unique_Identifier>`_ (UUIDs) are
-opaque identifiers using random 128-bit numbers, with an extremely low chance
-of collision. (See :ref:`SimulationNamesAndIdentifiers` for a longer
-description of these parameters.)
-
-``MetaDataIdentifier`` (external)
-    This is a character string without spaces (specifically, something
-    that can be picked by "%s"), that can be defined in a parameter
-    file, and will be written out in every following output, if it is
-    found.
-``MetaDataSimulationUUID`` (internal)
-    A UUID that will be written out in all of the following outputs.
-    Like ``MetaDataIdentifier``, an existing UUID will be kept, but if one
-    is not found, and new one will be generated.
-``MetaDataDatasetUUID`` (internal)
-    A UUID created for each specific output.
-``MetaDataRestartDatasetUUID`` (internal)
-    If a ``MetaDataDatasetUUID`` UUID is found when the parameter file is
-    read in, it will written to the following datasets. This is used to
-    track simulations across restarts and parameter adjustments.
-``MetaDataInitialConditionsUUID`` (internal)
-    This is similar to ``MetaDataRestartDatasetUUID``, except it's used to
-    track which initial conditions were used.
-
-I/O Parameters
---------------
-
-There are three ways to specify the frequency of outputs:
-time-based, cycle-based (a cycle is a top-grid timestep), and, for
-cosmology simulations, redshift-based. There is also a shortened
-output format intended for visualization (movie format). Please
-have a look at :ref:`controlling_data_output` for more information.
-
-``dtDataDump`` (external)
-    The time interval, in code units, between time-based outputs. A
-    value of 0 turns off the time-based outputs. Default: 0
-``CycleSkipDataDump`` (external)
-    The number of cycles (top grid timesteps) between cycle-based
-    outputs. Zero turns off the cycle-based outputs. Default: 0
-``DataDumpName`` (external)
-    The base file name used for both time and cycle based outputs.
-    Default: data
-``RedshiftDumpName`` (external)
-    The base file name used for redshift-based outputs (this can be
-    overridden by the ``CosmologyOutputRedshiftName`` parameter). Normally
-    a four digit identification number is appended to the end of this
-    name, starting from 0000 and incrementing by one for every output.
-    This can be over-ridden by including four consecutive R's in the
-    name (e.g. RedshiftRRRR) in which case the an identification number
-    will not be appended but the four R's will be converted to a
-    redshift with an implied decimal point in the middle (i.e. z=1.24
-    becomes 0124). Default: RedshiftOutput
-``CosmologyOutputRedshift[NNNN]`` (external)
-    The time and cycle-based outputs occur regularly at constant
-    intervals, but the redshift outputs are specified individually.
-    This is done by the use of this statement, which sets the output
-    redshift for a specific identification number (this integer is
-    between 0000 and 9999 and is used in forming the name). So the
-    statement ``CosmologyOutputRedshift[1] = 4.0`` will cause an output to
-    be written out at z=4 with the name RedshiftOutput0001 (unless the
-    base name is changed either with the previous parameter or the next
-    one). This parameter can be repeated with different values for the
-    number (NNNN) Default: none
-``CosmologyOutputRedshiftName[NNNN]`` (external)
-    This parameter overrides the parameter ``RedshiftOutputName`` for this
-    (only only this) redshift output. Can be used repeatedly in the
-    same manner as the previous parameter. Default: none
-``OutputFirstTimeAtLevel`` (external)
-    This forces Enzo to output when a given level is reached, and at
-    every level thereafter. Default is 0 (off). User can usefully
-    specify anything up to the maximum number of levels in a given
-    simulation.
-``FileDirectedOutput``
-    If this parameter is set to 1, whenever the finest level has finished
-    evolving Enzo will check for new signal files to output.  (See
-    :ref:`force_output_now`.)  Default 1.
-``XrayLowerCutoffkeV``, ``XrayUpperCutoffkeV``, ``XrayTableFileName`` (external)
-    These parameters are used in 2D projections (``enzo -p ...``). The
-    first two specify the X-ray band (observed at z=0) to be used, and
-    the last gives the name of an ascii file that contains the X-ray
-    spectral information. A gzipped version of this file good for
-    bands within the 0.1 - 20 keV range is provided in the
-    distribution in ``input/lookup_metal0.3.data``. If these
-    parameters are specified, then the second field is replaced with
-    integrated emissivity along the line of sight in units of 10\
-    :sup:`-23` erg/cm\ :sup:`2`/s. Default: ``XrayLowerCutoffkeV =
-    0.5``, ``XrayUpperCutoffkeV = 2.5``.
-``ExtractFieldsOnly`` (external)
-    Used for extractions (enzo -x ...) when only field data are needed
-    instead of field + particle data. Default is 1 (TRUE).
-``dtRestartDump``
-    Reserved for future use.
-``dtHistoryDump``
-    Reserved for future use.
-``CycleSkipRestartDump``
-    Reserved for future use.
-``CycleSkipHistoryDump``
-    Reserved for future use.
-``RestartDumpName``
-    Reserved for future use.
-``HistoryDumpName``
-    Reserved for future use.
-``ParallelRootGridIO`` (external)
-    Normally for the mpi version, the root grid is read into the root
-    processor and then partitioned to separate processors using communication.
-    However, for
-    very large root grids (e.g. 512\ :sup:`3`\ ), the root processor
-    may not have enough memory. If this toggle switch is set on (i.e.
-    to the value 1), then each processor reads its own section of the
-    root grid. More I/O is required (to split up the grids and
-    particles), but it is more balanced in terms of memory.
-    ``ParallelRootGridIO`` and ``ParallelParticleIO`` MUST be set to 1 (TRUE)
-    for runs involving > 64 cpus! Default: 0 (FALSE). See also ``Unigrid``
-    below.
-``Unigrid`` (external)
-    This parameter should be set to 1 (TRUE) for large cases--AMR as
-    well as non-AMR--where the root grid is 512\ :sup:`3`\  or larger.
-    This prevents initialization under subgrids at start up, which is
-    unnecessary in cases with simple non-nested initial conditions.
-    Unigrid must be set to 0 (FALSE) for cases with nested initial
-    conditions. Default: 0 (FALSE). See also ``ParallelRootGridIO`` above.
-``UnigridTranspose`` (external)
-    This parameter governs the fast FFT bookkeeping for Unigrid runs.
-    Does not work with isolated gravity. Default: 0 (FALSE). See also
-    ``Unigrid`` above.
-``OutputTemperature`` (external)
-    Set to 1 if you want to output a temperature field in the datasets.
-    Always 1 for cosmology simulations. Default: 0.
-``OutputCoolingTime`` (external)
-    Set to 1 if you want to output the cooling time in the datasets.
-    Default: 0.
-``OutputSmoothedDarkMatter`` (external)
-    Set to 1 if you want to output a dark matter density field,
-    smoothed by an SPH kernel. Set to 2 to also output smoothed dark
-    matter velocities and velocity dispersion. Set to 0 to turn off.
-    Default: 0.
-``OutputGriddedStarParticle`` (external)
-    Set to 1 or 2 to write out star particle data gridded onto mesh.
-    This will be useful e.g. if you have lots of star particles in a
-    galactic scale simulation. 1 will output just
-    ``star_particle_density``; and 2 will dump
-    ``actively_forming_stellar_mass_density``, ``SFR_density``, etc.
-    Default: 0.
-``VelAnyl`` (external)
-    Set to 1 if you want to output the divergence and vorticity of
-    velocity. Works in 2D and 3D.
-``BAnyl`` (external)
-    Set to 1 if you want to output the divergence and vorticity of
-    ``Bfield``. Works in 2D and 3D.
-``SmoothedDarkMatterNeighbors`` (external)
-    Number of nearest neighbors to smooth dark matter quantities over.
-    Default: 32.
-
-.. _streaming_param:
-
-Streaming Data Format
-~~~~~~~~~~~~~~~~~~~~~
-
-``NewMovieLeftEdge``, ``NewMovieRightEdge`` (external)
-    These two parameters control the region for which the streaming
-    data are written. Default: ``DomainLeftEdge`` and ``DomainRightEdge``.
-``MovieSkipTimestep`` (external)
-    Controls how many timesteps on a level are skipped between outputs
-    in the streaming data. Streaming format is off if this equals
-    ``INT_UNDEFINED``. Default: ``INT_UNDEFINED``
-``Movie3DVolume`` (external)
-    Set to 1 to write streaming data as 3-D arrays. This should always
-    be set to 1 if using the streaming format. A previous version had
-    2D maximum intensity projections, which now defunct. Default: 0.
-``MovieVertexCentered`` (external)
-    Set to 1 to write the streaming data interpolated to vertices. Set
-    to 0 for cell-centered data. Default: 0.
-``NewMovieDumpNumber`` (internal)
-    Counter for streaming data files. This should equal the cycle
-    number.
-``MovieTimestepCounter`` (internal)
-    Timestep counter for the streaming data files.
-``MovieDataField`` (external)
-    A maximum of 6 data fields can be written in the streaming format.
-    The data fields are specified by the array element of
-    BaryonField, i.e. 0 = Density, 7 = HII
-    Density. For writing temperature, a special value of 1000 is used.
-    This should be improved to be more transparent in which fields will
-    be written. Any element that equals ``INT_UNDEFINED`` indicates no
-    field will be written. Default: ``INT_UNDEFINED`` x 6
-``NewMovieParticleOn`` (external)
-    Set to 1 to write all particles in the grids. Set to 2 to write
-    ONLY particles that aren't dark matter, e.g. stars. Set to 3/4 to
-    write ONLY particles that aren't dark matter into a file separate
-    from the grid info. (For example, ``MoviePackParticle_P000.hdf5``,
-    etc. will be the file name; this will be very helpful in speeding
-    up the access to the star particle data, especially for the
-    visualization or for the star particle. See ``AMRH5writer.C``) Set to 0
-    for no particle output. Default: 0.
-
-Hierarchy Control Parameters
-----------------------------
-
-``StaticHierarchy`` (external)
-    A flag which indicates if the hierarchy is static (1) or dynamic
-    (0). In other words, a value of 1 takes the A out of AMR. Default:
-    1
-``RefineBy`` (external)
-    This is the refinement factor between a grid and its subgrid. For
-    cosmology simulations, we have found a ratio of 2 to be most useful.
-    Default: 4
-``MaximumRefinementLevel`` (external)
-    This is the lowest (most refined) depth that the code will produce.
-    It is zero based, so the total number of levels (including the root
-    grid) is one more than this value. Default: 2
-``CellFlaggingMethod`` (external)
-    The method(s) used to specify when a cell should be refined. This
-    is a list of integers, up to 9, as described by the following
-    table. The methods combine in an "OR" fashion: if any of them
-    indicate that a cell should be refined, then it is flagged. For
-    cosmology simulations, methods 2 and 4 are probably most useful.
-    Note that some methods have additional parameters which are
-    described below. Default: 1
-
-    :: 
-
-       1 - refine by slope		       6  - refine by Jeans length
-       2 - refine by baryon mass	       7  - refine if (cooling time < cell width/sound speed)
-       3 - refine by shocks 		       11 - refine by resistive length
-       4 - refine by particle mass	       12 - refine by defined region "MustRefineRegion"
-       5 - refine by baryon overdensity	       13 - refine by metallicity
-       	  (currently disabled)
-       101 - avoid refinement in regions
-             defined in "AvoidRefineRegion"
-
-``RefineRegionLeftEdge``, ``RefineRegionRightEdge`` (external)
-    These two parameters control the region in which refinement is
-    permitted. Each is a vector of floats (of length given by the
-    problem rank) and they specify the two corners of a volume.
-    Default: set equal to ``DomainLeftEdge`` and ``DomainRightEdge``.
-``RefineRegionAutoAdjust`` (external)
-    This is useful for multiresolution simulations with particles in
-    which the particles have varying mass. Set to 1 to automatically
-    adjust the refine region at root grid timesteps to only contain
-    high-resolution particles. This makes sure that the fine regions do
-    not contain more massive particles which may lead to small
-    particles orbiting them or other undesired outcomes. Setting to any
-    integer (for example, 3) will make AdjustRefineRegion to work at
-    (RefineRegionAutoAdjust-1)th level timesteps because sometimes the
-    heavy particles are coming into the fine regions too fast that you
-    need more frequent protection. Default: 0.
-``RefineRegionTimeType`` (external)
-    If set, this controls how the first column of a refinement region
-    evolution file (see below) is interpreted, 0 for code time, 1 for
-    redshift. Default: -1, which is equivalent to 'off'.
-``RefineRegionFile`` (external)
-    The name of a text file containing the corners of the time-evolving
-    refinement region. The lines in the file change the values of
-    ``RefineRegionLeft/RightEdge`` during the course of the simulation, and
-    the lines are ordered in the file from early times to late times.
-    The first column of data is the time index (in code units or
-    redshift, see the parameter above) for the next six columns, which
-    are the values of ``RefineRegionLeft/RightEdge``. For example, this
-    might be two lines from the text file when time is indexed by
-    redshift:
-    ::
-
-        0.60 0.530 0.612 0.185 0.591 0.667 0.208
-        0.55 0.520 0.607 0.181 0.584 0.653 0.201
-
-    In this case, the refinement region stays at the z=0.60 value
-    until z=0.55, when the box moves slightly closer to the (0,0,0)
-    corner. There is a maximum of 300 lines in the file and there is no
-    comment header line. Default: None.
-``MinimumOverDensityForRefinement`` (external)
-    These float values (up to 9) are used if the
-    ``CellFlaggingMethod`` is 2, 4 or 5. For method 2 and 4, the value is the density (baryon or particle), in code units, above which refinement occurs. When using method 5, it becomes rho [code] - 1. The elements in this array must match those in ``CellFlaggingMethod``. Therefore, if ``CellFlaggingMethod`` = 1 4 9 10, ``MinimumOverDensityForRefinement`` = 0 8.0 0 0.
-
-    In practice, this value is converted into a mass by
-    multiplying it by the volume of the top grid cell. The result is
-    then stored in the next parameter (unless that is set directly in
-    which case this parameter is ignored), and this defines the mass
-    resolution of the simulation. Note that the volume is of a top grid
-    cell, so if you are doing a multi-grid initialization, you must
-    divide this number by r\ :sup:`(d\*l)`\  where r is the refinement
-    factor, d is the dimensionality and l is the (zero-based) lowest
-    level. For example, for a two grid cosmology setup where a cell should be
-    refined whenever the mass exceeds 4 times the mean density of the
-    subgrid, this value should be 4 / (2\ :sup:`(3\*1)`\ ) = 4 / 8 =
-    0.5. Keep in mind that this parameter has no effect if it is
-    changed in a restart output; if you want to change the refinement
-    mid-run you will have to modify the next parameter. Up to 9
-    numbers may be specified here, each corresponding to the respective
-    ``CellFlaggingMethod``. Default: 1.5
-``MinimumMassForRefinement`` (internal)
-    This float is usually set by the parameter above and so is labeled
-    internal, but it can be set by hand. For non-cosmological simulations, it can be the easier refinement criteria to specify. It is the mass above
-    which a refinement occurs if the ``CellFlaggingMethod`` is
-    appropriately set. For cosmological simulations, it is specified in units such
-    that the entire mass in the computational volume is 1.0, otherwise it is in code units. There are 9 numbers here again, as per the
-    above parameter. Default: none
-``MinimumMassForRefinementLevelExponent`` (external).
-    This parameter modifies the behaviour of the above parameter. As it
-    stands, the refinement based on the ``MinimumMassForRefinement``
-    (hereafter Mmin) parameter is complete Lagrangian. However, this
-    can be modified. The actual mass used is
-    Mmin\*r\ :sup:`(l\*alpha)`\  where r is the refinement factor, l is
-    the level and alpha is the value of this parameter
-    (``MinimumMassForRefinementLevelExponent``). Therefore a negative value
-    makes the refinement super-Lagrangian, while positive values are
-    sub-Lagrangian. There are up to 9 values specified here, as per
-    the above two parameters. Default: 0.0
-``SlopeFlaggingFields[#]`` (external)
-    If ``CellFlaggingMethod`` is 1, and you only want to refine on the
-    slopes of certain fields then you can enter the number IDs of the
-    fields. Default: Refine on slopes of all fields.
-``MinimumSlopeForRefinement`` (external)
-    If ``CellFlaggingMethod`` is 1, then local gradients are used as the
-    refinement criteria. All variables are examined and the relative
-    slope is computed: abs(q(i+1)-q(i-1))/q(i). Where this value
-    exceeds this parameter, the cell is marked for refinement. This
-    causes problems if q(i) is near zero. This is a single integer (as
-    opposed to the list of five for the above parameters). Entering
-    multiple numbers here correspond to the fields listed in
-    ``SlopeFlaggingFields``. Default: 0.3
-``MinimumPressureJumpForRefinement`` (external)
-    If refinement is done by shocks, then this is the minimum
-    (relative) pressure jump in one-dimension to qualify for a shock.
-    The definition is rather standard (see Colella and Woodward's PPM
-    paper for example) Default: 0.33
-``MinimumEnergyRatioForRefinement`` (external)
-    For the dual energy formalism, and cell flagging by
-    shock-detection, this is an extra filter which removes weak shocks
-    (or noise in the dual energy fields) from triggering the shock
-    detection. Default: 0.1
-``MetallicityRefinementMinLevel`` (external)
-    Sets the minimum level (maximum cell size) to which a cell enriched
-    with metal above a level set by ``MetallicityRefinementMinMetallicity``
-    will be refined. This can be set to any level up to and including
-    ``MaximumRefinementLevel``. (No default setting)
-``MetallicityRefinementMinMetallicity`` (external)
-    This is the threshold metallicity (in units of solar metallicity)
-    above which cells must be refined to a minimum level of
-    ``MetallicityRefinementMinLevel``. Default: 1.0e-5
-``MustRefineRegionMinRefinementLevel`` (external)
-    Minimum level to which the rectangular solid volume defined by
-    ``MustRefineRegionLeftEdge`` and ``MustRefineRegionRightEdge`` will be
-    refined to at all times. (No default setting)
-``MustRefineRegionLeftEdge`` (external)
-    Bottom-left corner of refinement region. Must be within the overall
-    refinement region. Default: 0.0 0.0 0.0
-``MustRefineRegionRightEdge`` (external)
-    Top-right corner of refinement region. Must be within the overall
-    refinement region. Default: 1.0 1.0 1.0
-``MustRefineParticlesRefineToLevel`` (external)
-    The maximum level on which ``MustRefineParticles`` are required to
-    refine to. Currently sink particles and MBH particles are required
-    to be sitting at this level at all times. Default: 0
-``MustRefineParticlesRefineToLevelAutoAdjust`` (external)
-    The parameter above might not be handy in cosmological simulations
-    if you want your ``MustRefineParticles`` to be refined to a certain
-    physical length, not to a level whose cell size keeps changing.
-    This parameter (positive integer in pc) allows you to do just that.
-    For example, if you set ``MustRefineParticlesRefineToLevelAutoAdjust``
-    = 128 (pc), then the code will automatically calculate
-    ``MustRefineParticlesRefineToLevel`` using the boxsize and redshift
-    information. Default: 0 (FALSE)
-``FluxCorrection`` (external)
-    This flag indicates if the flux fix-up step should be carried out
-    around the boundaries of the sub-grid to preserve conservation (1 -
-    on, 0 - off). Strictly speaking this should always be used, but we
-    have found it to lead to a less accurate solution for cosmological
-    simulations because of the relatively sharp density gradients
-    involved. However, it does appear to be important when radiative
-    cooling is turned on and very dense structures are created.
-    It does work with the ZEUS
-    hydro method, but since velocity is face-centered, momentum flux is
-    not corrected. Species quantities are not flux corrected directly
-    but are modified to keep the fraction constant based on the density
-    change. Default: 1
-``InterpolationMethod`` (external)
-    There should be a whole section devoted to the interpolation
-    method, which is used to generate new sub-grids and to fill in the
-    boundary zones of old sub-grids, but a brief summary must suffice.
-    The possible values of this integer flag are shown in the table
-    below. The names specify (in at least a rough sense) the order of
-    the leading error term for a spatial Taylor expansion, as well as a
-    letter for possible variants within that order. The basic problem
-    is that you would like your interpolation method to be:
-    multi-dimensional, accurate, monotonic and conservative. There
-    doesn't appear to be much literature on this, so I've had to
-    experiment. The first one (ThirdOrderA) is time-consuming and
-    probably not all that accurate. The second one (SecondOrderA) is
-    the workhorse: it's only problem is that it is not always
-    symmetric. The next one (SecondOrderB) is a failed experiment, and
-    SecondOrderC is not conservative. FirstOrderA is everything except
-    for accurate. If HydroMethod = 2 (ZEUS), this flag is ignored, and
-    the code automatically uses SecondOrderC for velocities and
-    FirstOrderA for cell-centered quantities. Default: 1
-    ::
-
-              0 - ThirdOrderA     3 - SecondOrderC
-              1 - SecondOrderA    4 - FirstOrderA
-              2 - SecondOrderB  
-
-
-``ConservativeInterpolation`` (external)
-    This flag (1 - on, 0 - off) indicates if the interpolation should
-    be done in the conserved quantities (e.g. momentum rather than
-    velocity). Ideally, this should be done, but it can cause problems
-    when strong density gradients occur. This must(!) be set off for
-    ZEUS hydro (the code does it automatically). Default: 1
-``MinimumEfficiency`` (external)
-    When new grids are created during the rebuilding process, each grid
-    is split up by a recursive bisection process that continues until a
-    subgrid is either of a minimum size or has an efficiency higher
-    than this value. The efficiency is the ratio of flagged zones
-    (those requiring refinement) to the total number of zones in the
-    grid. This is a number between 0 and 1 and should probably by
-    around 0.4 for standard three-dimensional runs. Default: 0.2
-``NumberOfBufferZones`` (external)
-    Each flagged cell, during the regridding process, is surrounded by
-    a number of zones to prevent the phenomenon of interest from
-    leaving the refined region before the next regrid. This integer
-    parameter controls the number required, which should almost always
-    be one. Default: 1
-``RefineByJeansLengthSafetyFactor`` (external)
-    If the Jeans length refinement criterion (see ``CellFlaggingMethod``)
-    is being used, then this parameter specifies the number of cells
-    which must cover one Jeans length. Default: 4
-``JeansRefinementColdTemperature`` (external)
-    If the Jeans length refinement criterion (see ``CellFlaggingMethod``)
-    is being used, and this parameter is greater than zero, it will be
-    used in place of the temperature in all cells. Default: -1.0
-``StaticRefineRegionLevel[#]`` (external)
-    This parameter is used to specify regions of the problem that are
-    to be statically refined, regardless of other parameters. This is mostly
-    used as an internal mechanism to keep the initial grid hierarchy in
-    place, but can be specified by the user. Up to 20 static regions
-    may be defined (this number set in ``macros_and_parameters.h``), and
-    each static region is labeled starting from zero. For each static
-    refined region, two pieces of information are required: (1) the
-    region (see the next two parameters), and (2) the level at which
-    the refinement is to occurs (0 implies a level 1 region will always
-    exist). Default: none
-``StaticRefineRegionLeftEdge[#]``, ``StaticRefineRegionRightEdge[#]`` (external)
-    These two parameters specify the two corners of a statically
-    refined region (see the previous parameter). Default: none
-``AvoidRefineRegionLevel[#]`` (external)
-    This parameter is used to limit the refinement to this level in a
-    rectangular region.  Up to MAX_STATIC_REGIONS regions can be used.
-``AvoidRefineRegionLeftEdge[#]``, ``AvoidRefineRegionRightEdge[#]`` (external) 
-    These two parameters specify the two corners of a region that
-    limits refinement to a certain level (see the previous
-    parameter). Default: none
-``RefineByResistiveLength`` (external)
-    Resistive length is defined as the curl of the magnetic field over
-    the magnitude of the magnetic field. We make sure this length is
-    covered by this number of cells. Default: 2
-``LoadBalancing`` (external)
-    Set to 0 to keep child grids on the same processor as their
-    parents. Set to 1 to balance the work on one level over all
-    processors. Set to 2 or 3 to load balance the grids but keep them
-    on the same node. Option 2 assumes grouped scheduling, i.e. proc #
-    = (01234567) reside on node (00112233) if there are 4 nodes. Option
-    3 assumes round-robin scheduling (proc = (01234567) -> node =
-    (01230123)). Set to 4 for load balancing along a Hilbert
-    space-filling curve on each level. Default: 1
-``LoadBalancingCycleSkip`` (external)
-    This sets how many cycles pass before we load balance the root
-    grids. Only works with LoadBalancing set to 2 or 3. NOT RECOMMENDED
-    for nested grid calculations. Default: 10
-
-Hydrodynamic Parameters
------------------------
-
-``UseHydro`` (external)
-    This flag (1 - on, 0 - off) controls whether a hydro solver is used.  
-    Default: 1
-``HydroMethod`` (external)
-    This integer specifies the hydrodynamics method that will be used.
-    Currently implemented are
-
-    ============ =============================
-    Hydro method Description
-    ============ =============================
-    0            PPM DE (a direct-Eulerian version of PPM)
-    1            [reserved]
-    2            ZEUS (a Cartesian, 3D version of Stone & Norman). Note that if ZEUS is selected, it automatically turns off ``ConservativeInterpolation`` and the ``DualEnergyFormalism`` flags.
-    3            Runge Kutta second-order based MUSCL solvers.
-    4            Same as 3 but including Dedner MHD (Wang & Abel 2008). For 3 and 4 there are the additional parameters ``RiemannSolver`` and ``ReconstructionMethod`` you want to set.
-    ============ =============================
-
-    Default: 0
-
-    More details on each of the above methods can be found at :ref:`hydro_methods`.
-``RiemannSolver`` (external; only if ``HydroMethod`` is 3 or 4)
-    This integer specifies the Riemann solver used by the MUSCL solver. Choice of
-
-    ============== ===========================
-    Riemann solver Description
-    ============== ===========================
-    0              [reserved]
-    1              HLL (Harten-Lax-van Leer) a two-wave, three-state solver with no resolution of contact waves
-    2              [reserved]
-    3              LLF (Local Lax-Friedrichs)
-    4              HLLC (Harten-Lax-van Leer with Contact) a three-wave, four-state solver with better resolution of contacts
-    5              TwoShock
-    ============== ===========================
-
-    Default: 1 (HLL) for ``HydroMethod`` = 3; 5 (TwoShock) for
-    ``HydroMethod`` = 0
-
-``RiemannSolverFallback`` (external)
-    If the euler update results in a negative density or energy, the
-    solver will fallback to the HLL Riemann solver that is more
-    diffusive only for the failing cell.  Only active when using the
-    HLLC or TwoShock Riemann solver.  Default: OFF.
-``ReconstructionMethod`` (external; only if ``HydroMethod`` is 3 or 4)
-    This integer specifies the reconstruction method for the MUSCL solver. Choice of
-
-    ===================== ====================
-    Reconstruction Method Description
-    ===================== ====================
-    0                     PLM (piecewise linear)
-    1                     PPM (piecwise parabolic)
-    2                     [reserved]
-    3                     [reserved]
-    4                     [reserved]
-    ===================== ====================
-
-    Default: 0 (PLM) for ``HydroMethod`` = 3; 1 (PPM) for ``HydroMethod`` = 0
-
-``Gamma`` (external)
-    The ratio of specific heats for an ideal gas (used by all hydro
-    methods). If using multiple species (i.e. ``MultiSpecies`` > 0), then
-    this value is ignored in favor of a direct calculation (except for
-    PPM LR) Default: 5/3.
-``Mu`` (external)
-    The molecular weight. Default: 0.6.
-``ConservativeReconstruction`` (external)
-    Experimental.  This option turns on the reconstruction of the
-    left/right interfaces in the Riemann problem in the conserved
-    variables (density, momentum, and energy) instead of the primitive
-    variables (density, velocity, and pressure).  This generally gives
-    better results in constant-mesh problems has been problematic in
-    AMR simulations.  Default: OFF
-``PositiveReconstruction`` (external)
-    Experimental and not working.  This forces the Riemann solver to
-    restrict the fluxes to always give positive pressure.  Attempts to
-    use the Waagan (2009), JCP, 228, 8609 method.  Default: OFF
-``CourantSafetyNumber`` (external)
-    This is the maximum fraction of the CFL-implied timestep that will
-    be used to advance any grid. A value greater than 1 is unstable
-    (for all explicit methods). The recommended value is 0.4. Default:
-    0.6.
-``RootGridCourantSafetyNumber`` (external)
-    This is the maximum fraction of the CFL-implied timestep that will
-    be used to advance ONLY the root grid. When using simulations with
-    star particle creation turned on, this should be set to a value of
-    approximately 0.01-0.02 to keep star particles from flying all over
-    the place. Otherwise, this does not need to be set, and in any case
-    should never be set to a value greater than 1.0. Default: 1.0.
-``DualEnergyFormalism`` (external)
-    The dual energy formalism is needed to make total energy schemes
-    such as PPM DE and PPM LR stable and accurate in the
-    "hyper-Machian" regime (i.e. where the ratio of thermal energy to
-    total energy < ~0.001). Turn on for cosmology runs with PPM DE and
-    PPM LR. Automatically turned off when used with the hydro method
-    ZEUS. Integer flag (0 - off, 1 - on). When turned on, there are two
-    energy fields: total energy and thermal energy. Default: 0
-``DualEnergyFormalismEta1``, ``DualEnergyFormalismEta2`` (external)
-    These two parameters are part of the dual energy formalism and
-    should probably not be changed. Defaults: 0.001 and 0.1
-    respectively.
-``PressureFree`` (external)
-    A flag that is interpreted by the PPM DE hydro method as an
-    indicator that it should try and mimic a pressure-free fluid. A
-    flag: 1 is on, 0 is off. Default: 0
-``PPMFlatteningParameter`` (external)
-    This is a PPM parameter to control noise for slowly-moving shocks.
-    It is either on (1) or off (0). Default: 0
-``PPMDiffusionParameter`` (external)
-    This is the PPM diffusion parameter (see the Colella and Woodward
-    method paper for more details). It is either on (1) or off (0).
-    Default: 1 [Currently disabled (set to 0)]
-``PPMSteepeningParameter`` (external)
-    A PPM modification designed to sharpen contact discontinuities. It
-    is either on (1) or off (0). Default: 0
-``ZEUSQuadraticArtificialViscosity`` (external)
-    This is the quadratic artificial viscosity parameter C2 of Stone &
-    Norman, and corresponds (roughly) to the number of zones over which
-    a shock is spread. Default: 2.0
-``ZEUSLinearArtificialViscosity`` (external)
-    This is the linear artificial viscosity parameter C1 of Stone &
-    Norman. Default: 0.0
-
-Magnetohydrodynamic Parameters
-------------------------------
-
-``UseDivergenceCleaning`` (external)
-    Method 1 and 2 are a failed experiment to do divergence cleaning
-    using successive over relaxation. Method 3 uses conjugate gradient
-    with a 2 cell stencil and Method 4 uses a 4 cell stencil. 4 is more
-    accurate but can lead to aliasing effects. Default: 0
-``DivergenceCleaningBoundaryBuffer`` (external)
-    Choose to *not* correct in the active zone of a grid by a
-    boundary of cells this thick. Default: 0
-``DivergenceCleaningThreshold`` (external)
-    Calls divergence cleaning on a grid when magnetic field divergence
-    is above this threshold. Default: 0.001
-``PoissonApproximateThreshold`` (external)
-    Controls the accuracy of the resulting solution for divergence
-    cleaning Poisson solver. Default: 0.001
-``ResetMagneticField`` (external)
-    Set to 1 to reset the magnetic field in the regions that are denser
-    than the critical matter density. Very handy when you want to
-    re-simulate or restart the dumps with MHD. Default: 0
-``ResetMagneticFieldAmplitude`` (external)
-    The magnetic field values (in Gauss) that will be used for the
-    above parameter. Default: 0.0 0.0 0.0
-
-Cosmology Parameters
---------------------
-
-``ComovingCoordinates`` (external)
-    Flag (1 - on, 0 - off) that determines if comoving coordinates are
-    used or not. In practice this turns on or off the entire cosmology
-    machinery. Default: 0
-``CosmologyFinalRedshift`` (external)
-    This parameter specifies the redshift when the calculation will
-    halt. Default: 0.0
-``CosmologyOmegaMatterNow`` (external)
-    This is the contribution of all non-relativistic matter (including
-    HDM) to the energy density at the current epoch (z=0), relative to
-    the value required to marginally close the universe. It includes
-    dark and baryonic matter. Default: 0.279
-``CosmologyOmegaLambdaNow`` (external)
-    This is the contribution of the cosmological constant to the energy
-    density at the current epoch, in the same units as above. Default:
-    0.721
-``CosmologyComovingBoxSize`` (external)
-    The size of the volume to be simulated in Mpc/h (at z=0). Default:
-    64.0
-``CosmologyHubbleConstantNow`` (external)
-    The Hubble constant at z=0, in units of 100 km/s/Mpc. Default:
-    0.701
-``CosmologyInitialRedshift`` (external)
-    The redshift for which the initial conditions are to be generated.
-    Default: 20.0
-``CosmologyMaxExpansionRate`` (external)
-    This float controls the timestep so that cosmological terms are
-    accurate followed. The timestep is constrained so that the relative
-    change in the expansion factor in a step is less than this value.
-    Default: 0.01
-``CosmologyCurrentRedshift`` (information only)
-    This is not strictly speaking a parameter since it is never
-    interpreted and is only meant to provide information to the user.
-    Default: n/a
-
-Gravity Parameters
-------------------
-
-``TopGridGravityBoundary`` (external)
-    A single integer which specified the type of gravitational boundary
-    conditions for the top grid. Possible values are 0 for periodic and
-    1 for isolated (for all dimensions). The isolated boundary
-    conditions have not been tested recently, so caveat emptor.
-    Default: 0
-``SelfGravity`` (external)
-    This flag (1 - on, 0 - off) indicates if the baryons and particles
-    undergo self-gravity.
-``GravitationalConstant`` (external)
-    This is the gravitational constant to be used in code units. For cgs units it
-    should be 4\*pi\*G. For cosmology, this value must be 1 for the
-    standard units to hold. A more detailed decription can be found at :ref:`EnzoInternalUnits`. Default: 4\*pi.
-``GreensFunctionMaxNumber`` (external)
-    The Green's functions for the gravitational potential depend on the
-    grid size, so they are calculated on a as-needed basis. Since they
-    are often re-used, they can be cached. This integer indicates the
-    number that can be stored. They don't take much memory (only the
-    real part is stored), so a reasonable number is 100. [Ignored in
-    current version]. Default: 1
-``GreensFunctionMaxSize``
-    Reserved for future use.
-``S2ParticleSize`` (external)
-    This is the gravitational softening radius, in cell widths, in
-    terms of the S2 particle described by Hockney and Eastwood in their
-    book Computer Simulation Using Particles. A reasonable value is
-    3.0. [Ignored in current version]. Default: 3.0
-``GravityResolution`` (external)
-    This was a mis-guided attempt to provide the capability to increase
-    the resolution of the gravitational mesh. In theory it still works,
-    but has not been recently tested. Besides, it's just not a good
-    idea. The value (a float) indicates the ratio of the gravitational
-    cell width to the baryon cell width. [Ignored in current version].
-    Default: 1
-``PotentialIterations`` (external)
-    Number of iterations to solve the potential on the subgrids. Values
-    less than 4 sometimes will result in slight overdensities on grid
-    boundaries. Default: 4.
-``BaryonSelfGravityApproximation`` (external)
-    This flag indicates if baryon density is derived in a strange,
-    expensive but self-consistent way (0 - off), or by a completely
-    reasonable and much faster approximation (1 - on). This is an
-    experiment gone wrong; leave on. Well, actually, it's important for
-    very dense structures as when radiative cooling is turned on, so
-    set to 0 if using many levels and radiative cooling is on [ignored
-    in current version]. Default: 1
-``MaximumGravityRefinementLevel`` (external)
-    This is the lowest (most refined) depth that a gravitational
-    acceleration field is computed. More refined levels interpolate
-    from this level, provided a mechanism for instituting a minimum
-    gravitational smoothing length. Default: ``MaximumRefinementLevel``
-    (unless ``HydroMethod`` is ZEUS and radiative cooling is on, in which
-    case it is ``MaximumRefinementLevel`` - 3).
-``MaximumParticleRefinementLevel`` (external)
-    This is the level at which the dark matter particle contribution to
-    the gravity is smoothed. This works in an inefficient way (it
-    actually smoothes the particle density onto the grid), and so is
-    only intended for highly refined regions which are nearly
-    completely baryon dominated. It is used to remove the discreteness
-    effects of the few remaining dark matter particles. Not used if set
-    to a value less than 0. Default: -1
-
-External Gravity Source
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-These parameters set-up an external static background gravity source that is
-added to the acceleration field for the baryons and particles.
-
-``PointSourceGravity`` (external)
-    This parameter indicates that there is to be a
-    (constant) gravitational field with a point source profile (``PointSourceGravity`` =
-    1) or NFW profile (``PointSourceGravity`` = 2). Default: 0
-``PointSourceGravityConstant`` (external)
-    If ``PointSourceGravity`` = 1, this is the magnitude of the point
-    source acceleration at a distance of 1
-    length unit (i.e. GM in code units). If ``PointSourceGravity`` =
-    2, then it takes the mass of the dark matter halo in CGS
-    units. ``ProblemType`` = 31 (galaxy disk simulation) automatically calculates
-    values for ``PointSourceGravityConstant`` and
-    ``PointSourceGravityCoreRadius``. Default: 1
-``PointSourceGravityCoreRadius`` (external)
-    For ``PointSourceGravity`` = 1, this is the radius inside which
-    the acceleration field is smoothed in code units. With ``PointSourceGravity`` =
-    2, it is the scale radius, rs, in CGS units (see Navarro, Frank & White,
-    1997). Default: 0
-``PointSourceGravityPosition`` (external)
-    If the ``PointSourceGravity`` flag is turned on, this parameter
-    specifies the center of the point-source gravitational field in
-    code units. Default: 0 0 0
-``ExternalGravity`` (external)
-   This fulfills the same purpose as ``PointSourceGravity`` but is
-   more aptly named. ``ExternalGravity = 1`` turns on an alternative
-   implementation of the NFW profile with properties
-   defined via the parameters ``HaloCentralDensity``, ``HaloConcentration`` and ``HaloVirialRadius``. Boxsize is assumed to be 1.0 in this case. ``ExternalGravity = 10`` gives a gravitational field defined by the logarithmic potential in Binney & Tremaine, corresponding to a disk with constant circular velocity.  Default: 0 
-``ExternalGravityConstant`` (external)
-    If ``ExternalGravity = 10``, this is the circular velocity of the disk in code units. Default: 0.0
-``ExternalGravityDensity`` 
-   Reserved for future use.
-``ExternalGravityPosition`` (external)
-    If ``ExternalGravity = 10``, this parameter specifies the center of the gravitational field in code units. Default: 0 0 0
-``ExternalGravityOrientation`` (external)
-    For ``ExternalGravity = 10``, this is the unit vector of the disk's angular momentum (e.g. a disk whose face-on view is oriented in the x-y plane would have ``ExternalGravityOrientation = 0 0 1``). Default: 0 0 0 
-``ExternalGravityRadius`` (external)
-   If ``ExternalGravity = 10``, this marks the inner radius of the disk in code units within which the velocity drops to zero. Default: 0.0
-``UniformGravity`` (external)
-    This flag (1 - on, 0 - off) indicates if there is to be a uniform
-    gravitational field. Default: 0
-``UniformGravityDirection`` (external)
-    This integer is the direction of the uniform gravitational field: 0
-    - along the x axis, 1 - y axis, 2 - z axis. Default: 0
-``UniformGravityConstant`` (external)
-    Magnitude (and sign) of the uniform gravitational acceleration.
-    Default: 1
-
-Particle Parameters
--------------------
-
-``ParticleBoundaryType`` (external)
-    The boundary condition imposed on particles. At the moment, this
-    parameter is largely ceremonial as there is only one type
-    implemented: periodic, indicated by a 0 value. Default: 0
-``ParticleCourantSafetyNumber`` (external)
-    This somewhat strangely named parameter is the maximum fraction of
-    a cell width that a particle is allowed to travel per timestep
-    (i.e. it is a constant on the timestep somewhat along the lines of
-    it's hydrodynamic brother). Default: 0.5
-``NumberOfParticles`` (obsolete)
-    Currently ignored by all initializers, except for TestGravity and
-    TestGravitySphere where it is the number of test points. Default: 0
-``NumberOfParticleAttributes`` (internal)
-    It is set to 3 if either ``StarParticleCreation`` or
-    ``StarParticleFeedback`` is set to 1 (TRUE). Default: 0
-``AddParticleAttributes`` (internal)
-    If set to 1, additional particle attributes will be added and
-    zeroed. This is handy when restarting a run, and the user wants to
-    use star formation afterwards. Default: 0.
-``ParallelParticleIO`` (external)
-    Normally, for the mpi version, the particle data are read into the
-    root processor and then distributed to separate processors.
-    However, for very large number of particles, the root processor may
-    not have enough memory. If this toggle switch is set on (i.e. to
-    the value 1), then Ring i/o is turned on and each processor reads
-    its own part of the particle data. More I/O is required, but it is
-    more balanced in terms of memory. ``ParallelRootGridIO`` and
-    ``ParallelParticleIO`` MUST be set for runs involving > 64 cpus!
-    Default: 0 (FALSE).
-``ParticleSplitterIterations`` (external)
-    Set to 1 to split particles into 13 particles (= 12 children+1
-    parent, Kitsionas & Whitworth (2002)). This should be ideal for
-    setting up an low-resolution initial condition for a relatively low
-    computational cost, running it for a while, and then restarting it
-    for an extremely high-resolution simulation in a focused region.
-    Currently it implicitly assumes that only DM (type=1) and
-    conventional star particles (type=2) inside the ``RefineRegion`` get
-    split. Other particles, which usually become Star class objects,
-    seem to have no reason to be split. Default: 0
-``ParticleSplitterChildrenParticleSeparation`` (external)
-    This is the spacing between the child particles placed on a
-    hexagonal close-packed (HCP) array. In the unit of a cell size
-    which the parent particle resides in. Default: 1.0
-
-Parameters for Additional Physics
----------------------------------
-
-``RadiativeCooling`` (external)
-    This flag (1 - on, 0 - off) controls whether or not a radiative
-    cooling module is called for each grid. There are currently several
-    possibilities, controlled by the value of another flag. See :ref:`cooling` 
-    for more information on the various cooling methods.  Default: 0
-    
-    -  If the ``MultiSpecies`` flag is off, then equilibrium cooling is
-       assumed and one of the following two will happen. If the parameter
-       ``GadgetCooling`` is set to 1, the primordial equilibrium code is
-       called (see below). If ``GadgetCooling`` is set to 0, a file called
-       ``cool_rates.in`` is read to set a cooling curve. This file consists
-       of a set of temperature and the associated cgs cooling rate; a
-       sample compute with a metallicity Z=0.3 Raymond-Smith code is
-       provided in ``input/cool_rates.in``. This has a cutoff at 10000 K
-       (Sarazin & White 1987). Another choice will be
-       ``input/cool_rates.in_300K`` which goes further down to 300 K (Rosen
-       & Bregman 1995).
-    -  If the ``MultiSpecies`` flag is on, then the cooling rate is
-       computed directly by the species abundances. This routine (which
-       uses a backward differenced multi-step algorithm) is borrowed
-       from the Hercules code written by Peter Anninos and Yu Zhang,
-       featuring rates from Tom Abel. Other varieties of cooling are
-       controlled by the ``MetalCooling`` parameter, as discused below.
-
-``GadgetCooling`` (external)
-    This flag (1 - on, 0 - off) turns on (when set to 1) a set of
-    routines that calculate cooling rates based on the assumption of a
-    six-species primordial gas (H, He, no H2 or D) in equilibrium, and
-    is valid for temperatures greater than 10,000 K. This requires the
-    file ``TREECOOL`` to execute. Default: 0
-``MetalCooling`` (external)
-    This flag (0 - off, 1 - metal cooling from Glover & Jappsen 2007,
-    2 - Cen et al (1995), 3 - Cloudy cooling from Smith, Sigurdsson, &
-    Abel 2008) turns on metal cooling for runs that track
-    metallicity. Option 1 is valid for temperatures between 100 K and
-    10\ :sup:`8`\ K because it considers fine-structure line emission
-    from carbon, oxygen, and silicon and includes the additional metal
-    cooling rates from Sutherland & Dopita (1993). Option 2 is only
-    valid for temperatures above 10\ :sup:`4`\ K. Option 3 uses
-    multi-dimensional tables of heating/cooling values created with
-    Cloudy and optionally coupled to the ``MultiSpecies``
-    chemistry/cooling solver. This method is valid from 10 K to 10\
-    :sup:`8`\ K. See the Cloudy Cooling parameters below.  Default: 0.
-``MetalCoolingTable`` (internal)
-    This field contains the metal cooling table required for
-    ``MetalCooling`` option 1. In the top level directory input/, there are
-    two files ``metal_cool.dat`` and ``metal_cool_pop3.dat`` that consider
-    metal cooling for solar abundance and abundances from
-    pair-instability supernovae, respectively. In the same directory,
-    one can find an IDL routine (``make_Zcool_table.pro``) that generates
-    these tables. Default: ``metal_cool.dat``
-``MultiSpecies`` (external)
-    If this flag (1, 2, 3- on, 0 - off) is on, then the code follows
-    not just the total density, but also the ionization states of
-    Hydrogen and Helium. If set to 2, then a nine-species model
-    (including H2, H2+ and H-) will be computed, otherwise only six
-    species are followed (H, H+, He, He+, He++, e-). If set to 3, then
-    a 12 species model is followed, including D, D+ and HD. This
-    routine, like the last one, is based on work done by Abel, Zhang
-    and Anninos. Default: 0
-``GadgetEquilibriumCooling`` (external)
-    An implementation of the ionization equilibrium cooling code used
-    in the GADGET code which includes both radiative cooling and a
-    uniform metagalactic UV background specified by the ``TREECOOL`` file
-    (in the ``amr_mpi/exe`` directory). When this parameter is turned on,
-    ``MultiSpecies`` and ``RadiationFieldType`` are forced to 0 and
-    ``RadiativeCooling`` is forced to 1.
-    [Not in public release version]
-``PhotoelectricHeating`` (external)
-    If set to be 1, Gamma_pe = 5.1e-26 erg/s will be added uniformly
-    to the gas without any shielding (Tasker & Bryan 2008). At the
-    moment this is still experimental. Default: 0
-``MultiMetals`` (external)
-    This was added so that the user could turn on or off additional
-    metal fields - currently there is the standard metallicity field
-    (Metal_Density) and two additional metal fields (Z_Field1 and
-    Z_Field2). Acceptable values are 1 or 0, Default: 0 (off).
-
-.. _cloudy_cooling:
-
-Cloudy Cooling
-~~~~~~~~~~~~~~
-
-Cloudy cooling from Smith, Sigurdsson, & Abel (2008) interpolates
-over tables of precomputed cooling data. Cloudy cooling is turned
-on by setting ``MetalCooling`` to 3. ``RadiativeCooling`` must also be set
-to 1. Depending on the cooling data used, it can be coupled with
-``MultiSpecies`` = 1, 2, or 3 so that the metal-free cooling comes from
-the ``MultiSpecies`` machinery and the Cloudy tables provide only the
-metal cooling. Datasets range in dimension from 1 to 5. Dim 1:
-interpolate over temperature. Dim 2: density and temperature. Dim
-3: density, metallicity, and temperature. Dim 4: density,
-metallicity, electron fraction, and temperature. Dim 5: density,
-metallicity, electron fraction, spectral strength, and temperature.
-See Smith, Sigurdsson, & Abel (2008) for more information on
-creating Cloudy datasets.
-
-``CloudyCoolingGridFile`` (external)
-    A string specifying the path to the Cloudy cooling dataset.
-
-``IncludeCloudyHeating`` (external)
-    An integer (0 or 1) specifying whether the heating rates are to be
-    included in the calculation of the cooling. Some Cloudy datasets
-    are made with the intention that only the cooling rates are to be
-    used. Default: 0 (off).
-
-``CMBTemperatureFloor`` (external)
-    An integer (0 or 1) specifying whether a temperature floor is
-    created at the temperature of the cosmic microwave background
-    (T\ :sub:`CMB`\  = 2.72 (1 + z) K). This is accomplished in the
-    code by subtracting the cooling rate at T\ :sub:`CMB`\  such that
-    Cooling = Cooling(T) - Cooling(T\ :sub:`CMB`\ ). Default: 1 (on).
-
-``CloudyElectronFractionFactor`` (external)
-    A float value to account for additional electrons contributed by
-    metals. This is only used with Cloudy datasets with dimension
-    greater than or equal to 4. The value of this factor is calculated
-    as the sum of (A\ :sub:`i`\  \* i) over all elements i heavier than
-    He, where A\ :sub:`i`\  is the solar number abundance relative to
-    H. For the solar abundance pattern from the latest version of
-    Cloudy, using all metals through Zn, this value is 9.153959e-3.
-    Default: 9.153959e-3.
-
-Inline Halo Finding
-~~~~~~~~~~~~~~~~~~~
-
-Enzo can find dark matter (sub)halos on the fly with a
-friends-of-friends (FOF) halo finder and a subfind method,
-originally written by Volker Springel. All output files will be
-written in the directory FOF/.
-
-``InlineHaloFinder`` (external)
-    Set to 1 to turn on the inline halo finder. Default: 0.
-``HaloFinderSubfind`` (external)
-    Set to 1 to find subhalos inside each dark matter halo found in the
-    friends-of-friends method. Default: 0.
-``HaloFinderOutputParticleList`` (external)
-    Set to 1 to output a list of particle positions and IDs for each
-    (sub)halo. Written in HDF5. Default: 0.
-``HaloFinderMinimumSize`` (external)
-    Minimum number of particles to be considered a halo. Default: 50.
-``HaloFinderLinkingLength`` (external)
-    Linking length of particles when finding FOF groups. In units of
-    cell width of the finest static grid, e.g. unigrid -> root cell
-    width. Default: 0.1.
-``HaloFinderCycleSkip`` (external)
-    Find halos every N\ :sup:`th`\  top-level timestep, where N is this
-    parameter. Not used if set to 0. Default: 3.
-``HaloFinderTimestep`` (external)
-    Find halos every dt = (this parameter). Only evaluated at each
-    top-level timestep. Not used if negative. Default: -99999.0
-``HaloFinderLastTime`` (internal)
-    Last time of a halo find. Default: 0.
-
-Inline Python
-~~~~~~~~~~~~~
-
-``PythonSubcycleSkip`` (external)
-    The number of times Enzo should reach the bottom of the hierarchy
-    before exposing its data and calling Python. Only works with
-    python-yes in compile settings.
-
-.. _StarParticleParameters:
-
-Star Formation and Feedback Parameters
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-For details on each of the different star formation methods available in Enzo see :ref:`star_particles`.
-
-
-``StarParticleCreation`` (external)
-    This parameter is bitwise so that multiple types of star formation
-    routines can be used in a single simulation. For example if methods
-    1 and 3 are desired, the user would specify 10 (2\ :sup:`1`\  +
-    2\ :sup:`3`\ ), or if methods 1, 4 and 7 are wanted, this would be
-    146 (2\ :sup:`1`\  + 2\ :sup:`4`\  + 2\ :sup:`7`\ ). Default: 0
-    
-    ::
-
-	0 - Cen & Ostriker (1992)
-	1 - Cen & Ostriker (1992) with stocastic star formation
-	2 - Global Schmidt Law / Kravstov et al. (2003)
-	3 - Population III stars / Abel, Wise & Bryan (2007)
-	4 - Sink particles: Pure sink particle or star particle with wind feedback depending on 
-	    choice for HydroMethod / Wang et al. (2009)
-	5 - Radiative star clusters  / Wise & Cen (2009)
-	6 - [reserved]
-	7 - Cen & Ostriker (1992) with no delay in formation
-	8 - Springel & Hernquist (2003)
-	9 - Massive Black Hole (MBH) particles insertion by hand / Kim et al. (2010)
-	10 - Population III stellar tracers  
-
-``StarParticleFeedback`` (external)
-    This parameter works the same way as ``StarParticleCreation`` but only
-    is valid for ``StarParticleCreation`` = 0, 1, 2, 7 and 8 because methods 3, 5 and 9
-    use the radiation transport module and ``Star_*.C`` routines to
-    calculate the feedback, 4 has explicit feedback and 10 does not use feedback. Default: 0.
-
-``StarFeedbackDistRadius`` (external)
-    If this parameter is greater than zero, stellar feedback will be
-    deposited into the host cell and neighboring cells within this
-    radius.  This results in feedback being distributed to a cube with
-    a side of ``StarFeedbackDistRadius+1``. It is in units of cell
-    widths of the finest grid which hosts the star particle.  Only
-    implemented for ``StarFeedbackCreation`` = 0 or 1 with ``StarParticleFeedback`` =  1. (If ``StarParticleFeedback`` = 0, stellar feedback is only deposited into the cell in which the star particle lives).  Default: 0.
-
-``StarFeedbackDistCellStep`` (external)
-    In essence, this parameter controls the shape of the volume where
-    the feedback is applied, cropping the original cube.  This volume
-    that are within ``StarFeedbackDistCellSteps`` cells from the host
-    cell, counted in steps in Cartesian directions, are injected with
-    stellar feedback.  Its maximum value is ``StarFeedbackDistRadius``
-    * ``TopGridRank``.  Only implemented for ``StarFeedbackCreation`` = 0
-    or 1.  See :ref:`distributed_feedback` for an illustration.
-    Default: 0.
-
-``StarMakerTypeIaSNe`` (external)
-    This parameter turns on thermal and chemical feedback from Type Ia
-    supernovae.  The mass loss and luminosity of the supernovae are
-    determined from `fits of K. Nagamine
-    <http://www.physics.unlv.edu/~kn/SNIa_2/>`_.  The ejecta are
-    traced in a separate species field, ``MetalSNIa_Density``.  The
-    metallicity of star particles that comes from this ejecta is
-    stored in the particle attribute ``typeia_fraction``.  Can be used
-    with ``StarParticleCreation`` = 0, 1, 2, 5, 7, and 8.  Default:
-    0.
-
-``StarMakerPlanetaryNebulae`` (external) 
-    This parameter turns on thermal and chemical feedback from
-    planetary nebulae.  The mass loss and luminosity are taken from
-    the same `fits from K. Nagamine
-    <http://www.physics.unlv.edu/~kn/SNIa_2/>`_.  The chemical
-    feedback injects gas with the same metallicity as the star
-    particle, and the thermal feedback equates to a 10 km/s wind.  The
-    ejecta are not stored in its own species field.  Can be used
-    with ``StarParticleCreation`` = 0, 1, 2, 5, 7, and 8.  Default: 0.
-
-Normal Star Formation
-^^^^^^^^^^^^^^^^^^^^^
-
-The parameters below are considered in ``StarParticleCreation`` method
-0, 1, 2, 7 and 8.
-
-``StarMakerOverDensityThreshold`` (external)
-    The overdensity threshold in code units (for cosmological simulations, note that code units are relative to the total mean density, not
-    just the dark matter mean density) before star formation will be
-    considered. For ``StarParticleCreation`` = 7 in cosmological
-    simulations, however, ``StarMakerOverDensityThreshold`` should be in
-    particles/cc, so it is not the ratio with respect to the
-    ``DensityUnits`` (unlike most other
-    star_makers). This way one correctly represents the Jeans
-    collapse and molecular cloud scale physics even in cosmological
-    simulations. Default: 100
-``StarMakerSHDensityThreshold`` (external)
-    The critical density of gas used in Springel & Hernquist star
-    formation ( \\rho_{th} in the paper) used to determine the star
-    formation timescale in units of g cm\ :sup:`-3`\ . Only valid for ``StarParticleCreation`` = 8. Default: 7e-26.
-``StarMakerMassEfficiency`` (external)
-    The fraction of identified baryonic mass in a cell
-    (Mass\*dt/t_dyn) that is converted into a star particle. Default:
-    1
-``StarMakerMinimumMass`` (external)
-    The minimum mass of star particle, in solar masses. Note however,
-    the star maker algorithm 2 has a (default off) "stochastic" star formation
-    algorithm that will, in a pseudo-random fashion, allow star
-    formation even for very low star formation rates. It attempts to do
-    so (relatively successfully according to tests) in a fashion that
-    conserves the global average star formation rate. Default: 1e9
-``StarMakerMinimumDynamicalTime`` (external)
-    When the star formation rate is computed, the rate is proportional
-    to M_baryon \* dt/max(t_dyn, t_max) where t_max is this
-    parameter. This effectively sets a limit on the rate of star
-    formation based on the idea that stars have a non-negligible
-    formation and life-time. The unit is years. Default: 1e6
-``StarMassEjectionFraction`` (external)
-    The mass fraction of created stars which is returned to the gas
-    phase. Default: 0.25
-``StarMetalYield`` (external)
-    The mass fraction of metals produced by each unit mass of stars
-    created (i.e. it is multiplied by mstar, not ejected). Default:
-    0.02
-``StarEnergyToThermalFeedback`` (external)
-    The fraction of the rest-mass energy of the stars created which is
-    returned to the gas phase as thermal energy. Default: 1e-5
-``StarEnergyToStellarUV`` (external)
-    The fraction of the rest-mass energy of the stars created which is
-    returned as UV radiation with a young star spectrum. This is used
-    when calculating the radiation background. Default: 3e-6
-``StarEnergyToQuasarUV`` (external)
-    The fraction of the rest-mass energy of the stars created which is
-    returned as UV radiation with a quasar spectrum. This is used when
-    calculating the radiation background. Default: 5e-6
-
-Population III Star Formation
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The parameters below are considered in ``StarParticleCreation`` method 3.
-
-``PopIIIStarMass`` (external)
-    Stellar mass of Population III stars created in
-    ``StarParticleCreation`` method 3. Units of solar masses. The
-    luminosities and supernova energies are calculated from Schaerer
-    (2002) and Heger & Woosley (2002), respectively.
-``PopIIIBlackHoles`` (external)
-    Set to 1 to create black hole particles that radiate in X-rays for
-    stars that do not go supernova (< 140 solar masses and > 260 solar
-    masses). Default: 0.
-``PopIIIBHLuminosityEfficiency`` (internal)
-    The radiative efficiency in which the black holes convert accretion
-    to luminosity. Default: 0.1.
-``PopIIIOverDensityThreshold`` (internal)
-    The overdensity threshold (relative to the total mean density)
-    before Pop III star formation will be considered. Default: 1e6.
-``PopIIIH2CriticalFraction`` (internal)
-    The H_2 fraction threshold before Pop III star formation will be
-    considered. Default: 5e-4.
-``PopIIIMetalCriticalFraction`` (internal)
-    The metallicity threshold (relative to gas density, not solar)
-    before Pop III star formation will be considered. Note: this should
-    be changed to be relative to solar! Default: 1e-4.
-``PopIIISupernovaRadius`` (internal)
-    If the Population III star will go supernova (140<M<260 solar
-    masses), this is the radius of the sphere to inject the supernova
-    thermal energy at the end of the star's life. Units are in parsecs.
-    Default: 1.
-``PopIIISupernovaUseColour`` (internal)
-    Set to 1 to trace the metals expelled from supernovae. Default: 0.
-
-Radiative Star Cluster Star Formation
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The parameters below are considered in ``StarParticleCreation`` method 5.
-
-``StarClusterUseMetalField`` (internal)
-    Set to 1 to trace ejecta from supernovae. Default: 0.
-``StarClusterMinDynamicalTime`` (internal)
-    When determining the size of a star forming region, one method is
-    to look for the sphere with an enclosed average density that
-    corresponds to some minimum dynamical time. Observations hint that
-    this value should be a few million years. Units are in years.
-    Default: 1e7.
-``StarClusterIonizingLuminosity`` (internal)
-    The specific luminosity of the stellar clusters. In units of
-    ionizing photons per solar mass. Default: 1e47.
-``StarClusterSNEnergy`` (internal)
-    The specific energy injected into the gas from supernovae in the
-    stellar clusters. In units of ergs per solar mass. Default: 6.8e48
-    (Woosley & Weaver 1986).
-``StarClusterSNRadius`` (internal)
-    This is the radius of the sphere to inject the supernova thermal
-    energy in stellar clusters. Units are in parsecs. Default: 10.
-``StarClusterFormEfficiency`` (internal)
-    Fraction of gas in the sphere to transfer from the grid to the star
-    particle. Recall that this sphere has a minimum dynamical time set
-    by ``StarClusterMinDynamicalTime``. Default: 0.1.
-``StarClusterMinimumMass`` (internal)
-    The minimum mass of a star cluster particle before the formation is
-    considered. Units in solar masses. Default: 1000.
-``StarClusterCombineRadius`` (internal)
-    It is possible to merge star cluster particles together within this
-    specified radius. Units in parsecs. This is probably not necessary
-    if ray merging is used. Originally this was developed to reduce the
-    amount of ray tracing involved from galaxies with hundreds of these
-    radiating particles. Default: 10.
-
-Massive Black Hole Particle Formation
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The parameters below are considered in StarParticleCreation method 9.
-
-``MBHInsertLocationFilename`` (external)
-    The mass and location of the MBH particle that has to be inserted.
-    For example, the content of the file should be in the following
-    form. For details, see ``mbh_maker.src``. Default:
-    ``mbh_insert_location.in``
-    ::
-
-        #order: MBH mass (in Ms), MBH location[3], MBH creation time
-        100000.0      0.48530579      0.51455688      0.51467896      0.0
-
-.. _radiation_backgrounds:
-
-Background Radiation Parameters
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-``RadiationFieldType`` (external)
-    This integer parameter specifies the type of radiation field that
-    is to be used. Except for ``RadiationFieldType`` = 9, which should
-    be used with ``MultiSpecies`` = 2, UV backgrounds can currently
-    only be used with ``MultiSpecies`` = 1 (i.e. no molecular H
-    support). The following values are used. Default: 0
-
-   ::
-  
-     1. Haardt & Madau spectrum with q_alpha=1.5
-     2. Haardt & Madau spectrum with q_alpha = 1.8
-     3. Modified Haardt & Madau spectrum to match observations
-     	(Kirkman & Tytler 2005).
-     4. H&M spectrum (q_alpha=1.5. supplemented with an X-ray Compton heating
-        background from Madau & Efstathiou (see astro-ph/9902080)
-     9. a constant molecular H2 photo-dissociation rate
-     10. internally computed radiation field using the algorithm of Cen & Ostriker
-     11. same as previous, but with very, very simple optical shielding fudge
-     12. Haardt & Madau spectrum with q_alpha=1.57
-
-``RadiationFieldLevelRecompute`` (external)
-    This integer parameter is used only if the previous parameter is
-    set to 10 or 11. It controls how often (i.e. the level at which)
-    the internal radiation field is recomputed. Default: 0
-``RadiationSpectrumNormalization`` (external)
-    This parameter was initially used to normalize the photo-ionization
-    and photo-heating rates computed in the function
-    ``RadiationFieldCalculateRates()`` and then passed on to the
-    ``calc_photo_rates()``, ``calc_rad()`` and ``calc_rates()`` routines.
-    Later, the normalization as a separate input parameter was dropped
-    for all cases by using the rates computed in
-    ``RadiationFieldCalculateRates()`` with one exception: The molecular
-    hydrogen (H2) dissociation rate. There a normalization is performed
-    on the rate by multiplying it with ``RadiationSpectrumNormalization``.
-    Default: 1e-21
-``RadiationFieldRedshift`` (external)
-    This parameter specifies the redshift at which the radiation field
-    is calculated.  Default: 0
-``RadiationShield`` (external)
-    This parameter specifies whether the user wants to employ
-    approximate radiative-shielding. This parameter will be
-    automatically turned on when RadiationFieldType is set to 11. See
-    ``calc_photo_rates.src``. Default: 0
-``RadiationRedshiftOn`` (external) The redshift at which the UV 
-    background turns on. Default: 7.0.
-``RadiationRedshiftFullOn`` (external) The redshift at which the UV
-    background is at full strength.  Between z =
-    ``RadiationRedshiftOn`` and z = ``RadiationRedshiftFullOn``, the 
-    background is gradually ramped up to full strength. Default: 6.0.
-``RadiationRedshiftDropOff`` (external) The redshift at which the 
-    strength of the UV background is begins to gradually reduce,
-    reaching zero by ``RadiationRedshiftOff``. Default: 0.0.
-``RadiationRedshiftOff`` (external) The redshift at which the UV 
-    background is fully off. Default: 0.0.
-``AdjustUVBackground`` (external)
-    Add description. Default: 1.
-``SetUVAmplitude`` (external)
-    Add description. Default: 1.0.
-``SetHeIIHeatingScale`` (external)
-    Add description. Default: 1.8.
-``RadiationSpectrumSlope`` (external)
-    Add description. Default: 1.5.
-
-Minimum Pressure Support Parameters
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-``UseMinimumPressureSupport`` (external)
-    When radiative cooling is turned on, and objects are allowed to
-    collapse to very small sizes so that their Jeans length is no
-    longer resolved, then they may undergo artificial fragmentation
-    and angular momentum non-conservation.  To alleviate this problem,
-    as discussed in more detail in Machacek, Bryan & Abel (2001), a
-    very simple fudge was introduced: if this flag is turned on, then
-    a minimum temperature is applied to grids with level ==
-    ``MaximumRefinementLevel``. This minimum temperature is that
-    required to make each cell Jeans stable multiplied by the
-    parameter below.  More precisely, the temperature of a cell is set
-    such that the resulting Jeans length is the square-root of the
-    parameter ``MinimumPressureSupportParameter``.  So, for the
-    default value of 100 (see below), this insures that the ratio of
-    the Jeans length/cell size is at least 10.  Default: 0
-``MinimumPressureSupportParameter`` (external)
-    This is the numerical parameter discussed above. Default: 100
-
-Radiative Transfer (Ray Tracing) Parameters
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-``RadiativeTransfer`` (external)
-    Set to 1 to turn on the adaptive ray tracing following Abel, Wise &
-    Bryan 2007. Note that Enzo must be first recompiled after setting
-    ``make photon-yes``. Default: 0.
-``RadiativeTransferRadiationPressure`` (external)
-    Set to 1 to turn on radiation pressure created from absorbed photon
-    packages. Default: 0
-``RadiativeTransferInitialHEALPixLevel`` (internal)
-    Chooses how many rays are emitted from radiation sources. The
-    number of rays in Healpix are given through # =
-    12x4\ :sup:`level`\ . Default: 3.
-``RadiativeTransferRaysPerCell`` (external)