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

Tue Feb 21 09:20:09 PST 2012

I'm in favor of a general unit converting object for all quantities.  The
alternative to would be to have time_units, length_units, b_units, etc,
which will unwieldy quickly.  It might also be nice if it had some sort of
support for prefixes like kilo, mega, giga, etc.  That way, we wouldn't
have to carry around, for example, conversions to pc, kpc, and Mpc.  If
this sounds like what people would be interested in having, I wouldn't mind
working on this.

Britton

On Tue, Feb 21, 2012 at 7:37 AM, Matthew Turk <matthewturk at gmail.com> wrote:

> The places we typically use conversions to length scales explicitly in
> recipes:
>
> * Spheres (this accepts tuples)
> * Disks (this accepts tuples)
> * Plot collection (only accepts the equivalent of tuples)
>
> But we also implicitly use length scale when constructing things like
> regions, which require left_edge and right_edge.  A common pattern for
> those is to add on to a left edge a given length.
>
> Before I go committing any deprecation warnings, I'd like to make sure
> we have the idioms down.
>
> 1) Parameters should either be accessed as a property if they are
> independent of frontend (i.e., current_time, cosmology_simulation) or
> as an item in the .parameters dict.
> 2) Lengths when explicitly specified (as opposed to coordinates) are
> recommended to be in tuples when writing recipes.  yt should still
> accept code units.
> 3) Uses of unit conversion internal to yt (the only place they should
> be with any regularity, in my opinion) should explicitly query the
> appropriate {something}_units dict.
> 4) Any calls to __getitem__ on pf will raise a deprecation warning.
>
> But, how should we expose length conversion to the user, for instances
> of specifying (for instance) relative coordinates?  I would rather we
> come up with a solution now rather than later.  Of the different units
> -- length, density/b-field/whatever, time -- we really only need to
> expose to the user the conversion to and from code units for length.
> So should this be a special case?  i.e., pf.length(val, unit)?  Or
> should we set up a more generic, pf.units object, with
> pf.units.convert(ival, iunit, ounit='code')?
>
> -Matt
>
> On Mon, Feb 20, 2012 at 10:24 AM, Britton Smith <brittonsmith at gmail.com>
> wrote:
> > I'm +1 on deprecating the __getitem__ stuff.  I think at this point it
> > mostly creates confusion.
> >
> > I also think it might be a good idea to phase out instantiation of
> sphere,
> > disk, etc object in the manner discuss in point 3 and push toward using
> the
> > (size, unit) tuple method.  This method is consistent with how the
> > time_series analogs of those objects are created and I think that
> > consistency is valuable.
> >
> > Britton
> >
> >
> > On Sun, Feb 19, 2012 at 11:49 AM, Matthew Turk <matthewturk at gmail.com>
> > wrote:
> >>
> >> 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
> >> >
> >> _______________________________________________
> >> 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
> >
> _______________________________________________
> 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/20120221/c5076e39/attachment.html>