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.
this is required for regex-matching keywords. Once GCC 4.9 is the
minimum compiler version to be supported, this can be dropped in favor
of std::regex ...
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.
before this, the variants with the trailing minus were just silently
ignored, and even if they were not, the code generator would have
produced illegal code, because the keyword name is used for a C++
variable there, i.e. the names needed to be valid names in the C++
sense. "Happily", these the former bug canceled the latter, so the
build went through...
now, there is only one internal keyword called "MULT_XYZ" which
matches on all possible variants which are allowed in a deck. The
mechanism used is a deck name list...
These are all keywords which are used by the Norne deck within some
property modifiers plus all variants of these. (sans the variants for
radial grids which are completely pointless IMO.) The chances that
keywords which have not been added yet can also be used are very close
to 100%, though.
Note that the default values for these keywords are currently
incorrect as the Eclipse RM states that the values must be looked up
in their corresponding table if the keyword is left unspecified (see
e.g. the documentation SWU). This probably means that we need to
implement "ghosty" keywords which magically appear if they have not
been explicitly specified or maybe we should only provide them in
EclipseState to be able to do the context dependent table look-up
"vodoo"...
