|Version 5 (modified by sskory, 5 years ago)|
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.
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.
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.