[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