[yt-dev] Units in yt and astropy

Erik Tollerud erik.tollerud at gmail.com
Thu Dec 5 11:15:34 PST 2013


Hi Nathan et al.,

See below for the specific items - I think Astropy's units do support
this, but of course I understand that you've already started
developing and don't necessarily want to change horses in mid-stream.

> 1) Since many yt fields are complicated functions of other yt fields, we
> wanted to use a unit system that nicely and automatically handles unit
> conversions with fractional units or powers of units.  We ended up going
> with Casey Stark’s dimensional [1] library, which uses sympy to do symbolic
> manipulations on unit symbols.  We’re not using dimensionful proper, but a
> bundled version that we’ve modified somewhat to suit our needs.

This may not have been true when you last looked, but Astropy's unit
system does this now - at one point it did not, but it now supports
fractional units.  E.g., you can do:

from astropy import units as u
sqm = u.m ** 0.5
assert not sqm == u.m
m2 = sqm ** 2
assert m2 == i.m


> 2) We have domain-specific constraints: specifically we need a concept of
> ‘code units’ as well as simulation parameter dependent units (i.e.
> cosmological units, magnetic field units, and other domain-specific units).
> For example, the Enzo code has an internal unit system such that the domain
> runs from 0.0 to 1.0, yet the physical system the simulation represents can
> have arbitrary length units.  We want to present the user quantities in
> physical units rather than internal ‘code units', but we still want to make
> the internal unit data available (for simulation debugging purposes, for
> example).  This means that the code units need to be baked in to the unit
> system.

In principal I think this *could* be done with the Astropy units
system pretty easily: you just define a new unit type, e.g.
"tipsy_length", and give a scale between that and, say m.  Then
converting, say, an array from simulation units to meters is as simple
as:

metersarray = (simarray * tipsy_length).to(u.m)

Or am I missing some subtlety?


> 3) Avoiding a new hard dependency.  This one is a bit more debateable, but
> we want to expand beyond astronomy to become a general tool for analysis of
> volumetric data - having a hard dependency on astropy might hamstring those
> efforts.

That's totally understandable.  We've considered splitting out our
unit stuff to be a separate package, but I think the feeling is that
it's more administrative overhead for no clear payoff.  But if someone
really wanted it, we wouldn't necessarily be against doing that.

> That said, I think there’s definitely room for a conversion layer to
> astropy.units.  I’ll admit, I haven’t looked very closely at this, but I
> think it will be doable.  Would love to chat more about this once the unit
> work has settled down a bit.

Sounds good - from what I see on the YTEP, I suspect it should be
pretty easy to do a mapping in both directions, but of course there
could easily be devils in the details.




> On December 3, 2013 at 1:26:17 PM, Erik Tollerud (erik.tollerud at gmail.com)
> wrote:
>
> Hello all,
>
> I think this may be my first post on this list - I'm Erik Tollerud,
> one of the members of the Astropy coordinating committee.
>
> Today I learned there are plans afoot to do some refactoring of the yt
> units system. I was wondering if any of you here have spent much time
> looking at the Astropy units
> framework (https://astropy.readthedocs.org/en/stable/units/index.html)?
>
> I couldn't find much in a quick glance over yt's docs about how the
> unit system actually works, but I'm sure there's a lot of overlap
> there. So I can't help but think that we should at least try to get
> some sort of interoperability in place. Of course, you're welcome to
> directly use any part of Astropy's unit or Quantity frameworks that
> right now suit your needs. But given that one of Astropy's main goals
> is to improve compatibility and interoperability in python astronomy,
> tools, we are happy to do some leg work on our end if it will help
> you.
>
>
> --
> Erik T
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org



-- 
Erik



More information about the yt-dev mailing list