<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 7, 2013 at 1:25 PM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">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"><div class="im">On Tue, May 7, 2013 at 1:24 PM, Casey W. Stark <<a href="mailto:caseywstark@gmail.com">caseywstark@gmail.com</a>> wrote:<br>

> Ok, I just tried this and it doesn't work. Even though the Unit objects are<br>
> separate instances, the sympy Symbol objects in the expressions are treated<br>
> as the same. We will have to think about the design some more.<br>
<br>
</div>Although, on reflection, maybe *this is okay*.  We should perhaps<br>
assume that anyone who is actually dividing or multiplying or<br>
something the native code units knows what they're doing.  If they<br>
want to look at the cgs units, they should be doing so.  I'm not<br>
entirely sure.<br></blockquote><div><br></div><div style>I'm not so sure about this. What about simulations that are performed in dimensionless units? This is something that yt handles poorly right now, and I think this system should fix that. For example, in a dimensionless system, the code units are fully functional and probably what you want to work in. Or am I missing something here?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
><br>
><br>
> On Tue, May 7, 2013 at 10:17 AM, Casey W. Stark <<a href="mailto:caseywstark@gmail.com">caseywstark@gmail.com</a>><br>
> wrote:<br>
>><br>
>> > think of having two different parameter<br>
>> files from the same simulation open at the same time.<br>
>><br>
>> Ah, got it. You're right that this will be a problem. The two datasets<br>
>> will have separate unit registries, so something like "pccm" units can be<br>
>> different from each. However, if you try something like<br>
>> ds1_dd["enzo_comoving_density"] / ds2_dd["enzo_comoving_density"], sympy<br>
>> might just cancel out the symbols in the unit expressions and the conversion<br>
>> will not work. I'll try something...<br>
>><br>
>><br>
>> On Tue, May 7, 2013 at 10:05 AM, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> On Tue, May 7, 2013 at 12:13 PM, Casey W. Stark <<a href="mailto:caseywstark@gmail.com">caseywstark@gmail.com</a>><br>
>>> wrote:<br>
>>> > Hey Matt.<br>
>>> ><br>
>>> > Excellent! It's a considerable change, so we should dread it a bit, but<br>
>>> > really glad you like the idea too.<br>
>>> ><br>
>>> > About where the conversion should happen, I like the idea to return any<br>
>>> > universal fields in cgs by default. Operations between "code" fields<br>
>>> > ("mycode_density") would return in code units and ops between universal<br>
>>> > fields ("density") would return in cgs. That means most users won't see<br>
>>> > a<br>
>>> > change too. Mixing units is mostly straightforward. I think the only<br>
>>> > gotcha<br>
>>> > is for add and sub, where we return in the left object's units.<br>
>>><br>
>>> That sounds good to me.<br>
>>><br>
>>> ><br>
>>> >> How do we handle the fact<br>
>>> > that converting "code_density" to cgs is different for different<br>
>>> > arrays, depending on the code?  i.e., if I have two "code_density"<br>
>>> > arrays from a code that stores them in comoving code units, how do we<br>
>>> > distinguish between those two things during division, say?<br>
>>> ><br>
>>> > I'm not sure I'm following here, but is this a case where density field<br>
>>> > a<br>
>>> > has different units from density field b? If so, I think we have to<br>
>>> > define<br>
>>> > separate units for the code densities. Here's a quick Nyx example...<br>
>>><br>
>>> Not exactly, but close -- think of having two different parameter<br>
>>> files from the same simulation open at the same time.  If the sim<br>
>>> stores internally in comoving units, the native->propercgs will vary<br>
>>> between those two, but the registered units might be the same name,<br>
>>> for instance "enzo_density" or something.<br>
>>><br>
>>> ><br>
>>> > unit_registry.add("nyx_cm_density", "Msun/Mpccm**3")<br>
>>> > unit_registry.add("nyx_prop_density", "g/cm**3")<br>
>>> ><br>
>>> > add_field("nyx_density", units="nyx_cm_density")<br>
>>> > add_field("nyx_hi_density", units="nyx_prop_density")<br>
>>> ><br>
>>> > dd["nyx_density"] / dd["nyx_hi_density"]    (should return<br>
>>> > dimensionless<br>
>>> > YTArray)<br>
>>> ><br>
>>> > - Casey<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > On Tue, May 7, 2013 at 8:18 AM, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>><br>
>>> > wrote:<br>
>>> >><br>
>>> >> Hi Casey and Nathan,<br>
>>> >><br>
>>> >> Last night when I read this I felt a bit of dread in my stomach,<br>
>>> >> worrying that this would make things a lot more complex and difficult.<br>
>>> >>  But I have to say, now having thought it through and read your<br>
>>> >> pastes, reflected on the contents of the YTEP ... I think this is<br>
>>> >> beautiful and elegant.  Very nicely thought out.<br>
>>> >><br>
>>> >> I completely agree that -- particularly in 3.0 -- we no longer need to<br>
>>> >> perform any conversions at IO time, and instead we should be pushing<br>
>>> >> this to the places where the data will be presented to individual<br>
>>> >> users.  This will require some thought about where we want this<br>
>>> >> conversion to take place (i.e., at the display layer?) but it should<br>
>>> >> be completely workable to do so.  The ensure_cgs decorator is a great<br>
>>> >> way to manage this.<br>
>>> >><br>
>>> >> I'm +1 on this, and can help with the technical details.  As it<br>
>>> >> stands, all unit conversions happen in a single place in the code, so<br>
>>> >> we can simply remove the items there and instead just wrap them in the<br>
>>> >> appropriate "code" units.  We'll need to figure out the specific<br>
>>> >> semantics of that but it should be okay.  How do we handle the fact<br>
>>> >> that converting "code_density" to cgs is different for different<br>
>>> >> arrays, depending on the code?  i.e., if I have two "code_density"<br>
>>> >> arrays from a code that stores them in comoving code units, how do we<br>
>>> >> distinguish between those two things during division, say?<br>
>>> >><br>
>>> >> -Matt<br>
>>> >><br>
>>> >> On Mon, May 6, 2013 at 6:50 PM, Casey W. Stark <<a href="mailto:caseywstark@gmail.com">caseywstark@gmail.com</a>><br>
>>> >> wrote:<br>
>>> >> > Hey Nathan.<br>
>>> >> ><br>
>>> >> > Thanks for the reminder about `ensure_cgs`. Definitely helps to see<br>
>>> >> > the<br>
>>> >> > pseudocode too. Users could also write out the array.convert_to(...)<br>
>>> >> > in<br>
>>> >> > the<br>
>>> >> > field function for whatever obscure units. I guess this is similar<br>
>>> >> > to<br>
>>> >> > the<br>
>>> >> > fields with the units tacked on to the name, but much cleaner.<br>
>>> >> ><br>
>>> >> > I think making the code to universal field mapping more explicit<br>
>>> >> > will be<br>
>>> >> > very helpful. I've been confused about where some derived fields<br>
>>> >> > come<br>
>>> >> > from<br>
>>> >> > many times!<br>
>>> >> ><br>
>>> >> ><br>
>>> >> > On Mon, May 6, 2013 at 3:39 PM, Nathan Goldbaum<br>
>>> >> > <<a href="mailto:goldbaum@ucolick.org">goldbaum@ucolick.org</a>><br>
>>> >> > wrote:<br>
>>> >> >><br>
>>> >> >> Hey Casey,<br>
>>> >> >><br>
>>> >> >> That's pretty much what I was thinking, although I wanted to add a<br>
>>> >> >> little<br>
>>> >> >> bit of syntactic sugar so the CGS conversion happens automatically:<br>
>>> >> >><br>
>>> >> >> <a href="http://paste.yt-project.org/show/3443/" target="_blank">http://paste.yt-project.org/show/3443/</a><br>
>>> >> >><br>
>>> >> >> The ensure_cgs decorator would simply call convert_to_cgs on the<br>
>>> >> >> returned<br>
>>> >> >> YTArray.  The nice thing about this is the flow of data is clear,<br>
>>> >> >> things<br>
>>> >> >> come in to the field definition code units and leave in CGS.  This<br>
>>> >> >> also<br>
>>> >> >> eliminates the need for the unit conversion functions that are<br>
>>> >> >> scattered<br>
>>> >> >> throughout the frontends and universal_fields.py.<br>
>>> >> >><br>
>>> >> >> This has the nice feature that each of the code frontends will need<br>
>>> >> >> to<br>
>>> >> >> explicitly define mappings to the CGS fields (like Density) needed<br>
>>> >> >> by<br>
>>> >> >> universal fields.<br>
>>> >> >><br>
>>> >> >> -Nathan<br>
>>> >> >><br>
>>> >> >><br>
>>> >> >> On Mon, May 6, 2013 at 3:33 PM, Casey W. Stark<br>
>>> >> >> <<a href="mailto:caseywstark@gmail.com">caseywstark@gmail.com</a>><br>
>>> >> >> wrote:<br>
>>> >> >>><br>
>>> >> >>> Hey yt.<br>
>>> >> >>><br>
>>> >> >>> Nathan and I had a cool idea as an extension of the units work,<br>
>>> >> >>> but I<br>
>>> >> >>> am<br>
>>> >> >>> hitting a yt internals knowledge wall writing a YTEP. I would like<br>
>>> >> >>> some<br>
>>> >> >>> input on technical details or general feelings before I move ahead<br>
>>> >> >>> with the<br>
>>> >> >>> write-up.<br>
>>> >> >>><br>
>>> >> >>> One of the things mentioned in the units YTEP is handling code<br>
>>> >> >>> units.<br>
>>> >> >>> Basically each frontend static output should register the code<br>
>>> >> >>> units.<br>
>>> >> >>> In Nyx<br>
>>> >> >>> for instance, we would do something like registering "code_length"<br>
>>> >> >>> as<br>
>>> >> >>> Mpccm,<br>
>>> >> >>> "code_mass" as Msun, etc. Then any field from the dataset can be<br>
>>> >> >>> loaded in<br>
>>> >> >>> code units with something like<br>
>>> >> >>> dd["density"].in_units("code_density").<br>
>>> >> >>><br>
>>> >> >>> This got us thinking -- why load native fields in CGS now?<br>
>>> >> >>> Instead, we<br>
>>> >> >>> can define native fields exactly as they are on disk and users who<br>
>>> >> >>> want code<br>
>>> >> >>> units will never have to convert by hand again. If frontend<br>
>>> >> >>> developers<br>
>>> >> >>> define the fields and units on disk, and some mapping to the<br>
>>> >> >>> universal<br>
>>> >> >>> fields, we shouldn't have to define or convert units anywhere<br>
>>> >> >>> else.<br>
>>> >> >>><br>
>>> >> >>> I made a quick and dirty example of what we're thinking here:<br>
>>> >> >>> <a href="http://paste.yt-project.org/show/3441/" target="_blank">http://paste.yt-project.org/show/3441/</a><br>
>>> >> >>><br>
>>> >> >>> So, is something like this a good idea? Is it realistic? Would<br>
>>> >> >>> this<br>
>>> >> >>> make<br>
>>> >> >>> for a simpler field info container? Nathan, is there anything I<br>
>>> >> >>> missed?<br>
>>> >> >>><br>
>>> >> >>> - Casey<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>
>>> ><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>
> _______________________________________________<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></div>