Hi Chris, On Sun, Dec 19, 2010 at 1:25 PM, Chris Malone 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: http://yt.enzotools.org/wiki/yt-2.0 under the "Generalized Parameter Specification" section. Instead of accessing / setting via: pf["TopGridRank"] it would instead be: pf.dimensionality 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. -Matt

?

Any clarification would be helpful!

Chris

_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org