[yt-dev] yt-3.0 derived fields

[Sam Skillman]

Perfect, +1 from me.


On Sun, Mar 10, 2013 at 6: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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20130310/942c76dd/attachment.html>