[yt-dev] unitrefactor: enzo metal fields

[Britton Smith]

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-units/diff

Britton


On Fri, Dec 6, 2013 at 2:58 PM, Matthew Turk <matthewturk at gmail.com> wrote:

> On Fri, Dec 6, 2013 at 9:55 AM, Britton Smith <brittonsmith at 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 at gmail.com>
> wrote:
> >>
> >> Hi Bitton,
> >>
> >> On Fri, Dec 6, 2013 at 9:10 AM, Britton Smith <brittonsmith at 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 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
> >
> _______________________________________________
> 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/20131206/aff41232/attachment.html>