Work plan for `vtk` wells import

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

• 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

• Serial processing https://github.com/GEOSX/GEOS/pull/2345
• Integerates the imporField* patterns.
• 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

Start by reviewing issue 2209, PR 2345, and the existing InternalWellGenerator entry point. The work is only done after the well geometry and business abstractions are separated, the listed InternalWell and Perforation changes are addressed, and vtk import plus parallel partitioning are supported.