See the YTEP text for details. It is also much easier to read with full markup if you click the "view file" link in the diff view of YTEP-0031.rst. Alternatively you can build the sphinx project by cloning my YTEP repo, doing "make html" in the root of the repository, and then serving the build/html directory with a webserver (e.g. python3 -m http.server) so you can view the built page in your browser.
Comments and suggestions about any part of this document are great, but I'd particularly like feedback on the "Open Questions" section since there's some bits of this that haven't been implemented yet and some API or general design suggestions for those issues would be very much appreciated.
I think this is generally quite nice, and will make a lot of aspects of dealing with SPH data much more intuitive (and lower memory cost is awesome).
I want to ask if the current support for depositing particle information onto an octree is going to be disabled? I'd like to request that it not be (as well as the possiblity of adding volume_weighted_smoothed_fields). Even if it's not the default behavior, and has to be called by the user, I would find it useful. When I run radiative transfer (be it either dust radiative transfer via powderday/Hyperion, or line radiative transfer), I depend on the physical properties to be projected onto a grid of some sort. An octree makes a lot of sense with this, and I've become fairly dependent on this capability in my workflow. If it could remain an option to be able to project particle quantities onto the octree, I would find it super useful as a lot of my own workflow depends on it.
This is covered in the "deposition operations" section. Right now I think the idea is to have an octree data object, so you could do:
Does that seem ok? Some advice on what the API for ds.octree should look like would be great, the one I suggested in the snippet above is just an idea.
Ah - sorry I'd missed that in the open questions - thanks for the pointer to it!
I think this sounds great, and would require relatively minimal code alterations to adapt to this.
Is max_level intended to be a cap on the number of refinements, regardless of what n_ref is? I don't particularly find the current o_ref keyword useful/necessary aside from imaging (which would be obviated in this YTEP), though keeping the ability to toggle n_ref would be nice.