Commits

Greg Bryan  committed 89a4493 Merge

merge

  • Participants
  • Parent commits 00ffb65, a8501fd

Comments (0)

Files changed (542)

File .hgignore

File contents unchanged.
 bbf0a2ffbd22c4fbecf946c9c96e6c4fac5cbdae woc_pre_fld_merge
 48b4e9d9d6b90f703e48e621b488136be2a0e9cf woc_fld_merge
 b86d8ba026d6a0ec30f15d8134add1e55fae2958 Wise10_GalaxyBirth
+2d90aa38e06f00a531db45a43225cde1faf093f2 enzo-2.2
 
 == 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        goldbaum@ucolick.org
+   * 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/developer_guide/FloatIsDouble.rst

 and C/C++ code, the variable precision agrees between the two
 languages. Compilers do not attempt to ensure that calls from C/C++
 to Fortran make any sense, so the user is manifestly on their own.
-To this end, when writing Fortran code, the data type ``real``
-corresponds to ``float``, and ``REALSUB`` corresponds to ``FLOAT``. Mismatching
-these data types can cause misalignment in the data that is being
-passed back and forth between C/C++ and Fortran code (if the
-precision of ``float`` and ``FLOAT`` are not the same), and will often
+To this end, when writing Fortran code you must ensure that your
+variables are declared with the correct type.  Unlike Enzo's C/C++
+routines that overwrite the default ``float`` and ``int``
+types with their single/double precision equivalents, Enzo's Fortran
+routines do not overwrite the basic data types.  Hence, we have
+created unique type identifiers for the Fortran routines that map to
+Enzo's ``float``, ``FLOAT`` and ``int`` types, as specified below:
+
+==================  ==============
+**Enzo C/C++**      **Enzo F/F90**
+``float``           ``R_PREC``
+``int``             ``INTG_PREC``
+``FLOAT``           ``P_PREC``
+==================  ==============
+
+In addition, Fortran allows additional data types for both ``logical``
+and ``complex`` variables.  In Enzo, the precision of these variables
+may be chosen to match Enzo's ``int`` and ``float`` values from C/C++
+using the F/F90 types ``LOGIC_PREC`` and ``CMPLX_PREC`` respectively.
+
+Moreover, unlike C/C++, hard-coded constants in Fortran routines
+default to single-precision values.  This can be especially
+troublesome when calling a Fortran subroutine or function with
+constants as their inputs, or when writing complicated formulas using
+constants that must be of higher precision.  To this end, we have
+defined four type-modifier Fortran suffixes, that can be used to
+declare constants of differing precision:
+
+===================  ==========
+**Variable Type**    **Suffix**
+``R_PREC``           ``RKIND``
+``INTG_PREC``        ``IKIND``
+``P_PREC``           ``PKIND``
+``LOGIC_PREC``       ``LKIND``
+===================  ==========
+
+Note: since a complex number in Fortran is defined through a pair of
+real numbers, to create a complex constant of type ``CMPLX_PREC`` you
+would use the ``RKIND`` suffix on both components.
+
+For example, the type specifiers and constant suffixes could be used
+in the following ways: 
+
+.. code-block:: c
+
+    c     Declarations
+          R_PREC     third, tenth
+          INTG_PREC  one
+          P_PREC     fifth
+          CMPLX_PREC two_i
+          LOGIC_PREC test
+
+    c     Calculations
+          third = 1._RKIND / 3._RKIND
+	  tenth = 1.e-1_RKIND
+          one   = 1_IKIND
+          fifth = real(1, PKIND) / 5._PKIND
+          two_i = (0._RKIND, 2._RKIND)
+          test  = .true._LKIND
+
+
+All of these type definitions are supplied in the file
+``fortran_types.def`` and should be included within a Fortran routine
+within the scope of the function, after any ``implicit none``
+declaration, and before declaring any variables, e.g.
+
+.. code-block:: c
+
+          subroutine foo(a)
+             implicit none
+    #include "fortran_types.def"
+             R_PREC a
+
+The Enzo build system will preprocess this file to include
+``fortran_types.def`` at the specified location in the file, prior to
+compilation.  Moreover, the spacing in this file is usable using
+either fixed-source-form or free-source-form Fortran files.
+
+**A word of warning:** mismatching the data types between C/C++ and
+Fortran codes can cause misalignment in the data, and will often
 result in nonsense values that will break Enzo elsewhere in the
 code. This can be particularly tricky to debug if the values are
 not used immediately after they are modified!

File doc/manual/source/developer_guide/ProgrammingGuide.rst

 to be re-defined to higher precision types. This is outlined
 in :ref:`FloatIsDouble`.
 
+Fortran types
+-------------
+
+Unlike Enzo's C and C++ routines, Fortran files (.F and .F90) do not
+re-define the built-in 'integer' and 'real' types, so all variables
+and constants must be defined with the appropriate precision.  There
+are pre-defined type specifiers that will match Enzo's C and C++
+precision re-definitions, which should be used for all variables that
+pass through the C/Fortran interface.  This is discussed in detail in 
+:ref:`FloatIsDouble`.
+
 Header Files
 ------------
 

File doc/manual/source/physics/star_particles.rst

         s &= \frac{ \ln( 1 + 0.6 \, \chi + 0.01 \, \chi^2)}{0.6 \tau_c}; \qquad {\rm [MK10 \; Eq.(91)]} \\
 	f_{\rm H_2} &\simeq 1 - \frac{0.75 \, s}{1 + 0.25 s} \qquad {\rm [MK10 \; Eq.(93)]}
 
