[yt-dev] yt-3.0 derived fields

[Sam Skillman]

Hi Chris,

Just to be clear, this change would occur in the derived field definition,
not the call to get the star ParticleMassMsun itself, correct?

If so, I think something like this, or with a yt-specific term, would be
great.

Thanks,
Sam


On Sun, Mar 10, 2013 at 5:20 PM, Matthew Turk <matthewturk at gmail.com> wrote:

> Hi Chris,
>
> On Sat, Mar 9, 2013 at 4:00 PM, Christopher Moody <chrisemoody at gmail.com>
> wrote:
> > Hi everyone,
> > Fields in yt-3.0 are now defined like (field_type,field_name) but for
> > backwards-compatibility still maintains a field_name ->
> ("all",field_name)
> > mapping. Consider a few use cases:
> >
> > keys = ["ParticleMassMsun",
> >         ("all","ParticleMassMsun"),
> >         ("stars","particle_mass"),
> >         ("stars","ParticleMassMsun") ]#broken
> >
> > I think we all have natural expectations for what should happen, but at
> the
> > moment the last key in the series is broken. particle_mass is a native
> > field, ParticleMassMsun is a derived field:
> >
> > def _ParticleMassMsun(field, data):
> >     return data["particle_mass"]/mass_sun_cgs
> > add_field("ParticleMassMsun", function=_ParticleMassMsun,
> > particle_type=True)
> >
> > Note that in this case data["particle_mass"] maps to
> > data[("all","particle_mass")] even when I originally asked for
> > dd[("stars","ParticleMassMsun")], which is why things break.
> >
> > So I propose a syntax where in the derived field definition we can do
> > something like data[(Ellipsis,"ParticleMassMsun")] or alternatively
> > data[(field.field_type,"ParticleMassMsun")]. This ensures that derived
> > fields will work intuitively and be as specific to a field type as they
> want
> > to be or just pass through whatever field type they may want.
> >
>
> I like this, but maybe we should use a yt-specific object instead of
> Ellipsis.  This would be very nice and is something I have thought /
> worried about and been unable to come up with an elegant solution for.
>  Seems like you found one!  :)
>
> This week I need to address this for my own work on a simulation with
> multiple particle types; I'll take a pass at implementing something
> like this.  We're also a bit overdue for a YTEP that details access to
> multiple fluids and multiples particles.  Once some things get off my
> plate on Tuesday I will make that a priority.  Then we can use that as
> a place to sort of hash this out and how it'll work.
>
> -Matt
>
> > Thanks!
> > chris
> >
> > _______________________________________________
> > 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/20130310/357ea252/attachment.htm>