Adding a "blocks" attribute in yt 3.0

#10 Merged at 0c3b205
Repository
MatthewTurk
Branch
default
Repository
yt_analysis
Branch
default
Author
  1. MattT
Reviewers
Description

This change to the YTEP describes the addition in:

https://bitbucket.org/MatthewTurk/yt-3.0/commits/8bc4e5aa82eaaf567bc1d98f6bf1969e46fafa93

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?

Comments (9)

  1. Christopher Moody

    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?

      1. Christopher Moody

        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?

        1. MattT author

          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.

  2. Sam Skillman

    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.

    1. MattT author

      Yes, and I have already switched the kD-tree in 3.0 to use this, although it seems to be suffering from unrelated issues.

      1. Sam Skillman

        Ah, perfect. Yeah, I think this should work out well with what I had to do to get data_source renders to work.