unitrefactor: enzo metal fields
Hi all, 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? 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? Should I make a "code_metallicity" unit? This might actually be usable for the gas metallicity field as well.
Hi Bitton, On Fri, Dec 6, 2013 at 9:10 AM, Britton Smith <brittonsmith@gmail.com> wrote:
Hi all,
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. -Matt
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Matt, So I jumped ahead of this and created a metallicity unit and defined Zsun relative to that and it seems to work. Maybe you're right that this will cause more trouble, but maybe I'll issue a PR to your fork with the open PR and you can check it out. I put the metallicity field in yt/fields/fluid_fields.py. Does that not seem like the correct place? Britton On Fri, Dec 6, 2013 at 2:43 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Bitton,
On Fri, Dec 6, 2013 at 9:10 AM, Britton Smith <brittonsmith@gmail.com> wrote:
Hi all,
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.
-Matt
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Fri, Dec 6, 2013 at 9:55 AM, Britton Smith <brittonsmith@gmail.com> wrote:
Hi Matt,
So I jumped ahead of this and created a metallicity unit and defined Zsun relative to that and it seems to work. Maybe you're right that this will cause more trouble, but maybe I'll issue a PR to your fork with the open PR and you can check it out.
We'll let it shake out; I may just be alarmist.
I put the metallicity field in yt/fields/fluid_fields.py. Does that not seem like the correct place?
No, that should be fine. We may eventually split fluid_fields.py up into "astro" fields, but it's a good place at the moment.
Britton
On Fri, Dec 6, 2013 at 2:43 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Bitton,
On Fri, Dec 6, 2013 at 9:10 AM, Britton Smith <brittonsmith@gmail.com> wrote:
Hi all,
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.
-Matt
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi all, I just issued a PR to Matt's fork for adding a new metallicity field. Currently, this works by defining a fluid field "metal_density", which is aliased to (in Enzo) the field Metal_Density. To give it units, I created a metallicity symbol and associated it with the Zsun unit. This may need some polishing depending on how other codes handle metal fields, but please have a look here: https://bitbucket.org/MatthewTurk/yt/pull-request/3/metallicity-field-and-un... Britton On Fri, Dec 6, 2013 at 2:58 PM, Matthew Turk <matthewturk@gmail.com> wrote:
On Fri, Dec 6, 2013 at 9:55 AM, Britton Smith <brittonsmith@gmail.com> wrote:
Hi Matt,
So I jumped ahead of this and created a metallicity unit and defined Zsun relative to that and it seems to work. Maybe you're right that this will cause more trouble, but maybe I'll issue a PR to your fork with the open PR and you can check it out.
We'll let it shake out; I may just be alarmist.
I put the metallicity field in yt/fields/fluid_fields.py. Does that not seem like the correct place?
No, that should be fine. We may eventually split fluid_fields.py up into "astro" fields, but it's a good place at the moment.
Britton
On Fri, Dec 6, 2013 at 2:43 PM, Matthew Turk <matthewturk@gmail.com>
Hi Bitton,
On Fri, Dec 6, 2013 at 9:10 AM, Britton Smith <brittonsmith@gmail.com> wrote:
Hi all,
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
wrote: 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.
-Matt
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (2)
-
Britton Smith -
Matthew Turk