Bård spotet a bug after PR #805 was merged. Indead returning
-numeric_limits<type>::min() does not make sense for integral
values. This commit resorts to returning numeric_limits<type>::min().
Kudos to Bård for his attention.
This behaviour does not work for computing a global inner product.
Therfore this commit introduces a new function to the functor that
returns an appropriate initial value.
Previously we hardcoded float. Now we use the result_type of
the binary_function without any qualifiers. With any cv or reference
qualifiers std::numeric_limits uses a default implementation which
produces nonesense (e.g. numeric_limits<const int>::max() returns 0).
Previously, we used the setStatus method to set wells that do not
exist on the local grid to SHUT. Or at least this is what I thought
that ```well.setStatus(timestep, SHUT)```. Unfortunately, my
assumption was wrong. This was revealed while testing a parallel run
with SPE9 that threw an expeption about "Elements must be added in
weakly increasing order" in Opm::DynamicState::add(int, T). Seems like
the method name is a bit misleading.
As it turns out the WellManager has its own complete list of active
wells (shut wells are simply left out). Therefore we can use this
behaviour to our advantage: With this commit we not only exclude shut
wells from the list, but also the ones that do not exist on the local
grid. We even get rid of an ugly const_cast.
Currently, I have running a parallel SPE9 test that has not yet
aborted.
In this case the parallel index set might represent N entries (this might be the number of
cells of grid). Nevertheless, there several (n) equations/unknowns attached to each index.
In this case we construct a larger index set representing N*n unknows, where each unknown
is attached to an index.
This change only affects parallel runs.
In a parallel run each process only knows a part of the grid. Nevertheless
it does hold the complete well information. To resolve this the WellsManager
must be able to handle this case.
With this commit its constructor gets a flag indicating whether this is
a parallel run. If it is, then it does not throw if a well has cells that
are not present on the local part of the grid. Nevertheless it will check
that either all or none of the cells of a well are stored in the local part
of the grid.
Wells with no perforated cells on the local will still be present but set to SHUT.
This commit adds a verbose flag to the constructor of
SimulatorReport to allow for deactivating any
output to std:cout. This is handy for parallel runs where we only
want to print statistics on one process.
This commit updates the source code comment about using operator[] to
initialize the unordered map. Thanks to Bard's persistence we found
out that the cause is not the construction of the key value of type
std::string from const char* but the mapped type being a (mutable)
char* (due to C?).
This completes the PR #784.
g++-4.4 has problems converting const char* to char*
which it thinks is needed for constructing std::string.
Using operator[] circumvents this problem.
The compiler error fixed here was:
/usr/include/c++/4.4/bits/stl_pair.h: In constructor ‘std::pair<_T1, _T2>::pair(std::pair<_U1, _U2>&&) [with _U1 = const char*, _U2 = const char*, _T1 = const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, _T2 = char*]’:
/home/mblatt/src/dune/opm/opm-core/opm/core/linalg/LinearSolverPetsc.cpp:40: instantiated from here
/usr/include/c++/4.4/bits/stl_pair.h:107: error: invalid conversion from ‘const char*’ to ‘char*’
make[2]: *** [CMakeFiles/opmcore.dir/opm/core/linalg/LinearSolverPetsc.cpp.o] Fehler 1
Currently the keyword EQUIL is not supported by the fully
implicit blackoil simulator when using CpGrid. This
commit is a first step towards this as it makes the
implementation of initStateEquil generic.
Well, you never know. There are containers that use a signed integer
for storing its size. This results in a warning about comparing signed with
unsigned integers. This commit prevents this by explicitly casting the size
to std::size_t.
Due to the size of the overlap layer and the discretization scheme
the rhs might not contain correct values for overlap cells. This
commit makes sure they are correct by an additional communication step.
One would think that such an assumption is safe in any case,
wouldn't one? But foen Eigen'S container this does not hold.
They do not provide STL compliant iterators, and access to them.
With this patch make the even stricter assumption that the containers
are random access and use operator[] instead of iterators.
As there are no functors for computing the minimum and maximum,
we convert the std::max and std::min function pointers to
functors (which is not really nice.) Previously we were somehow
tricked into using std::greater and std::less, which of course do
return true or false and not what we need. Additionally, do more
excessive testing with different ranges.
We need to compute quite a few global reductions in the
Newton method of opm-autodiff. This commit adds the functionality
to compute several reductions combined using only one global
communication. Compiles and test succeeds with one or more process.
There were to identical if statements and the second one was followed
by an else branch. While in this case (if statement just throws) it is not
a bug, this commit cleans up one of the if statements.
gcc warned about the following
/home/mblatt/src/dune/opm/opm-core/opm/core/wells/WellsManager.cpp: In function ‘std::array<long unsigned int, 3ul> WellsManagerDetail::directionIndices(Opm::CompletionDirection::DirectionEnum)’:
/home/mblatt/src/dune/opm/opm-core/opm/core/wells/WellsManager.cpp:191: warning: control reaches end of non-void function
To calm it I introduced a throw clause after the switch statements. Thus adding a new
enum value will raise a warning on smart compilers, hopefully.
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.
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.
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 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.
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.
My last merge broke compilation of opm-autodiff, as this new function
still relied on the old behaviour (the one taking a grid instead of
the data directly). This patch moved initStateFromDeck to the new behaviour.
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
This patch refactors (hopefully) all parts of opm-core that are needed
by the fully implicite black oil solver in opm-autodiff and that inherently
relied on UnstructuredGrid.
We added a new simple grid interface consisting out of free functions
that will allow us to use CpGrid without copying it to an UnstructuredGrid
by the means of the GridAdapter. Using this interface we have add methods that
allow specifying the grid information (global_cell, cartdims, etc.) wherever
possible to prevent introducing grid parameters for the type of the grid.
Unfortunately this was not possible everywhere.
After this patch one can set the prolongation factor for all
AMG calls and the number of smoothing steps for all except
of FastAMG that currently only supports on step.
Markus Blatt