-* :math:`\left( \frac{\sigma_{d,-21}}{R_{-16.5}} \right)` is the ratio of the dust cross section per H nucleus to 1000 Angstroem radiation normalized to 10\ :sup:`-21` cm\ :sup:`-2` (:math:`\sigma_{d,-21}`) to the rate coefficient for H\ :sub:`2` formation on dust grains normalized to the Milky Way value of 10\ :sup:`-16.5` cm\ :sup:`3` s\ :sup:`-1` (:math:`R_{-16.5}`). Both are linearly proportional to the dust-to-gas ratio and hence the ratio is likely independent of metallicity. Although its value is probably close to unity in nature (see discussion in KMT09), Krumholz & Gnedin (2011) argue that in simulations with spatial resolution of ~50 pc, the value of :math:`R_{-16.5}` should be increased by a factor of ~30 in order to account for the subgrid clumping of the gas. The value of this ratio can be controlled with the parameter ``H2StarMakerSigmaOverR``.
+* :math:`\left( \frac{\sigma_{d,-21}}{R_{-16.5}} \right)` is the ratio of the dust cross section per H nucleus to 1000 Angstroem radiation normalized to 10\ :sup:`-21` cm\ :sup:`2` (:math:`\sigma_{d,-21}`) to the rate coefficient for H\ :sub:`2` formation on dust grains normalized to the Milky Way value of 10\ :sup:`-16.5` cm\ :sup:`3` s\ :sup:`-1` (:math:`R_{-16.5}`). Both are linearly proportional to the dust-to-gas ratio and hence the ratio is likely independent of metallicity. Although its value is probably close to unity in nature (see discussion in KMT09), Krumholz & Gnedin (2011) argue that in simulations with spatial resolution of ~50 pc, the value of :math:`R_{-16.5}` should be increased by a factor of ~30 in order to account for the subgrid clumping of the gas. The value of this ratio can be controlled with the parameter ``H2StarMakerSigmaOverR``.
 
 * :math:`G_0'` is the H\ :sub:`2` dissociating radiation field in units of the typical value in the Milky Way (7.5x10\ :sup:`-4` cm\ :sup:`3` s\ :sup:`-1`, Draine 1978). At the moment only a spatially uniform and time-independent radiation field is supported, and its strength is controlled by the parameter ``H2StarMakerH2DissociationFlux_MW``.
 

File doc/manual/source/reference/EnzoPrimaryReferences.rst

 The Enzo method paper is not yet complete. However, there are several papers
 that describe the numerical methods used in Enzo, and this documentation
 contains a brief outline of the essential physics in Enzo, in
-:ref:`EnzoAlgorithms`.  Two general references (that should be considered to
-stand in for the method paper) are:
-
-
-*  `Introducing Enzo, an AMR Cosmology Application <http://adsabs.harvard.edu/cgi-bin/bib_query?arXiv:astro-ph/0403044>`_
-   by **O'Shea et al.** In "Adaptive Mesh Refinement - Theory and
-   Applications," Eds. T. Plewa, T. Linde & V. G. Weirs, Springer
-   Lecture Notes in Computational Science and Engineering, 2004.
-   `Bibtex entry <http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=2004astro.ph..3044O&data_type=BIBTEX&db_key=PRE&nocookieset=1>`_
-*  `Simulating Cosmological Evolution with Enzo <http://adsabs.harvard.edu/cgi-bin/bib_query?arXiv:0705.1556>`_
-   by **Norman et al.** In "Petascale Computing: Algorithms and
-   Applications," Ed. D. Bader, CRC Press LLC, 2007.
-   `Bibtex entry <http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=2007arXiv0705.1556N&data_type=BIBTEX&db_key=PRE&nocookieset=1>`_
-
-Three somewhat older conferences proceedings are also relevant:
-
+:ref:`EnzoAlgorithms`.  These papers should be considered suitable for
+citations for Enzo in general:
 
 *  `Simulating X-Ray Clusters with Adaptive Mesh Refinement <http://adsabs.harvard.edu/abs/1997ASPC..123..363B>`_
    by **Bryan and Norman.** In "Computational Astrophysics; 12th
    Tomisaka, and Tomoyuki Hanawa. Boston, Mass. : Kluwer Academic,
    1999. (Astrophysics and space science library ; v. 240), p.19
    `Bibtex entry <http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=1999ASSL..240...19N&data_type=BIBTEX&db_key=AST&nocookieset=1>`_
+*  `Introducing Enzo, an AMR Cosmology Application <http://adsabs.harvard.edu/cgi-bin/bib_query?arXiv:astro-ph/0403044>`_
+   by **O'Shea et al.** In "Adaptive Mesh Refinement - Theory and
+   Applications," Eds. T. Plewa, T. Linde & V. G. Weirs, Springer
+   Lecture Notes in Computational Science and Engineering, 2004.
+   `Bibtex entry <http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=2004astro.ph..3044O&data_type=BIBTEX&db_key=PRE&nocookieset=1>`_
+*  `Simulating Cosmological Evolution with Enzo <http://adsabs.harvard.edu/cgi-bin/bib_query?arXiv:0705.1556>`_
+   by **Norman et al.** In "Petascale Computing: Algorithms and
+   Applications," Ed. D. Bader, CRC Press LLC, 2007.
+   `Bibtex entry <http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=2007arXiv0705.1556N&data_type=BIBTEX&db_key=PRE&nocookieset=1>`_
 
 The primary hydrodynamics methods are PPM and ZEUS, as described in
 the following two papers:
   1989, p. 64-84.  `Bibtex Entry
   <http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=1989JCoPh..82...64B&data_type=BIBTEX&db_key=PHY&nocookieset=1>`_.
 
-The YT papers can be found here:
+The paper describing the Dedner MHD can be found here:
 
