<div dir="ltr">Hi everyone,<div style>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:</div>
<div style><br></div><div style><div>k<font face="courier new, monospace">eys = ["ParticleMassMsun",</font></div><div><font face="courier new, monospace">        ("all","ParticleMassMsun"),</font></div>
<div><font face="courier new, monospace">        ("stars","particle_mass"),</font></div><div><span style="font-family:'courier new',monospace">        ("stars","ParticleMassMsun") ]#broken </span> </div>
<div><br></div><div style>I think we all have natural expectations for what should happen, but at the moment the last key in the series is broken. <font face="courier new, monospace">particle_mass</font> is a native field, <font face="courier new, monospace">ParticleMassMsun</font> is a derived field:</div>
<br><font face="courier new, monospace">def _ParticleMassMsun(field, data):<br>    return data["particle_mass"]/mass_sun_cgs<br>add_field("ParticleMassMsun", function=_ParticleMassMsun, particle_type=True)</font></div>
<div style><br></div><div style>Note that in this case <font face="courier new, monospace">data["particle_mass"]</font> maps to <font face="courier new, monospace">data[("all","particle_mass")]</font> even when I originally asked for <font face="courier new, monospace">dd[("stars","ParticleMassMsun")]</font>, which is why things break.</div>
<div style><br></div><div style>So I propose a syntax where in the derived field definition we can do something like <font face="courier new, monospace">data[(Ellipsis,"ParticleMassMsun")]</font> or alternatively <font face="courier new, monospace">data[(field.field_type,"ParticleMassMsun")]</font>. 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.</div>
<div style><br></div><div style>Thanks!</div><div style>chris</div></div>