Hi Casey,
On Tue, Feb 21, 2012 at 7:01 PM, Casey W. Stark
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.
It's not just unit conversion between existing units, but also between potentially comoving units from the code and proper units. As an example, a code might store units such that density == 1 corresponds to the mean density of the universe at a fixed redshift. So yes, it would be a layer on top of units that exist, that we know about -- for instance, it would need to know how to convert to code coordinates a distance of 100 kpc, but really you could imagine that on the backend it's converting into a fixed unit (cm, mpc, whatever) and then applying a conversion to kpc on top of that. So it's what you say, plus a bit of shine to make it aware of code-specific information.
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.
I think that it *should* be clear. One issue that we need to decide before steaming ahead is, do we want to confine to this -- where input is always in physical units, and output is always in code? I would be fine with this. It also then would work with time.
When I imagined units in yt before, I only thought about attaching units to fields. I'm not sure about the region object cases.
I am leaning toward what Britton suggested, which would also include converting fields. Since we've bandied about about this in the past, how does it strike you, in unifying these? -Matt
Best, Casey
On Tue, Feb 21, 2012 at 9:20 AM, Britton Smith
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
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
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
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
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
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org