- Saturations, phase pressures, and standard initialsation of RS and RV
now agree to baseline.
- Tables of RS and RV versus vertical depth (kw RSVD RVVD) have been
hardcoded for testing (need new parser) and the calculations agree to
baseline in the gas and oil zones. In the water zone there is some
differences: Our code computes saturated RS and RV using the final
phase pressures (these are modified to be consistent with saturations
and capillary pressures) while the baseline uses unmodified phase pressures.
maybe it is not a bug but a slightly spec. The problem is that GCC 4.4
does not implicitly convert std::shared_ptr<$FOO> to
std::shared_ptr<const $FOO> which caused the recent Jenkins build
errors at Statoil. Note that this problem only occurs with the output
writer in conjunction with the old Eclipse parser, so
OPM/opm-autodiff#105 also makes the problem disappear. The present
patch addresses the root cause, though...
At least for g++-4.4. shared_ptr does not have a constructor
taking an integer and therefore compilation fails. Therefore we
resort statements to construct empty pointers, like
```parser_(0)```
to using the empty constructor:
```parser_()```
This patch closes#533
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 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.
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.
This means that EclipseKeyword now never processes the data it
gets. Instead the data must be explicitly preprocessed by the calling
site using the new auxiliary functions "convertUnit()",
"extractFromStriped()", etc. This approach needs a few additional
temporary copies of the data, but given the facts that readability of
this code is much better using this approach, and that EclipseWriter
is neither a performance- nor a memory critical codepath, I don't care
too much about those temporary arrays...
According to @rolk defines should only be exported in
cmake/Modules/<module>-prereqs.cmake if they are used in the
headers. This is not the case for the dune-istl version macros and
therefore we use opm_need_version_of in the config_hook in the top
level CMakefile with this patch.
Atgeirr Flø Rasmussen
Bård Skaflestad
Tor Harald Sandve
osae
Kai Bao
Markus Blatt
Joakim Hove
Andreas Lauser