Heed advice from [at]joakim-hove to keep client code as close to
strictly SI as possible. We must nevertheless continue to store the
raw (input/output units) requested PI value internally as this is
the only way to ensure that both the client and implementation has
consistent view of the well's preferred phase. This means pushing
the unit conversion into Well::getWellPIScalingFactor().
Thanks to [at]joakim-hove for pointing out that the Well already
maintains an internal UnitSystem data member which makes the process
of converting the PI units trivial.
This commit ensures that we record a general, Schedule-level
WELL_PRODUCTIVITY_INDEX
event in addition to the well-specific event already recorded when
we encounter a WELPI keyword. We need this information in order to
trigger a PI calculation across all MPI processes in opm-simulators.
This makes the interface less convenient to use, but it is the only
way to guarantee that we have a consistent notion of preferred phase
for injectors. The downside is that the users of
Well::getWellPIScalingFactor()
must convert the argument to raw/input units before calling the
function.
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.
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.
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
This is different from COMPLETION_CHANGE which is unconditionally
recorded when processing COMPDAT. This event is recorded only when
the Well's internal WellConnections structure actually changes and
informs clients that they may need to rerun any dynamic WELPI
scaling. Such scaling will not be automatically forwarded onto the
new WellConnections structure.
This is arguably a hack.
This commit adds logic implementing the static parts of the WELPI
keyword. We internalize the keyword data, record appropriate events
and provide hooks for dynamically adjusting the per-connection
transmissibility factor (Connection::CF()) when those events occur.
We implement support at three levels
- WellConnections:
Add new public member functions prepareWellPIScaling and
applyWellPIScaling which, respectively, creates bookkeeping
data to track those connections which are subject to CF scaling
and actually applies that CF scaling.
- Well:
Add new data member 'productivity_index' which holds the 'WELPI'
data value from the input keyword (converted to SI) and new
member functions updateWellProductivityIndex and
applyWellProdIndexScaling. The first follows the 'update*'
protocol (return 'true' if state change) and assigns new values
to 'productivity_index' while the second uses the stored PI
value and a dynamically calculated effective PI value to rescale
the pertinent connections' CF value.
- Schedule:
Add new member function handleWELPI which internalizes the WELPI
keyword and its data and records WELPI events for subsequent
playback in the simulator layer.
Also add a set of unit tests to exercise the new features at all
levels.
In particular, include standard library headers as needed, fix
function declarations (operator<<() for Well::WellProductionProperties),
and make a few helper functions 'static' to avoid warnings of the
form "no previous declaration for".
For the Schedule's keyword handlers, also switch to storing member
function pointers directly instead of std::function objects. This
saves space and does not incur function pointer conversions. Use
std::invoke to call those handlers to avoid having to spell out the
'->*' operator.
This commit passes the run's notion of its active phases, an object
of type Opm::Phases, through to the initialisation layer for the
saturation functions' scaling properties. In particular, this
allows us to discriminate between the phases and to not index into
tables or properties that would not be appropriate (e.g., maximum
gas saturation (SGU) in a simulation run without active gas).
Moreover, we now have enough information to know to look for SOF2 in
two-phase run using family II saturation function keywords. These
changes are necessary in order to extend Flow's support for the
FILLEPS output request to two-phase runs.
Generally, this commit captures more of the surrounding context of
calls to the updateRFT() and updatePLT() member functions. We need
this additional context in order to handle the conflicting semantics
of output requests WRFT and WRFTPLT:FOPN. The former generates RFT
output when the well opens if this event does not happen earlier in
the simulation schedule than the output request. Otherwise no RFT
data is emitted. The latter outputs RFT data at request time if
well opens no later than the request; otherwise at well-open time.
To this end, switch the well_open_rft_name data member from an
unordered_set of well names into an unordered_map from well names to
RFT output request times. With this additional information we can
use well_open_rft_time to infer the appropriate response to whether
or not to activate RFT output at well open time. Moreover, we now
guarantee that no RFT output is ever activated before the first RFT
output request.
Switching the type of the well_open_rft_name data member also begets
an API update to the serialization related RFTConfig constructor and
to the return type of RFTConfig::wellOpenRftName().
We furthermore switch to caching the first RFT output event in a new
scalar data member, first_rft_event. This caching, coupled with the
additional calling context mentioned earlier, means we are now able
to report a high-fidelity, constant time answer to the
RFTConfig::firstRFTOutput()
request. This, in turn, is very useful for the RFT output code.
Finally, we also add a couple of new, private member functions to
simplify updating first_rft_event depending on context.
As part of this update, member function
RFTConfig::setWellOpenRFT(report_step)
will now use the minimum of all 'report_step' values to support the
WRFT keyword being specified more than once.
Finally, add a set of unit tests to exercise the various RFT output
request combinations.
While here, also switch to using unordered_map::find() and emplace()
where possible to limit repeated look-up of the same keys.
