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

Casey W. Stark caseywstark at gmail.com
Wed Feb 22 10:42:15 PST 2012 

Yes, I think StaticOutput "code" units and field units should be handled
exactly the same. Two separate unit systems would be confusing.

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.

Best,
Casey


On Tue, Feb 21, 2012 at 5:30 PM, Matthew Turk <matthewturk at gmail.com> wrote:

> Hi Casey,
>
> On Tue, Feb 21, 2012 at 7:01 PM, Casey W. Stark <caseywstark at gmail.com>
> wrote:
> > 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 <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
> >>
> >
> >
> > _______________________________________________
> > 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/20120222/122152c2/attachment.html>

More information about the yt-dev mailing list