Hi Matt.<div><br></div><div>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.</div>

<div><br></div><div>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"])?</div>

<div><br></div><div><br><div class="gmail_quote">On Sun, Jan 29, 2012 at 3:15 PM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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