Unit conversions in frontends
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. 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. Best, Casey
Hi Casey, On Sat, Jan 28, 2012 at 7:38 PM, Casey W. Stark <caseywstark@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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"])? On Sun, Jan 29, 2012 at 3:15 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Casey,
On Sat, Jan 28, 2012 at 7:38 PM, Casey W. Stark <caseywstark@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Casey, On Mon, Jan 30, 2012 at 2:23 AM, Casey W. Stark <caseywstark@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@gmail.com> wrote:
Hi Casey,
On Sat, Jan 28, 2012 at 7:38 PM, Casey W. Stark <caseywstark@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (2)
-
Casey W. Stark -
Matthew Turk