Commits

Matthew Turk  committed ff74743 Merge

Merging from week-of-code into new_problem_types

  • Participants
  • Parent commits a69ef71, 6aaa7d5
  • Branches new_problem_types

Comments (0)

Files changed (933)

 *~
 
 bin/enzo
+bin/inits
 DEPEND
 DEPEND.bak
 auto_show_*.C

File doc/implicit_fld/gfldproblem_UG.tex

 
 In order to use the implicit FLD radiation solver module, and to
 allow optimal control over the nonlinear and linear solution methods
-used, there are a number of parameters than may be supplied to Enzo.
+used, there are a number of parameters that may be supplied to Enzo.
 We group these into two categories, those associated with the general
 startup of the module via the Enzo infrastructure, and those that may
 be supplied to the module itself.  However, prior to embarking on a

File doc/manual/Makefile

+# Makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXOPTS    =
+SPHINXBUILD   = sphinx-build
+PAPER         =
+BUILDDIR      = build
+
+# Internal variables.
+PAPEROPT_a4     = -D latex_paper_size=a4
+PAPEROPT_letter = -D latex_paper_size=letter
+ALLSPHINXOPTS   = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) source
+
+.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest
+
+help:
+	@echo "Please use \`make <target>' where <target> is one of"
+	@echo "  html       to make standalone HTML files"
+	@echo "  dirhtml    to make HTML files named index.html in directories"
+	@echo "  singlehtml to make a single large HTML file"
+	@echo "  pickle     to make pickle files"
+	@echo "  json       to make JSON files"
+	@echo "  htmlhelp   to make HTML files and a HTML help project"
+	@echo "  qthelp     to make HTML files and a qthelp project"
+	@echo "  devhelp    to make HTML files and a Devhelp project"
+	@echo "  epub       to make an epub"
+	@echo "  latex      to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
+	@echo "  latexpdf   to make LaTeX files and run them through pdflatex"
+	@echo "  text       to make text files"
+	@echo "  man        to make manual pages"
+	@echo "  changes    to make an overview of all changed/added/deprecated items"
+	@echo "  linkcheck  to check all external links for integrity"
+	@echo "  doctest    to run all doctests embedded in the documentation (if enabled)"
+
+clean:
+	-rm -rf $(BUILDDIR)/*
+
+html:
+	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
+	@echo
+	@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
+
+dirhtml:
+	$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
+	@echo
+	@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
+
+singlehtml:
+	$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
+	@echo
+	@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
+
+pickle:
+	$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
+	@echo
+	@echo "Build finished; now you can process the pickle files."
+
+json:
+	$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
+	@echo
+	@echo "Build finished; now you can process the JSON files."
+
+htmlhelp:
+	$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
+	@echo
+	@echo "Build finished; now you can run HTML Help Workshop with the" \
+	      ".hhp project file in $(BUILDDIR)/htmlhelp."
+
+qthelp:
+	$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
+	@echo
+	@echo "Build finished; now you can run "qcollectiongenerator" with the" \
+	      ".qhcp project file in $(BUILDDIR)/qthelp, like this:"
+	@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/Enzo.qhcp"
+	@echo "To view the help file:"
+	@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/Enzo.qhc"
+
+devhelp:
+	$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
+	@echo
+	@echo "Build finished."
+	@echo "To view the help file:"
+	@echo "# mkdir -p $$HOME/.local/share/devhelp/Enzo"
+	@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/Enzo"
+	@echo "# devhelp"
+
+epub:
+	$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
+	@echo
+	@echo "Build finished. The epub file is in $(BUILDDIR)/epub."
+
+latex:
+	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+	@echo
+	@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
+	@echo "Run \`make' in that directory to run these through (pdf)latex" \
+	      "(use \`make latexpdf' here to do that automatically)."
+
+latexpdf:
+	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
+	@echo "Running LaTeX files through pdflatex..."
+	make -C $(BUILDDIR)/latex all-pdf
+	@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
+
+text:
+	$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
+	@echo
+	@echo "Build finished. The text files are in $(BUILDDIR)/text."
+
+man:
+	$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
+	@echo
+	@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
+
+changes:
+	$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
+	@echo
+	@echo "The overview file is in $(BUILDDIR)/changes."
+
+linkcheck:
+	$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
+	@echo
+	@echo "Link check complete; look for any errors in the above output " \
+	      "or in $(BUILDDIR)/linkcheck/output.txt."
+
+doctest:
+	$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
+	@echo "Testing of doctests in the sources finished, look at the " \
+	      "results in $(BUILDDIR)/doctest/output.txt."

File doc/manual/source/EnzoLicense.rst

+Enzo Public License
+===================
+
+**University of Illinois/NCSA Open Source License**
+
+Copyright (c)  1993-2000 by Greg Bryan and the Laboratory for Computational 
+Astrophysics and the Board of Trustees of the University of Illinois in 
+Urbana-Champaign.  All rights reserved.
+
+Developed by:           
+
+   * Laboratory for Computational Astrophysics
+   * National Center for Supercomputing Applications
+   * University of Illinois in Urbana-Champaign
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of
+this software and associated documentation files (the "Software"), to deal with
+the Software without restriction, including without limitation the rights to
+use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
+of the Software, and to permit persons to whom the Software is furnished to do
+so, subject to the following conditions:
+
+ 1.  Redistributions of source code must retain the above copyright notice, 
+     this list of conditions and the following disclaimers.
+ 2.  Redistributions in binary form must reproduce the above copyright notice,
+     this list of conditions and the following disclaimers in the documentation
+     and/or other materials provided with the distribution.
+ 3.  Neither the names of The Laboratory for Computational Astrophysics,
+     The National Center for Supercomputing Applications, The University of 
+     Illinois in Urbana-Champaign, nor the names of its contributors may be used
+     to endorse or promote products derived from this Software without specific
+     prior written permission.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 
+CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS WITH 
+THE SOFTWARE.
+
+
+**University of California/BSD License**
+
+Copyright (c) 2000-2008 by Greg Bryan and the Laboratory for Computational 
+Astrophysics and the Regents of the University of California.
+
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without 
+modification, are permitted provided that the following conditions are met:
+
+ 1.  Redistributions of source code must retain the above copyright notice,
+     this list of conditions and the following disclaimer.
+ 2.  Redistributions in binary form must reproduce the above copyright notice,
+     this list of conditions and the following disclaimer in the documentation
+     and/or other materials provided with the distribution.
+ 3.  Neither the name of the Laboratory for Computational Astrophysics, the
+     University of California, nor the names of its contributors may be used to
+     endorse or promote products derived from this software without specific prior
+     written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 
+ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE 
+LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 
+CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF 
+SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 
+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN 
+CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 
+ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF 
+THE POSSIBILITY OF SUCH DAMAGE.

File doc/manual/source/EnzoParameters.rst

+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 the 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.
+
+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: 0*
+``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.
+``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? </wiki/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? </wiki/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. It's 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. [Not all of these problems run with more than one
+    processor. The list of those known to work in parallel are: 23, 25,
+    30.] Default: none. For other problem-specific parameters follow
+    the links below.
+
+   - 1. Shocktube problem
+   - 2. Wave pool
+   - 3. Shock pool
+   - 4. Double Mach reflection
+   - 5. ShockInABox
+   - 6. Implosion
+   - 7. SedovBlast
+   - 8. KH Instability
+   - 9. 2D/3D Noh Problem
+   - 10. RotatingCylinder
+   - 11. RadiatingShock
+   - 12. Free expansion blast wave
+   - 20. Zeldovich Pancake
+   - 21. 1D Pressureless collapse
+   - 22. Adiabatic expansion
+   - 23. GravityTest
+   - 24. Spherical Infall
+   - 25. TestGravitySphere
+   - 26. GravityEquilibriumTest
+   - 27. CollapseTest
+   - 28. TestGravityMotion
+   - 29. TestOrbit
+   - 30. Cosmology Simulation
+   - 31. GalaxySimulation
+   - 35. Shearing Box Simulation
+   - 40. Supernova Explosion from restart
+   - 50. Photon Test
+   - 60. Turbulence Simulation.
+   - 61. Protostellar Collapse
+   - 62. Cooling test problem
+   - 107. Put Sink from restart
+   - 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
+   - 412. Radiation-Hydrodynamics test 12 -- HI ionization of a clump
+   - 413. Radiation-Hydrodynamics test 13 -- HI ionization of a steep region
+
+``TopGridRank`` (external)
+    This specified 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)
+    When a shearing boundary is used and the other two boundary pairs
+    are both periodic, selected the direction of the shearing velocity.
+``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 output
+    format). Default: generally 0, depends 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 output
+    format). Default: generally 0, depends on problem
+``GridVelocity`` (obsolete)
+    For problems in which the grid must move. Originally implemented,
+    but was never used, and so almost surely doesn't work. Default: 0 0
+    0
+
+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. NB: inits, ring and Enzo
+    still need to be modified to support this.
+
+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:`ControllingDataOutput` 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.
+``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 available here. 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`\ 2/s.
+``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 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 it's 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 five, 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             5 - refine by baryon overdensity (currently disabled)
+              2 - refine by baryon mass       6 - refine by Jeans length
+              3 - refine by shocks            7 - refine if cooling time < cell width/sound speed
+              4 - refine by particle mass     11 - refine by resistive length
+                                              12 - refine by defined region "MustRefineRegion"
+                                              13 - refine by metallicity 
+
+
+``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 5) are used if the ``CellFlaggingMethod`` is
+    2, 4, or 5 although in slightly different ways. For Method 5, this
+    is the overdensity in terms of (rho/<rho> - 1), where rho is the
+    density of the cell, and <rho> is the mean density. For the others,
+    the meaning is actually just rho/<rho> where rho is the density of
+    the appropriate species. This value is converted into a mass, by
+    multiplying by the volume of the a top grid cell. This result is
+    then stored in the next parameter (unless it 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 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 five
+    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. It is the mass (in units such
+    that the entire mass in the computational volume is 1.0) above
+    which a refinement occurs if the ``CellFlaggingMethod`` is
+    appropriately set. There are five 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 five 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. Th