-* M Turk, `Analysis and Visualization of Multi-Scale Astrophysical Simulations
-  Using Python and NumPy
-  <http://conference.scipy.org/proceedings/SciPy2008/paper_11/>`_ in Proceedings
-  of the 7th Python in Science conference (!SciPy 2008), G Varoquaux, T Vaught, J
-  Millman (Eds.), pp. 46-50 (`Bibtex entry <http://hg.yt-project.org/yt/wiki/Citation>`_)
+ * `Magnetohydrodynamic Simulations of Disk Galaxy Formation: The Magnetization of the Cold and Warm Medium <http://adsabs.harvard.edu/abs/2009ApJ...696...96W>`_,
+   by Wang, P.; Abel, T.  The Astrophysical Journal, Volume 696, Issue 1, pp. 96-109 (2009)
+   `Bibtex Entry <http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=2009ApJ...696...96W&data_type=BIBTEX&db_key=AST&nocookieset=1>`_.
+
+The paper describing the ray-tracing algorithm (MORAY) can be found here:
+
+ * `ENZO+MORAY: radiation hydrodynamics adaptive mesh refinement simulations with adaptive ray tracing <http://adsabs.harvard.edu/abs/2011MNRAS.414.3458W>`_,
+   Wise, J.; Abel, T.  Monthly Notices of the Royal Astronomical Society, Volume 414, Issue 4, pp.  3458-3491.
+   `Bibtex Entry <http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=2011MNRAS.414.3458W&data_type=BIBTEX&db_key=AST&nocookieset=1>`_.
+
+The YT paper can be found here:
 
 * `yt: A Multi-code Analysis Toolkit for Astrophysical Simulation Data
   <http://adsabs.harvard.edu/abs/2011ApJS..192....9T>`_, by Turk, M. J.;

File doc/manual/source/reference/MakeOptions.rst

 **MACH_LDFLAGS**   Machine-dependent flags for the linker
 ================== ============
 
-Precision flags:
+Machine-specific flags:
 
 ============================== ============
 **MACH_DEFINES**               Machine-specific defines, e.g. ``-DLINUX``, ``-DIBM``, ``-DIA64``, etc.
-**MACH_FFLAGS_INTEGER_32**     Fortran flags for specifying 32-bit integers
-**MACH_FFLAGS_INTEGER_64**     Fortran flags for specifying 64-bit integers
-**MACH_FFLAGS_REAL_32**        Fortran flags for specifying 32-bit reals
-**MACH_FFLAGS_REAL_64**        Fortran flags for specifying 64-bit reals
 ============================== ============
 
 Paths to include header files:

File doc/manual/source/user_guide/EnzoTestSuite.rst

 that are accessible using the Enzo test code, both separately and in
 various permutations.  Tests can be selected based on a variety of
 criteria, including (but not limited to) the physics included, the
-estimated runtime of the test, and the dimensionality.  For
-convenience, three pre-created, overlapping sets of tests are
-provided:
+estimated runtime of the test, and the dimensionality.  The 
+testing suite runs enzo on each selected test problem, produces 
+a series of outputs, and then uses yt to process these outputs
+in a variety of different ways (making projections, looking at
+fields, etc.).  The results of these yt analyses are then compared
+against similarly generated results from an earlier "good" version 
+of the enzo code run on the same problems.  In test problems where
+we have them, analytical solutions are compared against the test
+results (e.g. shocktubes).  Lastly, a summary of these test results 
+are returned to the user for interpretation.
 
-1.  The "quick suite" (``--quicksuite=True``).  This is composed of
+One can run individual tests or groups of tests using the various
+run time flags_.  For convenience, three pre-created, 
+overlapping sets of tests are provided.  For each set of tests, the 
+test suite can automatically pull the "gold standard" results from a 
+remote server; or one can generate their own standard locally against 
+which she can compare different builds of the code.
+
+1.  The "quick suite" (``--suite=quick``).  This is composed of
 small calculations that test critical physics packages both
 alone and in combination.  The intent of this package is to be run
-relatively frequently (multiple times a day) to ensure that bugs have
-not been introduced during the code development process.  All runs 
-in the quick suite use no more than a single processor.  The total 
-run time should be about 25 minutes.  The gold standard results for 
-the quick suite alone can be downloaded 
-`here <http://enzo-project.org/tests/gold_standard_quick.tar.gz>`_.
+automatically and relatively frequently (multiple times a day) on 
+a remote server to ensure that bugs have not been introduced during the code 
+development process.  All runs in the quick suite use no more than 
+a single processor.  The total run time should be about 15 minutes 
+on the default lowest level of optimization..  
 
-2.  The "push suite" (``--pushsuite=True``).  This is a slightly 
+2.  The "push suite" (``--suite=push``).  This is a slightly 
 large set of tests, encompassing all of the quick suite and 
 some additional larger simulations that test a wider variety of physics 
 modules.  The intent of this package is to provide a thorough validation 
 of the code prior to changes being pushed to the main repository.  The 
-total run time is roughly 90 minutes and all simulations use only a single 
-processor.  The gold standard results for the push suite can be downloaded 
-`here <http://enzo-project.org/tests/gold_standard_push.tar.gz>`_.
+total run time is roughly 60 minutes for default optimization, and 
+all simulations use only a single processor.  
 
-3.  The "full suite" (``--fullsuite=True``).  This encompasses essentially 
+3.  The "full suite" (``--suite=full``).  This encompasses essentially 
 all of test simulations contained within the run directory.  This suite 
 provides the most rigorous possible validation of the code in many different 
 situations, and is intended to be run prior to major changes being pushed 
 to the stable branch of the code.  A small number of simulations in the full 
 suite are designed to be run on 2 processors and will take multiple hours to 
-complete.  The total run time is roughly 36 hours.  The gold standard results
-for the full suite can be downloaded 
-`here <http://enzo-project.org/tests/gold_standard_full.tar.gz>`_.
+complete.  The total run time is roughly 60 hours for the default lowest
+level of optimization.
 
-How to run the test suite
--------------------------
+.. _running:
+.. _`running the test suite against the gold standard`:
 
-The Enzo test suite is run within the ``run/`` subdirectory of the
-Enzo source distribution, using the ``test_runner.py`` file.  To
-run the test suite, follow these instructions:
+How to run the test suite against the gold standard
+---------------------------------------------------
 
