[yt-dev] Issue #825: Creating an all_data object does not generate the field_info object. (yt_analysis/yt)

[Matthew Turk]

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