[yt-users] YTFieldUnitError

Tue Nov 24 19:53:12 PST 2015

On Tue, Nov 24, 2015 at 8:35 PM, Elizabeth Tasker <
tasker at astro1.sci.hokudai.ac.jp> wrote:

> Hi Everyone,
>
> Nathan — thank you very much for that detailed explanation.
>
> I like Cameron’s idea of having a force override — much of the code I
> write isn’t “good” so much as debugging and checking. For that, user checks
> impede more than help since speed-writing is what I’m after.
>

You can also define them youself, but you'll need to make sure they have
units attached to them. For example, if I wanted to define the weight of my
pet hamster as a physical constant, I could do:

    from yt.units import gram

    m_hamster = 100*gram

You could also do:

    from yt import YTQuantity

    m_hamster = YTQuantity(100, 'g')

Take a look at the contents of yt/units/__init__.py to see all of the units
defined in the yt.units namespace:

https://bitbucket.org/yt_analysis/yt/src/d7acb82ef45047599a23e3c08805ab2af01c7b32/yt/units/__init__.py?at=stable&fileviewer=file-view-default

so you can look at yt/units/unit_symbols.py to see all the units in the
yt.units namespace:

https://bitbucket.org/yt_analysis/yt/src/03a54b627189e63eaee9f2bc1d4a36c3ab6b9637/yt/units/unit_symbols.py?at=yt&fileviewer=file-view-default

On the dev branch (i.e. in the upcoming yt 3.3 release) we do something a
little fancier in yt/__init__.py to also include physical constants in the
yt.units namespace and ensure that the only symbols defined there are
YTQuantity instances:

https://bitbucket.org/yt_analysis/yt/src/03a54b627189e63eaee9f2bc1d4a36c3ab6b9637/yt/units/__init__.py?at=yt&fileviewer=file-view-default

If you're on the current stable release of yt and want to use yt's
predefined physical constants, you want to import them from the
"yt.ulitilies.physical_constants" namespace. If you're on the dev branch
you should import physical constants from the "yt.units" namespace. These
physical constants are YTQuantity instances that have yt unit objects
attached to them.

>
> Elizabeth
>
>
>
>
> On 25 Nov 2015, at 10:23, Cameron Hummels <chummels at gmail.com> wrote:
>
> I guess what I meant to ask was if the code I put was a solution to the
> problem, not an example of the problem?
>
> On Tue, Nov 24, 2015 at 11:56 AM, 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>
>> > 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.
>> 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>
>> >> 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
>> >
>> >>>> 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>
>> >>>>> 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> 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
>> >>>>>>> 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
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> 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
>> >>>>> 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
>> >>>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> 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
>>
>>
>
>
> --
> 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
> 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/20151124/762929ef/attachment.html>