[yt-dev] Particle field generation in 3.0

[Cameron Hummels]

Hey Matt,

OK, so we *can* do it, but the question is, does it make sense to do it?  I
thought it would be more consistent, but I'm not married to the idea.  Do
you think it's worth the effort of modifying the code?  I'm just trying to
look ahead to the future to when we have tons of different particle types,
but maybe this is no big deal, in which case we can leave it as is.

Cameron


On Thu, Jul 3, 2014 at 7:32 PM, Matthew Turk <matthewturk at gmail.com> wrote:

> 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
> >
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>



-- 
Cameron Hummels
Postdoctoral Researcher
Steward Observatory
University of Arizona
http://chummels.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140703/08fada07/attachment.htm>