problem accessing EOSCriticalDensity parameter (enzo)
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
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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
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.
Britton
On Wed, Aug 17, 2011 at 5:55 PM, David Collins dcollins@physics.ucsd.eduwrote:
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@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@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
Hi all,
On Wed, Aug 17, 2011 at 5:59 PM, Britton Smith brittonsmith@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@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@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@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
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@gmail.com wrote:
Hi all,
On Wed, Aug 17, 2011 at 5:59 PM, Britton Smith brittonsmith@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@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@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@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
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@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@gmail.com wrote:
Hi all,
On Wed, Aug 17, 2011 at 5:59 PM, Britton Smith brittonsmith@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@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@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@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
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 dcollins@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@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@gmail.com wrote:
Hi all,
On Wed, Aug 17, 2011 at 5:59 PM, Britton Smith brittonsmith@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@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@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@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
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@gmail.comwrote:
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 dcollins@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@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@gmail.com
wrote:
Hi all,
On Wed, Aug 17, 2011 at 5:59 PM, Britton Smith <brittonsmith@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@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@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@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
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
On Thu, Aug 18, 2011 at 11:30 AM, Britton Smith brittonsmith@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@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...
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@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@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@gmail.com wrote:
Hi all,
On Wed, Aug 17, 2011 at 5:59 PM, Britton Smith brittonsmith@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@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@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@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
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
Hi David,
Thanks, that worked perfectly. Somewhere in the back of my brain, I knew that yt doesn't just load in the entire pf, but I forgot how to add another param.
j
On Wed, Aug 17, 2011 at 2:55 PM, David Collins dcollins@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@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@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
participants (4)
-
Britton Smith -
David Collins -
j s oishi -
Matthew Turk