[yt-dev] Particle field generation in 3.0

[Matthew Turk]

Hi Cameron,

I'd be fine with this change, but it touches a *lot* of user-facing
code already.  If we did this, then inside _determine_fields and all
the other places we guess the field names, we'd need backward
compatibility.

-Matt

On Thu, Jul 3, 2014 at 6:21 PM, Cameron Hummels <chummels at gmail.com> wrote:
> Hello everyone,
>
> As I'm updating some of the documentation in 3.0 to be current on field
> generation, I thought of something that might make the particle fields a bit
> more clean as we build on them in the future.
>
> As I understand it, each particle type from a given code will generate its
> own namespace for those native particle quantities.  So for example a Gadget
> binary dataset will read in its star, gas, and DM particles as:
>
> ('star', 'particle_mass')
> ('gas', 'particle_mass')
> ('DM', 'particle_mass')
>
> but when these different particles are deposited and smoothed on to the
> grid, they all get put into the same 'deposit' namespace:
>
> ('deposit', 'star_density')
> ('deposit', 'gas_density')
> ('deposit', 'DM_density')
>
> It seems to me that perhaps we should create a separate deposit namespace
> for each of the native particle types, so that we'll have a clean 1-to-1
> conversion between native particle types and smoothed particle types in
> namespaces.  Now the above fields would map to:
>
> ('deposit_star', 'density')
> ('deposit_gas', 'density')
> ('deposit_DM', 'density')
>
> This doesn't seem like it would be hard to change in the field-generation
> infrastructure, but it might break things later on, which I've just not yet
> considered.  Anyway, I just wanted to bounce this off of people.  It may not
> be better in the long run, but it seemed like if we're breaking API, it
> should be done now instead of later on.  I may be missing something big
> here, but I wanted to see what others thought.
>
> Cameron
>
> --
> Cameron Hummels
> Postdoctoral Researcher
> Steward Observatory
> University of Arizona
> http://chummels.org
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>