Implementing corner point grids meshes in GEOSX

[TotoGaz]

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 :shrug:

[CusiniM]

If building faces and edges for CPG is really impossible what you are proposing makes sense. However, a few things to keep in mind:

• If we don't construct faces and edges any more (not sure if I understood this correctly) we will need a new strategy to create the stencils since they now heavily rely on the existence of faces and edges.

• The algorithms that generates the embedded surfaces needs the edges so if we decide not to construct them we will need a new way of finding interstections between a fracture plane and the background grid. Unless we decide not to use CPG and fractures but I don't think this would be a wise choice.

• I would also suggest that you have a quick look at #1354. There are some new objects in the hierarchy, specifically an embeddedSurfaceNodeManager which contains the nodes (vertices) defining the embedded surfaces. Edges are also created for these surfaces and used to construct the stencil (connectivities are defined based on the edges). This may not be a real issue though.

I guess that the alternative could be to treat CPG as unstructured grids provided by an external generator but there would still be an issue about how to handle cells that have crazy number of faces and I guess the ElementHeterogeneousSubRegion could be the way to go.

[TotoGaz]

Thx for the comments!

If we don't construct faces and edges any more we will need a new strategy to create the stencils since they now heavily rely on the existence of faces and edges.

The algorithms that generates the embedded surfaces needs the edges so if we decide not to construct them we will need a new way of finding interstections between a fracture plane and the background grid. Unless we decide not to use CPG and fractures but I don't think this would be a wise choice.

We do construct them (faces and edges), but I propose to move this construction somewhere it will be done only if required (i.e. not in the Managers but around the MeshGeneratorBase)

I guess that the alternative could be to treat CPG as unstructured grids provided by an external generator.

This is more or less what's proposed here. The issue being how to we deal with both CPG and automatic faces/edges construction like we do now, in a quite clean and consistent piece of software.

the ElementHeterogeneousSubRegion could be the way to go.

This is the most crucial question to me...

[CusiniM]

Ok, I had misunderstood part of your proposal. I guess the question is how we would handle these ElementHeterogeneousSubRegion in the mechanics kernels which require to know the size (basically the number of nodes) at compilation time. But I am also not sure what kind of FE space should be used for an element with 22 faces...

[TotoGaz]

Ok, I had misunderstood part of your proposal.

No pb, it's complicated to explain everything in a single post, that's why it's interesting to exchange.

I guess the question is how we would handle these ElementHeterogeneousSubRegion in the mechanics kernels which require to know the size (basically the number of nodes) at compilation time. But I am also not sure what kind of FE space should be used for an element with 22 faces...

We want to use @andrea-borio 's VEM which aim at dealing with strange cells ;) I do not know much about all of that. @francoishamon has better insights.

[andrea-borio]

Hi @TotoGaz! The classes that implement VEM are templatized on the maximum number of nodes per cell and the maximum number of nodes per face, so these quantities should be known at compile time. These quantities are required for preallocation, so it is of course sufficient to provide upper bounds, but the larger these upper bounds are the more you will waste memory when computing local matrices and right hand sides.

[TotoGaz]

@francoishamon @IsaacJu-debug How does this behave w.r.t. your PR? I'm not sure there is the heterogeneous feature?