[yt-users] YTFieldUnitError

Nathan Goldbaum nathan12343 at gmail.com
Tue Nov 24 13:51:14 PST 2015


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.



> 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
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20151124/5d237016/attachment.htm>


More information about the yt-users mailing list