I think something like the first example you gave would be the best. It's
definitely more in keeping with the data_object[field] notation for getting
grid data. In a very similar vein, I find it much more intuitive to think
of asking for the particles or grid data associated with a particular object
than say start with some larger structure for handling particles for the
entire pf, and give me only the ones in some sphere or other object (this is
my interpretation of the second example you gave).
Additionally, I think particle data-space stuff you done in Enzo is great.
It seems silly to have to read in an entire set of particles only to filter
most of them back out, like with star particles. This will also come in
handy for other people who are working with tracer particles.
Britton
On Wed, Sep 9, 2009 at 8:47 PM, Matthew Turk
Hi guys,
I've noticed several of you making commits about particles. (John, Britton, looking at you guys.) In recent versions of Enzo, I stuck in a dataspace supplement that pre-computes dataspaces for different particle types in each grid, which should makes things really cheap to read *only* star particles, or particles of a different type. I've put in support for this in the yt-hg repo, but the biggest problem with it was that I couldn't figure out the right way to address it -- so I'd like to put out there a question to you guys.
In an ideal world, if you have some data object:
data_obj
what is the best way to be able to address particles of different types, and only get those particles? (Let's pretend either that IO is cheap, or we have the dataspace hack.)
For instance,
data_object.particles[type]["x"] # for instance
or maybe,
pf.h.particles[type].sphere(...)
or something? What do you think? Any off-the-wall ideas?
-Matt _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org