[yt-dev] yt-3.0 derived fields

Christopher Moody chrisemoody at gmail.com
Sun Mar 10 17:23:42 PDT 2013 

Hi Nathan, Matt,

Matt beat me to it, but here's my longer description:

I *don't* think we should allow dd[...,"ParticleMassMsun"] to work. For
example, if you have three kinds of particles ("stars", "planets",
"darkmatter") and do

dd["stars","ParticleMassMsun"]
dd["planets","ParticleMassMsun"]

and then

dd[...,"ParticleMassMsun"]

should that last call include all three particle types (including
"darkmatter") available on disk or should it just include the two particle
types you've already got cached in memory? If you are making a call as a
user, you'd probably expect to get "all" particles. But if you're a derived
field, that ellipsis would be passing through whatever fields you have in
memory, which is the opposite case.

To avoid that confusion, I'd reserve "all" for the user, and ...
exclusively for a derived field.

chris



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

> I'd rather that not work, to tell the truth.  I think Chris's
> suggestion, where you define a derived field that is neutral to the
> *type* of particle, is powerful, but I don't see an advantage to it
> during the call to getting the data, particularly since that loses a
> bit of ability to discriminate between particles/fluids.
>
> On Sun, Mar 10, 2013 at 8:14 PM, Nathan Goldbaum <nathan12343 at gmail.com>
> wrote:
> > Just to clarify, dd[…, "ParticleMassMsun"] would work as well, right?
> >
> > On Mar 10, 2013, at 5:05 PM, Christopher Moody <chrisemoody at gmail.com>
> > wrote:
> >
> > Hi Sam,
> > Yeah; I think it should change only the derived field. You want the
> derived
> > field to pass along whatever field type you asked for, or use the
> implicit
> > one if you didn't ask for the type explicitly. If you tried to implement
> > this in the original call, you'd do something like
> > dd[(Ellipsis,"ParticleMassMsun")].   I can't see use cases where this
> would
> > be better than dd[("all","ParticleMassMsun")] -- so yeah, no changes to
> the
> > original call.
> >
> > chris
> >
> >
> > On Sun, Mar 10, 2013 at 4:30 PM, Sam Skillman <samskillman at gmail.com>
> wrote:
> >>
> >> 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
> >>
> >>
> >>
> >> _______________________________________________
> >> 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/20130310/bb68f563/attachment.html>

More information about the yt-dev mailing list