<div dir="ltr">> <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 style><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="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 class="im">On Tue, May 7, 2013 at 12:13 PM, Casey W. Stark <<a href="mailto:caseywstark@gmail.com">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 class="im"><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 class="HOEnZb"><div class="h5"><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">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">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">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">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">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>
</div></div></blockquote></div><br></div>