Discontinuous Galerkin elements and other novel cell-types/function-spaces

Development
,
4

This is very interesting work and it seems very tricky to design a satisfying solution with all of VTK’s legacy. Hopefully this will work well :slight_smile:

I have a few questions:

  • How does vtkCellGrid behave in an SMP instance? Do you have a thread-safe way to get a cell? If not, could we fill a CellType passed as a parameter?
  • Creating cells is pretty expensive: lots of buffer copying. As a result, performance can be hit quite a lot from actually using vtkCell instances. An example of that is vtkClipDataSet, which uses vtkCell::Clip to generate the output cells, and is terribly slow compared to vtkTableBasedClipDataSet which uses switch statements on the input cell types in coordination with a clip table to decide how to clip the cells. I feel like the latter approach would not be possible with this design. Do you think there could be a way to optimize a clip filter for vtkCellGrid in a similar way somehow, or is it a necessary limitation that we are paying by linking against any custom cell type?
  • Do you think that it would be possible to somehow, in the long run, merge the implementation of every vtkDataSet into some more general API such as vtkCellGrid to avoid having to duplicate the filter implementation for both types? I don’t think it would be achievable in the short term, I’m asking long term, kind of like vtkPartitionedDataSet trying to replace vtkMultiBlockDataSet.
  • Ghost question: how do we handle ghosts in Galerkin meshes? Do we have ghost edges? Ghost anything? If so, is it time to unify the ghost framework? Currently HIDDENCELL and HIDDENPOINT don’t hold the same value for legacy reasons coming from VisIt. Any take on that?
1 Like