Skip to content

Eliminate need of SpatialDecomposition in contour tree code

At the moment, the distributed versions of the contour tree filters rely on a helper class SpatialDecomposition, which stores information for a regular, rectilinear grid that is split among the MPI ranks and stored as a set of vtkm::cont::DataSet objects with a vtkm::cont::CellSetStructured cell set.

PastedGraphic-1

The contour tree code currently assumes that blocks are split along a set of points along each coordinate axis. For example, in the 2D mesh in the following figure is split at index 6 in x direction and at index 5 in y direction, resulting in four blocks:

  • BLOCK 0 (lower left): Origin: 0,0; Size 6, 5
  • BLOCK 1 (lower right): Origin: 6, 0; Size 4, 5
  • BLOCK 2 (upper left): Origin: 0, 5; Size 6, 5
  • BLOCK 3 (upper right): Origin 6, 5; Size 4, 5

The contour tree codes needs the following information (mainly to set up DIY correctly, in particular to set up vtkmdiy::RegularSwapPartners correctly)

  • BlocksPerDimension: How many blocks are there along each axis. In the example in the figure this would be (2, 2).
  • GlobalSize: The size of the mesh consisting of the union of all blocks. In the example in the figure this would be (10, 10) cells or (11, 11) points.
  • LocalBlockIndices: Is an array with the logical indices of the blocks (how they are tiled in global space). In the example above, these would be (0,0), (1,0), (0,1), (1,1)
  • LocalBlockOrigins: These are origins of the boxes in index space: (0,0), (6,0), (0,5), (6,5) in the example.
  • LocalBlockSizes: Are the extents of the blocks (6,5), (4,5), (6,5), (4, 5) in the example.

Of these LocalBlockSizes are redundant, as this information is readily available from the CellSet. I believe LocalBlockOrigins corresponds to the result of GetGlobalPointIndexStart() in vtkm::cont::CellSetStructured and thus is redundant, too,

However, to completely eliminate the need for the SpatialDecomposition helper class, I'd need GlobalSize, BlocksPerDimension, and LocalBlockIndices as well. Ideally, I'd associate this information with one of vtkm::cont::CellSetStructured, vtkm::cont::DataSet or vtkm::cont::PartitionedDataSet, so that I can re-use it between filter executions.

  1. Would it make sense to add these to vtkm:::cont::CellSetStructured? Or are there any arguments against that?
  2. Alternatively, with VTK, you could attach information like this as "field data" to a VTK DataSet. Is there a similar concept for vtk-m?
  3. I see that there is already an AssignerPartitionedDataSet for interfacing to DIY. Should there be a RegularSwapPartnersPartitionedDataSet as well that provides a better interface between DIY and PartitionedDataSet for this use case?
Edited by Gunther Weber