Loading summary vector from restart simulation with loadBaseRunData = true and selected summary vector not present in baserun.
Common use case where a new vector added in the restart run.
The ESMRY file can be updated with more time step data in the time span between opening an ESMRY file
and loading actual summary data from the file. This can happen if the ESMRY is generated by an active
run. Length of summary vectors extracted will be equal to number of time steps on disk when the file was
first opened (with the constructor).
We effectively ignore JFUNC data unless end-point scaling is
activated through the ENDSCALE keyword in the RUNSPEC section.
Alert the user to this fact by terminating the simulation run if the
case uses JFUNC without ENDSCALE present in RUNSPEC. In this case,
issue a diagnostic message of the form
Error: Unrecoverable errors while loading input: Problem with keyword JFUNC
In CASE.DATA line 125
Incompatible keyword combination: JFUNC declared, but ENDSCALE is missing.
The current Network::Balance class applies default values a little
too eagerly and this leads to problems for restarted simulation. We
must take care to preserve the "did this item have a value" state
also in the restart file lest interactions with TUNING be lost
there.
To this end, make the minimum timestep size for network balancing be
an std::optional<> and use std::nullopt to represent "no value set"
in the input file. While here, also preserve negative balancing
intervals exactly instead of replacing these values by zero.
In particular, add more unit testing and give names to a number of
index constants.
Thanks to [at]blattms for reviewing the initial version of this
patch.
Instead, just declare that all non-FIELD groups are subject to
higher-level control of the water injection.
This hack is needed for compatibility on a real field case. We must
revisit this at a later point.
If a simulation model explicitly assigns a target or limit of 0.0,
then we must honour that value in the restart file. Use a more
complete condition to detect whether or not group level targets or
limits are defaulted in GCONPROD and/or GCONINJE.
In particular, add entries from WECON, WGRUPCON and, WVFPEXP and fix
an incorrect item attribution for the WTEST 'reason' parameter.
Thanks to [at]tskille for invaluable assistance in identify these
items.
This commit outputs the various BxIP* summary output values such as
BOIP (block-level oil-in-place) and BGIPL (block-level gas-in-place
in liquid phase). While here, also add support for outputting the
block-level dissolved gas-oil-ratio (BRS) and vaporised
oil-gas-ratio (BRV).
Adds a method get_injection_properties() to the Python interface to
Opm::Schedule. This method can be used to get information about
Well::WellInjectionProperties for a given report step.
In order to avoid code duplication between opm-simulators and opm-common,
logic in CMakeLists.txt was refactored out into
cmake/Modules/PyInstallPrefix.cmake
This commit introduces a new overload of the updateUDQActive member
function of the WellInjectionProperties and WellProductionProperties
classes. The new overload is specifically targeted at accounting
for any active UDAs in WELTARG records. It is possible to have
"regular" UDAs introduced in WCONPROD/WCONINJE and also a separate
set of UDAs attributed to WELTARG at the same time so we need to be
able to distinguish the two cases.
Call the new overload from the WELTARG keyword handler.
This replaces the cost of maintaining sets of switch/case statements
with some additional runtime cost of looking up the corresponding
keyword in a std::map<>, but these functions are not called in inner
loops so the extra cost is justified.
This commit extends the set of supported UDQ enumators to include
those of the WELTARG keyword. This is in preparation of adding
restart file support for such cases.
We usually list all libraries that might be needed for linking in the
CMake package configuration files. This is needed when building static
libraries as we do not yet use CMake targets (which would allow to
list them differently). As we are doing this unconditionally and
also including the ones listed in modules that we depend on, changing
a library (e.g. moving from Python 3.9 to 3.10) requires a complete
rebuild of all modules to get rid of the stale dependency on
libpython3.9.
At least when building shared libraries listing the dependencies is
not needed and this patch simply removes all shared libraries form the
list in the CMake package configuration file. Thus we only need to
recompile the modules that have direct dependency on a stale library.
We now print
"Keyword category 'Region' (e.g., summary keywords RPR) not supported
by ACTIONX."
instead of
"make_default_nodes does not yet support: RPR"
Adds get_production_properties() to the python interface to Schedule.
This method can be used to get information about
Well::WellProductionProperties for a given report step
