Implementing corner point grids meshes in GEOSX

What is the requested feature?

Hello, @francoishamon and myself need to get Corner Point Grids (CPG) inside of GEOSX (see COORD, ZCORN, ACTNUM).
CPG have lots of crazy cells, some with 22 faces… In a nutshell, those cells follow no rule.

So we surely to modify GEOSX to support this kind of meshes.

Below a first proposition, please give me your comments.

Summary of the current situation. On top, an abstract base class MeshGeneratorBase, imposes virtual void generateMesh(DomainPartition&domain)=0 as unique API.

The 3 implementations of MeshGeneratorBase (PAMELAMeshGenerator, InternalMeshGenerator, InternalWellboreGenerator) mainly respect the following same pattern.

1. Register some parallel split information; retrieve cellBlockMgr and nodeMgr.
2. The nodeMgr is filled with node positions, node sets, local->global mappings
3. For each type of cell, we fill a CellBlock with the node list, some local->global mappings, some properties/fields.
4. Surfaces are registered in node sets

After the MeshGeneratorBase::generateMesh( domain ) has been called, inside of ProblemManager::generateMesh

1. Node data is already in the nodeMgr
2. Contents of cellBlocks are copied into elementMgr

Followed by

1. faceMgr builds faces
2. edgeMgr builds edges
3. elementMgr, faceMgr, nodeMgr build their elementMaps, faceMaps, edgeMaps, etc.

Describe the solution you'd like

This is the current hierarchy

ObjectManagerBase
├── ElementRegionBase
│   ├── CellElementRegionBase
│   ├── SurfaceElementRegion
│   └── WellElementRegion
├── ElementSubRegionBase
│   ├── CellBlock
│   │   └── CellElementSubRegion
│   ├── SurfaceElementSubRegion
│   │   ├── EmbeddedSurfaceSubRegion
│   │   └── FaceElementSubRegion
│   └── WellElementSubRegion
├── EdgeManager
├── ElementRegionManager
├── FaceManager
└── NodeManager

Because of corner point grids (CPG), we cannot not always build faces and edges anymore (it contains lots of cells that obey no rule, no convention). I would like to be able to use an abstracted mesh in our "populating process" in order not to rely on if/then/else that are hell to maintain.

My proposition is to remove the building of cell/face/edge/node connections from the managers and make it be implemented behind an abstract API around the MeshGeneratorBase.

1. Today CellBlock is unique in the ElementSubRegionBase hierarchy (Surface and Well don't really have it). I suggest to remove it from the hierarchy to get symmetry back.
   • The lost features of CellBlock are transferred in CellElementSubRegion not to break everything
2. Then we could create an abstract CellBlockBase, FaceBlockBase, EdgeBlockBase hierarchy aside MeshGeneratorBase. The current mesh generators will use the current buildFaces, buildEdges in their implementations. CPG implementation will simply return a list read from a file, or any other implementation.
   • Build the abstract API to plug into current managers implementation
   • Move the FaceManager::buildFaces, EdgeManager::buildEdges into the CellBlock, FaceBlock, EdgeBlock hierarchy.
   • Maybe move the nodeList, faceList etc. maps construction there too? I don't know.
3. Adapt MeshGeneratorBase::generateMesh accordingly (maybe returns some CellBlockBase, FaceBlockBase, EdgeBlockBase containers?)

This new design must be validated w.r.t. current meshes before implementing CPG.

For CPG we have a lot of crazy cells -> it's not really possible to keep one cell type per ElementSubRegion. Do we want to introduce an ElementHeterogeneousSubRegion and ElementHomegeneousSubRegion (or something like this?). Can we accept one ElementSubRegion with some mixed cells (dangerous I think)?

Are there strong implicit commitments for this homogeneous assumption throughout the code that needs attention?
Do we need to have one version for homogenous and another for heterogeneous? Is it worth the price?

Please feel free to comment.
We can set up an on-line meeting if needed.

Describe alternatives you've considered
None

Additional context

PS Partition: We have an abstract base class PartitionBase with one unique implementation, SpatialPartition. At some locations here and there we seem to assume implicitly that we are using SpatialPartition and not the abstraction. And we do some tricks when using metis. I do not know if we'll have to modify this (it's next to the path, but maybe not on the path), but having a MetisPartition and using PartitionBase seems to be a promising solution.

We must try to provide some results on mid-june. Which means that wee have both some time and lots of word 🤷

Start by reading MeshGeneratorBase::generateMesh and the current PAMELAMeshGenerator, InternalMeshGenerator, and InternalWellboreGenerator implementations. Then trace FaceManager::buildFaces, EdgeManager::buildEdges, and the CellBlock hierarchy to understand their assumptions about homogeneous cells and connectivity. Done means agreeing on an abstraction that preserves current mesh behavior and can represent Corner Point Grid connectivity.