-1.  Before running the test suite, you should download the "gold
-standard" results for the 
-`quick <http://enzo-project.org/tests/gold_standard_quick.tar.gz>`_, 
-`push <http://enzo-project.org/tests/gold_standard_push.tar.gz>`_, or 
-`full <http://enzo-project.org/tests/gold_standard_full.tar.gz>`_ 
-suites and untar that file into a convenient directory.
 
-2.  Compile Enzo.  The gold standard calculations use the default 
+1.  **Compile Enzo.**  The gold standard calculations use the default 
 compiler settings that can be restored with ``make default``.  
-If you use significantly different compilation options
-(higher-level optimization in particular) you may see somewhat
-different outputs that will result in failed tests.
-
-3.  Go into the ``run/`` subdirectory in the Enzo repository and
-type the following command:
+If you have already built enzo, you can skip this step and the test will 
+use your existing enzo executable, however be forewarned. If you use 
+significantly different compilation options (high-level optimization 
+in particular) you may see somewhat different outputs from the tests 
+that could result in failed tests.   To compile enzo with the standard 
+settings, complete these commands:
 
 ::
 
-    ./test_runner.py --quicksuite=True  --compare-dir=/path/to/gold_standard \
-            --output-dir=/enzo/test/directory
+    $ cd <enzo_root>/src/enzo
+    $ make default
+    $ make clean
+    $ make
 
-In this comand, ``--quicksuite=True`` instructs the test runner to
-use the quick suite (other possible keyboards here are
-``--pushsuite=True`` and ``--fullsuite=True``).
-``--output-dir=/enzo/test/directory`` instructs the test runner to
-write output to the user-specified directory, and
-``--compare-dir=/path/to/gold_standard`` instructs the test runner
-to use the set of data files in the listed directory as a gold
-standard for comparison.  It is also possible to choose sets of tests
-that are sorted by dimensionality, physics modules, runtime, number of
-processors required, and other criteria.  A single named test can be run 
-by giving ``--name=<name of test>``.  Type ``./test_runner.py
---help`` for a more complete listing.
+Note that you need not copy the resulting enzo executable to your path,
+since the enzo.exe will be symbolically linked from the src/enzo directory
+into each test problem directory before tests are run.
 
