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

[dcthomp (David Thompson (Kitware))]

Hi Yohann,

@Yohann_Bearzi

How does vtkCellGrid behave in an SMP instance? Do you have a thread-safe way to get a cell?

Currently, there is no equivalent to vtkCell. The vtkCellMetadata class is a single instance representing all the cells of a given type in the entire vtkCellGrid. I would resist the urge to use class inheritance to force a common API for individual cells. By removing this level of granularity, we can remove a lot of the overhead you mention (copying connectivity/field data/etc. into a data structure just to iterate cells).

As far as SMP goes, the vtkCellGrid doesn’t do anything to help or hurt you; responders to vtkCellGridQuery classes implement an algorithm however they choose (and they should choose to use vtkSMPTools wherever it makes sense).

We could in theory make vtkCellGrid::Query() perform task parallelism by running responders in multiple threads, but that could complicate access to the vtkCellGridQuery instance that all the responders typically insert result/output data into. It would not be impossible to be efficient (for instance, the prototype vtkOpenGLCellGridRenderRequest class provides a GetState<StateType>(cellType) method that each cell type could access without fear of races/deadlocks). However, queries that require responders to modify shared state would need to provide atomics or locks for thread safety.

@Yohann_Bearzi

… vtkClipDataSet, which uses vtkCell::Clip to generate the output cells, and is terribly slow compared to vtkTableBasedClipDataSet … 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?

That is part of the design. Each cell type registers responders that can handle a given query class. When you run a query:

vtkCellGrid* grid;
vtkNew<vtkCellGridClipQuery> clipper;
clipper->SetImplicitFunction(fn);
grid->Query(clipper);

The grid iterates over all its cell types (instances of subclasses of vtkCellMetadata) and for each one, attempts to find a responder (i.e., vtkCellGridResponder<vtkCellGridQuerySubclass>) to the query class you pass it (from the list of registered responders, indexed on both cell type and query type). Each responder is then invoked on the query in turn. No copying is done. The responders can make calls on the query object to record their output. The base query class has virtual Initialize() and Finalize() methods called before-any/after-all responders have been invoked.

@Yohann_Bearzi

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?

Yes, it is possible. Insert coin here. In theory, even vtkTable or vtkGraph could become vtkCellGrid instances with different subclasses of vtkCellMetadata representing rows/columns or nodes/arcs, respectively.

Right now, there’s enough rope to make plenty of nooses.

@Yohann_Bearzi

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?

That is currrently up to the individual cell classes.

1. I think traditional DG cells will have slightly different needs than NURBS or polyhedral cells. Exotic cells (table rows? graph arcs?) may have significantly different needs. This has played out a bit with structured vs. unstructured grids in VTK with extents vs pieces (not directly related to ghost cells, but the way that decomposition is performed will affect ghosts and I do not want to force concepts about data decomposition into the base API yet).
2. If possible, I would like to allow the arrays present in vtkCellGrid to match simulation codes as much as possible rather than force “translation” of ghosts – the query responders should adapt solver-specific array-data to the task at hand.
3. It is important not to force a uniform API that is not completely generic.

So, I don’t want to deal with ghost cells/points/(edges/faces/graph-arcs/table-rows/table-columns) until we have implemented ghosts in 2-3 specific contexts first.