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 patch refactors the calls to the dune-istl solvers.
The SeqScalarProduct, and SequentialInformation is now explicitly
constructed and later used to construct the smoothers
generically. Aditionally the linear operator (MatrixAdapter) is
constructed before calling the various solver dependent solve
routines.
While this does not change the behaviour of the code it is a
preparatory step to support parallel solvers. These parallel
solvers only differ in the type of the scalarproduct and
linear operator used from the sequential ones.
This patch refactors the calls to the dune-istl solvers.
The SeqScalarProduct, and SequentialInformation is now explicitly
constructed and later used to construct the smoothers
generically. Aditionally the linear operator (MatrixAdapter) is
constructed before calling the various solver dependent solve
routines.
While this does not change the behaviour of the code it is a
preparatory step to support parallel solvers. These parallel
solvers only differ in the type of the scalarproduct and
linear operator used from the sequential ones.
This fixes further occurences of DUNE_HAS_FASTAMG that were
missed in pull request #530.
Previously we relied on the define DUNE_HAS_FAST_AMG to detect
whether these preconditioners are available. This define is only
available in the 2.2 release with cmake support. Therfore we now
addtionally test whether we are using dune-istl 2.3 or newer.
and throw an exception if "simple" is encountered...
According to Ove, gwseg should be used, because "gwseg is the model
relevant to the norne case - i.e the model eclipse uses.
The fix for the simple model has to wait for a refac of the satfunc
complex."
Previously we relied on the define DUNE_HAS_FAST_AMG to detect
whether these preconditioners are available. This define is only
available in the 2.2 release with cmake support. Therfore we now
addtionally test whether we are using dune-isl 2.3 or newer.
Patch 31c09aed was erroneous as it was trying to assing a
SaturationPropsFromDeck<SatFuncSimpleNonuniform> to a
SaturationPropsFromDeck<SatFuncSimpleUniform> in the constructor
taking the new parser. This patch fixes this.
The mentioned commit was applied before the merge of
opm-parser-integrate and therefore the changes did not carry over
to the code that uses the new parser. This code mimics the
changed behaviour for the new parser.
Closes issue #516
Instead of making well rates zero for wells that are not controlled by
surface volume, we initialize them to a small value with the correct
sign (positive for injectors, negative for producers).
This includes relative permeability and capillary pressure functions.
The default has been to make a monotone spline from the given table
values and use a fine, uniform sampling of that. Now the default
is to use the tables as-is. It is still possible to use the spline
approach. For example in the class BlackoilPropertiesFromDeck one
may pass nonzero values for the 'pvt_tab_size' and 'sat_tab_size'
parameters, corresponding to how fine the spline will be sampled.
