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