How to run an Enzo test problem

Enzo comes with a set of pre-written parameter files which are used to test Enzo. This is useful when migrating to a new machine with different compilers, or when new versions of compilers and libraries are introduced. Also, all the test problems should run to completion, which is generally not a guarantee!

At the top of each enzo parameter file is a line like ProblemType = 23, which tells enzo the type of problem. You can see how this affects enzo by inspecting src/enzo/InitializeNew.C. In this example, this gets called:

  if (ProblemType == 23)
    ret = TestGravityInitialize(fptr, Outfptr, TopGrid, MetaData);

which then calls the routine in src/enzo/TestGravityInitialize.C, and so on. By inspecting the initializing routine for each kind of problem, you can see what and how things are being included in the simulation.

The test problem parameter files are inside doc/examples:

/doc/examples> ls
AMRCollapseTest.enzo          GravityStripTest.enzo          SedovBlast.enzo
AMRCosmologySimulation.enzo   GravityTest.enzo               SedovBlastAMR.enzo
AMRCosmologySimulation.inits  GravityTestSphere.enzo         ShockPool2D.enzo
AMRShockPool2D.enzo           Implosion.enzo                 ShockPool3D.enzo
AMRShockTube.enzo             ImplosionAMR.enzo              ShockTube.enzo
AMRZeldovichPancake.enzo      NohProblem2D.enzo              SphericalInfall.enzo
AdiabaticExpansion.enzo       NohProblem2DAMR.enzo           StripTest.enzo
CollapseTest.enzo             NohProblem3D.enzo              WavePool.enzo
CollideTest.enzo              NohProblem3DAMR.enzo           ZeldovichPancake.enzo
DoubleMachReflection.enzo     PressurelessCollapse.enzo      cool_rates.in
ExtremeAdvectionTest.enzo     ProtostellarCollapse_Std.enzo

The files that end in .enzo are the enzo parameter files, and .inits are inits parameter files. inits files are only used for cosmology simulations, and you can see an example of how to run that here. Let's try a couple of the non-cosmology test problems.

ShockPool3D test

The ShockPool3D is a purely hydrodynamical simulation testing a shock with non-periodic boundary conditions. Once you've compiled enzo, make a directory to run the test problem in. Copy enzo.exe and ShockPool3D.enzo into that directory. On Kraken, to run in an interactive queue, type:

qsub -I -V -q debug -lwalltime=2:00:00,size=16

I have requested 16 cores (four nodes) for two hours. Of course, this procedure may differ on your machine. Once you're in the interactive session, inside your test run directory, enter:

aprun -n 16 ./enzo.exe -d ShockPool3D.enzo > 01.out

I am running the test problem on 16 processors, I've turned on the debug flag (-d), and I'm piping the standard output to a file (01.log). This took about an hour and twenty minutes to run on Kraken.

If you want to keep track of the progress of the run, in another terminal type:

tail -f 01.out
tail -f 01.out | grep dt

I find that the first command above gives too verbose output. The second one will show what's more interesting, like the current cycle number and how deep in the AMR hierarchy the run is going (look for Level[n] where n is the zero-based AMR level number). This command is especially useful for batch queue jobs where the standard out always goes to a file.

GravityTest test

The GravityTest.enzo problem only tests setting up the gravity field of 5000 particles. A successful run looks like this and should take less than a second, even on one processor:

test2> aprun -n 1 ./enzo.exe GravityTest.enzo > 01.out
****** GetUnits:  1.000000e+00 1.000000e+00 1.000000e+00 1.000000e+00 *******
CWD test2
Global Dir set to test2
Successfully read in parameter file GravityTest.enzo.
INITIALIZATION TIME =   6.04104996e-03
Successful run, exiting.

I've attached a file below showing my output from this test problem on Kraken. You may wish to compare your results.