[yt-dev] Unit conversions in frontends

Casey W. Stark caseywstark at gmail.com
Sun Jan 29 23:23:22 PST 2012


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 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20120129/c7e74421/attachment.htm>


More information about the yt-dev mailing list