<div dir="ltr">Hey Matt.<div><br></div><div>Excellent! It's a considerable change, so we should dread it a bit, but really glad you like the idea too.</div><div><br></div><div style>About where the conversion should happen, I like the idea to return any universal fields in cgs by default. Operations between "code" fields ("mycode_density") would return in code units and ops between universal fields ("density") would return in cgs. That means most users won't see a change too. Mixing units is mostly straightforward. I think the only gotcha is for add and sub, where we return in the left object's units.</div>

<div style><br></div><div style><span style="font-family:arial,sans-serif;font-size:13px">> How do we handle the fact</span></div><span style="font-family:arial,sans-serif;font-size:13px">that converting "code_density" to cgs is different for different</span><br style="font-family:arial,sans-serif;font-size:13px">

<span style="font-family:arial,sans-serif;font-size:13px">arrays, depending on the code?  i.e., if I have two "code_density"</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">arrays from a code that stores them in comoving code units, how do we</span><br style="font-family:arial,sans-serif;font-size:13px">

<span style="font-family:arial,sans-serif;font-size:13px">distinguish between those two things during division, say?</span><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">I'm not sure I'm following here, but is this a case where density field a has different units from density field b? If so, I think we have to define separate units for the code densities. Here's a quick Nyx example...</font></div>

<div><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif">unit_registry.add("nyx_cm_density", "Msun/Mpccm**3")</font></div><div style><span style="font-family:arial,sans-serif">unit_registry.add("nyx_prop_density", "g/cm**3")</span><font face="arial, sans-serif"><br>

</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">add_field("nyx_density", units="nyx_cm_density")</font></div><div><font face="arial, sans-serif">add_field("nyx_hi_density", units="nyx_prop_density")</font></div>

<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">dd["nyx_density"] / dd["nyx_hi_density"]    (should return dimensionless YTArray)<br></font><div style><br></div>

<div style>- Casey</div><div><br></div><div><br></div><div><br><div class="gmail_extra"><div class="gmail_quote">On Tue, May 7, 2013 at 8:18 AM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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>
<div><div><br>
On Mon, May 6, 2013 at 6:50 PM, Casey W. Stark <<a href="mailto:caseywstark@gmail.com" target="_blank">caseywstark@gmail.com</a>> wrote:<br>
> Hey Nathan.<br>
><br>
> Thanks for the reminder about `ensure_cgs`. Definitely helps to see the<br>
> pseudocode too. Users could also write out the array.convert_to(...) in the<br>
> field function for whatever obscure units. I guess this is similar to 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 will be<br>
> very helpful. I've been confused about where some derived fields come from<br>
> many times!<br>
><br>
><br>
> On Mon, May 6, 2013 at 3:39 PM, Nathan Goldbaum <<a href="mailto:goldbaum@ucolick.org" target="_blank">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 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 returned<br>
>> YTArray.  The nice thing about this is the flow of data is clear, things<br>
>> come in to the field definition code units and leave in CGS.  This also<br>
>> eliminates the need for the unit conversion functions that are scattered<br>
>> throughout the frontends and universal_fields.py.<br>
>><br>
>> This has the nice feature that each of the code frontends will need to<br>
>> explicitly define mappings to the CGS fields (like Density) needed by<br>
>> universal fields.<br>
>><br>
>> -Nathan<br>
>><br>
>><br>
>> On Mon, May 6, 2013 at 3:33 PM, Casey W. Stark <<a href="mailto:caseywstark@gmail.com" target="_blank">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, but I am<br>
>>> hitting a yt internals knowledge wall writing a YTEP. I would like some<br>
>>> input on technical details or general feelings before I move ahead with the<br>
>>> write-up.<br>
>>><br>
>>> One of the things mentioned in the units YTEP is handling code units.<br>
>>> Basically each frontend static output should register the code units. In Nyx<br>
>>> for instance, we would do something like registering "code_length" as Mpccm,<br>
>>> "code_mass" as Msun, etc. Then any field from the dataset can be loaded in<br>
>>> code units with something like dd["density"].in_units("code_density").<br>
>>><br>
>>> This got us thinking -- why load native fields in CGS now? Instead, we<br>
>>> can define native fields exactly as they are on disk and users who want code<br>
>>> units will never have to convert by hand again. If frontend developers<br>
>>> define the fields and units on disk, and some mapping to the universal<br>
>>> fields, we shouldn't have to define or convert units anywhere 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 this make<br>
>>> for a simpler field info container? Nathan, is there anything I missed?<br>
>>><br>
>>> - Casey<br>
>>><br>
>>> _______________________________________________<br>
>>> yt-dev mailing list<br>
>>> <a href="mailto:yt-dev@lists.spacepope.org" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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></div></div>