+2.  **Get/update yt.**  The enzo tests are generated and compared using the 
+yt analysis suite.  You must be using yt 2.5 or later in order for the
+test suite to work.  If you do not yet have yt, visit 
+http://yt-project.org/#getyt for installation instructions.  
+If you already have yt and yt is in your path, make sure you're using
+the most up-to-date version by running the following command:
+
+::
+
+    $ yt update
+
+3.  **Run the test suite.** The testing suite operates by running a 
+series of enzo test files throughout the ``run`` subdirectory.  You can 
+initiate the quicksuite test simulations and their comparison against the 
+current gold standard by running the following commands:
+
+::
+
+    $ cd <enzo_root>/run
+    $ ./test_runner.py -o <output_dir> 
+
+In this comand, ``--output-dir=<output_dir>`` instructs the 
+test runner to output its results to a user-specified directory 
+(preferably outside of the enzo file hierarchy).  Make sure this
+directory is created before you call test_runner.py, or it will 
+fail.  The default behavior is to use the quick suite, but you
+can specify any set of tests using the ``--suite`` or ``--name``
+flags_. Lastly, we compare against the current gold standard in 
+the cloud: ``enzogold2.2``.  For a full description of the many 
+flags associated with test_runner.py, see the flags_ section.
+
+4.  **Review the results.**  While the test_runner is executing, you should 
+see the results coming up at the terminal in real time, but you can review 
+these results in a file output at the end of the run.  The test_runner 
+creates a subdirectory in the output directory you provided it, as shown
+in the example below.  
+
+::
+
+    $ ls <output_dir>
+    fe7d4e298cb2    
+
+    $ ls <output_dir>/fe7d4e298cb2    
+    Cooling        GravitySolver    MHD                    test_results.txt 
+    Cosmology      Hydro            RadiationTransport     version.txt
+
+The name of this directory will be the unique hash of the version of
+enzo you chose to run with the testing suite.  In this case it is
+``fe7d4298cb2``, but yours will likely be different, but equally
+unintelligible.  You can specify an optional additional suffix to be
+appended to this directory name using ``--run-suffix=<suffix>``. This
+may be useful to distinguish multiple runs of a given version of enzo,
+for example with different levels of optimization. Within this
+directory are all of the test problems that you ran along with their
+simulation outputs, organized based on test type (e.g.  ``Cooling``,
+``AMR``, ``Hydro``, etc.)  Additionally, you should see a file called
+``test_results.txt``, which contains a summary of the test runs and
+which ones failed and why.  
+
+By default, the testing suite does not expect bitwise agreement between 
+the gold standard and your results, due to compiler, architecture and 
+operating system differences between versions of enzo.  There must be 
+a significant difference between your result and the gold standard for 
+you to fail any tests, thus you should be passing all of the tests.  
+If you are not, then examine more closely what modifications you made 
+to the enzo source which caused the test failure.  If this is a fresh 
+version of enzo that you grabbed and compiled, then you should write 
+the enzo-dev@googlegroups.com email list with details of your test run 
+(computer os, architecture, version of enzo, version of yt, what test 
+failed, what error message you received), so that we can address this 
+issue.
+
+
+My tests are failing and I don't know why
+-----------------------------------------
+
+A variety of things cause tests to fail: differences in compiler,
+optimization level, operating system, MPI submission method, 
+and of course, your modifications to the code.  Go through your 
+``test_results.txt`` file for more information about which tests 
+failed and why.  You could try playing with the relative tolerance 
+for error using the ``--tolerance`` flag as described in the flags_ 
+section.  For more information regarding the failures of a specific 
+test, examine the ``estd.out`` file in that test problem's subdirectory
+within the ``<output_dir>`` directory structure, as it contains the 
+``STDERR`` and ``STDOUT`` for that test simulation.
+
+If you are receiving ``EnzoTestOutputFileNonExistent`` errors, it
+means that your simulation is not completing.  This may be due to
+the fact that you are trying to run enzo with MPI which your 
+system doesn't allow you to initiate from the command line.
+(e.g. it expects you to submit mpirun jobs to the queue).  
+You can solve this problem by recompiling your enzo executable with
+MPI turnend off (i.e. ``make use-mpi-no``), and then just pass the 
+local_nompi machine flag (i.e. ``-m local_nompi``) to your 
+test_runner.py call to run the executable directly without MPI support.  
+Currently, only a few tests use multiple cores, so this is not a 
+problem in the quick or push suites.
+
+If you see a lot of ``YTNoOldAnswer`` errors, it may mean that your
+simulation is running to a different output than the gold standard
+does, and the test suite is trying to compare your last output file
+against a non-existent file in the gold standard.  Look carefully
+at the results of your simulation for this test problem using the 
+provided python file to determine what is happening.  Or it may
+simply mean that you specified the wrong gold standard.
+
+.. _generating_standard:
+
+How to generate your own reference standard
+-------------------------------------------
+
+There may be some circumstances under which you do not wish to compare
+your test results against the gold standard, but against your own
+homegrown standard.  Perhaps you've created a new test not yet in 
+the gold standard, or you want to test one of your forks against another.
+Regardless of the reason, you want to generate your own reference
+standard for comparison.  To do this, follow the instructions for
+`running the test suite against the gold standard`_, but replace step #3 with:
+
+3. **Run the test suite.** Run the suite with these flags within
+the ``run/`` subdirectory in the enzo source hierarchy:
+
+::
+
+    $ cd <enzo_root>/run
+    $ ./test_runner.py --suite=quick -o <output_dir> --answer-store --answer-name=<test_name> 
+                       --local 
+
+N.B. We're creating a reference set in this example with the quick 
+suite, but we could just as well create a reference from any number 
+of test problems using other test problem flags_.
+
+Here, we are storing the results from our tests locally in a file 
+called <test_name> which will now reside inside of the ``<output_dir>``.
+If you want to, you can leave off ``--answer-name`` and get a sensible
+default.
+
+.. _directory layout:
+
+::
+
+    $ ls <output_dir>
+    fe7d4e298cb2    <test_name>        
+
+    $ ls <output_dir>/<test_name>
+    <test_name>.db
+
+When we inspect this directory, we now see that in addition to the
+subdirectory containing the simulation results, we also have a
+<test_name> subdirectory which contains python-readable shelve files,
+in this case a dbm file.  These are the files which actually contain
+the reference standard.  You may have a different set of files
+or extensions depending on which OS you are using, but don't worry
+Python can read this no problem.  Congratulations, you just 
+produced your own reference standard.  Feel free to test against
+this reference standard or tar and gzip it up and send it to another 
+machine for testing.
+
+How to run the test suite against a different reference standard
+----------------------------------------------------------------
+
+First, you must place a copy of your reference standard's files in
+some directory outside the enzo source hierarchy (e.g. your 
+``<output_dir>`` from previous tests), so that it looks something 
+like this `directory layout`_.  From here, you must follow the 
+instructions for `running the test suite against the gold 
+standard`_, but replace step #3 with:
+
+3.  **Run the test suite.**  Run the suite with these flags inside
+the ``run/`` subdirectory in the enzo source hierarchy:
+
+::
+
+    $ cd <enzo_root>/run
+    $ ./test_runner.py --suite=quick -o <output_dir> --answer-name=<test_name> 
+                       --local --clobber
+
+Here, we're running the quick suite and outputting our results to
+``<output_dir>``.  We are comparing the simulation results against a 
+local (``--local``) reference standard which is named ``<test_name>``
+also located in the ``<output_dir>`` directory.  Note, we included the 
+``--clobber`` flag to rerun any simulations that may have been present
+in the ``<output_dir>`` under the existing enzo version's files, since 
+the default behavior is to not rerun simulations if their output files 
+are already present.  Because we didn't set the ``--answer-store`` flag,
+the default behavior is to compare against the ``<test_name>``.
+
+.. _flags:
+
+Descriptions of all the testing suite flags
+-------------------------------------------
+
+You can type ``./test_runner.py --help`` to get a quick summary of all 
+of the command line options for the testing suite.  Here is a more 
+thorough explanation of each.
+
+**General flags**
+
+``-h, --help``
+    list all of the flags and their argument types (e.g. int, str, etc.)
+
+``-o str, --output-dir=str`` default: None
+    Where to output the simulation and results file hierarchy.  Recommended
+    to specify outside of the enzo source hierarchy.
+
+``-m str, --machine=str`` default: local
+    Specify the machine on which you're running your tests.  This loads 
+    up a machine-specific method for running your tests.  For instance,
+    it might load qsub or mpirun in order to start the enzo executable
+    for the individual test simulations.  You can only use machine
+    names of machines which have a corresponding machine file in the 
+    ``run/run_templates`` subdirectory (e.g. nics-kraken). *N.B.*
+    the default, ``local``, will attempt to run the test simulations using
+    mpirun, so if you are required to queue on a machine to execute 
+    mpirun, ``test_runner.py`` will silently fail before finishing your
+    simulation.  You can avoid this behavior by compiling enzo without
+    MPI and then setting the machine flag to ``local_nompi``.
+
+``--repo=str`` default: current directory
+    Path to repository being tested.
+
+``--interleave`` default: False
+    Interleaves preparation, running, and testing of each 
+    individual test problem as opposed to default batch
+    behavior.
+
+``--clobber`` default: False
+    Rerun enzo on test problems which already have 
+    results in the destination directory
+
+``--tolerance=int`` default: see ``--strict``
+    Sets the tolerance of the relative error in the 
+    comparison tests in powers of 10.  
+
+    Ex: Setting ``--tolerance=3`` means that test results
+    are compared against the standard and fail if
+    they are off by more than 1e-3 in relative error.
+    
+``--bitwise`` default: see ``--strict``
+    Declares whether or not bitwise comparison tests
+    are included to assure that the values in output
+    fields exactly match those in the reference standard.
+
+``--strict=[high, medium, low]`` default: low
+    This flag automatically sets the ``--tolerance``
+    and ``--bitwise`` flags to some arbitrary level of
+    strictness for the tests.  If one sets ``--bitwise``
+    or ``--tolerance`` explicitly, they trump the value
+    set by ``--strict``.  When testing enzo general 
+    functionality after an installation, ``--strict=low``
+    is recommended, whereas ``--strict=high`` is suggested
+    when testing modified code against a local reference 
+    standard.
+
+    ``high``: tolerance = 13, bitwise = True
+    ``medium``: tolerance = 6, bitwise = False
+    ``low``: tolerance = 3, bitwise = False
+
+``--sim-only`` default: False
+    Only run simulations, do not store the tests or compare them against a 
+    standard.
+
+``--test-only`` default: False
+    Only perform tests on existing simulation outputs, do not rerun the simulations.
+
+``--time-multiplier=int`` default: 1
+    Multiply simulation time limit by this factor.  Useful if you're on a slow
+    machine or you cannot finish the specified tests in their allocated time.
+
+``--run-suffix=str`` default: None
+    An optional suffix to append to the test run directory. Useful 
+    to distinguish multiple runs of a given changeset.
+
+``-v, --verbose`` default: False
+    Verbose output in the testing sequence.  Very good for tracking down
+    specific test failures.
+
+``--pdb`` default: False
+    When a test fails a pdb session is triggered.  Allows interactive inspection
+    of failed test data.
+
+**Flags for storing, comparing against different standards**
+
+``--answer-store`` default: False
+    Should we store the results as a reference or just compare
+    against an existing reference?
+
+``--answer-name=str`` default: latest gold standard
+    The name of the file where we will store our reference results,
+    or if ``--answer-store`` is false, the name of the reference against 
+    which we will compare our results. 
+
+``--local`` default: False
+    Store/Compare the reference standard locally (i.e. not on the cloud)
+
+**Bisection flags**
+
+``-b, --bisect`` default: False
+    Run bisection on test. Requires revisions ``--good`` and
+    ``--bad``.  Best if ``--repo`` is different from location of
+    ``test_runner.py`` runs  ``--problematic`` suite.  
+
+``--good=str`` default: None
+    For bisection, most recent good revision
+
+``--bad=str`` default: None
+    For bisection, most recent bad revision
+
+``-j int, --jcompile=int`` default: 1
+    number of processors with which to compile when running bisect
+
+``--changeset=str`` default: latest
+    Changeset to use in simulation repo.  If supplied,
+    make clean && make is also run
+
+
+**Flags not used**
+
+``--with-answer-testing`` default: False
+    DO NOT USE.  This flag is used in the internal yt answer testing
+    and has no purpose in the enzo testing infrastructure.
+
+``--answer-big-data`` default: False
+    DO NOT USE.  This flag is used in the internal yt answer testing
+    and has no purpose in the enzo testing infrastructure.
+
+**Flags for specifying test problems**
+
+These are the various means of specifying which test problems you want
+to include in a particular run of the testing suite.
+
+``--suite=[quick, push, full]`` default: None
+    A precompiled collection of several different test problems.
+    quick: 37 tests in ~15 minutes, push: 48 tests in ~30 minutes, 
+    full: 96 tests in ~60 hours.
+
+``--answer_testing_script=str`` default: None
+
+``--AMR=bool`` default: False         
+    Test problems which include AMR
+
+``--author=str`` default: None
+    Test problems authored by a specific person
+
+``--chemistry=bool`` default: False
+    Test problems which include chemistry
+
+``--cooling=bool`` default: False
+    Test problems which include cooling
+
+``--cosmology=bool`` default: False   
+    Test problems which include cosmology
+
+``--dimensionality=[1, 2, 3]``
+    Test problems in a particular dimension
+
+``--gravity=bool`` default: False        
+    Test problems which include gravity
+
+``--hydro=bool`` default: False          
+    Test problems which include hydro
+
+``--max_time_minutes=float``
+    Test problems which finish under a certain time limit
+
+``--mhd=bool`` default: False            
+    Test problems which include MHD
+
+``--name=str`` default: None
+    A test problem specified by name
+
+``--nprocs=int`` default: 1
+    Test problems which use a certain number of processors
+
+``--problematic=bool`` default: False 
+    Test problems which are deemed problematic
+
+``--radiation=[None, fld, ray]`` default: None    
+    Test problems which include radiation
+
+``--runtime=[short, medium, long]`` default: None
+    Test problems which are deemed to have a certain predicted runtime
+
+
+.. _bisect:
+
+How to track down which changeset caused your test failure
+----------------------------------------------------------
+
+In order to identify changesets that caused problems, we have 
+provied the ``--bisect`` flag.  This runs hg bisect on revisions 
+between those which are marked as --good and --bad.
+
+hg bisect automatically manipulates the repository as it runs its 
+course, updating it to various past versions of the code and 
+rebuilding.  In order to keep the tests that get run consistent through 
+the course of the bisection, we recommend having two separate enzo
+installations, so that the specified repository (using ``--repo``) where 
+this rebuilding occurs remains distinct from the repository where the 
+testing is run.  
+
+To minimize the number of tests run, bisection is only run on tests 
+for which ``problematic=True``.  This must be set by hand by the user 
+before running biset.  It is best that this is a single test problem, 
+though if multiple tests match that flag, failures are combined with "or"
+
+
+An example of using this method is as follows:
+
+::
+
+    $ echo "problematic = True" >> Cosmology/Hydro/AdiabaticExpansion/AdiabaticExpansion.enzotest
+    $ ./test_runner.py  --output-dir=/scratch/dcollins/TESTS --repo=/SOMEWHERE_ELSE 
+                        --answer-compare-name=$mylar/ac7a5dacd12b --bisect --good=ac7a5dacd12b 
+                        --bad=30cb5ff3c074 -j 8
+
+To run preliminary tests before bisection, we have also supplied the 
+``--changeset`` flag.  If supplied, ``--repo`` is updated to 
+``--changeset`` and compiled.  Compile errors cause ``test_runner.py`` 
+to return that error, otherwise the tests/bisector is run. 
+
+.. _new_test:
 
 How to add a new test to the library
 ------------------------------------
 (with extension ``.enzotest``).  The latter contains a set of
 parameters that specify the properties of the test.  Consider the test
 suite parameter file for InteractingBlastWaves, which can be found in the
