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.
There and back again. We don't actually need the preferred phase at
the time of encountering the WELPI request. [at]joakim-hove was
right, the preferred phase of an injector must reflect the state at
the same report step as the WELPI keyword. In other words, if the
injected phase is reset at the same report step as a WELPI keyword,
then the new preferred phase must be that of the new injected phase.
This reverts commit 3eef45e87d.
The current code that aggregates flow rates from connection to
segment levels assumes that the simulator generates connection
results for the open connections only. Relax this restriction as
upcoming work in the context of WELPI will require generating at
least the CTFs even for shut connections.
