Incoming changes to the AMR data model of VTK

One year ago, @spyridon97 opened this issue to show that the AMR data model was not adapted with the way VTK had been developped and required a refactoring in order to be integrated into modern developpements: https://gitlab.kitware.com/vtk/vtk/-/issues/19246

This is currently being developped and here is a heads up of what is happening.

AMR used to inherit from vtkCompositeDataSet and was mostly a collection of vtkUniformGrid with the actual AMR implementation done in vtkAMRData and vtkAMRInformation.

However, this required lots of custom code to traverse the AMR, by making an AMR inherits from vtkDataObjectTree, we can now rely on the classic traversal of data object tree like vtkPartitionedDataSetCollection.

Here is how it is implemented now:

An AMR is now a recursive vtkDataObjectTree that contain N+1 child corresponding the the N grid at the current level and another AMR that is the next level.

This recursive implementation contains the AMR structure itself.

There is no need for vtkAMRData anymore and the vtkAMRInformation has been split into vtkAMRMetaData and vtkOverlappingAMRMetaData.

This metadata is shared accross the recursive AMR and is of the right type depending if overlapping or non-overlapping AMR is being used.

You can take a look at the merge request here: https://gitlab.kitware.com/vtk/vtk/-/merge_requests/12230

I’ll of course update the documentation accordingly.

Please note many methods and classes have been deprecated in the process, this will have impact on your code using VTK AMR.

2 Likes

Well, turns out that recursive structure was actually not needed as all the information is present in vtkAMRMetaData.

The implementation will be much closer to the PartitionedDataSetCollection.

That being said, not much is changed in terms of impact on the API, many methods have been deprecated.

1 Like