Hi Matt, On 2 Sep 2010, at 00:22, Matthew Turk wrote:
Hi everyone,
It's becoming increasingly clear that particle handling in yt (and frankly in Enzo) needs to be improved.
I totally agree with you. Recently I had to analyze particles in a large(ish) simulation, and I had to write my own routine to filter by particle type. http://paste.enzotools.org/show/1144/ It filters the particles only one time, and then reads multiple particle fields. It works in parallel, also. I didn't know how to incorporate this into the current fields and parallel interface, so I left it as a standalone routine. Now that I think about it -- could we use a similar interface as the cut regions to select particle types?
I'm at something of a loss for how to improve this, because of the issues with the following things:
1) How do different particle types get selected? Even in Enzo, this is variable, which drives me somewhat batty. The distinction via creation_time or particle_type is unfortunately quite vague. How can we do this without getting an enormous logic tree? On some level, because Enzo's handling of particles is relatively difficult to handle in this regard, I'm okay with pushing a change upstream to Enzo and then migrating toward that in yt over time.
I think it an option in Enzo to write individual particle fields for each type (as we discussed off-list) is a good idea. It will have to be an option, leaving the old format available for existing analysis codes.
2) Presupposing that this happens, how do we distinguish between fields for different particle types? What is the most pleasing API for selecting only the star particles in an AMRSphere? I see several possibilities:
sphere["popiii_particle_velocity_x"] sphere["popiii", "particle_velocity_x"] sphere.particles["popiii"]["particle_velocity_x"]
I can't decide which of these is the nicest. Or maybe there's even a better one I haven't thought of yet. The trick is figuring out the most simple way of addressing it, while still retaining the fundamental idea of data objects as conduits for data.
I like either the 2nd or 3rd options because looping over fields and particle types will be easier. If the 1st option is used, then you'll have to do field = star_type_string + "_" + particle_field to construct the key before requesting the data.
The solution to this issue is not unlike any future solution to a multi-fluid problem, as well.
So what does everyone think? I think we can agree, particularly as we move to more simulations of stellar clusters and whatnot, that a better mechanism for selecting and addressing particles needs to be figured out...
John