Re: [yt-users] problem accessing EOSCriticalDensity parameter (enzo)

Hi Dave, We can move this to yt-dev if we want to get into it more in depth, but the items that go into attributes right now are guaranteed to be: http://yt.enzotools.org/doc/advanced/developing.html#variable-names-and-enzo... All of these are necessary to perform fundamental actions in the code. For instance, one does not necessarily need to know (in Enzo terms) the overdensity for refinement to conduct generic analysis. However, one likely *does* need to know the domain left edge, the dimensions of the top grid, the dimensionality, etc. It's not necessarily true that these are the correct parameters, but I think that one could make an argument for generic vs specific pieces of information about a simulation. Generic should go into attributes, and should be guaranteed to exist. -Matt On Thu, Aug 18, 2011 at 11:03 AM, David Collins wrote:

I'm for it in general.  The difference between "attributes" and "parameters" is not obvious to me (rather, what things would be in which category), but I'm not the fastest dog on the track.  I say go for it.

d.

On Thu, Aug 18, 2011 at 8:16 AM, Britton Smith wrote:

...

This sounds good to me.  Go ahead and add it as you described, I say.

On Thu, Aug 18, 2011 at 8:09 AM, Matthew Turk wrote:

...

Hi all,

On Wed, Aug 17, 2011 at 5:59 PM, Britton Smith wrote:

...

Hey Jeff,

Are you getting this variable like this: pf.parameters['EOSCriticalDensity'] or like this: pf.get_parameter('EOSCriticalDensity', float)

If it's the first, then Dave is right that many of the pf parameters are not loaded by default, in which case you need to do the second way the first time.  After you've done that, you can refer to it with pf.parameters every time after that.

I had occasion last week to write a script to parse the Enzo parameter file and interpret the values, guessing at their type.  (This was for uploading Enzo simulation records to an IVOA database, which required type-information about parameters.)  I think it might be a nice addition, but I would like to propose that if it gets included, it not be accessible via pf[every_parameter_in_enzo], simply because that namespace is getting too crowded -- unit conversions, parameters, and length conversions.

What if we included the parsing, and then for 3.0 (still a ways off) we split into units, parameters, and attributes.  Attributes are common between different output types -- domain_left_edge, domain_right_edge, etc.  Then one could do:

pf.domain_right_edge pf.units["mpc"] pf.parameters["EOSCriticalDensity"]

Would that be alright?  For now we can just pollute the dict namespace, but I don't particularly want this to be the permanent solution.

-Matt

...

Britton

On Wed, Aug 17, 2011 at 5:55 PM, David Collins wrote:

...

I think yt only knows about certain parameters initially, and for others you need to tell it how to parse.  I have things like this in my plugins file:

from yt.frontends.enzo.definitions import parameterDict parameterDict['WhatDoesABoatDo'] = float

which then tells yt what type of variable 'WhatDoesABoatDo' should be parsed as.

d.

On Wed, Aug 17, 2011 at 3:18 PM, j s oishi wrote:

...

Hi all,

I am trying to reach Enzo's EOSCriticalDensity parameter in my pf within yt (hg hash 486d7131f1c2) . For some reason, it throws a KeyError, even though grepping EOSCriticalDensity in the DD0001/data0001 file turns it right up:

$ grep EOSCriticalDensity DD0001/data0001 EOSCriticalDensity         = 1e-13

I have deleted the .yt file, but to no avail. The error message is:

In [1]: pf['EOSCriticalDensity']

--------------------------------------------------------------------------- KeyError                                  Traceback (most recent call last)

/home/jsoishi/build/yt-unknown/src/yt-hg/yt/utilities/command_line.pyc in <module>() ----> 1      2      3      4      5

/home/jsoishi/build/yt-unknown/src/yt-hg/yt/data_objects/static_output.pyc in __getitem__(self, key)    118                   self.conversion_factors]:    119             if key in d: return d[key] --> 120         raise KeyError(key)    121    122     def keys(self):

KeyError: 'EOSCriticalDensity'

Can anyone provide insight? I feel fairly certain I'm doing something dumb, but I don't see what.

thanks,

jeff _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

-- Sent from my computer. _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

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

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

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

-- Sent from my computer. _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org