<div dir="ltr">Ok, I just tried this and it doesn't work. Even though the Unit objects are separate instances, the sympy Symbol objects in the expressions are treated as the same. We will have to think about the design some more.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 7, 2013 at 10:17 AM, Casey W. Stark <span dir="ltr"><<a href="mailto:caseywstark@gmail.com" target="_blank">caseywstark@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 dir="ltr"><div class="im">> <span style="font-family:arial,sans-serif;font-size:13px">think of having two different parameter</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">files from the same simulation open at the same time.</span><div>
<span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></div><div><span style="font-family:arial,sans-serif;font-size:13px">Ah, got it. You're right that this will be a problem. The two datasets will have separate unit registries, so something like "pccm" units can be different from each. However, if you try something like ds1_dd["enzo_comoving_density"] / ds2_dd["enzo_comoving_density"], sympy might just cancel out the symbols in the unit expressions and the conversion will not work. I'll try something...</span></div>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 7, 2013 at 10:05 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Tue, May 7, 2013 at 12:13 PM, Casey W. Stark <<a href="mailto:caseywstark@gmail.com" target="_blank">caseywstark@gmail.com</a>> 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 a<br>
> change too. Mixing units is mostly straightforward. I think the only gotcha<br>
> is for add and sub, where we return in the left object's units.<br>
<br>
</div>That sounds good to me.<br>
<div><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 a<br>
> has different units from density field b? If so, I think we have to define<br>
> separate units for the code densities. Here's a quick Nyx example...<br>
<br>
</div>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>
<div><div><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 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" target="_blank">matthewturk@gmail.com</a>> 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" target="_blank">caseywstark@gmail.com</a>><br>
>> 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<br>
>> > the<br>
>> > field function for whatever obscure units. I guess this is similar 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 will be<br>
>> > very helpful. I've been confused about where some derived fields come<br>
>> > 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<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 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 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<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 units.<br>
>> >>> Basically each frontend static output should register the code units.<br>
>> >>> In Nyx<br>
>> >>> for instance, we would do something like registering "code_length" 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 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<br>
>> >>> 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<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" 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>
><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></blockquote></div><br></div>