[yt-dev] Unit conversions in frontends

[Matthew Turk]

Hi Casey,

On Mon, Jan 30, 2012 at 2:23 AM, Casey W. Stark <caseywstark at gmail.com> wrote:
> Hi Matt.
>
> Okay I think I understand. I set the numbers I use for field conversions in
> yt.frontends.nyx.definitions, so I can use those again to fill units,
> time_units, and conversion_factors. We can clean this up in the future, but
> it sounds like this will be most complete with the current frontend
> infrastructure.
>
> For future units, do you think the Unit object for a given field should be
> an attribute of each field (pf.h.all_data()["density"].units) or the
> parameter file (pf.units["density"])?

For the *future*, I would say we keep 'units' as is for a given field,
such that it's a string, and the unit-conversion/unit-handling object
would hang off the pf.

Let me know if I can help with the Nyx units stuff.

-Matt

>
>
> On Sun, Jan 29, 2012 at 3:15 PM, Matthew Turk <matthewturk at gmail.com> wrote:
>>
>> Hi Casey,
>>
>> On Sat, Jan 28, 2012 at 7:38 PM, Casey W. Stark <caseywstark at gmail.com>
>> wrote:
>> > Hi all.
>> >
>> > I'm a bit confused about the unit mechanics in yt right now. I noticed
>> > there's a convert_function for fields, but there are also the units,
>> > time_units, and conversion_factors attributes for StaticOutput.
>>
>> Yup.  These need to be consolidated, and querying the StaticOutput
>> subclass (in my opinion) should only return values from *one* of these
>> dictionaries.  I believe that we can use a deprecation warning in 2.4
>> and actually remove querying it in 3.0.
>>
>> _convert_function largely exists independently.  Imagine the case that
>> you have a velocity (in code units) field and units to convert length
>> and time.  You would use them in the _convert_function.
>>
>> >
>> > For the Nyx frontend, I have added convert_function's for each field to
>> > convert the cosmological units into CGS. This works in my fork now and
>> > everything is in cgs and plots fine. Now I know I need to update the
>> > _set_units method of NyxStaticOutput, but I'm not sure what to do with
>> > those
>> > attributes and how they are used later.
>>
>> They only get used explicitly.  Typically what happens is you set
>> conversion_factors for, say, Density, and then explicitly convert
>> Density using them.
>>
>> I would like to see this change dramatically in future releases, with
>> an explicit "Units" object that gets attached to each parameter file.
>> This Units object would be initialized with a handful of specific
>> "code-native to CGS" values and then we could query it for, say,
>> "code-native to Gauss" or "code-native to g/cc".  I have no real
>> sketch yet of how to do this, but we could either use an existing
>> external tool, modify something like what you wrote to do it that you
>> showed me a few weeks ago, or come up with an entirely new thing.
>>
>> Thoughts?
>>
>> -Matt
>>
>> >
>> > Best,
>> > Casey
>> >
>> > _______________________________________________
>> > yt-dev mailing list
>> > yt-dev at lists.spacepope.org
>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>