<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Hi Erik,</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">We did look a bit at astropy.units, but decided not to rely on it for a couple of reasons. Some of this might be mistaken on my part - I’m not very familiar with astropy’s unit system.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">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.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">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.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">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.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Right now there isn’t any documentation for the new unit system, although it is described in a YTEP [2].</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">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.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">[1] https://github.com/caseywstark/dimensionful</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">[2] http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0011.html</div> <div id="bloop_sign_1386095345519506944"></div> <br><p style="color:#A0A0A8;">On December 3, 2013 at 1:26:17 PM, Erik Tollerud (<a href="mailto://erik.tollerud@gmail.com">erik.tollerud@gmail.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div>Hello all,
<br>
<br>I think this may be my first post on this list - I'm Erik Tollerud,
<br>one of the members of the Astropy coordinating committee.
<br>
<br>Today I learned there are plans afoot to do some refactoring of the yt
<br>units system. I was wondering if any of you here have spent much time
<br>looking at the Astropy units
<br>framework (https://astropy.readthedocs.org/en/stable/units/index.html)?
<br>
<br>I couldn't find much in a quick glance over yt's docs about how the
<br>unit system actually works, but I'm sure there's a lot of overlap
<br>there. So I can't help but think that we should at least try to get
<br>some sort of interoperability in place. Of course, you're welcome to
<br>directly use any part of Astropy's unit or Quantity frameworks that
<br>right now suit your needs. But given that one of Astropy's main goals
<br>is to improve compatibility and interoperability in python astronomy,
<br>tools, we are happy to do some leg work on our end if it will help
<br>you.
<br>
<br>
<br>--
<br>Erik T
<br>_______________________________________________
<br>yt-dev mailing list
<br>yt-dev@lists.spacepope.org
<br>http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
<br></div></div></span></blockquote></body></html>