This commit splits Schedule::handleWCONProducer() into those parts
that are specific to the individual keywords (WCONHIST/matching and
WCONPROD/prediction) and those that are common to both.
In particular we introduce two new helper functions
matchingProperties() and predictionProperties()
of which the first constructs a WellProductionProperties object
specific to matching semantics and the latter constructs a similar
object specifc to prediction. In the case of WCONHIST, the well
always supports component rates at surface conditions ({O,W,G}RAT)
as well as liquid rate (LRAT) and (total) reservoir volume rate
(RESV). The prediction mode keeps the existing semantics of not
supporting control modes for which the values have been defaulted.
The final helper, function producerProperties(), dispatches to
matchingProperties() or predictionProperties() depending on
handleWCONProducer()'s 'isPredictionMode' flag and handles the
record properties that are common to both WCONHIST and WCONPROD,
including whether or not to assign a new active control mode.
The end result is that handleWCONProducer() becomes a loop of
keyword data records that
1) Determines the wells affected by a given record
2) Determines whether or not the wells are OPEN
3) Computes control mode properties (producerProperties())
4) Assigns status and those properties to all affected wells
This approach reorders the well loop compared to the previous
implementation which computed separate WellProductionProperties for
each well.
Improved performance by checking for wildcard before entering the loop. Logic slightly changed since method now only supports wildcards at the end of the string.
This entails:
- Adding a new data member of type Opm::Phase::PhaseEnum.
- Adding method getPreferredPhase().
- Adding extra constructor argument.
- Modifying constructor call in Schedule::addWell().
- Adding unit test for the new preferredPhase property.
- Modifying constructor call in all the well unit tests.
for SPE-9 only the well/group names contain spurious white space, but
I suppose that other decks also feature them in control modes, status,
etc. so it's probably a good idea to trim these as well...
for some reason, the Norne deck included whitespace for some control
modes of some wells which lead to an exception. Since Eclipse seems to
eat this, and Eclipse is correct by defintion, let's adapt our
digestion system a bit...