When first evaluating ACTIONX the WLISTS might not even exist.
In addition they may be empty.
We support WLIST for the following well keywords in ACTIONX:
COMPDAT, COMPLUMP, WCONINJE, WCONPROD, WECON, WEFAC, WELOPEN, WELPI,
WELSPECS, WELTARG, WGRUPCON, WPIMULT, WSEGVALV, WTEST,
WTMULT, WELSPECS
These keywords that probably allow WLIST, still insist they are never empty:
WELTRAJ, COMPTRAJ, CSKIN, WCONHIST, WCONINJH, WFOAM, WINJMULT,
WINJTEMP, WLIFTOPT, WMICP, WINJCLN, WINJDAM, WINJFCNC, WPMITAB,
WPOLYMER, WSALT, WSEGSICD, WSEGAICD, WSKPTAB, WSOLVENT, WTEMP,
WTRACER, WVFPDP, WVFPEXP, WWPAVE, WPAVEDEP, WRFT, WRFTPLT
These are currently not allowed in ACTIONX.
This way there is no constructor with an output parameter and we
prevent introducing an additional member in ActionX that is only used
in one constructor.
When encountering these (e.g. a number instead of an expression on
the left hand side) the simulator would immediately abort with an
error message like:
```
Error: An error occurred while creating the reservoir schedule
Internal error: Extra unhandled data starting with token[0] = 135
Error: Unrecoverable errors while loading input: Extra unhandled data starting with token[0] = 135
```
(The message above is for the number 135 on the left hand side)
With this change we now use the usual way of handling errors and
warnings in the parser and continue parsing.
The error message for the problem above is now
```
Error: condition of action EX1 has the following error: Left side of comparsion (135) has to be an expression!
Error: Problem with keyword ACTIONX
In model.schedule line 562
condition of action EX1 has the following error: Left side of comparsion (135) has to be an expression!
Error: Unrecoverable errors while loading input: Problem with keyword ACTIONX
In model.schedule line 562
condition of action EX1 has the following error: Left side of comparsion (135) has to be an expression!
This commit adds a new, very specialised, operation to the material
law manager,
void EclMaterialLawManager::applyRestartSwatInit(cell, maxPcow)
This will apply a SWATINIT-like rescaling of the oil/water capillary
pressure curve based on a caller-provided maximum capillary pressure
value. The primary use case is this maximum value being taken from
the PPCW array in a restart file at simulation restart time. We
assign the "maxPcow" member of the associate EpsInfo structure and
reinitialise the EpsPoints structure using this new information.
The latter is needed lest the maxPcnw() member function return
incorrect values in restarted simulations.
This commit enables updating individual well properties for one or
more wells using the WELSPECS keyword. In particular, this revised
logic enables changing the controlling group without affecting any
other well property such as the location of the well head or the
well reference depth.
Defaulted properties do not affect change in Well::update*(). This,
in turn, begets a change to the logic of how we update the reference
depths. Previously, we always interpreted a defaulted reference
depth item as
Compute the reference depth from the location of the well's
reservoir connections
We now alter this interpretation slightly to mean
Don't recompute the reference depth if the input has already
assigned a numerical value for this property
If the input has never assigned an explicit numerical value for the
reference depth, then we continue using the original interpretation
of a defaulted reference depth item--e.g., to update the reference
depth as a result of new reservoir connections.
The simulation can request the original interpretation even after
having assigned a numeric reference depth, by entering a new
WELSPECS keyword specifying a negative value for the the reference
depth item.
To this end, introduce a new data member in the Well class,
bool Well::derive_refdepth_from_conns_
which tracks whether or not the reference depth has been assigned an
explicit numeric value.
As an example, this new WELSPECS behaviour enables using something
like
ACTIONX
A 1 /
WOPR 'P*' < 123.4 /
/
WELSPECS
'?' 'LOWPRESS' /
/
ENDACTIO
as a way to move all wells matching the pattern 'P*', and with a low
oil production rate, to the group 'LOWPRESS'. This could, in turn,
apply a different set of group-level production controls to those
wells.
This commit creates new helper functions
Schedule::welspecsCreateNewWell()
Schedule::welspecsUpdateExistingWells()
which handle the creation of a new well or the property update of
one or more existing wells, respectively, in the context of
processing records in the WELSPECS keyword.
In preparation of making the WELSPECS keyword useful for changing
the controlling group of a collection of wells, we pass a vector of
well names as an argument to the update function. Furthermore, we
construct this vector using normal 'wellNames()' processing which
enables using patterns and well list names such as
* 'P-2'
* 'PROD-*'
* '?'
* '*PROD'
as arguments/well names (item 1).
