[yt-dev] Field units from code to code

Thu Mar 29 15:58:54 PDT 2012

+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.

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:

ds = load(filename)

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).

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?

On Mar 29, 2012, at 3:40 PM, Matthew Turk <matthewturk at gmail.com> wrote:

> Hi Nathan and Casey,
> 
> I agree with what both of you have said.  The Orion/Nyx units should
> be made to be consistent, but more importantly I think we should
> continue breaking away from Enzo-isms in the code.
> 
> As it stands, all of the universal fields call underlying Enzo-named
> aliases -- Density, ThermalEnergy, etc etc.  I hope we can have a 3.0
> out within a calendar year, hopefully by the end of this year.  (I've
> been pushing on the geometry refactor, although recently other efforts
> have been paying off which has decreased my output there.)  I am much,
> much less doubtful than Casey is that we cannot do this; in fact, I'm
> completely in favor of this and I think it would be relatively
> straightforward to implement.
> 
> In the existing system we have a mechanism for aliasing fields.  What
> we can do is provide an additional translation system where we
> enumerate the fields that are available for items in UniversalFields,
> and then construct aliases to those.  This would mean changing what is
> aliased in existing non-Enzo frontends, and adding aliases in Enzo.
> The style of name Casey proposes is what I woudl also agree with:
> underscores, lower cases, and erring on the side of verbosity.  The
> fields off hand that we would need to do this for (in their current
> enzo-isms):
> 
> x-velocity => velocity_x (same for y, z)
> Density => density
> TotalEnergy => ?
> GasEnergy => thermal_energy_specific (and thermal_energy_density)
> Temperature => temperature
> 
> and so on.
> 
> Once we have these aliases in place, an overall cleanup of
> UniversalFields should take place.  One place we should clean up is
> ensuring that there are no conditionals; rather than conditionals
> inside the functions, we should place those conditionals inside the
> parameter file types.  So for instance, if you have a field that is
> calculated differently depending on the parameter HydroMethod (in Enzo
> for instance) you simply set a validator on the field requiring the
> parameter be set to a particular value, and then only the field which
> satisfies that validator will be called when requested.
> 
> So we've gotten rid of a bunch of enzo-isms in the parameter files;
> after fields, what else can we address?  And, I'd be up for sprinting
> on this (which should take just a few hours) basically any time next
> week or after.  I'd also be up for talking more about geometry
> refactoring, if anyone is interested, but it's not quite to the point
> that I think I am satisfied enough with the architecture to request
> input / contributions.  Sometimes (especially with big architectural
> things like this) I think it's a shame we do all of our work
> virtually, as I think a lot of this would be easier to bang out in
> person for a couple hours.
> 
> -Matt
> 
> On Wed, Mar 28, 2012 at 6:14 PM, Casey W. Stark <caseywstark at gmail.com> wrote:
>> Hi Nathan.
>> 
>> 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).
>> 
>> Best,
>> Casey
>> 
>> 
>> On Wed, Mar 28, 2012 at 1:47 PM, Nathan Goldbaum <goldbaum at ucolick.org>
>> wrote:
>>> 
>>> Hi all,
>>> 
>>> 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
>>> goldbaum at ucolick.org
>>> http://www.ucolick.org/~goldbaum
>>> 
>>> _______________________________________________
>>> yt-dev mailing list
>>> yt-dev at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> 
>> 
>> 
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> 
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> 
> !DSPAM:10175,4f74e5073356450621218!
> 