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

Tue Feb 21 16:01:07 PST 2012

I don't think I understand all the uses here, but is it just a question of
unit conversion? If so, I don't think it should be tied into StaticOutput,
but a function and a dictionary of unit data in cgs sitting somewhere.

Is it always clear what type of unit is being converted? I like the idea of
getting values in code units like the pf.length(dist_in_mpc, "Mpc") idiom
Matt suggests.

When I imagined units in yt before, I only thought about attaching units to
fields. I'm not sure about the region object cases.

Best,
Casey

On Tue, Feb 21, 2012 at 9:20 AM, Britton Smith <brittonsmith at gmail.com>wrote:

> 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
>>
>
>
> _______________________________________________
> 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/915303cc/attachment.html>