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

[Nathan Goldbaum]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140401/98e64e01/attachment.html>