Previously the control mode was initialized to ORAT; this was later set
to the correct value when parsing the relevant keywords - but in the
case of a SHUT well the control mode was not updated, and we were left
with a well under ORAT control.
I know it was only added recently, but all of the "setInDeck()" calls
can now be substituted by a combination of item->size() and
item->defaultApplied(index)...
i.e. remove the defaultSet() method and its friends. this is required
to be able to specify defaults in DATA items like grid properties or
saturation tables. e.g.
SGL
10*0.1 10* 10*0.2 /
would not be possible without this. If no meaningful default for an
item is defined, float and double items get NaN, int items get -1 and
string ones get an empty string. The hope is that if these values get
used in the simulation, they will make the result obviously
incorrect. (Whether a data point of an item was defaulted can be
queried using item->defaultApplied(index).)
also, this renames DeckItem::setInDeck() to DeckItem::wasSetInDeck()
because the former method can easily be confused with a setter method
(which it is not, it is a 'getter').
note that there is a small semantical difference now: the old
signatures specified the status of the whole *item* while the new
variants are specific for a single *data point* of an item. Though at
this point the index passed to the methods is still disregarded..
The data values in a deck item can be in three different states, given
by the DeckValue enum in DeckItem.hpp. The three values are:
SET_IN_DECK : The value has been set explictly in the deck.
DEFAULT : The value was not present in the input deck, but a default
value has been supplied in the configuration and that value
has been set.
NOT_SET : No value has been set for this item; it was not explicitly
set in the deck and also not included in the configuration.
If you ask for DeckItem->value which is in state NOT_SET you will get an
exception. The method setInDeck() can be used to check if a value has
been set explicitly in the deck; the method defaultApplied() will check
if a default value has been applied.
Observe that the system for handling defaults is not really well suited
for multi valued data items, as it is only a scalar state variable. In
the case of multi valued data items both defaultApplied() and
setInDeck() might return true.
If a well is available for group control, we should add that control
mode to its Injection or ProductionProperties before assigning a new
current (active) control mode to the well ('.controlMode').
Suggested by: [at] joakim-hove.
This commit splits the creation of WellProductionProperties objects,
and especially the ad-hoc helper functions historyProperties()
and predictionProperties() out to a separate module,
WellProductionProperties.[hc]pp. Creating the properties object
from a DeckRecordConstPtr is deferred to two named constructors,
WellProductionProperties::history() and
WellProductionProperties::prediction()
that, respectively, assume the roles of historyProperties() and
predictionProperties(). Reimplement handleWCONProducer() in terms
of these named constructors and remove the producerProperties()
helper whose task, inspecting the status and retrieving/setting the
CMODE if not SHUT, can be assumed by handleWCONProducer().
Add a simple test module, WellPropertiesTest.cpp, to enforce the
rather peculiar semantics of the WCONHIST keyword. Control modes
{O,W,G}RAT, LRAT, and RESV are *always* (unconditionally) supported
in WCONHIST but there is no control mode switching. The latter is
deferred to client code, depending on the '.predictionMode' flag.
Suggested by: [at] joakim-hove
This fixes a programming error introduced in the refactoring of
Schedule::handleWCONProducer() (commit 3889e92). When there is a BHP
limit in WCONHIST, we obviously need the value specified in the input
deck. The refactoring led to the limit being extracted only in the
prediction mode.
Pointy hat: [at] bska
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.
