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.fluid["Dust"]["Density"]
or
dd = pf.h.all_data() dd.particles["dark_matter"]["velocity-x"]
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.,
dd["Density"] dd.particles["dark_matter"]["velocity-x"]
3) Move to requiring both .fluids and .particles, and make both dict-of-dicts.
dd.fluid[:]["Density"] # for all densities summed dd.particles[:]["velocity-x"]
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["particle-velocity-x"] dd["PopII", "particle-velocity-x"]
5) Use the object for fluids with optional type specifier, and dict-of-dicts for particles:
dd["Density"] dd["dust","Density"]
Votes?
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 challenges.
I'd like to hear any suggestions or feedback on these items, or alternate suggestions.
Thanks,
Matt