- satfuncStandard: Unscaled curves, using standard version of the
Gwseg model.
- satfuncEPSBase: Unscaled curves, but using the EPS version of
the Gwseg model. There are some differences between this and the
standard version of Gwseg for derivatives at critical saturations.
The scheme for calculating the derivatives should be discussed.
(Will file a separate issue on this.)
- satfuncEPS_A: Scaled curves. Scaling parameters specified via
SWL family.
- satfuncEPS_B: Scaled curves. Scaling parameters identical to _A
but this time specified via the ENPTVD table. Test currently
suspended due problems with eclipse-state.
- satfuncEPS_C: Scaled curves. Scaling parameters identical to _A
but this time specified via Norne-like syntax (EQUALS, COPY etc.).
Shut wells are not added to the well list and thus not considered in the
simulator.
The shut well test in test_wellsmanager is modified to assert this
behaviour.
BUG: This change provokes an assert in the EclipeWriter as number of
wells in wellstate is different from number of wells in the schedule.
this is necessary because tables now must be queried using
EclipseState instead of directly. This implies that EclipseState can
be instantiated in the first place...
TODO (?): allow EclipseState instatiation for decks without a grid.
New function well_controls_clone(), implemented in terms of the
public API only, mirrors the objective of function clone_wells(),
only for well control sets. Add a basic test to demonstrate the
function too.
this basically means using Opm::EclipseState instead of the raw deck
for these keywords.
with this, property modifiers like ADD, MULT, COPY and friends are
supported for at least the PERM* keywords. If additional keywords are
required these can be added relatively easily as well.
no ctest regressions have been observed with this patch on my machine.
To support this the solveSystem methods of the LinearSolverInterface gets
an optional additional template parameter of type boost::any. It can hold any
copy constructable object. In our case it is used to pass the information about
the parallelization into the solvers of dune-istl without the compiler needing to know
their type. Inside of LinearSolverIstl::solveSystem we check whether the type stored inside of
boost::any is the new ParallelIstlInformation. If this is the case we extract the information
and use the parallel solvers if available, otherwise we solve serial/sequential.
The new ParallelIstlInformation is needed as the OwnerOverlapCopyCommunication is not copy
constructable. This is indeed a design flaw that should and will fixed upstream, but for the
time being we need ParallelIstlInformation to transfer the ParallelIndexSet and RemoteIndices
objects.
This test sets up a simple laplace problem and solves it with the available
solvers. It assume that either dune-istl or UMFPack is present, which is
assume to be safe.
