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.



> 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