Yes, I think StaticOutput "code" units and field units should be handled exactly the same. Two separate unit systems would be confusing.<div><br></div><div>So the StaticOutput conversion methods would use the frontend "code" unit data and outsource conversion to something like yt.units? +1 on being explicit about what is comoving and proper.</div>
<div><br></div><div>Best,</div><div>Casey</div><div><br></div><div><br><div class="gmail_quote">On Tue, Feb 21, 2012 at 5:30 PM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com">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">Hi Casey,<br>
<div class="im"><br>
On Tue, Feb 21, 2012 at 7:01 PM, Casey W. Stark <<a href="mailto:caseywstark@gmail.com">caseywstark@gmail.com</a>> wrote:<br>
> I don't think I understand all the uses here, but is it just a question of<br>
> unit conversion? If so, I don't think it should be tied into StaticOutput,<br>
> but a function and a dictionary of unit data in cgs sitting somewhere.<br>
<br>
</div>It's not just unit conversion between existing units, but also between<br>
potentially comoving units from the code and proper units. As an<br>
example, a code might store units such that density == 1 corresponds<br>
to the mean density of the universe at a fixed redshift. So yes, it<br>
would be a layer on top of units that exist, that we know about -- for<br>
instance, it would need to know how to convert to code coordinates a<br>
distance of 100 kpc, but really you could imagine that on the backend<br>
it's converting into a fixed unit (cm, mpc, whatever) and then<br>
applying a conversion to kpc on top of that. So it's what you say,<br>
plus a bit of shine to make it aware of code-specific information.<br>
<div class="im"><br>
><br>
> Is it always clear what type of unit is being converted? I like the idea of<br>
> getting values in code units like the pf.length(dist_in_mpc, "Mpc") idiom<br>
> Matt suggests.<br>
<br>
</div>I think that it *should* be clear. One issue that we need to decide<br>
before steaming ahead is, do we want to confine to this -- where input<br>
is always in physical units, and output is always in code? I would be<br>
fine with this. It also then would work with time.<br>
<div class="im"><br>
><br>
> When I imagined units in yt before, I only thought about attaching units to<br>
> fields. I'm not sure about the region object cases.<br>
<br>
</div>I am leaning toward what Britton suggested, which would also include<br>
converting fields. Since we've bandied about about this in the past,<br>
how does it strike you, in unifying these?<br>
<br>
-Matt<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Best,<br>
> Casey<br>
><br>
><br>
> On Tue, Feb 21, 2012 at 9:20 AM, Britton Smith <<a href="mailto:brittonsmith@gmail.com">brittonsmith@gmail.com</a>><br>
> wrote:<br>
>><br>
>> I'm in favor of a general unit converting object for all quantities. The<br>
>> alternative to would be to have time_units, length_units, b_units, etc,<br>
>> which will unwieldy quickly. It might also be nice if it had some sort of<br>
>> support for prefixes like kilo, mega, giga, etc. That way, we wouldn't have<br>
>> to carry around, for example, conversions to pc, kpc, and Mpc. If this<br>
>> sounds like what people would be interested in having, I wouldn't mind<br>
>> working on this.<br>
>><br>
>> Britton<br>
>><br>
>><br>
>> On Tue, Feb 21, 2012 at 7:37 AM, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> The places we typically use conversions to length scales explicitly in<br>
>>> 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>
>>><br>
>>> On Mon, Feb 20, 2012 at 10:24 AM, Britton Smith <<a href="mailto:brittonsmith@gmail.com">brittonsmith@gmail.com</a>><br>
>>> 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<br>
>>> > sphere,<br>
>>> > disk, etc object in the manner discuss in point 3 and push toward using<br>
>>> > 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">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">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<br>
>>> >> > data<br>
>>> >> > knows what a Mpc, or even Rsun is. While it's trivial to workaround<br>
>>> >> > 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">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">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">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">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">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">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">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>