-``run/Hydro/Hydro-1D/InteractingBlastWavest`` directory:
+``run/Hydro/Hydro-1D/InteractingBlastWaves`` directory:
 
 ::
 
     answer_testing_script = None
     nprocs = 1
     runtime = 'short'
-    critical = True
-    cadence = 'nightly'
     hydro = True
     gravity = False
+    AMR = True
     dimensionality = 1
     max_time_minutes = 1
+    fullsuite = True
+    pushsuite = True
+    quicksuite = True
 
 This allows the user to specify the dimensionality, physics used, the
 runtime (both in terms of 'short', 'medium', and 'long' calculations,
-and also in terms of an actual wall clock time), and whether the test
-problem is critical (i.e., tests a fundamental piece of the code) or
-not.  A general rule for choosing the runtime value is 'short' for runs 
-taking less than 5 minutes, 'medium' for run taking between 5 and 30 minutes, 
-and 'long' for runs taking more than 30 minutes.  A full listing of options 
-can be found in the ``run/README`` file.
+and also in terms of an actual wall clock time).  A general rule for 
+choosing the runtime value is 'short' for runs taking less than 5 minutes, 
+'medium' for run taking between 5 and 30 minutes, and 'long' for runs taking 
+more than 30 minutes.  If the test problem runs successfully in any amount 
+of time, it should be in the full suite, selected by setting 
+``fullsuite=True``.  If the test runs in a time that falls under 'medium' 
+or 'short', it can be added to the push suite (``pushsuite=True``).  If 
+the test is 'short' and critical to testing the functionality of the code, 
+add it to the quick suite (``quicksuite=True``).
 
 Once you have created a new problem type in Enzo and thoroughly
 documented the parameters in the Enzo parameter list, you should
 follow these steps to add it as a test problem:
 
