[yt-dev] Field units from code to code

Thu Mar 29 16:04:03 PDT 2012

+1 on datasets.

On 3/29/12 6:58 PM, Nathan Goldbaum wrote:
> +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!
>>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>