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())


Any clarification would be helpful!