-1.  Create a new subdirectory in the appropriate place in the
+1.  Create a fork of Enzo.
+
+2.  Create a new subdirectory in the appropriate place in the
 ``run/`` directory.  If your test problem uses multiple pieces of
 physics, put it under the most relevant one.
 
-2.  Add an Enzo parameter file, ending in the extension ``.enzo``,
+3.  Add an Enzo parameter file, ending in the extension ``.enzo``,
 for your test problem to that subdirectory.
 
-3.  Add an Enzo test suite parameter file, ending in the extension
-``.enzotest``.  In that file, add any relevant parameters (as
-described in the ``run/README`` file).
+4.  Add an Enzo test suite parameter file, ending in the extension
+``.enzotest``.  In that file, add any relevant parameters as described 
+above.
 
-4.  Create a "gold standard" set of data for your test problem, by
-running with the default compile options. Contact Britton Smith 
-(brittonsmith@gmail.com) and arrange 
-to send him this data.  Please try to minimize the quantity of data
-generated by your calculation by only writing out data at the end of
-the calculation, not during the interim (unless evolution of a
-quantity or quantities is important).
+5.  By default, the final output of any test problem will be tested by 
+comparing the min, max, and mean of a set of fields.  If you want to 
+have additional tests performed, create a script in the problem type 
+sybdirectory and set the ``answer_testing_script`` parameter in the 
+``.enzotest`` file to point to your test script.  For an example of 
+writing custom tests, see 
+``run/Hydro/Hydro-3D/RotatingCylinder/test_rotating_cylinder.py``.
 
-If you want to examine the output of your test problem for something
-specific, you can optionally add a script that is indicated by the
-``answer_testing_script`` parameter.  Look in the directory
-``run/Hydro/Hydro-3D/RotatingCylinder`` for an example of how this
-is done.
+6.  Submit a Pull Request with your changes and indicate that you have 
+created a new test to be added to the testing suites.
 
 Congratulations, you've created a new test problem!
 
 
 6.  Push your Enzo changes to the repository.
 
-
-How to create a new set of reference calculations
--------------------------------------------------
-
-It may be necessary for you to generate a set of reference
-calculations for some reason.  If so, here is how you do this.
-
-1.  First, build Enzo using the default set of compile options.  
-Type ``make default`` to restore the defaults.  You will 
-now have an enzo binary in the ``src/enzo`` directory.
-
-2.  Go into the ``run/`` directory and call test_runner.py without the ``--compare-dir`` directory.  If you
-are have multiple Enzo repositories, you can specify the one you want:
-
-::
-
-    ./test_runner.py --repo=/path/to/desired/enzo/repo \
-         --output-dir=/path/to/new/reference/directory
-
-Note that you should only use the top-level directory in the
-repository, not src/enzo, and if you simply want to use the current
-repository (that is, the one your run directory is located in) you can
-leave out the ``--repo`` option.  Once this step is completed, you should
-have a full set of test problems.
-
-3.  If you then want to compare against this set of test problems, use
-the following command:
-
-::
-
-    ./test_runner.py --repo=/path/to/desired/enzo/repo  \
-         --compare-dir=/path/to/new/reference/directory \
-         --output-dir=/path/to/output/directory
-
-
-
-
+.. _http://yt-project.org/#getyt: http://yt-project.org/#getyt

