I'm also worried about this and I agree that fields with the same name should all be consistent. I would support some sort of cleanup of frontend fields, and I can get the Nyx fields in line and help with Enzo.
I doubt we can do this, but I would prefer changing the field names as part of the removing enzo-isms and geometry handling refactoring pushes. For instance, the field in Orion could be thermal_energy_density and the field in Enzo could be specific_thermal_energy. I also noticed this issue when I was using "Density" in Enzo (proper density in cgs) and "density" in Nyx (comoving density in cgs).
On Wed, Mar 28, 2012 at 1:47 PM, Nathan Goldbaum email@example.com:
On IRC today we noticed that Orion defines its ThermalEnergy field per unit volume but Enzo and FLASH define ThermalEnergy per unit mass. Is this a problem? Since yt defaults to the Enzo field names, should we try to make sure that all fields are defined using the same units as in Enzo? Is there a convention for how different codes should define derived fields that are aliased to Enzo fields?
One problem for this particular example is that the Pressure field is defined in terms of ThermalEnergy in universal_fields.py so the units of ThermalEnergy become important if a user merely wants the gas pressure in the simulation.
One possible solution for this issue would be the units overhaul we're planning. If all fields are associated with a unit object, we can simply query the units to ensure that units are taken care of correctly and code-to-code comparisons aren't sensitive to the units chosen for fields in the frontend.
Personally, I think it would be best if we could make sure that all of the fields aliased to Enzo fields have the same units.
Nathan Goldbaum Graduate Student Astronomy & Astrophysics, UCSC firstname.lastname@example.org http://www.ucolick.org/%7Egoldbaum
yt-dev mailing list email@example.com http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org