[yt-dev] RFC: (yt-3.0) Accessing fluids and particles

Matthew Turk matthewturk at gmail.com
Mon Feb 27 11:20:50 PST 2012

Hi all,

During the geometry handling hangout today (which I think was quite
successful!) the question came up of how to handle accessing particles
and fluids came up.

The suggestion has been put forth to change all access of field values
into .fluid/.field and .particles, with the optional type specifier as
the first attribute.  This would look like:

dd = pf.h.all_data()


dd = pf.h.all_data()

I have an opinion on what we should do, but I'd like to hear from
others before continuing down this path.  Here are the options:

1) Keep everything as is for now, requiring users to manually
selection things like particle type and fluid type (in case of
multiple fluids) and just say who cares if people have multiple
particle types.
2) Move to requiring dict-of-dicts for particles only, and allow
fluids to exist as is.  i.e.,


3) Move to requiring both .fluids and .particles, and make both dict-of-dicts.

dd.fluid[:]["Density"] # for all densities summed

4) Leave things mostly as is, but use tuple-access for types.  This would mean:

dd["Density"] # gives the total density
dd["dust","Density"] # only dust density
dd["PopII", "particle-velocity-x"]

5) Use the object for fluids with optional type specifier, and
dict-of-dicts for particles:



To be honest, thinking about this worries me a bit.  I'm inclined not
to break old code unless absolutely necessary.  But, I would like to
support two-fluids in a more reasonable way, and I also want to
support multiple particle types (a more common use case, I think) more
elegantly.  As a rule, even though this is coming down the road a bit,
I'd like to try to keep in mind that big changes are frustrating for
people, so for each change that is made a good reason for making it
should be present.  In this case, I initially wanted to make it much
easier to select individual particle types, but then the discussion
grew from there.  We need to consider both aesthetic and technical

I'd like to hear any suggestions or feedback on these items, or
alternate suggestions.



More information about the yt-dev mailing list