[yt-users] YTFieldUnitError

[Cameron Hummels]

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