[yt-users] YTFieldUnitError

Kacper Kowalik xarthisius.kk at gmail.com
Tue Nov 24 14:03:34 PST 2015 

On 11/24/2015 03:51 PM, Nathan Goldbaum wrote:
> On Tuesday, November 24, 2015, Kacper Kowalik <xarthisius.kk at gmail.com>
> wrote:
> 
>> On 11/24/2015 12:33 PM, Cameron Hummels wrote:
>>> On Tue, Nov 24, 2015 at 9:10 AM, Kacper Kowalik <xarthisius.kk at gmail.com
>> <javascript:;>>
>>> wrote:
>>>>
>>>>
>>>> I'd be strongly -1 on "force_units". In that scenario you invoke several
>>>> costly calls to sympy just to disregard the result. IMO you should drop
>>>> units at the very beginning and create YTArray during return in the
>>>> derived field's definition.
>>>>
>>>
>>> By this you mean something like:
>>>
>>> def _temperature(field, data):
>>>     tr = array_of_wrong_units
>>>     data.apply_units(tr, 'K')
>>>     return tr
>>>
>>> ds.add_field('temperature', function=_temperature, units='K')
>>
>> Nope, if you change units of the array that's cheap (I think), but when
>> you do:
>>
>> def _temp(field, data):
>>     temp = data["foo"] * constant1 * constant2
>>     return temp
>>
>> only to disregard units, that's a huge waste of cycles.
> 
> 
> If the constants here don't have units, there isn't any overhead, which I
> think is what Elizabeth was doing in her original email.

I meant that in general, I wasn't referring to Elizabeth's particular
example.

On the other hand:

$ cat foo.py
import yt
import numpy as np

c1 = 1.0
c2 = 1.0
tab = yt.YTArray(np.arange(100), '')

def foo1(data, constant1, constant2):
    temp = data * constant1 * constant2
    return temp

def foo2(data, constant1, constant2):
    temp = data.d * constant1 * constant2
    return yt.YTArray(temp, '')

