Issue #825: Creating an all_data object does not generate the field_info object. (yt_analysis/yt)
New issue 825: Creating an all_data object does not generate the field_info object. https://bitbucket.org/yt_analysis/yt/issue/825/creating-an-all_data-object-d... Nathan Goldbaum: The following script and traceback illustrates the issue: ``` #!python import yt ds = yt.load('IsolatedGalaxy/galaxy0030/galaxy0030') ad = ds.all_data() print ad.quantities.total_mass() ``` ``` File "test.py", line 7, in <module> print ad.quantities.total_mass() File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/derived_quantities.py", line 188, in __call__ fi = self.data_source.pf.field_info AttributeError: 'EnzoDataset' object has no attribute 'field_info' ``` Adding a call to ds.index before the call to the `total_mass` derived quantity eliminates the error.
Hi Nathan, This was by design -- whether that was right or not -- because I wanted to allow all of the objects to be created without requiring an index, until data was accessed. Specifically this fails because TotalMass accesses field_info directly instead of via _get_field_info. -Matt On Tue, Apr 1, 2014 at 8:02 PM, Nathan Goldbaum <issues-reply@bitbucket.org> wrote:
New issue 825: Creating an all_data object does not generate the field_info object. https://bitbucket.org/yt_analysis/yt/issue/825/creating-an-all_data-object-d...
Nathan Goldbaum:
The following script and traceback illustrates the issue:
``` #!python
import yt
ds = yt.load('IsolatedGalaxy/galaxy0030/galaxy0030')
ad = ds.all_data()
print ad.quantities.total_mass() ```
``` File "test.py", line 7, in <module> print ad.quantities.total_mass() File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/derived_quantities.py", line 188, in __call__ fi = self.data_source.pf.field_info AttributeError: 'EnzoDataset' object has no attribute 'field_info'
```
Adding a call to ds.index before the call to the `total_mass` derived quantity eliminates the error.
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Matt, So the fix would be to get the field_info via _get_field_info in __call__ for the derived quantity? -Natan On Tue, Apr 1, 2014 at 5:04 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Nathan,
This was by design -- whether that was right or not -- because I wanted to allow all of the objects to be created without requiring an index, until data was accessed. Specifically this fails because TotalMass accesses field_info directly instead of via _get_field_info.
-Matt
On Tue, Apr 1, 2014 at 8:02 PM, Nathan Goldbaum <issues-reply@bitbucket.org> wrote:
New issue 825: Creating an all_data object does not generate the field_info object.
https://bitbucket.org/yt_analysis/yt/issue/825/creating-an-all_data-object-d...
Nathan Goldbaum:
The following script and traceback illustrates the issue:
``` #!python
import yt
ds = yt.load('IsolatedGalaxy/galaxy0030/galaxy0030')
ad = ds.all_data()
print ad.quantities.total_mass() ```
``` File "test.py", line 7, in <module> print ad.quantities.total_mass() File
"/Users/goldbaum/Documents/yt-hg/yt/data_objects/derived_quantities.py", line 188, in __call__
fi = self.data_source.pf.field_info AttributeError: 'EnzoDataset' object has no attribute 'field_info'
```
Adding a call to ds.index before the call to the `total_mass` derived
quantity eliminates the error.
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I think so, yes. That manually instantiates the index. Now, I guess the bigger question is, *should* this be the fix, or should we somehow transparently catch this, and pass all the _get_field_info logic into __getitem__ in the field info container? I am torn on that front. On Tue, Apr 1, 2014 at 8:06 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
Hi Matt,
So the fix would be to get the field_info via _get_field_info in __call__ for the derived quantity?
-Natan
On Tue, Apr 1, 2014 at 5:04 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Nathan,
This was by design -- whether that was right or not -- because I wanted to allow all of the objects to be created without requiring an index, until data was accessed. Specifically this fails because TotalMass accesses field_info directly instead of via _get_field_info.
-Matt
On Tue, Apr 1, 2014 at 8:02 PM, Nathan Goldbaum <issues-reply@bitbucket.org> wrote:
New issue 825: Creating an all_data object does not generate the field_info object.
https://bitbucket.org/yt_analysis/yt/issue/825/creating-an-all_data-object-d...
Nathan Goldbaum:
The following script and traceback illustrates the issue:
``` #!python
import yt
ds = yt.load('IsolatedGalaxy/galaxy0030/galaxy0030')
ad = ds.all_data()
print ad.quantities.total_mass() ```
``` File "test.py", line 7, in <module> print ad.quantities.total_mass() File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/derived_quantities.py", line 188, in __call__ fi = self.data_source.pf.field_info AttributeError: 'EnzoDataset' object has no attribute 'field_info'
```
Adding a call to ds.index before the call to the `total_mass` derived quantity eliminates the error.
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I've opened a PR here that fixes it: https://bitbucket.org/yt_analysis/yt/pull-request/784/generate-the-index-for... I think this is a special case - it's the only derived quantity that uses the `field_info` like this. On Tue, Apr 1, 2014 at 5:08 PM, Matthew Turk <matthewturk@gmail.com> wrote:
I think so, yes. That manually instantiates the index.
Now, I guess the bigger question is, *should* this be the fix, or should we somehow transparently catch this, and pass all the _get_field_info logic into __getitem__ in the field info container? I am torn on that front.
On Tue, Apr 1, 2014 at 8:06 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
Hi Matt,
So the fix would be to get the field_info via _get_field_info in __call__ for the derived quantity?
-Natan
On Tue, Apr 1, 2014 at 5:04 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Nathan,
This was by design -- whether that was right or not -- because I wanted to allow all of the objects to be created without requiring an index, until data was accessed. Specifically this fails because TotalMass accesses field_info directly instead of via _get_field_info.
-Matt
On Tue, Apr 1, 2014 at 8:02 PM, Nathan Goldbaum <issues-reply@bitbucket.org> wrote:
New issue 825: Creating an all_data object does not generate the field_info object.
https://bitbucket.org/yt_analysis/yt/issue/825/creating-an-all_data-object-d...
Nathan Goldbaum:
The following script and traceback illustrates the issue:
``` #!python
import yt
ds = yt.load('IsolatedGalaxy/galaxy0030/galaxy0030')
ad = ds.all_data()
print ad.quantities.total_mass() ```
``` File "test.py", line 7, in <module> print ad.quantities.total_mass() File
"/Users/goldbaum/Documents/yt-hg/yt/data_objects/derived_quantities.py",
line 188, in __call__ fi = self.data_source.pf.field_info AttributeError: 'EnzoDataset' object has no attribute 'field_info'
```
Adding a call to ds.index before the call to the `total_mass` derived quantity eliminates the error.
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I personally find the behavior of field_info to be one of the biggest friction points in my day-to-day use and development in yt. Specifically, I really think that if I ask to access field_info, it should be filled out/constructed automatically. At the very least I think we should move _get_field_info to get_field_info, and then people might think to use that rather than access the field_info container directly. In fact, if that's the route we go, we should even consider moving field_info to _field_info since it is a less stable interface to the information. My $0.02 On Tue, Apr 1, 2014 at 5:14 PM, Nathan Goldbaum <nathan12343@gmail.com>wrote:
I've opened a PR here that fixes it: https://bitbucket.org/yt_analysis/yt/pull-request/784/generate-the-index-for...
I think this is a special case - it's the only derived quantity that uses the `field_info` like this.
On Tue, Apr 1, 2014 at 5:08 PM, Matthew Turk <matthewturk@gmail.com>wrote:
I think so, yes. That manually instantiates the index.
Now, I guess the bigger question is, *should* this be the fix, or should we somehow transparently catch this, and pass all the _get_field_info logic into __getitem__ in the field info container? I am torn on that front.
On Tue, Apr 1, 2014 at 8:06 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
Hi Matt,
So the fix would be to get the field_info via _get_field_info in __call__ for the derived quantity?
-Natan
On Tue, Apr 1, 2014 at 5:04 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Nathan,
This was by design -- whether that was right or not -- because I wanted to allow all of the objects to be created without requiring an index, until data was accessed. Specifically this fails because TotalMass accesses field_info directly instead of via _get_field_info.
-Matt
On Tue, Apr 1, 2014 at 8:02 PM, Nathan Goldbaum <issues-reply@bitbucket.org> wrote:
New issue 825: Creating an all_data object does not generate the field_info object.
https://bitbucket.org/yt_analysis/yt/issue/825/creating-an-all_data-object-d...
Nathan Goldbaum:
The following script and traceback illustrates the issue:
``` #!python
import yt
ds = yt.load('IsolatedGalaxy/galaxy0030/galaxy0030')
ad = ds.all_data()
print ad.quantities.total_mass() ```
``` File "test.py", line 7, in <module> print ad.quantities.total_mass() File
"/Users/goldbaum/Documents/yt-hg/yt/data_objects/derived_quantities.py",
line 188, in __call__ fi = self.data_source.pf.field_info AttributeError: 'EnzoDataset' object has no attribute 'field_info'
```
Adding a call to ds.index before the call to the `total_mass` derived quantity eliminates the error.
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I tend to agree with sam - can field_info be create-on-demand like derived_field_list? On Tue, Apr 1, 2014 at 5:21 PM, Sam Skillman <samskillman@gmail.com> wrote:
I personally find the behavior of field_info to be one of the biggest friction points in my day-to-day use and development in yt. Specifically, I really think that if I ask to access field_info, it should be filled out/constructed automatically. At the very least I think we should move _get_field_info to get_field_info, and then people might think to use that rather than access the field_info container directly. In fact, if that's the route we go, we should even consider moving field_info to _field_info since it is a less stable interface to the information.
My $0.02
On Tue, Apr 1, 2014 at 5:14 PM, Nathan Goldbaum <nathan12343@gmail.com>wrote:
I've opened a PR here that fixes it: https://bitbucket.org/yt_analysis/yt/pull-request/784/generate-the-index-for...
I think this is a special case - it's the only derived quantity that uses the `field_info` like this.
On Tue, Apr 1, 2014 at 5:08 PM, Matthew Turk <matthewturk@gmail.com>wrote:
I think so, yes. That manually instantiates the index.
Now, I guess the bigger question is, *should* this be the fix, or should we somehow transparently catch this, and pass all the _get_field_info logic into __getitem__ in the field info container? I am torn on that front.
On Tue, Apr 1, 2014 at 8:06 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
Hi Matt,
So the fix would be to get the field_info via _get_field_info in __call__ for the derived quantity?
-Natan
On Tue, Apr 1, 2014 at 5:04 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Nathan,
This was by design -- whether that was right or not -- because I wanted to allow all of the objects to be created without requiring an index, until data was accessed. Specifically this fails because TotalMass accesses field_info directly instead of via _get_field_info.
-Matt
On Tue, Apr 1, 2014 at 8:02 PM, Nathan Goldbaum <issues-reply@bitbucket.org> wrote:
New issue 825: Creating an all_data object does not generate the field_info object.
https://bitbucket.org/yt_analysis/yt/issue/825/creating-an-all_data-object-d...
Nathan Goldbaum:
The following script and traceback illustrates the issue:
``` #!python
import yt
ds = yt.load('IsolatedGalaxy/galaxy0030/galaxy0030')
ad = ds.all_data()
print ad.quantities.total_mass() ```
``` File "test.py", line 7, in <module> print ad.quantities.total_mass() File
"/Users/goldbaum/Documents/yt-hg/yt/data_objects/derived_quantities.py",
line 188, in __call__ fi = self.data_source.pf.field_info AttributeError: 'EnzoDataset' object has no attribute 'field_info'
```
Adding a call to ds.index before the call to the `total_mass` derived quantity eliminates the error.
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Okay -- before everyone piles on, how about this. I think maybe the best solution is to stick all the _get_field_info logic into __getitem__ for FieldInfoContainer, and make field_info a property that on-demand calls create_field_info if self._field_info does not exist, and then call it a day? I can't commit to implementing this in the next few days, but it should not be too terrible. On Tue, Apr 1, 2014 at 8:24 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
I tend to agree with sam - can field_info be create-on-demand like derived_field_list?
On Tue, Apr 1, 2014 at 5:21 PM, Sam Skillman <samskillman@gmail.com> wrote:
I personally find the behavior of field_info to be one of the biggest friction points in my day-to-day use and development in yt. Specifically, I really think that if I ask to access field_info, it should be filled out/constructed automatically. At the very least I think we should move _get_field_info to get_field_info, and then people might think to use that rather than access the field_info container directly. In fact, if that's the route we go, we should even consider moving field_info to _field_info since it is a less stable interface to the information.
My $0.02
On Tue, Apr 1, 2014 at 5:14 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
I've opened a PR here that fixes it: https://bitbucket.org/yt_analysis/yt/pull-request/784/generate-the-index-for...
I think this is a special case - it's the only derived quantity that uses the `field_info` like this.
On Tue, Apr 1, 2014 at 5:08 PM, Matthew Turk <matthewturk@gmail.com> wrote:
I think so, yes. That manually instantiates the index.
Now, I guess the bigger question is, *should* this be the fix, or should we somehow transparently catch this, and pass all the _get_field_info logic into __getitem__ in the field info container? I am torn on that front.
On Tue, Apr 1, 2014 at 8:06 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
Hi Matt,
So the fix would be to get the field_info via _get_field_info in __call__ for the derived quantity?
-Natan
On Tue, Apr 1, 2014 at 5:04 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Nathan,
This was by design -- whether that was right or not -- because I wanted to allow all of the objects to be created without requiring an index, until data was accessed. Specifically this fails because TotalMass accesses field_info directly instead of via _get_field_info.
-Matt
On Tue, Apr 1, 2014 at 8:02 PM, Nathan Goldbaum <issues-reply@bitbucket.org> wrote: > New issue 825: Creating an all_data object does not generate the > field_info object. > > > https://bitbucket.org/yt_analysis/yt/issue/825/creating-an-all_data-object-d... > > Nathan Goldbaum: > > The following script and traceback illustrates the issue: > > > ``` > #!python > > import yt > > ds = yt.load('IsolatedGalaxy/galaxy0030/galaxy0030') > > ad = ds.all_data() > > print ad.quantities.total_mass() > ``` > > > ``` > File "test.py", line 7, in <module> > print ad.quantities.total_mass() > File > > "/Users/goldbaum/Documents/yt-hg/yt/data_objects/derived_quantities.py", > line 188, in __call__ > fi = self.data_source.pf.field_info > AttributeError: 'EnzoDataset' object has no attribute 'field_info' > > ``` > > Adding a call to ds.index before the call to the `total_mass` > derived > quantity eliminates the error. > > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (4)
-
Matthew Turk -
Nathan Goldbaum -
Nathan Goldbaum -
Sam Skillman