Polyhedron face connectivity improvements

Development
1

Following discussions in the VTKHDF polyhedrons thread, we would like to discuss a potential improvement to the vtkUnstructuredGrid data model that allows reusing the same faces using different orientations in different polyhedral cells.

For that, as suggested by @olesenm , we would change the FaceLocations array to handle negative values: face n is referenced as -(n+1) to signify a flipped orientation (ie points are taken in the reverse order). This way, 2 adjacent polyhedrons sharing a face will only have to define this face once, and use the flipped orientation in the FaceLocations array for one of these polygons to get correct normal vectors. This saves on both storage space when written to disk, and in memory.

Impact

The required changes are mostly internal to vtkUnstructuredGrid. For instance, face streams will be unchanged. GetPolyhedronFaceLocations will be renamed to GetOrientedPolyhedronFaceLocations that returns a cell array, referencing positive or negative face ids as points, depending on their orientation. GetPolyhedronFaceLocations will be deprecated and will implement a compatibility layer, that creates new faces so that every face id is positive, as it was before. All code using GetPolyhedronFaceLocations will need to adapt to the new GetOrientedPolyhedronFaceLocationswhich will require new code to handle the negative face ids. It should be mostly transparent for readers/writers that simply copy the array from/to disk.

2 Likes
2

@ahernsean

vtkHDF: Add support for polyhedron cells
3

Nice!

In some code ideas that will be related to this: I’ve also been looking at how to handle topological point merging (within the openfoam export code) since ghost points/cells don’t really seem tractable for non-trivial geometries. This looks to combine fairly well with the rest of the handling – I’m using hyperslabs when writing the VTKHDF, so the resulting file appears as if it was written in serial, irrespective of how many ranks were actually used.

Even when using the proposed oriented faces to cut down on the bookkeeping, it would be necessary that they continue to also support specifying duplicate faces as before. I’d assume that would be the case, but just wanted to make certain that that also remains in the spec. My use case would be to have positive/negative face addressing for everything within a processor rank, but still allow duplicated faces so that we don’t have to do any weird face flipping on processor-processor boundaries (the topological point merge happens at a later stage).

4

This is a great thread, it would be good to get these improvements in especially with Voronoi meshing coming on line.

Please make sure Jeff Lee is involved - maybe he is already but I CCd him just in case.