[yt-dev] yt-3.0 derived fields

[Matthew Turk]

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
>