I'm down for a sprint on this next week. If others are interested in this one, we could poll for times. Maybe sit in a google hangout while we code? It's not quite pair-programming, but it's a big step up from IRC.<div>
<br></div><div>Best,</div><div>Casey</div><div><br><br><div class="gmail_quote">On Thu, Mar 29, 2012 at 3:40 PM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com">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">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>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Mar 28, 2012 at 6:14 PM, Casey W. Stark <<a href="mailto:caseywstark@gmail.com">caseywstark@gmail.com</a>> wrote:<br>
> 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">goldbaum@ucolick.org</a>><br>
> wrote:<br>
>><br>
>> 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>
>> Astronomy & Astrophysics, UCSC<br>
>> <a href="mailto:goldbaum@ucolick.org">goldbaum@ucolick.org</a><br>
>> <a href="http://www.ucolick.org/~goldbaum" target="_blank">http://www.ucolick.org/~goldbaum</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>