because as discussed with Atgeirr, this function should no longer
write the initial solution, it also does no longer need to know the
initial simulator state...
recently UG has become free software (yay!), so we can now support it
with a good conscience. The CMake module is based on the "UseUG.cmake"
module of dune-grid but it is quite a bit simpler and actually
works. (I cannot see how UseUG.cmake can work without ever including
the ug-config*.cmake files...)
the UG source code is available here:
https://github.com/ugfem/ug
this patch gets rid of the old-parser-taking methods of
EclipseWriter. this avoids quite a few consistency issues and also
reduces the amount of duplicate work required.
The simulator object will probably have created a time map anyway to
control the timestepping so this can be reused directly by the output
writer. (If not, it is easy to create one and pass it).
As @bska pointed in my issue #518 this definition was
accidentally removed in commit 20468d1 during a merge of
upstream changes. Therefore I readd it with this patch.
- 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.
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.
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...