if __name__ == '__main__':
    import timeit
    print(timeit.timeit("foo1(tab,c1,c2)", setup="from __main__ import
c1,c2,tab,foo1", number=10000))
    print(timeit.timeit("foo2(tab,c1,c2)", setup="from __main__ import
c1,c2,tab,foo2", number=10000))

Says that foo1() is 2 times slower than foo2()
Cheers,
Kacper


> 
> 
>> Cheers,
>> Kacper
>>
>>> ?
>>>
>>> Or is the syntax wrong here?  I'm not really sure how to use this.
>>>
>>>
>>>
>>>
>>>> Cheers,
>>>> Kacper
>>>>
>>>>> On Tue, Nov 24, 2015 at 7:32 AM, Matthew Turk <matthewturk at gmail.com
>> <javascript:;>>
>>>> wrote:
>>>>>
>>>>>> If absolutely necessary, you can "force" units with:
>>>>>>
>>>>>> data.apply_units(array_to_override, unit_string)
>>>>>>
>>>>>> On Tue, Nov 24, 2015 at 9:31 AM, Cameron Hummels <chummels at gmail.com
>> <javascript:;>>
>>>>>> wrote:
>>>>>>> I would be a fan of making a "force_units" kwarg to enable one to
>>>> create
>>>>>> a
>>>>>>> new field with different units than those specified.  This could
>>>> resolve
>>>>>>> some of the problems with native frontend fields being stuck in the
>>>> wrong
>>>>>>> unit, like I was running into last week.  As long as force_unit is
>> off
>>>> by
>>>>>>> default, it would just enable us to give full control to the user.
>>>>>>>
>>>>>>> On Tue, Nov 24, 2015 at 4:25 AM, Nathan Goldbaum <
>>>> nathan12343 at gmail.com <javascript:;>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Elizabeth,
>>>>>>>>
>>>>>>>> This is discussed in the docs here:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> http://yt-project.org/doc/developing/creating_derived_fields.html#defining-a-new-field
>>>>>>>>
>>>>>>>> You can do one of two things. First, the way I'd handle this is to
>>>>>> ensure
>>>>>>>> that your field definition is returning data that have units of
>>>> Kelvin.
>>>>>>>>
>>>>>>>> For example, something like:
>>>>>>>>
>>>>>>>>     from yt.utilities.physical_constants import kb, mh
>>>>>>>>
>>>>>>>>     mu = 0.6
>>>>>>>>
>>>>>>>>     @derived_field(name=‘Temp’, units=“K”)
>>>>>>>>     def _Temp(field, data):
>>>>>>>>         return data['thermal_energy'] / kb * mu * mh
>>>>>>>>
>>>>>>>> You could also make mu a field parameter rather than a constant, or
>> if
>>>>>> you
>>>>>>>> have a simulation where mu varies with position, make a mean
>> molecular
>>>>>>>> weight derived field.
>>>>>>>>
>>>>>>>> You can also ensure that your field definition returning a
>>>> dimensionless
>>>>>>>> value by stripping the units:
>>>>>>>>
>>>>>>>>     @derived_field(name=‘Temp’, units=“K”)
>>>>>>>>     def _Temp(field, data):
>>>>>>>>         ret = data['thermal_energy'])
>>>>>>>>         return ret.ndarray_view()
>>>>>>>>
>>>>>>>> We don't currently have a way to *force* the units to be whatever
>> you
>>>>>>>> specify in add_field. That said, I don't think it would be terribly
>>>>>> hard to
>>>>>>>> implement.
>>>>>>>>
>>>>>>>> We already have units='auto', which forces the units to be the same
>> as
>>>>>> the
>>>>>>>> return value of your field function. We might add a keyword
>>>>>>>> 'force_units=True' to add_field which does what you're looking for.
>>>> I'd
>>>>>> be
>>>>>>>> happy to review a pull request adding this, or feel free to open an
>>>>>> issue
>>>>>>>> about it to add to our project backlog.
>>>>>>>>
>>>>>>>> Also, worth pointing out that this was designed this way not to
>> anger
>>>>>>>> users, but to protect them from making mistakes in their field
>> units,
>>>>>> which
>>>>>>>> we found to be a common cause of bugs in yt-2. It does mean you need
>>>> to
>>>>>> "buy
>>>>>>>> into" the unit system in your field definition, but the bonus is
>> that
>>>>>> you
>>>>>>>> can be much more sure that you're not making a mistake.
>>>>>>>>
>>>>>>>> Hope that helps,
>>>>>>>>
>>>>>>>> Nathan
>>>>>>>>
>>>>>>>> On Tue, Nov 24, 2015 at 12:41 AM, Elizabeth Tasker
>>>>>>>> <tasker at astro1.sci.hokudai.ac.jp <javascript:;>> wrote:
>>>>>>>>>
>>>>>>>>> Hi everyone,
>>>>>>>>>
>>>>>>>>> While using yt-3, I created a derived field:
>>>>>>>>>
>>>>>>>>> @derived_field(name=‘Temp’, units=“K”)
>>>>>>>>> def _Temp …..
>>>>>>>>>
>>>>>>>>> It crashes with a YTFieldUnitError because it believes the units
>>>> should
>>>>>>>>> be cm**2/s**2. I understand why yt thinks this — I’m using
>>>>>> thermal_energy in
>>>>>>>>> the definition for Temp. However, the units are truly Kelvin and I
>>>>>> think I
>>>>>>>>> should be able to specify whatever I like in “units”!
>>>>>>>>>
>>>>>>>>> Is there a way to stop yt crashing when it disagrees with your life
>>>>>>>>> choices?
>>>>>>>>>
>>>>>>>>> Elizabeth
>>>>>>>>> _______________________________________________
>>>>>>>>> yt-users mailing list
>>>>>>>>> yt-users at lists.spacepope.org <javascript:;>
>>>>>>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> yt-users mailing list
>>>>>>>> yt-users at lists.spacepope.org <javascript:;>
>>>>>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Cameron Hummels
>>>>>>> NSF Postdoctoral Fellow
>>>>>>> Department of Astronomy
>>>>>>> California Institute of Technology
>>>>>>> http://chummels.org
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> yt-users mailing list
>>>>>>> yt-users at lists.spacepope.org <javascript:;>
>>>>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>>>>>
>>>>>> _______________________________________________
>>>>>> yt-users mailing list
>>>>>> yt-users at lists.spacepope.org <javascript:;>
>>>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> yt-users mailing list
>>>>> yt-users at lists.spacepope.org <javascript:;>
>>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> yt-users mailing list
>>>> yt-users at lists.spacepope.org <javascript:;>
>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> yt-users mailing list
>>> yt-users at lists.spacepope.org <javascript:;>
>>> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20151124/4ec06d24/attachment.pgp>

More information about the yt-users mailing list