[yt-users] Confused about units in derived fields

[Nathan Goldbaum]

On Thu, Nov 20, 2014 at 7:13 PM, Naiman, Jill <jill.naiman at cfa.harvard.edu>
wrote:

>
>
> On Thu, Nov 20, 2014 at 9:36 PM, Nathan Goldbaum <nathan12343 at gmail.com>
> wrote:
>
>> Hi Jill,
>>
>> On Thu, Nov 20, 2014 at 6:27 PM, Jill Naiman <jill.naiman at cfa.harvard.edu
>> > wrote:
>>
>>> Hi all,
>>>
>>> As the title states, I am confused - specifically about units.  I want
>>> to create a derived field where parts of the field are different values,
>>> dependent upon some cutoff criteria like so:
>>>
>>> def _dene2(field,data):
>>>     tl = data['temperature']
>>>     dl = data['density']
>>>     print("TEMP")
>>>     print(tl.in_cgs())
>>>     aux = np.where(tl.in_cgs() > 5000.)
>>>     np.putmask(dl,aux, 0.0)
>>>     dene = dl
>>>     return dene
>>>
>>>
>>> ds.add_field("dene", units="g/cm**3", function = _dene2)
>>>
>>>
>>> Not only does this produce a very worrisome error:  "RuntimeError:
>>> Something has gone terribly wrong, _function is NullFunc for ('flash',
>>> 'temp')"
>>>
>>
>> This happens when field detection fails badly.  I'm a bit surprised to
>> see it referencing a "temp" field - have you defined a "temp" field
>> somewhere?
>>
>
> I do not have a "temp" field defined anywhere, its actually one of the
> flash fields that is read in (I've printed out ds.field_list just to be
> sure and see: [('flash', 'dens'), ('flash', 'temp'), ('flash', 'pres'),
> ('flash', 'gpot'), ('flash', 'divb'), ('flash', 'velx'), ('flash', 'vely'),
> ('flash', 'velz'), ('flash', 'magx'), ('flash', 'magy'), ('flash', 'magz'),
> ('flash', 'magp')]
>
> ... I assume ('flash','temp') is 'temp'... or I am even more confused than
> previously thought :)
>
>
>
>>
>>
>>>
>>> The print statement in there shows a bunch of values close to 1, which
>>> is why the "aux" mask never returns anything.But why is data a bunch of 1's
>>> in here?  How do I access/convert to the "real" units?
>>>
>>
>> yt's field detection algorithm will feed a field fake data that is close
>> to 1 to see if there are errors in the field definition.  The values close
>> to 1 you are seeing almost certainly come from field detection.  If the
>> field validates correctly, real data will eventually be passed in.
>>
>
> Makes sense, I assume in the actual plotting routine as that is where the
> actual error is happening, full error below:
>
> Traceback (most recent call last):
>   File "testderv.py", line 28, in <module>
>     plot = yt.PhasePlot(my_sphere, "dene", "radius", ["temperature"],
> weight_field="cell_volume")
>   File
> "/pfs/sw/yt-3.0/yt-x86_64/src/yt-hg/yt/visualization/profile_plotter.py",
> line 709, in __init__
>     fractional=fractional)
>   File "/pfs/sw/yt-3.0/yt-x86_64/src/yt-hg/yt/data_objects/profiles.py",
> line 1151, in create_profile
>     for f, l in zip(bin_fields, logs)]
>   File
> "/pfs/sw/yt-3.0/yt-x86_64/src/yt-hg/yt/data_objects/derived_quantities.py",
> line 483, in __call__
>     rv = super(Extrema, self).__call__(fields, non_zero)
>   File
> "/pfs/sw/yt-3.0/yt-x86_64/src/yt-hg/yt/data_objects/derived_quantities.py",
> line 59, in __call__
>     sto.result = self.process_chunk(ds, *args, **kwargs)
>   File
> "/pfs/sw/yt-3.0/yt-x86_64/src/yt-hg/yt/data_objects/derived_quantities.py",
> line 491, in process_chunk
>     fd = data[field]
>   File
> "/pfs/sw/yt-3.0/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py",
> line 214, in __getitem__
>     self.get_data(f)
>   File
> "/pfs/sw/yt-3.0/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py",
> line 623, in get_data
>     self._generate_fields(fields_to_generate)
>   File
> "/pfs/sw/yt-3.0/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py",
> line 640, in _generate_fields
>     fd = self._generate_field(field)
>   File
> "/pfs/sw/yt-3.0/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py",
> line 251, in _generate_field
>     tr = self._generate_fluid_field(field)
>   File
> "/pfs/sw/yt-3.0/yt-x86_64/src/yt-hg/yt/data_objects/data_containers.py",
> line 271, in _generate_fluid_field
>     rv = finfo(gen_obj)
>   File "/pfs/sw/yt-3.0/yt-x86_64/src/yt-hg/yt/fields/derived_field.py",
> line 176, in __call__
>     "for %s" % (self.name,))
> RuntimeError: Something has gone terribly wrong, _function is NullFunc for
> ('flash', 'temp')
>
>
>>
>> Is there any chance you can reproduce this issue using one of the test
>> datasets on yt-project.org/data?  If so, can you pastebin a script that
>> causes the error you're seeing?  That should make it much easier to
>> reproduce and figure out exactly what's going wrong.
>>
>>
> Done: http://paste.yt-project.org/show/5216/
>

When I phrase your script like this, it works for me:

http://paste.yt-project.org/show/5217/

I'm not sure why 'dene' is being associated with the flash field registry,
but explicitly giving it a field type of 'gas' seems to work.


> Thanks!
> -Jill
>
>
>> -Nathan
>>
>>
>>>
>>> Any help is appreciated,
>>> -Jill
>>>
>>>
>>> _______________________________________________
>>> yt-users mailing list
>>> yt-users at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>
>>>
>>
>> _______________________________________________
>> yt-users mailing list
>> yt-users at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>
>>
>
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20141120/99476608/attachment.html>