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-the-total_mass/diff

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-does-not
>> >
>> > 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