This commit adds a very early, alpha-quality implementation of the
"horizontal subdivision" strategy (N < 0) of the EQUIL directive.
This in turn enables more accurate derivations of the initial fluids
in place.
Interactions with SWATINIT are completely untested, and the initial
Rs/Rv derivations in this context are possibly incomplete. More
work is likely needed in this area, but this does at least enable
more widespread testing.
The purpose of this function is to determine the vertical extent of
a set of cells. Counting the number of cells in the region is not
its responsibility.
This commit splits out the per-cell initial state derivation to two
separate helper functions, equilibrateCellCentres() and cellLoop().
The latter manages the per-cell assignments to pertinent data
members and calls an arbitrary "equilbration method" that is
provided as a callback and which calculates per-cell phase
pressures, phase saturations and mixing ratios (Rs/Rv).
In turn, the equilibrateCellCentres() uses the cellLoop() to affect
the existing equilibration procedure within a cell using values at
the depths of the cell centres only.
This commit introduces a new helper class,
Opm::EQUIL::Details::PhaseSaturations<>
that subsumes the responsibility of the existing helper function
Opm::EQUIL::phaseSaturations<>()
and generalises that functionality to arbitrary depth points within
single cells. This is in preparation of adding support for the N<0
case of the initial fluid in place procedure defined in the EQUIL
keyword. The class consumes an already equlibrated pressure table
for the pertinent equilibration region, calculates capillary
pressure values and inverts Pc curves to derive saturation values.
If the capillary pressure curves are constant within a cell, then a
simple depth consideration with respect to the implied sharp phase
interface is used to derive saturation values. We also preserve
existing support for SWATINIT-type initialisation of the water
saturation field.
Switch InitialStateComputer<>::calcPressSatRsRv() over to using the
pressure and saturation helper classes instead of the original
helper functions since this provides additional control. Also
remove those helper functions to reduce risk of confusion over which
method to use. Update the unit tests accordingly.
These unit test were previously disabled. While here, also fix some
'missing declaration' errors by putting the test functions into a
private namespace.
At some point we should rewrite this to use Boost.Test.
This commit is the first step of several that implements ECLIPSE's
"accurate fluid-in-place" model initialization procedure based on
subdividing the vertical range/extent of individual cells. This
first step puts the O/G/W phase-pressure calculation into a helper
class,
Opm::EQUIL::Details::PressureTable<>
through which phase pressure values can be calculated at abritrary
depths rather than just at the cell centre depths. In other words,
this helper class extends and subsumes the responsibilities of the
existing helper functions
Opm::EQUIL::Details::PhasePressure::assign()
Opm::EQUIL::Details::PhasePressure::oil()
Opm::EQUIL::Details::PhasePressure::gas()
Opm::EQUIL::Details::PhasePressure::water()
We still use the same ODE-based evaluation procedure for the phase
pressures and the equilibrateOWG() helper function still computes
the phase pressure values at cell centre depths only.
That, in turn, corresponds to the "N = 0" case (steady state) of the
basic equilibration facility.
The RFTConfig object gained a new data member and constructor
argument, in addition to altering the type of the data member
well_open_rft_name from an unordered_set to an unordered_map.
Update serialization code accordingly.
This commit ensures that the previous solvent restart fix (commit
afba6c8e8, PR #2023) does not attempt to index into the data member
solventSaturation_ unless solvent is activated.
This commit calls the aquifer model's 'initFromRestart' function if
the loadParallelRestart() function happens to return any aquifer
data from the restart file. Such data is currently limited to two
items of information for analytic aquifers (from XAAQ vector), but
future extensions are likely.
This commit adds a new public member function,
EclProblem::mutableAquiferModel()
that returns a read/write reference to the contained EclAquiferModel
object. The immediate use-case is initializing analytic aquifers
from restart data.
This commit adds a new member function,
initFromRestart()
to the EclBaseAquiferModel and the BlackoilAquiferModel. The former
does nothing, the latter calls AquiferInterface::initFromRestart()
on the contained analytic aquifer objects.
This commit adds a new member function,
AquiferInterface::initFromRestart()
that consumes a vector<data::AquiferData> constructed from
information in the restart file's SAAQ and XAAQ vectors. At the
moment, we use the initial aquifer pressure, the total produced
liquid volume and the current aquifer pressure at restart.
We implement the interface's member function in terms of the virtual
function
AquiferInterface::assignRestartData()
that must be overridden in derived classes.
Implement a trivial such function for Carter-Tracy aquifers, and a
function that only stores the current aquifer pressure for the
Fetkovich aquifer model.
Additionally, record whether or not the aquifer object was
initialised from a previous solution. If so, don't reset total
produce liquid volumes or aquifer pressures to their base values
from the model input file.
This commit switches the 'test_ecl_output' unit test to using the
EclIO::ESmry class from OPM-Common. We add simple alternative
implementations of ecl_get_field_var() and ecl_get_general_var() in
terms of ESmry to avoid rewriting the test code itself.
As class ESmry does currently not support reading non-unified
(separate) summary files (.S000n), we temporarily switch the deck to
using unified output.
In particular, the .type() function is renamed to .category(), and
it no longer returns a LibECL type. Similarly, the .num() function
has been renamed to .number().
The output code has an unfriendly error mode in which we
unceremoniously crash--without writing any data--if some declared
array dimensions from RUNSPEC aren't big enough to hold all the
dynamic objects (wells, groups, connections &c).
Verify that the declared dimensions are indeed big enough for the
current simulation run before starting the simulator to ensure that we
don't waste a lot of computational effort if, for instance, the first
output is very close to the end of the simulation.
Bård Skaflestad