[Yt-dev] Request For Ideas: Particle Handling
John Wise
jwise at astro.princeton.edu
Thu Sep 2 06:48:31 PDT 2010
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
More information about the yt-dev
mailing list