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

Matthew Turk matthewturk at gmail.com
Thu Aug 18 08:36:38 PDT 2011 

On Thu, Aug 18, 2011 at 11:30 AM, Britton Smith <brittonsmith at gmail.com> wrote:
> 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.

I completely agree, this is an unnecessary source of confusion, both
for the code and for people, and I would like to get rid of it.  It
has been left in there because of a mistake on my part five years ago.

The issue with simply removing it is that there are numerous places
where the construction:

some_value/pf[some_unit]

is used, including in many of my scripts, the yt recipes, etc.  So
this would be something to remove at the 3.0 phase, which is some time
off.  But I think we should do this, too.  I would like to see the
dict-like access on parameter files disappear, move to attributes for
specific things, and explicitly have a "units" object, which handles
conversions.

We should move to yt-dev for further discussion.  (And perhaps a
meta-discussion about how to properly propose invasive changes,
deprecate old functionality, and how to implement.)

-Matt

>
> 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
>
>
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
>

More information about the yt-users mailing list