Current version executes reordered solve once for each tracer. The benefit
is a simpler code and the ability to use MDU with tracers. The cost is
potentially higher runtime, compared to doing a single sweep for all
tracers (and tof).
When this boolean parameter is true (the default), tracer solutions
will be normalized so that the tracer averages will sum to one in each cell.
This behaviour is the same as before, the change is that it can now be
turned off.
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.
The queried keywords are unknown to the parser and after manual
inspection also to the Eclipse RM. There might be wrong keywords some
left, but these were to ones needed to get SPE9 started using
sim_fibo_ad...
the largest change is that all classes below opm/core/props/pvt take
the PVT region index as an argument, the higher-level ones (i.e.,
BlackoilProps*) take cell indices.
Previous fix was wrong because it called getKeyword() outside the
hasKeyword() check. Current version (like original code) uses the
short-circuiting behaviour of && to ensure this.
that one was completely unused and the "grdecl" struct defined in
there collided name-wise with the one defined in "GridManager.hpp".
trying to link code which used the version of the grdecl.h header with
code that used the one from GridManager.hpp would have resulted in _a
lot_ hilarity...
This was missing in commit 4c2120c and produced some build failures
that were hard to analyse. I'm not convinced that the underlying
problem is solved, but this does at least restore the build.
The functions
multiplyFaceNormalWithArea
maybeFreeFaceNormal
operating on Dune::CpGrids must not be implemented unless they are
actually used. Otherwise we get link failures if (e.g.,)
opm-autodiff is being built without CpGrid support.
Hide the definitions behind "#ifdef HAVE_DUNE_CORNERPOINT".
In this pull requested we resorted to storing the data items (e.g. cart_dims, global_cell,
etc.) instead of the UnstructuredGrid. Unfortunately, this is a change of the lifetime
guarantees: Previously, a shared_ptr to the Unstructuredgrid was stored. Thus the data members
were available for the lifetime of the EclipseWriter. With the previous changes the grid could
actually have been destroyed before the writer.
Therefore we no store a shared_ptr to the UnstructuredGrid again (in addition to the datamembers).
Thus at least for UnstructuredGrid the old guarantees still hold.
The class OwnerOverlapCopyCommunication is not defined unless MPI is
avilable. Therefore, we cannot reference the type unless we know
that MPI is available in the current translation unit.
Removed conflicts in
opm/core/wells/WellsManager.cpp
that were due to the change
```diff
- pd.well_index = WellsManagerDetail::computeWellIndex(radius, cubical, cell_perm, completion->getDiameter());
+ pd.well_index = WellsManagerDetail::computeWellIndex(radius, cubical, cell_perm, completion->getSkinFactor());
```
in WellsManager::createWellsFromSpecs which moved from WellsManager.cpp to WellsManager_impl.hpp file in a previous commit.
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...
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...
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.
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 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...
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.
that is one of the more subtle differences between the old and the
new parsers. now, valgrind does not seem to complain anymore, so everything
should be All Right (TM) ;)
- the output=true|false parameter gets respected now
- if output is "true", it is checked that the value of the
"output_dir" parameter is a directory (although I did not find an
easy way to check whether it is writable short of writing a file to
it.)
- the "output_interval" parameter gets respected as well
- the index of a written timestep is now independent of the time step
index of the simulation: the initial solution is always 0, the first
result written to disk is always 1 and so on... (i.e., it does not
matter anymore how many steps the simulator needed between two writes)
these changes have been proposed by @atgeirr. Thanks!
