<div dir="ltr">Hey Nathan.<div><br></div><div>Thanks for the reminder about `ensure_cgs`. Definitely helps to see the pseudocode too. Users could also write out the array.convert_to(...) in the field function for whatever obscure units. I guess this is similar to the fields with the units tacked on to the name, but much cleaner.</div>

<div><br></div><div style>I think making the code to universal field mapping more explicit will be very helpful. I've been confused about where some derived fields come from many times!</div></div><div class="gmail_extra">

<br><br><div class="gmail_quote">On Mon, May 6, 2013 at 3:39 PM, Nathan Goldbaum <span dir="ltr"><<a href="mailto:goldbaum@ucolick.org" target="_blank">goldbaum@ucolick.org</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">Hey Casey,<div><br></div><div>That's pretty much what I was thinking, although I wanted to add a little bit of syntactic sugar so the CGS conversion happens automatically:</div><div><br></div>

<div><a href="http://paste.yt-project.org/show/3443/" target="_blank">http://paste.yt-project.org/show/3443/</a><br></div><div><br></div><div>The ensure_cgs decorator would simply call convert_to_cgs on the returned YTArray.  The nice thing about this is the flow of data is clear, things come in to the field definition code units and leave in CGS.  This also eliminates the need for the unit conversion functions that are scattered throughout the frontends and universal_fields.py.</div>



<div><br></div><div>This has the nice feature that each of the code frontends will need to explicitly define mappings to the CGS fields (like Density) needed by universal fields.</div><div><br></div><div>

-Nathan</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Mon, May 6, 2013 at 3:33 PM, Casey W. Stark <span dir="ltr"><<a href="mailto:caseywstark@gmail.com" target="_blank">caseywstark@gmail.com</a>></span> wrote:<br>



</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Hey yt.<div><br></div><div>Nathan and I had a cool idea as an extension of the units work, but I am hitting a yt internals knowledge wall writing a YTEP. I would like some input on technical details or general feelings before I move ahead with the write-up.</div>





<div><br></div><div>One of the things mentioned in the units YTEP is handling code units. Basically each frontend static output should register the code units. In Nyx for instance, we would do something like registering "code_length" as Mpccm, "code_mass" as Msun, etc. Then any field from the dataset can be loaded in code units with something like dd["density"].in_units("code_density").</div>





<div><br></div><div>This got us thinking -- why load native fields in CGS now? Instead, we can define native fields exactly as they are on disk and users who want code units will never have to convert by hand again. If frontend developers define the fields and units on disk, and some mapping to the universal fields, we shouldn't have to define or convert units anywhere else.</div>





<div><br></div><div>I made a quick and dirty example of what we're thinking here: <a href="http://paste.yt-project.org/show/3441/" target="_blank">http://paste.yt-project.org/show/3441/</a></div><div><br></div><div>

So, is something like this a good idea? Is it realistic? Would this make for a simpler field info container? Nathan, is there anything I missed?</div><span><font color="#888888"><div><br></div><div>- Casey</div>

</font></span></div>
<br></div></div>_______________________________________________<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></blockquote></div><br></div>
<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></blockquote></div><br></div>