[yt-users] problem accessing EOSCriticalDensity parameter (enzo)
David Collins
dcollins at physics.ucsd.edu
Thu Aug 18 08:03:39 PDT 2011
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.
More information about the yt-users
mailing list