1. The well reference depth should *not* be updated when new connections are
added with COMPDAT.
2. The well reference depth should be recalculated when the well is updated with
the WELSPECS keyword.
The parmetis.h distributed via the parmetis binding of scotch
with Ubuntu 18.04 (libscotchparmetis-dev) includes the header
scotch.h located in /usr/include/scotch/. Therefore our check
of the include file failed. With this commit we check the
parmetis.h header another time with the scotch include path added.
Now parmetis is found on my Ubuntu.
This commit adds a new member function
applyWellProdIndexScaling(well_name, report_step, scalingFactor)
which applies WELPI-based CTF scaling (by scalingFactor) for all
pertinent report steps from 'report_step' and until the end of the
simulation run. We use the 'scalingApplicable' array to communicate
connection eligibility between report steps and only apply the
scaling if the internal connections pointers differ between report
steps.
This commit adds a new in/out parameter, scalingApplicable, to the
applyWellProdIndexScaling functions. This parameter carries time
(history) information on whether or not a particular connection is
eligible for WELPI-based CTF scaling. Entries are marked ineligible
(false) and left untouched on subsequent calls if the corresponding
connection is ineligible at any point--e.g., as a result of new
COMPDAT entries.
This ability enables implementing WELPI CTF scaling at the Schedule
level which is the only level that has sufficient time information
to identify all the unique Well/WellConnections object combinations.
This commit adds a new special purpose predicate member function
bool Well::hasSameConnectionsPointers
which checks if the internal WellConnections pointers of two Well
objects (*this and the input argument) point to the same object.
This, in turn, enables identifying when to apply dynamic WELPI CTF
scaling across the time direction the internalized connection
information.
First part, implemented in a new member function
Well::getWellPIScalingFactor
calculates a CTF scaling factor from stored WELPI information and a
dynamically calculated well-level PI value. The second part, using
the original name applyWellProdIndexScaling, applies an externally
calculate CTF scaling factor to all eligble connections.
This is needed to enable applying multiple scalings across the time
direction. Update unit tests accordingly.
This is to handle the case of an injector changing its injected (and
therefore preferred) phase (e.g., in WCONINJE or WCONINJH) at the
same report step as a WELPI CTF rescaling, but logically after the
WELPI action is applied.
For instance, this happens in the following setup:
WCONINJH
INJ2 WATER OPEN 5500 /
/
DATES
1 'JAN' 2020 /
/
WELPI
'INJ2' 0.1E5 /
/
WCONINJH
INJ2 GAS OPEN 701627 /
/
DATES
1 'FEB' 2020 /
/
In this case, the WELPI for 'INJ2' is supposed to be interpreted as
the water-phase PI (preferred phase is 'WATER' when we read WELPI),
but since the injecting phase is reset to 'GAS' at the same report
step we risk misinterpreting the PI as pertaining to the 'GAS' phase
when calculating the well's effective/dynamic PI in the simulator if
we just use Well::getPreferredPhase().
Switch the the well's input PI from an optional<double> to an
optional<struct> that captures both the input PI value (SI units)
and the preferred phase when processing the WELPI data. Provide a
way to query that information from the simulator and update unit
tests accordingly.
Since the Well stores a pointer to its connections, rather than the
connections themselves, we must take care not change the existing
state of the connections' WELPI eligibility flag. Do the update
check on a copy of the connections instead of the real connections.
Pointy Hat: [at]bska
