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@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@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@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@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@lists.spacepope.org
>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> >
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev@lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev@lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org