Hi Chris, On Sun, Dec 19, 2010 at 1:25 PM, Chris Malone <chris.m.malone@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: 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