Clarification of Enzo Parameters, TopGridRank and TopGridDimensions
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/parameterssorted.htmland 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 3d data sets, so this /should/ be set to 3 for current use? (2) TopGridDimensions = TopGridRankvector 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()) ? Any clarification would be helpful! Chris
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/parameterssorted.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 3d data sets, so this /should/ be set to 3 for current use? (2) TopGridDimensions = TopGridRankvector 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/yt2.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 Enzoisms. 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
_______________________________________________ Ytdev mailing list Ytdev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/ytdevspacepope.org
Hi Matt, Thanks for the clarification.
domain_dimensions (ndarray of ints  not a list) domain_left_edge (ndarray of float64) domain_right_edge (ndarray of float64)
I suspect you mean a onedimensional array, instead of a multidimensional array (ndarray) here? If not, what are the other dimensions for?
Hope that helps  feel free to ping back with any other questions
about generalizing.
Matt
Chris
_______________________________________________
Ytdev mailing list
Ytdev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/ytdevspacepope.org
_______________________________________________
Ytdev mailing list
Ytdev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/ytdevspacepope.org
Hi Chris, On Wed, Dec 22, 2010 at 10:47 AM, <chris.m.malone@gmail.com> wrote:
Hi Matt,
Thanks for the clarification.
domain_dimensions (ndarray of ints  not a list) domain_left_edge (ndarray of float64) domain_right_edge (ndarray of float64)
I suspect you mean a onedimensional array, instead of a multidimensional array (ndarray) here? If not, what are the other dimensions for?
Yup, all should be shape (3,). I just want to make sure that they are ndarrays rather than lists because I believe in the code we do things like (position_vector  domain_left_edge) / (domain_right_edge  domain_left_edge) Matt Matt
Hope that helps  feel free to ping back with any other questions
about generalizing.
Matt
Chris
_______________________________________________
Ytdev mailing list
Ytdev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/ytdevspacepope.org
_______________________________________________
Ytdev mailing list
Ytdev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/ytdevspacepope.org
_______________________________________________ Ytdev mailing list Ytdev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/ytdevspacepope.org
Hi Chris, Just as a point of clarification,
I suspect you mean a onedimensional array, instead of a multidimensional array (ndarray) here? If not, what are the other dimensions for?
An "ndarray" is the name of the numpy ndimensional array object type. Matt was trying to clarify that it is a numpy array rather than a native python list, not specifying that it is Ndimensional in the sense of greater than one. An ndarray could be onedimensional, for example: $ python c "import numpy as na; a = na.zeros(10); print a.__class__" <type 'numpy.ndarray'> j
Hi, Right, I understand what he meant about it being a numpy object rather than a list. For some reason, however, I thought "ndarray" implied multidimensional arrays. Thanks again for the clarification. Chris On Dec 22, 2010 2:08pm, js oishi <jsoishi@gmail.com> wrote:
Hi Chris,
Just as a point of clarification,
I suspect you mean a onedimensional array, instead of a multidimensional
array (ndarray) here? If not, what are the other dimensions for?
An "ndarray" is the name of the numpy ndimensional array object type.
Matt was trying to clarify that it is a numpy array rather than a
native python list, not specifying that it is Ndimensional in the
sense of greater than one. An ndarray could be onedimensional, for
example:
$ python c "import numpy as na; a = na.zeros(10); print a.__class__"
j
_______________________________________________
Ytdev mailing list
Ytdev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/ytdevspacepope.org
participants (4)

Chris Malone

chris.m.malone＠gmail.com

j s oishi

Matthew Turk