Make vtkUniformGridAMR a subclass of vtkPartitionedDataSetCollection/vtkDataObjectTree
The following chart described the hierarchy of vtkCompositeDataSet subclasses.
As we plan, to deprecate vtkMultiBlockDataSet, and vtkMultiPieceDataSet thanks to the introduction of vtkPartitionedDataSetCollection, vtkPartitionedDataSet, we should also consider making vtkUnformGridAMR a subclass of vtkPartitionedDataSetCollection or at least vtkDataObjectTree. vtkUnformGridAMR has a flat hierarchy similar to vtkPartitionedDataSetCollection: a set of levels, where each level has vtkUniformGrid(s).
There are three differences that these data structures have:
- vtkUniformGridAMR has AMRData which encapsulate bounds related information (and also store the datasets for the time being),
- vtkUniformGridAMR requires that all levels have the same number of vtkUniformGrid(s) in each level across all nodes, which is not a requirement for vtkPartitionedDataSetCollection in each vtkPartitionedDataSet.
- vtkPartitionedDataSetCollection can optionally store a vtkDataAssembly, which could be potentially used to store the bounds related information that AMRData stores.
Making vtkUnformGridAMR a subclass of vtkPartitionedDataSet or vtkPartitionedDataSetCollection would be really important so that CopyStructure function, and SetDataSet/GetDataSet functions using vtkDataObjectTreee iterators work seamlessly between vtkUniformGridAMR and vtkPartitionedDataSetCollection. This is needed for all filters that their input is vtkUniformGridAMR and the output is vtkPartitionedDataSetCollection, such as vtkPVGeometryFIlter, vtkPlaneCutter, vtkExtractSelection. Fixing especially CopyStructure would make sure that the level information is still present in the output of a filter. Finally, doing such a change would help in making sure that vtkUniformGridAMR would get all the benefits that vtkPartitionedDataSetCollection might get in the future (or already has), therefore significantly reducing future development costs and fixing several bugs because vtkUniformGridAMR needs special treatment, which doesn't have right now.
P.S. If we decide to do something like, let's also deprecate vtkHierarchicalBoxDataSet, the ancestor of vtkUnformGridAMR.
P.S. 2, I believe that refactoring core data structures wherever is meaningful is required to sustain VTK for another 30 years.
@berkgeveci @cory.quammen @mwestphal @dcthomp @acbauer @wascott @patchett2002 @will.schroeder