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

Britton Smith brittonsmith at gmail.com
Thu Aug 18 08:30:39 PDT 2011 

One source of confusion may be the fact that both pf.parameters and
pf.units, and perhaps others, are both accessible by just doing
pf[some_variable].  In other words, you can do
pf['cm'] the same as pf.units['cm']
and
pf['InitialTime'] the same as pf.parameters['InitialTime'].

I'm not sure this offers more convenience than it does confusion, so I would
be in favor of getting rid of this feature.

Britton

On Thu, Aug 18, 2011 at 11:21 AM, Matthew Turk <matthewturk at gmail.com>wrote:

> 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-isms
>
> 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
> <dcollins at physics.ucsd.edu> 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 <brittonsmith at gmail.com>
> 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 <matthewturk at gmail.com>
> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> On Wed, Aug 17, 2011 at 5:59 PM, Britton Smith <brittonsmith at gmail.com
> >
> >>> 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
> >>> > <dcollins at physics.ucsd.edu>
> >>> > 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 <jsoishi at gmail.com>
> 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 at lists.spacepope.org
> >>> >> > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >>> >> >
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >> Sent from my computer.
> >>> >> _______________________________________________
> >>> >> yt-users mailing list
> >>> >> yt-users at lists.spacepope.org
> >>> >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > yt-users mailing list
> >>> > yt-users at lists.spacepope.org
> >>> > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >>> >
> >>> >
> >>> _______________________________________________
> >>> yt-users mailing list
> >>> yt-users at lists.spacepope.org
> >>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >>
> >>
> >> _______________________________________________
> >> yt-users mailing list
> >> yt-users at lists.spacepope.org
> >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >>
> >>
> >
> >
> >
> > --
> > Sent from my computer.
> > _______________________________________________
> > yt-users mailing list
> > yt-users at lists.spacepope.org
> > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20110818/6acb6e34/attachment.html>

More information about the yt-users mailing list