Hi everyone, It's becoming increasingly clear that particle handling in yt (and frankly in Enzo) needs to be improved. 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. 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. 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... ANY ideas would be greatly appreciated. Thanks, Matt
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
All,
sphere["popiii_particle_velocity_x"] sphere["popiii", "particle_velocity_x"] sphere.particles["popiii"]["particle_velocity_x"]
I don't know if it would be correct to do it in this framework, but we could consider making the particle statements a bit more powerful and allowing multiple filters. For example, something like this: sphere[["popiii", "M>1e10"], "particle_velocity_x"] would pick out p_v_x of fantastically massive popiii stars. This may make doing analysis of large datasets simpler for the end-user when it's done in parallel, if we do the back-end particle handing "right". I can see some problems with this, but I'm putting the idea out there. _______________________________________________________ sskory@physics.ucsd.edu o__ Stephen Skory http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student ________________________________(_)_\(_)_______________
Hi All,
Okay, after thinking it through, reading Stephen and John's comments,
and talking to some other people, I've decided I'm going to go with
the pairwise field access:
sphere["popiii", "particle_velocity_x"]
It'll probably be a while coming, but that's what I think is the best
bet. We need answer testing before I touch any of the underlying
machinery for data access or units ...
Thanks for your feedback!
-Matt
On Thu, Sep 2, 2010 at 7:15 AM, Stephen Skory
All,
sphere["popiii_particle_velocity_x"] sphere["popiii", "particle_velocity_x"] sphere.particles["popiii"]["particle_velocity_x"]
I don't know if it would be correct to do it in this framework, but we could consider making the particle statements a bit more powerful and allowing multiple filters. For example, something like this:
sphere[["popiii", "M>1e10"], "particle_velocity_x"]
would pick out p_v_x of fantastically massive popiii stars. This may make doing analysis of large datasets simpler for the end-user when it's done in parallel, if we do the back-end particle handing "right". I can see some problems with this, but I'm putting the idea out there.
_______________________________________________________ sskory@physics.ucsd.edu o__ Stephen Skory http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student ________________________________(_)_\(_)_______________
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (3)
-
John Wise
-
Matthew Turk
-
Stephen Skory