[yt-dev] Field units from code to code

[Casey W. Stark]

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.

Best,
Casey


On Thu, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20120329/e4bdcaa9/attachment.html>