ENZO_MOVIE

NAME
OVERVIEW
FILES
MOVIE HEADER
EXAMPLES
AUTHOR

NAME

enzo_movie - description of the Enzo movie format

OVERVIEW

The Enzo movie format is one of the data formats supported by the Enzo cosmology code. Enzo uses Adaptive Mesh Refinement (AMR) techniques in its computation and outputs. The enzo movie output format was developed by John Wise at Stanford University, and his documentation for the format can be found at <http://www.slac.stanford.edu/~jwise/professional/newMovie/newMovie.html>

Unfortunately, even with only two Enzo users producing output in the new format, the format has already diverged into two variants. Using either ’flavor’ still requires a little hand-twiddling. This man page gives a brief overview of the format and describes the changes necessary so that enzo movie output can be used with the libc_amr library (which was developed at NCSA). For more in-depth information on the format, including the exact binary details of how volume and particle data is stored, see John Wise’s website.

FILES

A movie produced by Enzo produces several output files, each of which are one of four types: header,index, field data or particle data. Each movie has exactly one header file, but has several index and data files.

movieHeader.dat

This file is a plain text file containing global information about the simulation, including the data types, root grid resolution, and data file locations. This file is the only one which will require tweaking.

Index (.idx) files

These files contain meta-information about each subgrid, including the origin, extent and spacing of the grid, as well as fields indicating whether any field or particle data for this grid was written out. The filenames of the index files are all of the form: <movie_name><num>.idx_<cpu_id>.
Example: "MoviePack001.idx_0003"

Movie data (.mdat) files

These files contain the volume data for a particular scalar field of the movie. There is a one-to-one correspondence between the index files and the movie files, and within each movie data file, the scalar data for the grids appears in the same order as the grids appear in the index file. The filenames are of the form: <movie_name><num>.mdat.<field-id>_<cpu_id>.
Example: "MoviePack001.mdat.0_0003"

Particle data (.part) files

These files contain particle data for the simulation. Particles are stored by grouping them together by which AMR grid contains them, and then writing them out in grid order. Similarly to the .mdat files, these groups of particles are written out in the same order that they appear in the index file. Not all simulations produce particle data. The filenames are of the form: <movie_stem><num>.part_<cpu_id>.
Example: "MoviePack001.part_0003"

A note on the file naming scheme: Besides the cpu id portion of the filename, there is also a ’file number’ part ( <num> in the patterns above). To avoid generating huge files, Enzo places a limit on the number of grid volumes that can be written to the mdat file. Thus, when this limit is reached, Enzo names the new .idx, .mdat, and .part (if applicable) files by incrementing the file number.

MOVIE HEADER

The movie header file (usually named movieHeader.dat) is a text file. Each line contains a parameter name-value pair with the syntax:

Name = Value

Here are the valid parameter names:

MovieVersion(required)

Version of the enzo movie format used. This document describes version 1.4.

Endianness(required)

Byte order of the simulation output data. Valid values are BIG or LITTLE.

CoordFloatSize(required)

The size, in bytes, of the data used for the time and space coordinates of the grids (as described in the index file). Valid values are 4 for 32-bit floats, or 8 for 64-bit floats.

DtFloatSize(optional)

Index files produced by the Stanford variant of Enzo always use a 32-bit float to store grid lifetimes (delta_t), whereas the in the UCSD variant, delta_t is stored with the same precision as the other coordinates. Valid values are 4 or 8. If this keyword is omitted, then the precision defaults to the same value as CoordFloatSize.

DataFloatSize(required)

The size, in bytes, of the data used for storing scalar fields. Valid values are 4 for 32-bit floats, or 8 for 64-bit floats.

RecordSize(required)

The number of bytes per grid record in the index file. This is mainly a sanity check, as it can be calculated from the formula:

32 + 6*CoordFloatSize + DtFloatSize

RootReso(required)

An integer giving the resolution of the root grid. This is expressed as a single integer, so that a value of "128" means that the root grid has 128^3 cells.

FileStem(optional)

A stem filename for the movie index and data files. Movie files are expected to have the format <file_stem><num>.<type>_<cpu_id>, where <num> is a file number. The file stem may include a path prefix, such as /data/amr/MoviePack. The default is MoviePack.

IndexFilePattern(optional)

This is an alternative to MovieStem to specify the names of the index files. It is more flexible. It uses python-style format strings (which are much like c-style formatting strings, but have named parameters) to specify the files. You can use %(FILENUM)d and %(CPU)d to specify parameters in the pattern. These also accept precision arguments: %04(CPU)d means to use "%04d" printf format specifier for the CPU id.
The default index file pattern is ’MoviePack%(FILENUM)03d.idx_%(CPU)04d’

NumCPUs(required)

The number of CPUs used to run the simulation. This is important for finding all of the various data and index files.

MaxFilenum(required)

Maximum file number to look for in this dataset.

MinFilenum(optional)

Minimum file number to look for in this dataset. This defaults to 0, which normally suffices. However, after an Enzo simulation is restarted, the file numbers do not necessarily start at zero.

NumFields(optional)

The number of data fields that are output. Defaults to 1

FieldNames(optional)

A space-delimited list of names for the scalar fields. If this is omitted, scalar fields will be named Field_0, Field_1, Field_2, ad nauseum.

EXAMPLES

A typical file output from the UCSD flavor of enzo looks something like this:

MovieVersion = 1.3
RootReso = 128
FLOATSize = 8
RecordSize = 88
NumFields = 1
NumCPUs = 32
FileStem = MoviePack

We don’t document version 1.3 of the movie header here. In that version, FLOATSize takes the place of both CoordFloatSize and DataFloatSize. The libc_amr library can handle this earlier version. However, this movieHeader.dat file is missing a specification of endianness, which is needed. In this case, after asking the person who ran the simulation, we find that the data is stored in little-endian format.
Another required parameter that is missing is the MaxFilenum, which we can find by looking at a listing of all the .idx files. Be aware that each cpu can produce a different maximum, so you will need to find the maximum out of all the cpu ids.
Once the missing information has been gathered, create a new movieHeader.dat file like the one below:

MovieVersion = 1.4
RootReso = 128
Endianness = LITTLE
CoordFloatSize = 8
DataFloatSize = 8
RecordSize = 88
NumFields = 1
NumCPUs = 32
MaxFilenum =165
FileStem = /data/amr/MoviePack
FieldNames = BaryonDensity

The last two lines are optional. The FileStem line specifies a full path to the data (in case the movieHeader.dat file is stored separately). The FieldNames line gives a more meaningful name to the first scalar field.

AUTHOR

Matthew Hall <mahall at ncsa dot uiuc dot edu>