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
Keyword WCONHIST always supports GRAT control mode, even when
defaulted. The default value (zero) might not be very useful in a
simulation case but it's supported nonetheless.
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.
it turns out that boost::regex does not work for the libstdc++ debug
mode. This patch should fix this for sufficiently new compilers.
Note that this requires the FindCXX11Features.cmake tests pulled in
from opm-core and an additional compiler flag...
Parser::hasKeyword() was called with deckNames but looked up the map
for internal names. This patch renames the method to hasDeckName(),
renames Parser::getKeyword() to Parser::getKeywordFromDeckName() and
adapts/extends the tests.
the RE used is specified via the "deck_name_regex" in the JSON file of
the respective keyword. A deck name is assumed to match a given parser
internal keyword if the deck name is valid and if it is either in the
list specified by the "deck_names" entry or if it matches the regular
expression.
This functionality is useful to implement the well probes for the
tracers as well as replacing the current "wild card keyword"
implementation which only allows a star as a suffix.
Whoever came up with that keyword deserves a spanking because its
semantics are adapting thickness of the grid layers using the rock
properties without modifying the grid (and thus the output is not
showing what is actually used). As I understood that whole affair,
this is also done incorrectly, because the flow is not distorted in
depth direction but this the permeability should be divided by the NTG
values as the fluids seep through the thinner layers more quickly...
Anyway, we have to implement it, so here we go.
