On Fri, Dec 6, 2013 at 9:10 AM, Britton Smith firstname.lastname@example.org wrote:
I trying to add the metallicity field back to the enzo frontend and am wondering what field registry it would be appropriate to put it in. Anyone have any thoughts on this?
So -- the way it's currently set up is that each frontend has a set of fields defined like so:
known_other_fields = ( ("Cooling_Time", ("code_time", ["cooling_time"], None)), ("HI_kph", ("1/code_time", , None)), ("HeI_kph", ("1/code_time", , None)), ...
(Note that in breaking with tradition, this includes a mutable in the class definition. I think it's okay.)
The format of these tuples is:
("FieldNameOnDisk", ("units_on_disk", ["alias_to_this_yt_field", "and_this_one"], "display_name_or_none")
So what I think you would want is a generic metallicity field, and an alias to that. For now, I've been putting "generic yt field" names in yt/frontends/stream/fields.py but I would eventually like to move them elsewhere, so that there can be a collection of fields that yt knows about and that people can utilize. Right now this is a poor reference. RAMSES has a "Metallicity" field aliased as "metallicity" presently, but no units.
I'm glad this came up, since this is a design decision that hasn't been reviewed or commented on. Feedback?
Additionally, I noticed that the particle field metallicity_fraction currently has units of Zsun. As far as I know, this is not correct. I believe the field is actually unitless and would have to be divided by ~0.02 to be in units of Zsun. How can I set this up correctly to make it aware of these units?
My understanding is that you can set the units to be "Zsun / 0.02" in that case.
Should I make a "code_metallicity" unit? This might actually be usable for the gas metallicity field as well.
Potentially, but I'm not certain, as we may then step into the mess of defining interoperability with other units.
yt-dev mailing list email@example.com http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org