GEOS Work plan for `vtk` wells import

This issue proposes a work plan to improve the definition of wells in geosx.

[x] This issue should be done after issue https://github.com/GEOSX/GEOS/issues/2209 is done. This issue splits business and geometrical considerations for mesh data.

Wait for DFNs to be done

[x] Serial processing https://github.com/GEOSX/GEOS/pull/2345
[x] Integerates the imporField* patterns.
[x] Full parallel processing (ghosts…)

Some name changes should be done

[ ] Remove the ABC suffixes that are pointless to consumers.
[ ] Rename the CellBlockManager, MeshGenerator, WellBlock, ... into more meaningful classes.

Split the WellElementSubRegion::generate and move the geometrical part behind the CellBlockManagerABC curtain:

[ ] Split WellElementSubRegion::assignUnownedElementsInReservoir . Move the cellBlock/subRegion into the CellBlockManagerABC region. Keep the region management outside. Be consistent with what was done for the binding between CellBlocks and sub regions. (e.g. see ElementRegionManager::getCellBlockToSubRegionMap)
[ ] WellElementSubRegion::checkPartitioningValidity, WellElementSubRegion::collectLocalAndBoundaryNodes, WellElementSubRegion::updateNodeManagerSize, WellElementSubRegion::constructSubRegionLocalElementMaps are geometrical validations that can be moved in the geometrical part.
[ ] Split field import from constructSubRegionLocalElementMaps (in the current case, radius and volume) and move it to business domain. Be consistent with the management for DFNs with the element aperture (e.g.). Implement the importField on WellBlocks (for radius and volume first).
[ ] Consider WellElementSubRegion::updateNodeManagerNodeToElementMap with care. It surely can be split, because there’s obviously the er, esr, ei triplet which can hint into interweaved business/geometrical management.

Eventually trim WellBlockABC to get the new reduced abstraction.

From this point, it should be possible to change the (currently unique) source of data more easily, and add the vtk support.

[ ] Compute geometrical considerations using vtk, as driven by the new abstraction (see InternalWellGenerator below for a better taste of those computations).
[ ] Deal with the parallel partitioning appropriately; maybe FaceBlock can be a good example. If not, make it evolve to ensure consistency.

@dkachuma also proposes an improvement about the wells' definitions for InternalWellGenerator. The main motivation is that well perforations should be specified by an interval as opposed to a precise location (point) in the mesh. This allows more independence between the well mesh and the reservoir mesh. This also allows the length of intersection between the well and the mesh to be independent of the cell sizes for cases in which the mesh is refined for example. Proposed changes:

[ ] On the InternalWell element, rename the polylineSegmentConn field to branches. This should still be a list of lists of node indices but will instead specify the nodes that make up the different branches of the well. An example:
```
<InternalWell
   name="TheWell"
   polylineNodeCoords="{{1.0,1.5,-10},{1.0,1.5,-12},...,{1.0,1.5,-20}}"
   branches="{
      {0,1,2,3,4,5,6},
      {3,7,8,9,10},
      {3,11,12,13,14},
      {5,15,16,17,18}
   }">
</InternalWell>
```
This defines a well with 4 branches. The main branch is made up of the first 7 nodes. Off of this, 2 branches start at node 3 and another branch starting at node 5. The branches field should be optional and if not speficied, it should be assumed that the well has a single branch with all the nodes specified in sequence. Is the branched well already implemented?
[ ] On the InternalWell element, add an optional measuredDepth field. This should be a list of real non-negative values which should correspond to the measured depth of each node in the polylineNodeCoords field. This should give the true measured depth of the point, usually the length of the well from the starting point of drilling to the current point. In the absence of this data, the measured depth of the first point should be assumed to be 0 and should increase as the length of the polyline.
[ ] On the InternalWell element, remove the numElementsPerSegment. The number of elements should be automatically calculated depending on how the well trajectory intersects the mesh and where the perforations are located.
[ ] On the Perforation element, remove the distanceFromHead field and replace with two fields: startMeasuredDepth and stopMeasuredDepth. These 2 should define the segment of the well which has been perforated instead of a single point.
[ ] On the Perforation element add an optional branch field indicating the branch on which the perforation is located. This will be relevant when the branched well is implemented.

Further ideas:

[ ] The well polyline should be discretised by working out where it intersects the domain mesh and generate the well elements accordingly. Instead of depending on the size of the cell in which the perforation is located, this should dome with its own length.
[ ] With lengths and directions of intersections with cells, the projected Peaceman formula for transmissibility calculation should be used to work out the well-cell connection transmissibility.
[ ] If a well falls on the face or edge of a cell then I would advocate for something pragmatic but deterministic.

PS: Note that wells & EDFM should receive a quite similar treatment. @herve-gross

Mar 20 '23 02:03 TotoGaz

On the InternalWell element, remove the numElementsPerSegment. The number of elements should be automatically calculated depending on how the well trajectory intersects the mesh and where the perforations are located.

The well polyline should be discretised by working out where it intersects the domain mesh and generate the well elements accordingly. Instead of depending on the size of the cell in which the perforation is located, this should dome with its own length.

Is there existing practice/research showing benefits of this? To the best of my knowledge, discretization of the wellbore is intentionally kept separate from the reservoir mesh as the accuracy requirements of the wellbore solve are different from those of the reservoir. While it's true that keeping an extremely coarse wellbore while refining the mesh may lead to inconsistent results, I don't think that fully automating this and taking away control from the user is the way (but I don't talk to reservoir engineers so happy to be corrected). On the other hand, perforation intervals and auto computing locations sounds like a great thing to have. But "perforation" != "well element".

Mar 20 '23 07:03 klevzoff

Is there existing practice/research showing benefits of this? To the best of my knowledge, discretization of the wellbore is intentionally kept separate from the reservoir mesh as the accuracy requirements of the wellbore solve are different from those of the reservoir.

I agree in that we should maintain the flexibility to discretise the well independently of the mesh. My suggestion to remove numElementsPerSegment was aimed at addressing 2 issues that we have found a bit frustrating

Having 2 perforations on the same well element.
Requiring that the last well element has a perforation.

Whereas you can resolve the first issue by increasing numElementsPerSegment, that almost invariably means you fall into the second issue.

I find the reservoir engineers prefer pragmatic solutions that don't require them to fiddle with their data. I would suggest:

If 2 (or more) perforations fall on the same well element, then internally split the element.
Remove well elements at the end of the trajectory that have no perforations.

Apr 05 '23 21:04 dkachuma

I do not reallu understand what is needed by the solver. Is it the 3d position of the perforation and the transmisibility ? On the mesh domain hand what should theoretically be associated to the reservoir mesh for the solver ? The well element, the well vertex position ? The geometric position of a perforation is completely independent of the discretization of the well. A perforation could then be associated to a well element but also to a well vertex. So why are not both associated to the so called reservoir mesh ?

Jul 10 '23 15:07 untereiner

@TotoGaz let's make sure these items are either completed, re-assigned, or discarded. Thanks!

Jul 03 '24 20:07 herve-gross

Isn't this the role of the architecture and operations committees as described in https://github.com/GEOS-DEV/GEOS/pull/3178 ?

Jul 04 '24 18:07 TotoGaz