<div dir="ltr">Yeah, I now see this was a stupid concern. Disregard.<div><br></div><div>sorry.</div><div><br></div><div>j</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 7, 2013 at 5:10 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 5:06 PM, j s oishi <<a href="mailto:jsoishi@gmail.com">jsoishi@gmail.com</a>> wrote:<br>

><br>
><br>
><br>
> On Tue, May 7, 2013 at 1:25 PM, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>> wrote:<br>
>><br>
>> On Tue, May 7, 2013 at 1:24 PM, Casey W. Stark <<a href="mailto:caseywstark@gmail.com">caseywstark@gmail.com</a>><br>
>> wrote:<br>
>> > Ok, I just tried this and it doesn't work. Even though the Unit objects<br>
>> > are<br>
>> > separate instances, the sympy Symbol objects in the expressions are<br>
>> > treated<br>
>> > as the same. We will have to think about the design some more.<br>
>><br>
>> 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>
><br>
><br>
> I'm not so sure about this. What about simulations that are performed in<br>
> dimensionless units? This is something that yt handles poorly right now, and<br>
> I think this system should fix that. For example, in a dimensionless system,<br>
> the code units are fully functional and probably what you want to work in.<br>
> Or am I missing something here?<br>
<br>
</div>What you're describing will be much, much easier to do in the system<br>
Casey and Nathan have outlined.  What I was describing was comparing<br>
two code unitful arrays with the same name where that name means<br>
something different for each of the two arrays.  For instance,<br>
comparing the same Enzo cosmology run in *code units* at z=10 and z=1.<br>
 I at first thought that this would be an undefined operation that we<br>
don't know how to manage, but then I realized that anyone who is doing<br>
this probably knows what they are doing.<br>
<br>
For dimensionless simulations, you will be able to access the native<br>
fields with less overhead in this new system, simply by querying -- as<br>
Casey showed above -- the native fields.<br>
<br>
This will also simplify (as Casey noted) the field generation and<br>
field info container logic.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
>><br>
>><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<br>
>> >> be<br>
>> >> different from each. However, if you try something like<br>
>> >> ds1_dd["enzo_comoving_density"] / ds2_dd["enzo_comoving_density"],<br>
>> >> sympy<br>
>> >> might just cancel out the symbols in the unit expressions and the<br>
>> >> 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<br>
>> >>> <<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,<br>
>> >>> > but<br>
>> >>> > really glad you like the idea too.<br>
>> >>> ><br>
>> >>> > About where the conversion should happen, I like the idea to return<br>
>> >>> > any<br>
>> >>> > universal fields in cgs by default. Operations between "code" fields<br>
>> >>> > ("mycode_density") would return in code units and ops between<br>
>> >>> > universal<br>
>> >>> > fields ("density") would return in cgs. That means most users won't<br>
>> >>> > 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<br>
>> >>> > 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<br>
>> >>> > 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<br>
>> >>> >> 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<br>
>> >>> >> to<br>
>> >>> >> perform any conversions at IO time, and instead we should be<br>
>> >>> >> 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<br>
>> >>> >> should<br>
>> >>> >> be completely workable to do so.  The ensure_cgs decorator is a<br>
>> >>> >> 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,<br>
>> >>> >> so<br>
>> >>> >> we can simply remove the items there and instead just wrap them in<br>
>> >>> >> 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<br>
>> >>> >> 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<br>
>> >>> >> <<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<br>
>> >>> >> > see<br>
>> >>> >> > the<br>
>> >>> >> > pseudocode too. Users could also write out the<br>
>> >>> >> > array.convert_to(...)<br>
>> >>> >> > in<br>
>> >>> >> > the<br>
>> >>> >> > field function for whatever obscure units. I guess this is<br>
>> >>> >> > 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<br>
>> >>> >> >> a<br>
>> >>> >> >> little<br>
>> >>> >> >> bit of syntactic sugar so the CGS conversion happens<br>
>> >>> >> >> 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<br>
>> >>> >> >> clear,<br>
>> >>> >> >> things<br>
>> >>> >> >> come in to the field definition code units and leave in CGS.<br>
>> >>> >> >> 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<br>
>> >>> >> >> need<br>
>> >>> >> >> to<br>
>> >>> >> >> explicitly define mappings to the CGS fields (like Density)<br>
>> >>> >> >> 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<br>
>> >>> >> >>> like<br>
>> >>> >> >>> some<br>
>> >>> >> >>> input on technical details or general feelings before I move<br>
>> >>> >> >>> 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<br>
>> >>> >> >>> "code_length"<br>
>> >>> >> >>> as<br>
>> >>> >> >>> Mpccm,<br>
>> >>> >> >>> "code_mass" as Msun, etc. Then any field from the dataset can<br>
>> >>> >> >>> 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<br>
>> >>> >> >>> 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>
><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>