[yt-dev] RFC: introduce {length, mass}_units (similar to time_units)

[Matthew Turk]

Hi Kacper,

This is a gigantic weak spot in yt: handling of units, which generally
does *work*, is done behind some relatively old and unnecessary code.
When I started writing it, I learned about operator overloading, and
so I tossed all the parameters, units, and time_units into a single
call to __getitem__.  I've disliked this for quite some time, as it
conflates all types of conversion between things, as well as
conflating conversion with parameters.

Adding a length and mass unit system would be a bandaid to this system
... I'm inclined to say it's probably okay to do, but I would rather
we go through a more in-depth improvement.

1) Deprecate *immediately* __getitem__ on a parameter file.  This
means adding a DeprecationWarning, in whcih we say that in version 3.0
this functionality will go away.
2) Replace all usages of pf[whatever] in the code with calls to
explicitly the parameters dict or something else.
3) Find all places where the idiom something/pf[unit] is used, and
either replace them with fix_length on it or find some other way
around it.  (Did you know that spheres, cylinders, etc can all have
tuples of value, unit passed in?)
4) Set up our base of unit conversions, which are applied when IO is conducted.
5) Use conversions between those units rather than relying on the
parameter file.

For #5, we could either use a system like Amusecode.org uses (where
they apply sidecar unit values to wrapped ndarrays; the main amuse
architect is on this list, so perhaps he could say a bit more) or I
noticed that Casey's blog indicated he released Dimensionful, a
library for light tracking and converting units, which would also work
quite nicely for this.

Either way, I want to get rid of the current system and plan something
out; first step is letting people know that we're deprecating
pf[something].  [+-][01]?  But, for now, adding on what you suggest is
fine, Kacper.  :)

Thoughts?

-Matt

On Sat, Feb 18, 2012 at 10:02 AM, Kacper Kowalik
<xarthisius.kk at gmail.com> wrote:
> Hi,
> I've been hit by a part of the code
> (plot_modifications:get_smallest_appropriate_unit) that assumed my data
> knows what a Mpc, or even Rsun is. While it's trivial to workaround by
> using try/except, that made wonder why time_units get a special
> treatment in StaticOutput? Would it be beneficial to introduce
> corresponding {lenght,mass}_units?
> Cheers,
> Kacper
>
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>