[yt-dev] Field units from code to code

[Casey W. Stark]

+1 on datasets, although I would like to see the unit object(s) at the
field level.


On Thu, Mar 29, 2012 at 4:04 PM, Cameron Hummels <
chummels at astro.columbia.edu> wrote:

> +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 <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<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<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<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<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<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/e066bf17/attachment.html>