File doc/userguide/Index.txt

-= Enzo User's Guide =
-
-Note: This user guide for the public trunk of Enzo development. For a particular release, please the [http://lca.ucsd.edu/software/enzo/v1.0.1/ Enzo v1.0.1 docs], or the [wiki:Enzo1.5 Enzo v1.5 docs].
-
- 1. Introduction
- 1. Preparing and testing enzo
-   * Obtaining the code
-   * Requirements for Compilation
-   * Compiling the code
-   * Running the tests
-   * ENZO Test Suite (2D Hydro Tests)
- 1. Setting up and running a cosmological simulation
-   * Generating the initial conditions
-     * Running inits
-   * Preparing a cosmology simulation
-   * Running a cosmology simulation
-   * Analyzing the output
-      * Analyzing the output: projections
-      * Analyzing the output: extractions
-      * Analyzing the output: profiles
- 1. Reference information
-   * A complete list of Enzo parameters
-   * A complete list of Inits parameters
-   * Summary of all executables, their arguments and their outputs.
-   * Output format
-

File doc/userguide/LICENSE

-
-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
-			http://cosmos.ucsd.edu/
-
-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-2004 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/userguide/TO-DO

-To-do items:
-
-1.  add counter to enzo download page (mike's request)
-
-2.  instructions on how to interpret jbPerf/jbmem outputs - James?
-
-3.  troubleshooting help (common problems/common questions)
-
-add uncommented but worked parameter files
-
-add images to image gallery, movies to movie 
-	gallery (especially AMR level movies)
-
-add section on press releases - 
-	link to SDSC Pascal's page
-
-put counter on home page
-
-
-

File doc/userguide/amr_guide/AMRShockPool2D

-#
-# AMR PROBLEM DEFINITION FILE: 2D Shock Propogation test (amr version)
-#
-#  define problem
-#
-ProblemType                = 3        // Shock Pool
-TopGridRank                = 2
-TopGridDimensions          = 75 75
-RightFaceBoundaryCondition = 1 1  // set right faces to outflow 
-HydroMethod                = 0
-#
-#  problem parameters
-#
-ShockPoolAngle          = 45.0    // angle relative to x-axis (in degrees)
-ShockPoolMachNumber     = 2.0 
-#
-#  set I/O and stop/start parameters
-#
-StopTime               = 0.2
-#dtDataDump             = 0.05
-#
-#  set Hydro parameters
-#
-Gamma                  = 1.4
-CourantSafetyNumber    = 0.5
-PPMDiffusionParameter  = 0       // diffusion off
-PPMFlatteningParameter = 0       // flattening on
-PPMSteepeningParameter = 0       // steepening on
-FluxCorrection         = 1
-#
-#  set grid refinement parameters
-#
-StaticHierarchy           = 0    // dynamic hierarchy
-MaximumRefinementLevel    = 1    // 2 levels total
-RefineBy                  = 3    // refinement factor
-CellFlaggingMethod        = 3    // use shock criteria for refinement 
-MinimumEfficiency         = 0.8  // good value for 2d
-#
-#  set some misc global parameters
-#
-tiny_number               = 1.0e-6  // fixes velocity slope problem
-

File doc/userguide/amr_guide/AMRShockTube

-#
-# AMR PROBLEM DEFINITION FILE: ShockTube test (amr version)
-#
-#  define problem
-#
-ProblemType            = 1       // Shock Tube
-TopGridRank            = 1
-TopGridDimensions      = 100
-HydroMethod            = 0
-#
-#  set I/O and stop/start parameters
-#
-StopTime               = 0.251
-dtDataDump             = 0.4
-#
-#  set hydro parameters
-#
-Gamma                  = 1.4
-CourantSafetyNumber    = 0.8
-PPMDiffusionParameter  = 0       // diffusion off
-#
-#  set grid refinement parameters
-#
-CellFlaggingMethod        = 1
-StaticHierarchy           = 0    // dynamic hierarchy
-MaximumRefinementLevel    = 1    // use up to 2 levels
-RefineBy                  = 3    // refinement factor
-MinimumSlopeForRefinement = 0.1  // set this to <= 0.2 to refine CD
-#
-#  set some global parameters
-#
-tiny_number            = 1.0e-3  // fixes velocity slope problem
-MinimumEfficiency      = 0.8     // better value for 1d than 0.2

File doc/userguide/amr_guide/AdiabaticExpansion

-#
-# AMR PROBLEM DEFINITION FILE: Adiabatic Expansion test
-#
-#  define problem
-#
-ProblemType                = 22      // Adiabatic Expansion
-TopGridRank                = 1
-TopGridDimensions          = 8
-SelfGravity                = 0       // gravity off
-TopGridGravityBoundary     = 0       // Periodic BC for gravity
-LeftFaceBoundaryCondition  = 3       // same for fluid
-RightFaceBoundaryCondition = 3
-#
-#  problem parameters
-#
-AdiabaticExpansionInitialTemperature = 1000   // K
-AdiabaticExpansionInitialVelocity    = 100   // km/s
-#
-#  define cosmology parameters
-#
-ComovingCoordinates        = 1       // Expansion ON
-CosmologyHubbleConstantNow = 0.5
-CosmologyComovingBoxSize   = 64.0    // 64 Mpc/h
-CosmologyMaxExpansionRate  = 0.01    //
-CosmologyInitialRedshift   = 20      // start at z=20
-GravitationalConstant      = 1       // this must be true for cosmology
-#
-#  set I/O and stop/start parameters
-#
-dtDataDump             = 80.0
-#
-#  set hydro parameters
-#
-Gamma                  = 1.6667