[Yt-dev] not_in_all
david collins
antpuncher at gmail.com
Mon Jun 27 08:41:23 PDT 2011
Hey, Matt--
Thanks for the tips on places to look. Good luck with the
restructure, that's a major feat of code design! I'll poke around as
my workaround breaks down, and fix what I can.
Thanks a ton,
d.
On Mon, Jun 27, 2011 at 8:38 AM, Matthew Turk <matthewturk at gmail.com> wrote:
> Hi David,
>
> On Sun, Jun 26, 2011 at 9:34 PM, david collins <antpuncher at gmail.com> wrote:
>> Hey, Matt--
>>
>> Sorry it took me a minute to get back to this. I have a work around,
>> so this is low priority for all parties. But it's behavior I don't
>> quite understand, so I thought I'd ask.
>>
>> I added a conversion specifier as you suggested, in my plugins file,
>> as this below, but I still see the same error.
>>
>> for aaa in list_of_fields:
>> add_field(aaa,lambda a, b: None, convert_function = lambda a:1.0,
>> take_log = False, not_in_all=True)
>>
>> The traceback I get is:
>>
>> <trace>
>> Traceback (most recent call last):
>> File "mrg_check_pstp.py", line 29, in <module>
>> ud(output='x')
>> File "/Users/dcollins/Sites/Research/CodeGames/yt2.0/uberdiff.py",
>> line 166, in __call__
>> g1_full = self.uber1.h.grids[grid1-1][field1]
>> File "/Users/dcollins/local/lib/python2.6/site-packages/yt-2.1dev-py2.6-macosx-10.4-i386.egg/yt/data_objects/grid_patch.py",
>> line 147, in __getitem__
>> self.get_data(key)
>> File "/Users/dcollins/local/lib/python2.6/site-packages/yt-2.1dev-py2.6-macosx-10.4-i386.egg/yt/data_objects/grid_patch.py",
>> line 190, in get_data
>> self._generate_field(field)
>> File "/Users/dcollins/local/lib/python2.6/site-packages/yt-2.1dev-py2.6-macosx-10.4-i386.egg/yt/data_objects/grid_patch.py",
>> line 135, in _generate_field
>> self[field] = self.pf.field_info[field](self)
>> File "/Users/dcollins/local/lib/python2.6/site-packages/yt-2.1dev-py2.6-macosx-10.4-i386.egg/yt/data_objects/field_info_container.py",
>> line 308, in __call__
>> dd *= self._convert_function(data)
>> TypeError: unsupported operand type(s) for *=: 'NoneType' and 'float'
>> </trace>
>>
>> When I jump in with pdb, self._convert_function(data) returns 1.0, as
>> intended, but
>>
>> dd = self._function(self,data)
>>
>> is returning none. (the location of that is below) I suppose this
>> isn't surprising, since that's the function I gave it. When I force
>> the field to be defined on all grids, the problem goes away. I feel
>> like this code has worked in the past for a different not_in_all
>> field. But I also feel like I should be living in a state that
>> doesn't catch on fire so readily, so apparently I'm wrong a lot. So
>> is the "function" argument to my add_field wrong, or is there a better
>> choice?
>
> I agree, this used to work, but right now the field state is a bit
> mixed up. In order to meet the needs of the various different
> incompatible Enzo versions, I made a few changes that made things work
> more reliably in the case of derived fields that mirror non-derived
> fields. This likely changed the behavior you're seeing. I would say
> that perhaps you could fix it by lookign for where the not_in_all is
> checked inside the grid patch object and then tryign to determine
> which portions (hg blame) of that code have recently changed.
>
> Unfortunately, as I mentioned, Casey and I are working to replace the
> current field system with a new one. The new one should remove a
> number of the ifs/elifs/etc that make the field system a bit
> spaghetti. So I am going to try to focus on that, since you have a
> workaround for now; it should improve maintainability. Please do feel
> free to fix the necessary code and either submit a pull request or
> push it to the repository.
>
> Thanks,
>
> Matt
>
>>
>> Thanks a ton,
>> d.
>>
>> <pdb list>
>>
>>>>> pdb.pm()
>>> /Users/dcollins/local/lib/python2.6/site-packages/yt-2.1dev-py2.6-macosx-10.4-i386.egg/yt/data_objects/field_info_container.py(308)__call__()
>> -> dd *= self._convert_function(data)
>> (Pdb) list
>> 303 Return the value of the field in a given *data* object.
>> 304 """
>> 305 ii = self.check_available(data)
>> 306 original_fields = data.keys() # Copy
>> 307 dd = self._function(self, data)
>> 308 -> dd *= self._convert_function(data)
>> 309 for field_name in data.keys():
>> </pdb list>
>>
>>
>> On Mon, Jun 20, 2011 at 9:55 PM, Matthew Turk <matthewturk at gmail.com> wrote:
>>> Hi Dave,
>>>
>>> This comes from not having a conversion specifier. You can mock this
>>> up by manually adding an entry to pf.conversion_factors, or, better
>>> yet, adding the field in your plugins with a lambda a: 1.0 for the
>>> conversion function.
>>>
>>> The long term solution is to follow Enzo's conventions and include a
>>> #DataCGSConversion line above the name of the data label. This would
>>> auto-supply a conversion factor.
>>>
>>> Casey and I have been working hard on re-doing the field specifiers to
>>> create classes of "known" and "derived" fields that are specific to
>>> each code. That would help somewhat with this, but unfortunately it
>>> is very, very challenging in general to detect fields and try to
>>> manipulate them productively. The new field system will help make
>>> this clearer and more straightforward.
>>>
>>> -Matt
>>>
>>> On Mon, Jun 20, 2011 at 8:50 PM, david collins <antpuncher at gmail.com> wrote:
>>>> It does.
>>>>
>>>> However I changed something since my last email, now I'm getting a
>>>> different error. Now I get:
>>>>
>>>> Traceback (most recent call last):
>>>> File "<stdin>", line 1, in <module>
>>>> File "/Users/dccollins/local/src/yt-hg/yt/data_objects/grid_patch.py",
>>>> line 147, in __getitem__
>>>> self.get_data(key)
>>>> File "/Users/dccollins/local/src/yt-hg/yt/data_objects/grid_patch.py",
>>>> line 190, in get_data
>>>> self._generate_field(field)
>>>> File "/Users/dccollins/local/src/yt-hg/yt/data_objects/grid_patch.py",
>>>> line 135, in _generate_field
>>>> self[field] = self.pf.field_info[field](self)
>>>> File "/Users/dccollins/local/src/yt-hg/yt/data_objects/field_info_container.py",
>>>> line 308, in __call__
>>>> dd *= self._convert_function(data)
>>>> TypeError: unsupported operand type(s) for *=: 'NoneType' and 'float'
>>>>
>>>> That leads me to believe this is operator error-- I'll poke around
>>>> more and get back to you.
>>>>
>>>> Thanks,
>>>> d.
>>>>
>>>>
>>>> On Mon, Jun 20, 2011 at 8:58 PM, Matthew Turk <matthewturk at gmail.com> wrote:
>>>>> Hi Dave,
>>>>>
>>>>> Does it show up in the list of detected fields when debug mode is on?
>>>>>
>>>>> -Matt
>>>>>
>>>>> On Mon, Jun 20, 2011 at 7:53 PM, david collins <antpuncher at gmail.com> wrote:
>>>>>> Hi--
>>>>>>
>>>>>> I have (a probably stupid) problem. I have a field that I'm writing
>>>>>> out to some grids. The field is called 'AvgElec0', and only exists on
>>>>>> level>0 grids (non-root-grids). I've defined this field
>>>>>>
>>>>>> def _AEx(field,data):
>>>>>> return data['AvgElec0'][:,:-1,:-1]
>>>>>> add_field('AEx',function=_AEx,validators=[ValidateSpatial(0)],take_log=False,not_in_all=True)
>>>>>>
>>>>>> (the slice is for the centering of the field). When I do something
>>>>>> like pf.h.grids[1]['AEx'] I get a key error, "AvgElec0," even though
>>>>>> double checking the field is in fact in that grid. If I change the
>>>>>> code so it's written on all levels, the same pf.h.grids[1]['AEx']
>>>>>> works fine, as one would expect. Has the not_in_all behavior changed?
>>>>>> Might I be doing something stupid?
>>>>>>
>>>>>> Thanks,
>>>>>> d.
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sent from my computer.
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sent from my computer.
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>>
>> --
>> Sent from my computer.
>> _______________________________________________
>> 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
>
--
Sent from my computer.
More information about the yt-dev
mailing list