of a "blocks" attribute to data containers in yt 3.0. That replaces the old usage of _grids, which is code-specific and does not carry the necessary information. An iteration over blocks looks like:
for block, mask in data_source.blocks:
# mask now masks both overlapping and data-source selected data
block[something] * mask # or whatever
Since development of yt 3.0 is largely occurring without the peer review that comes from the pull request mechanism, I would like this PR to open up discussion on the implementation and system.
Some specific questions:
Should it be called "blocks"? I do not want it to be "grids".
Is there a better way to do this?
Does the backwards incompat need to be made more explicit?
Is this the wrong solution?
What happens when .blocks is asked of an octree? I am still returned block-like data? If that's not the case maybe a more AMR and octree-agnostic name?
The idea would be that yes, you would be returned block-like data.
Is this creating a bunch of covering grid-esque objects? Is this as expensive as this sounds?
And the point is to allow backwards-compatibility with stuff built for grids?
That's right. The point is that really, in general a lot of things depend on grid objects that should not. By breaking backwards compatibility and removing the usage of the word "grid" we emphasize that really what we're interested in is 3D objects, not "grid" objects. And we also then are able to identify which regions can be updated, and we make the decision: "Do we need grids here or not?"
And what they generate is up to the geometry frontend. For instance, oct frontends may choose to yield individual octs. They can yield them one at a time, or they can pre-generate tons and yield them piecemeal after that. I don't think any will be covering grids.
Yes, though, it will be expensive for octrees in all likelihood. But I don't think there are many places that actually require 3D arrays. This will help flush them out.
Awesome. Thanks for clarifying!
Hi Matt, I think this looks good. Do the blocks have left/right edges information? If they do then I can build the AMRKDTree on top of those, probably.
Yes, and I have already switched the kD-tree in 3.0 to use this, although it seems to be suffering from unrelated issues.
Ah, perfect. Yeah, I think this should work out well with what I had to do to get data_source renders to work.