<div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>
When I imagined units in yt before, I only thought about attaching units to fields. I'm not sure about the region object cases.</div>
<div><br></div><div>Best,</div><div>Casey</div><div><br></div><br><div class="gmail_quote">On Tue, Feb 21, 2012 at 9:20 AM, Britton Smith <span dir="ltr"><<a href="mailto:brittonsmith@gmail.com">brittonsmith@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<span class="HOEnZb"><font color="#888888"><br>
<br>Britton</font></span><div class="HOEnZb"><div class="h5"><br><br><div class="gmail_quote">On Tue, Feb 21, 2012 at 7:37 AM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">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">
The places we typically use conversions to length scales explicitly in recipes:<br>
<br>
* Spheres (this accepts tuples)<br>
* Disks (this accepts tuples)<br>
* Plot collection (only accepts the equivalent of tuples)<br>
<br>
But we also implicitly use length scale when constructing things like<br>
regions, which require left_edge and right_edge. A common pattern for<br>
those is to add on to a left edge a given length.<br>
<br>
Before I go committing any deprecation warnings, I'd like to make sure<br>
we have the idioms down.<br>
<br>
1) Parameters should either be accessed as a property if they are<br>
independent of frontend (i.e., current_time, cosmology_simulation) or<br>
as an item in the .parameters dict.<br>
2) Lengths when explicitly specified (as opposed to coordinates) are<br>
recommended to be in tuples when writing recipes. yt should still<br>
accept code units.<br>
3) Uses of unit conversion internal to yt (the only place they should<br>
be with any regularity, in my opinion) should explicitly query the<br>
appropriate {something}_units dict.<br>
4) Any calls to __getitem__ on pf will raise a deprecation warning.<br>
<br>
But, how should we expose length conversion to the user, for instances<br>
of specifying (for instance) relative coordinates? I would rather we<br>
come up with a solution now rather than later. Of the different units<br>
-- length, density/b-field/whatever, time -- we really only need to<br>
expose to the user the conversion to and from code units for length.<br>
So should this be a special case? i.e., pf.length(val, unit)? Or<br>
should we set up a more generic, pf.units object, with<br>
pf.units.convert(ival, iunit, ounit='code')?<br>
<br>
-Matt<br>
<div><div><br>
On Mon, Feb 20, 2012 at 10:24 AM, Britton Smith <<a href="mailto:brittonsmith@gmail.com" target="_blank">brittonsmith@gmail.com</a>> wrote:<br>
> I'm +1 on deprecating the __getitem__ stuff. I think at this point it<br>
> mostly creates confusion.<br>
><br>
> I also think it might be a good idea to phase out instantiation of sphere,<br>
> disk, etc object in the manner discuss in point 3 and push toward using the<br>
> (size, unit) tuple method. This method is consistent with how the<br>
> time_series analogs of those objects are created and I think that<br>
> consistency is valuable.<br>
><br>
> Britton<br>
><br>
><br>
> On Sun, Feb 19, 2012 at 11:49 AM, Matthew Turk <<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi Kacper,<br>
>><br>
>> This is a gigantic weak spot in yt: handling of units, which generally<br>
>> does *work*, is done behind some relatively old and unnecessary code.<br>
>> When I started writing it, I learned about operator overloading, and<br>
>> so I tossed all the parameters, units, and time_units into a single<br>
>> call to __getitem__. I've disliked this for quite some time, as it<br>
>> conflates all types of conversion between things, as well as<br>
>> conflating conversion with parameters.<br>
>><br>
>> Adding a length and mass unit system would be a bandaid to this system<br>
>> ... I'm inclined to say it's probably okay to do, but I would rather<br>
>> we go through a more in-depth improvement.<br>
>><br>
>> 1) Deprecate *immediately* __getitem__ on a parameter file. This<br>
>> means adding a DeprecationWarning, in whcih we say that in version 3.0<br>
>> this functionality will go away.<br>
>> 2) Replace all usages of pf[whatever] in the code with calls to<br>
>> explicitly the parameters dict or something else.<br>
>> 3) Find all places where the idiom something/pf[unit] is used, and<br>
>> either replace them with fix_length on it or find some other way<br>
>> around it. (Did you know that spheres, cylinders, etc can all have<br>
>> tuples of value, unit passed in?)<br>
>> 4) Set up our base of unit conversions, which are applied when IO is<br>
>> conducted.<br>
>> 5) Use conversions between those units rather than relying on the<br>
>> parameter file.<br>
>><br>
>> For #5, we could either use a system like Amusecode.org uses (where<br>
>> they apply sidecar unit values to wrapped ndarrays; the main amuse<br>
>> architect is on this list, so perhaps he could say a bit more) or I<br>
>> noticed that Casey's blog indicated he released Dimensionful, a<br>
>> library for light tracking and converting units, which would also work<br>
>> quite nicely for this.<br>
>><br>
>> Either way, I want to get rid of the current system and plan something<br>
>> out; first step is letting people know that we're deprecating<br>
>> pf[something]. [+-][01]? But, for now, adding on what you suggest is<br>
>> fine, Kacper. :)<br>
>><br>
>> Thoughts?<br>
>><br>
>> -Matt<br>
>><br>
>> On Sat, Feb 18, 2012 at 10:02 AM, Kacper Kowalik<br>
>> <<a href="mailto:xarthisius.kk@gmail.com" target="_blank">xarthisius.kk@gmail.com</a>> wrote:<br>
>> > Hi,<br>
>> > I've been hit by a part of the code<br>
>> > (plot_modifications:get_smallest_appropriate_unit) that assumed my data<br>
>> > knows what a Mpc, or even Rsun is. While it's trivial to workaround by<br>
>> > using try/except, that made wonder why time_units get a special<br>
>> > treatment in StaticOutput? Would it be beneficial to introduce<br>
>> > corresponding {lenght,mass}_units?<br>
>> > Cheers,<br>
>> > Kacper<br>
>> ><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > yt-dev mailing list<br>
>> > <a href="mailto:yt-dev@lists.spacepope.org" target="_blank">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" target="_blank">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>
><br>
> _______________________________________________<br>
> yt-dev mailing list<br>
> <a href="mailto:yt-dev@lists.spacepope.org" target="_blank">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" target="_blank">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>
</div></div></blockquote></div><br>
</div></div><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></blockquote></div><br>