[Yt-dev] not_in_all

david collins antpuncher at gmail.com
Sun Jun 26 21:34:51 PDT 2011


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?

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.



More information about the yt-dev mailing list