[Yt-dev] Clarification of Enzo Parameters, TopGridRank and TopGridDimensions

Matthew Turk matthewturk at gmail.com
Sun Dec 19 13:31:01 PST 2010

Hi Chris,

On Sun, Dec 19, 2010 at 1:25 PM, Chris Malone <chris.m.malone at gmail.com> wrote:
> Hi,
> In attempting to develop yt support for an additional computer code,
> MAESTRO, I'm finding a little confusion in relating the Enzo parameters to
> some parameters used in MAESTRO.  I have checked
> http://lca.ucsd.edu/software/enzo/v1.0.1/amr_guide/parameters-sorted.html
> and compared, for example, TopGridRank and TopGridDimensions to what is used
> in the yt code.  My understanding is as follows:
> (1) TopGridRank = < int >
>      essentially the spatial dimensionality of the problem;  As far as I can
> tell, yt supports only 3-d data sets, so this /should/ be set to 3 for
> current use?
> (2) TopGridDimensions = TopGridRank-vector of < int >'s
>      essentially the number of zones (not counting ghosts/guards) in each
> direction of the problem;  Again, as far as I can tell this should be
> something like:
>           TopGridDimensions = number_zones_x number_zones_y number_zones_z
> Is this correct?
> If it is, then I'm confused about how the Orion frontend loads these
> parameters.  For that frontend, there is a dictionary which translates
> between the Orion (i.e. BoxLib) parameters and those of Enzo:
> orion2enzoDict.  It is defined in frontends/orion/definitions.py as:
> orion2enzoDict = {"amr.n_cell": "TopGridRank",
>                   "materials.gamma": "Gamma",
>                   "amr.ref_ratio": "RefineBy"
>                   }
> I don't have a sample Orion parameter file, but I do have one for Castro,
> which also uses the BoxLib data format.  For Castro, the amr.n_cell line of
> a parameter file looks like:
>  amr.n_cell           = 32   32   32
> If I make the assumption (and maybe this is where I'm going wrong...) that
> the grid parameters used in a Castro parameter file are the same as those in
> an Orion parameter file, then the OrionStaticOutput._parse_parameter_file
> method is mapping TopGridRank to a list of < int >'s, which is what I
> thought TopGridDimensions was given (2) above.  In other words, if (1) and
> (2) are correct, shouldn't
> TopGridRank = len(amr.n_cell.split())
> TopGridDimensions = map(int, amr.n_cell.split())

Yes, this is correct.  The Orion one looks like a bug.

As a quick note, in the transition to the 2.0 release, we've changed
some of the parameters, as noted here:


under the "Generalized Parameter Specification" section.  Instead of
accessing / setting via:


it would instead be:


The reason for this is primarily what you're referring to: a removal
of Enzo-isms.  The full list of parameters that need to be set for a
parameter file is:

refine_by (int)
dimensionality (int)
domain_dimensions (ndarray of ints -- not a list)
current_time (float, time of the current simulation output)
domain_left_edge (ndarray of float64)
domain_right_edge (ndarray of float64)
unique_identifier (something unique; CTIME should work)
current_redshift (0 if not cosmo)
cosmological_simulation (0 or 1)
omega_matter (0 if not cosmo)
omega_lambda (0 if not cosmo)
hubble_constant (0 if not cosmo)

Hope that helps -- feel free to ping back with any other questions
about generalizing.


> ?
> Any clarification would be helpful!
> Chris
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

More information about the yt-dev mailing list