Embedded Discrete Fractures copy node map and create stand-alone EdgeManager.

[rrsettgast]

• [ ] Copy Node map from embedded cut cell into the EmbeddedSurfaceSubregion.
• [ ] Create an populate a stand-alone EdgeManager to hold connectivity information between the EmbededSuraceSubRegion
• [ ] Add EmbeddedSurfaceSubRegion interactions to FaceElementStencil and CellElementStencil

[CusiniM]

I have been looking into the SinglePhaseFlow solvers, the stencils and I have thought about how to approach this.

I have listed below a few issues on which I would like to have some feedback before starting to work on this.

Issue 1: Size of the node map living on the EmbeddedSurfaceSubRegion. In each CellElementSubRegion the Node map has a different size and the same EmbeddedSurfaceSubregion can have, e.g., some elements cutting a tetrahedron and others cutting an hexahedron. Solution proposed: I propose to size the map based on the maximum number of nodes that an element can have (should be 8?) and then assign a value that can be filtered out (-1?) for those cells which do not actually have 8 nodes. The alternative would be to have multiple EmbeddedSurfaceSubRegion objects so that there is one for each CellElementSubRegion.

Issue 2: Where to place the extra EdgeManager ? Solutions proposed:

• option 1: I add it to the EmbeddedSurfaceRegion.
• option 2: I add it to the MeshLevel by creating an m_embeddedSurfacesEdgeManager. I personally prefer this option as I think that all mesh information should probably live in the same place.
• option 3: Create a separate MeshBody for the mesh of the embedded fractures. I am not sure if this was the way mesh bodies were supposed to be used though but I think it could work. This may be the most elegant approach but it may be a little more convoluted. It would allow to create an entirely separate mesh for the fractures though which is kind of the whole idea behind employing an embedded approach. Actually, for the flow problem, the fracture mesh could be completely independent when using EDFM (like in the figure below).

This is not really the case for the mechanics though. This approach would also allow to have separate coarsening strategies (different mesh levels) for the fractures and the rock matrix. -option 4: the last option would be to avoid having this extra EdgeManager but create a separate stencil object that does not need edges to define connectivities. What I do not like about this is that it would treat EmbeddedSurfaceSubRegions and FaceElementSubRegions in very different ways which I do not think it's what we want.

@rrsettgast @joshua-white @af1990 @klevzoff @francoishamon let me know what you prefer and if there are other possibilities that I have not thought of yet.

[andrea-franceschini]

For issue 1, if the combination of virtual element method and embedded fractures is on the plan, it would be impossible to known an a-priory maximum number of nodes per element. Nevertheless, for classical FE, this should work fine and it doesn't seem to bring to much new complexity. Regarding issue 2, I would prefer either option 1 or option 2. I think they should be flexible enough to allow all the stencil based computations, without too much overhead (like, I would say, option 3 will bring, specially thinking to mechanics, where everything is coupled, and the related solver). Finally, option 4 seems to me something very specialized for the EDFM ...

[joshua-white]

I agree with @af1990:

On issue 1, I think we should just assume each node list has a different length and store it that way. The cut is going to be an arbitrary polyhedral mesh, and we will want to use that capability for a variety of solvers.

On issue 2, I vote for option 2 to centralize all the mesh management classes. How does your class need to differ from the existing EdgeManager? Rather than create a new version, can we rethink the design of the existing one to be more flexible?

[CusiniM]

@joshua-white so, the idea of adding a separate EdgeManager was to introduce a whole new set of edges which are relative to the 2D fracture grid and that can be used to define the connectivity between the embedded fracture elements. And I believe that we concluded that adding edges to the existing list would create some other issues.

[joshua-white]

Okay, obviously do whatever makes the most sense, particularly given you are prototyping. I completely see the need for separate edge lists. My question is more: can you store two edge lists and act on them with two distinct objects of the same type EdgeManager (our usual one, and your embedded list) or do you need a new class EmbeddedSurfaceEdgeManager that actually has some distinct functionality? My thought is we could keep all the edge based functionality in one place, even if we end up using them on two distinct lists. We could also anticipate redesigning the edge manager to better handle sub-lists, but that is a big lift at the moment.