These codes are reimplemented in the ebos simulator and should
be reused, instead. This commit factilitates this and starts
reusing the logging setup code in ebos. Hence reduces code duplication.
Before this we had a set of external*_ variabales (unique_ptrs), a set of
internal_*_ variables (unique_ptrs) and another set of pointers that
point to the pointers actually used. That seemed a bit much. With this
commit skip the internal variables and use unique_ptrs for all
others. In the constructor either the external*_ gets moved or the
objects are directly created as unique_ptrs.
We resort to consistently use unique_ptrs in EclBaseVanguard for
the data read from ECL files or set externally. This means that
during the simulation EclBaseVanguard owns this data and not Main
or the ebos setup functions. This ownership transfer becomes
transparent due to std::move.
This came up when trying to fix the parallel runs of ebos and during
that removing some code duplication.
That was removed before in lieu of the fraction of cells that
violate CNV.
This change should make the results as before unless somebody changes
maxStrictIter or RelaxedMaxPvFraction
We hold a shared pointer to the umpfack solver that gets reset
whenever the matrix is changed. When applying the decomposition
we will be recomputed if the solver pointer is null.
Previously we used relaxed tolerance once a certain number of Newton
steps was exceeded. Now we check for all cells violating CNV locally
and if their pore volume is less than a certaun fraction (default 3%)
we use the relaxed tolerance (default: 1e9)
Original idea originated from Norce.
With multisegment wells we allocate WellContributions::hx and hy with
`CudaMallocHost`. Yet we tried to deallocate them with
`delete[]`. This caused segementation faults e.g. for
model1/MSW_MODEL_1. Now we use `CudaFreeHost` for freeing if we used
CUDA.
Closes#2719
Up to now We always assumed that cardDims[i]>1 holds. which it does for most
of the cases. But when e.g. simulating a vertical stack of 5 cells
flow would report the transmissibilities in the Z direction in TRANX
and output TRANZ as zero. Similar problems should be there for 2D grids.
With this commit we actually check whether there can be neighbours in
the X and Z direction to prevent this behavior.
Previously only the master process was aware of the error and flow did
deadlock in parallel runs if there were parser errors
encountered. With this commit all processes are made aware of the
problem and flow aborts with an error code.
boost::property_try::get without a defaults throws an exception. As
result the nonlinear solver and timestepper think that there is a
problem with solving and chop the timnestep until they give up.
This commit fixes this by using a default and falling back to the
command line specified value for the default solvers.
For some of the scaling approaches the wrong matrix (dereferenced
nullptr) would have been used which should have resulted segmentation
faults. With this commit we add a method getMatrix() that returns the
correct one and use that for scaling.
Somehow that approach went missing in action and it is always the
same as the assembled matrix. Hence no need for that member anymore
and we remove it to prevent confusion.
In this case matrix_ is a nullptr and noGhostMat_ is the optimized
matrix to use. Before this commit we experienced a segmentation fault
as the nullptr was dereferenced and passed to the solver.
Previously all the ranks print linear solver statistics in verbose
mode which cluttered the output in parallel runs. Now only rank 0
will print like it should be.
Previously, one had to call a seperate binary called
flow_blackoil_dunecpr. Unforntunately, that was only built if users
requested that the tests (`-DBUILD_TESTING=ON`) and the flow
variants (`-DBUILD_FLOW_VARIANTS=ON`) should be built. In addition
it would use a slightly different nonlinear solver implementation.
With this commit flow can be asked to either use
CPR (`--use-cpr=true --matrix-add-well-contributions=true`) or to use
the flexible solvers bx setting the `--linear-solver-configuration`
option. In all other cases the usual solver implementations are still
used.
Note that the flexible solvers still need
`--matrix-add-well-contributions=true` and hence cannot cope with
multi-segment wells.
The default was 0 for flow and 3 for flow_blackoil_dunecpr. Now we
always use 3. This is safe as it will not be used for any other
solvers than the flexible ones.
as there already is a specialization for an arbitrary Block
and that one leads to compile errors because we redefine it
in OPM (and miss some other specializations for Opm:MatrixBlock,
e.g. isNumber).
At least on Debian 10 the standard c++ compiler is g++-8,
but CUDA only supports g++-7 and our test for CUDA in cmake
did send an error in that case/combination which is quite
annoying.
The reason was that check_language(CUDA) did not honor
the CMAKE_CUDA_FLAGS variable and always used the default g++7,
but enable_language(CUDA) did honor it. As we do set the underlying
host compiler the fromer reported that CUDA is available while the
latter marked the CUDA compiler as broken.
With this commit we work around this by setting the environment
variable ENV{CUDAHOSTCXX} which nvcc will use. Hence now we only try
to enable CUDA if it is compatible with the C++ compiler
Markus Blatt