<div dir="ltr">Hi Chris,<div><br></div><div style>Just to be clear, this change would occur in the derived field definition, not the call to get the star ParticleMassMsun itself, correct?  </div><div style><br></div><div style>

If so, I think something like this, or with a yt-specific term, would be great.</div><div style><br></div><div style>Thanks,</div><div style>Sam</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Mar 10, 2013 at 5:20 PM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br>

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