Previously, we exported an unordered map containing all names of
wells that are not present in the local part of the grid.
As we envision to have wells that are distributed across multiple
processors, this information does not seem to be enough. We need
to be able to set up communication for each well. To do this we need
to find out who handles perforations of each well.
We now export a full list of well name together with a boolean
indicating whether it perforates local cells (vector of pair of string
and bool).
This is in preparation of adding support for outputting the network
node pressure quantity, GPR, to the summary file. In particular,
'GroupValues' is renamed to 'GroupAndNetworkValues' and has new
individual datamembers for the former group-level data and the new
node-level data.
Update BlackoilWellModel::groupData() and CollectToIORank
accordingly and bring the parallel restart facility in line with the
new layout.
As part of support the RPR__xxx summary keywords the ecloutputblackoilmodule.hh
file hase been refactored significantly:
- std::optional<> is used to manage the calculate once initial values.
- several small functions are extracted from the outputFipLog() function.
- std::array<> is used instead of ScalarBuffer to manage containers over all
FipTypes.
- SummaryConfig nodes for the requested summary output is stored in the class.
- A small struct RegionSum is created to hold the region summed properties.
For PINCH(5)==ALL, we take the minimum of MULTZ+ and ignore MULTZ-.
We also prepare for PINCH(5)==TOP taking only the toplevel MULTZ+
value.
For non-vertical directions we use both MULTZ+ and MULTZ-
We used a method isGlobalIdxOnThisRank to determine whether to write
an entry for a summary keyword (like BPR). Unfortunately, this did
exactly what the name suggested, but we actually passed a cartesian
index to it. That meant that a lower cartesian index might have found on
many processes (with different cartesian index and hence resulting in
wrong values), while higher for ones no process would have been found
with it (resulting in writing zeros).
With this commit we store a sorted list of cartesian indices and query
that in the renamed and restructured function isCartesianidxOnThisRank.
Most probably this broke during refactoring.
Closes#2665
This will process the same faces in serial and parallel.
Hence it make the silent assumption that we only process faces
from low cartesian index to high cartesian index hold again.
This should fix PINCH MULTZ ALL in parallel.
