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

[dcthomp (David Thompson (Kitware))]

@Yohann_Bearzi

Correct me if I’m wrong … Each cell grid query type is linked to a responder that performs whatever you want done on each visited cells.

Yes. But each cell type may have a different responder for the same query.

@Yohann_Bearzi

If you want to have, say a vtkImageData, done with this representation, you’ll need to give it a different voxel cell type than on a vtkUnstructuredGrid represented as a vtkCellGrid, because we want to take advantage of the implicit structure of an image and do not need to carry a conn array for the connectivity.

To a degree, yes. It is possible that filters will not care about connectivity or other arrays that distinguish cell types (e.g., Calculator-like algorithms). There is nothing in that case to stop you from registering the same responder to multiple cell types. Or it may be that a responder can support several cell types.

For instance, the prototype provides a vtkDGSidesResponder for identifying the external faces (sides) of hexahedra in a mesh. But the same provider could easily handle any shape (it just hashes the connectivity entries for each boundary of a cell and looks for odd numbers of matching hashes to report out). My plan was to add support for another few cell shapes (quad, tet, tri, maybe pyramid) and use the same responder for them all. Coding the faces of each of those types is simple. And if some novel cell type appears that makes things difficult, a separate responder can be added.

@Yohann_Bearzi

Do you see us specializing instances of vtkCellGrid in such a way that you have a vtkImageData-like or a vtkUnstructuredGrid-like?

Yes, something along those lines. (Edit no: I think I understand your question now. I would add new vtkCellMetadata subclasses but would probably not subclass vtkCellGrid.) I never claimed it was easy to develop, but I do claim it is flexible enough to accommodate nearly all the solver schemas for memory layout you might imagine. Figure 2 in the top post shows how DG cells might be developed first for fields that use the same order interpolant for all cells in a mesh (top) and then adapted to deal with varying the interpolant order on a per-cell basis. You can imagine either (a) abandoning the first cell type for the second or (b) keeping both around to deal with different solvers as efficiently as possible. Which you choose to do depends on (a) how stable the API is (maintenance costs) and (b) how much funding/developer time is available. For other cases (like your image vs unstructured grid), it is easier to see how both would be needed.

@Yohann_Bearzi

I feel like it would conflict with vtkCellGrid::AddCellMetadata API for vtkImageData because we’re restricting ourselves to uniform grids in this instance.

You could have a vtkCellGrid instance with both an unstructured grid and a structured grid inside it. (I am not saying that’s advisable, just that you could.) I would expect a NURBS cell type to deal with both rectilinear and curvilinear structured data much like image data today (and be more flexible as well). Many filters would not need to know about the knot vector since they just add new fields arrays on points or cells.

@Yohann_Bearzi

If we do not create specialized instances of such dataset types, how do you deal with filter selection in ParaView on filters that do not work on a certain dataset type? As an example, we can think of a convolution filter which is well defined on images, but maybe more complicated to generalize to wilder topologies.

It is not in this prototype, but it would be easy to add a method to vtkCellGrid such as bool TestQuery(vtkCellGridQuery*);. That would simply check whether there is a responder registered for the given query that can handle every vtkCellMetadata object in a particular vtkCellGrid instance.

Not every vtkCellGrid needs to have every type of cell-metadata; also – even if a grid does have every type of cell – it may be that, due to the arrays present, there are zero cells of that type in the grid.

@Yohann_Bearzi

Or do we assume more that you can put any cell types in a vtkCellGrid, uniform grids of voxels, triangles, hexahedrons, and that each cell being linked to a responder, we just try to respond to a query, and if no responder exists, we skip, and thus we never gray out filters in ParaView?

I don’t think we need to do that. We could even have a TestQuery() method provide feedback about what cell types are unsupported for a query; ParaView could then provide tooltips like “The triangle-strip filter does not support quadrilaterals,” for a disabled filter.