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@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@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@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@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@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@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@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@lists.spacepope.org
>>>>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> yt-users mailing list
>>>>>> yt-users@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@lists.spacepope.org
>>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>>>
>>>> _______________________________________________
>>>> yt-users mailing list
>>>> yt-users@lists.spacepope.org
>>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> yt-users mailing list
>>> yt-users@lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>
>>
>>
>>
>> _______________________________________________
>> yt-users mailing list
>> yt-users@lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>
>>
>
>
>
>
> _______________________________________________
> yt-users mailing list
> yt-users@lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>

_______________________________________________
yt-users mailing list
yt-users@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@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

_______________________________________________
yt-users mailing list
yt-users@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org