[yt-users] YTFieldUnitError

Tue Nov 24 18:35:33 PST 2015

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.

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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <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 <mailto: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 <mailto:yt-users at lists.spacepope.org>
> >>>>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org <http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> yt-users mailing list
> >>>>>> yt-users at lists.spacepope.org <mailto:yt-users at lists.spacepope.org>
> >>>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-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 <http://chummels.org/>
> >>>>>
> >>>>> _______________________________________________
> >>>>> yt-users mailing list
> >>>>> yt-users at lists.spacepope.org <mailto:yt-users at lists.spacepope.org>
> >>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org <http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org>
> >>>>>
> >>>> _______________________________________________
> >>>> yt-users mailing list
> >>>> yt-users at lists.spacepope.org <mailto:yt-users at lists.spacepope.org>
> >>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org <http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> yt-users mailing list
> >>> yt-users at lists.spacepope.org <mailto:yt-users at lists.spacepope.org>
> >>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org <http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org>
> >>>
> >>
> >>
> >>
> >> _______________________________________________
> >> yt-users mailing list
> >> yt-users at lists.spacepope.org <mailto:yt-users at lists.spacepope.org>
> >> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org <http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org>
> >>
> >>
> >
> >
> >
> >
> > _______________________________________________
> > yt-users mailing list
> > yt-users at lists.spacepope.org <mailto:yt-users at lists.spacepope.org>
> > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org <http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org>
> >
> 
> 
> 
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org <mailto:yt-users at lists.spacepope.org>
> http://lists.spacepope.org/listinfo.cgi/yt-users-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 <http://chummels.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/20151125/af2bd1aa/attachment.htm>