FiedlPropsManager::keys() list the FieldProperties needed by the
TransCalculator, but these cannot be queried the normal way as this
raises exceptions and results in a deadlock. Hence we use the new
funtionality to get also the unsupported ones, by passing true to
get_double_field_data.
This commit switches the helper function
WellGroupHelpers::updateGuideRateForGroups<>()
to include efficiency factors in the potential rates at grouptree
levels below a particular group. We furthermore switch the helper
function
WellGroupHelpers::updateGuideRatesForWells<>()
to not include efficiency factors at all.
The motivation for this change is that efficiency factors always
apply to the level we're accumulating rate values into rather than
to the rate values themselves.
As the ErrorGuard also dumps warnings we now always dump
it (previously only on error) to get these messages in the
console.
If there are error encountered, we log a meaningful error
message (the real cause was missing previously) and do a
graceful exit after MPI_Finalize.
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
