+1 on datasets, although I would like to see the unit object(s) at the field level.<div><br><br><div class="gmail_quote">On Thu, Mar 29, 2012 at 4:04 PM, Cameron Hummels <span dir="ltr"><<a href="mailto:chummels@astro.columbia.edu">chummels@astro.columbia.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+1 on datasets.<div><div class="h5"><br>
<br>
On 3/29/12 6:58 PM, Nathan Goldbaum 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">
+1. I'd also be up to help out with the sprint. Doing a virtual sprint using a google hangout might help mitigate some of the distance problems.<br>
<br>
While we're brining up Enzo-isms that we should get rid of, I think it might be a good idea to make a conceptual shift in the basic python UI. Instead referring to the interface between the user and the data as a parameter file, I think instead we should be talking about datasets. One would instantiate a dataset just like we do now with parameter files:<br>
<br>
ds = load(filename)<br>
<br>
A dataset would also have some universal attributes which would present themselves to the user as a dict, e.g. ds.units, ds.parameters, ds.basic_info (like current_time, timestep, filename, and simulation code), and ds.hierarchy (not sure how that would interfere with the geometry refactor).<br>
<br>
This may be a paintibg the bike shed discussion, but I think this shift will help new users understand how to access their data. Thoughts?<br>
<br>
On Mar 29, 2012, at 3:40 PM, Matthew Turk<<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>> wrote:<br>
<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">
Hi Nathan and Casey,<br>
<br>
I agree with what both of you have said. The Orion/Nyx units should<br>
be made to be consistent, but more importantly I think we should<br>
continue breaking away from Enzo-isms in the code.<br>
<br>
As it stands, all of the universal fields call underlying Enzo-named<br>
aliases -- Density, ThermalEnergy, etc etc. I hope we can have a 3.0<br>
out within a calendar year, hopefully by the end of this year. (I've<br>
been pushing on the geometry refactor, although recently other efforts<br>
have been paying off which has decreased my output there.) I am much,<br>
much less doubtful than Casey is that we cannot do this; in fact, I'm<br>
completely in favor of this and I think it would be relatively<br>
straightforward to implement.<br>
<br>
In the existing system we have a mechanism for aliasing fields. What<br>
we can do is provide an additional translation system where we<br>
enumerate the fields that are available for items in UniversalFields,<br>
and then construct aliases to those. This would mean changing what is<br>
aliased in existing non-Enzo frontends, and adding aliases in Enzo.<br>
The style of name Casey proposes is what I woudl also agree with:<br>
underscores, lower cases, and erring on the side of verbosity. The<br>
fields off hand that we would need to do this for (in their current<br>
enzo-isms):<br>
<br>
x-velocity => velocity_x (same for y, z)<br>
Density => density<br>
TotalEnergy => ?<br>
GasEnergy => thermal_energy_specific (and thermal_energy_density)<br>
Temperature => temperature<br>
<br>
and so on.<br>
<br>
Once we have these aliases in place, an overall cleanup of<br>
UniversalFields should take place. One place we should clean up is<br>
ensuring that there are no conditionals; rather than conditionals<br>
inside the functions, we should place those conditionals inside the<br>
parameter file types. So for instance, if you have a field that is<br>
calculated differently depending on the parameter HydroMethod (in Enzo<br>
for instance) you simply set a validator on the field requiring the<br>
parameter be set to a particular value, and then only the field which<br>
satisfies that validator will be called when requested.<br>
<br>
So we've gotten rid of a bunch of enzo-isms in the parameter files;<br>
after fields, what else can we address? And, I'd be up for sprinting<br>
on this (which should take just a few hours) basically any time next<br>
week or after. I'd also be up for talking more about geometry<br>
refactoring, if anyone is interested, but it's not quite to the point<br>
that I think I am satisfied enough with the architecture to request<br>
input / contributions. Sometimes (especially with big architectural<br>
things like this) I think it's a shame we do all of our work<br>
virtually, as I think a lot of this would be easier to bang out in<br>
person for a couple hours.<br>
<br>
-Matt<br>
<br>
On Wed, Mar 28, 2012 at 6:14 PM, Casey W. Stark<<a href="mailto:caseywstark@gmail.com" target="_blank">caseywstark@gmail.com</a>> 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">
Hi Nathan.<br>
<br>
I'm also worried about this and I agree that fields with the same name<br>
should all be consistent. I would support some sort of cleanup of frontend<br>
fields, and I can get the Nyx fields in line and help with Enzo.<br>
<br>
I doubt we can do this, but I would prefer changing the field names as part<br>
of the removing enzo-isms and geometry handling refactoring pushes. For<br>
instance, the field in Orion could be thermal_energy_density and the field<br>
in Enzo could be specific_thermal_energy. I also noticed this issue when I<br>
was using "Density" in Enzo (proper density in cgs) and "density" in Nyx<br>
(comoving density in cgs).<br>
<br>
Best,<br>
Casey<br>
<br>
<br>
On Wed, Mar 28, 2012 at 1:47 PM, Nathan Goldbaum<<a href="mailto:goldbaum@ucolick.org" target="_blank">goldbaum@ucolick.org</a>><br>
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">
Hi all,<br>
<br>
On IRC today we noticed that Orion defines its ThermalEnergy field per<br>
unit volume but Enzo and FLASH define ThermalEnergy per unit mass. Is this<br>
a problem? Since yt defaults to the Enzo field names, should we try to make<br>
sure that all fields are defined using the same units as in Enzo? Is there<br>
a convention for how different codes should define derived fields that are<br>
aliased to Enzo fields?<br>
<br>
One problem for this particular example is that the Pressure field is<br>
defined in terms of ThermalEnergy in universal_fields.py so the units of<br>
ThermalEnergy become important if a user merely wants the gas pressure in<br>
the simulation.<br>
<br>
One possible solution for this issue would be the units overhaul we're<br>
planning. If all fields are associated with a unit object, we can simply<br>
query the units to ensure that units are taken care of correctly and<br>
code-to-code comparisons aren't sensitive to the units chosen for fields in<br>
the frontend.<br>
<br>
Personally, I think it would be best if we could make sure that all of the<br>
fields aliased to Enzo fields have the same units.<br>
<br>
Nathan Goldbaum<br>
Graduate Student<br></div></div>
Astronomy& Astrophysics, UCSC<div class="im"><br>
<a href="mailto:goldbaum@ucolick.org" target="_blank">goldbaum@ucolick.org</a><br>
<a href="http://www.ucolick.org/~goldbaum" target="_blank">http://www.ucolick.org/~<u></u>goldbaum</a><br>
<br>
______________________________<u></u>_________________<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/<u></u>listinfo.cgi/yt-dev-spacepope.<u></u>org</a><br>
</div></blockquote><div class="im">
<br>
<br>
______________________________<u></u>_________________<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/<u></u>listinfo.cgi/yt-dev-spacepope.<u></u>org</a><br>
<br>
</div></blockquote><div class="im">
______________________________<u></u>_________________<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/<u></u>listinfo.cgi/yt-dev-spacepope.<u></u>org</a><br>
<br>
!DSPAM:10175,<u></u>4f74e5073356450621218!<br>
<br>
</div></blockquote><div class="im">
______________________________<u></u>_________________<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/<u></u>listinfo.cgi/yt-dev-spacepope.<u></u>org</a><br>
<br>
</div></blockquote><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<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/<u></u>listinfo.cgi/yt-dev-spacepope.<u></u>org</a><br>
</div></div></blockquote></div><br></div>