Fixes
```
In file included from opm-simulators/opm/simulators/flow/BlackoilModelEbos.hpp:53,
from opm-simulators/opm/simulators/flow/SimulatorFullyImplicitBlackoilEbos.hpp:26,
from opm-simulators/flow/flow_ebos_gaswater.cpp:28:
opm-simulators/opm/simulators/linalg/ISTLSolverEbos.hpp: In member function ‘bool Opm::ISTLSolverEbos<TypeTag>::solve(Opm::ISTLSolverEbos<TypeTag>::Vector&)’:
opm-simulators/opm/simulators/linalg/ISTLSolverEbos.hpp:265:56: error: incomplete type ‘Opm::WellContributions’ used in nested name specifier
auto wellContribs = WellContributions::create(accelerator_mode, useWellConn_);
^~~~~~
```
split in API specific classes for Cuda/OpenCL
this to
1) it's cleaner
2) it avoids pulling in openCL code in cuda classes which leads
to clashes between nvidia headers and opencl.hpp
there is still too much API specific things in interface between the
bda components to work through a virtual interface so we still have to cast
to the relevant implementation in various places.
OpenCL header was included and OpenclKernels used unconditionally
in WellContributions.cpp. As this file is compiled if CUDA is found,
too it lead to undefined references for e.g. cl::CommandQueue if
opencl headers were there and compile error if not.
annoyingly, dune has a casting operator for mpicollectivecommunication
-> MPIComm but for some reason does not have a casting operator for
the dummy collectivecommunication -> No_Comm
Removed message in amgclbackend was:
warning: catching polymorphic type ‘class
boost::property_tree::json_parser::json_parser_error’ by value
[-Wcatch-value=]
The reduction rate is computed differently for cases without wells under GRUP
For a well to check whether to switch to GRUP it needed to use the reduction rate
that would have been computed if this particular well was under GRUP control
and thus recompute the reduction rate without entering the no-grup path
This commit extends the guide rate reporting to always extracting
and reporting pertinent production guide rates at the well level
(i.e., WxPGR) if at least one of the groups in the well's upline has
an entry in GCONPROD. This is for increased compatibility with
ECLIPSE.
This commit uses the new GroupTreeWalker helper class to ensure that
we always extract and report pertinent injection guide rates at the
well level (i.e., WxIGR) if at least one of the groups in the well's
upline has an entry for the corresponding phase in GCONINJE. This
is for increased compatibility with ECLIPSE.
Prior to this change we would report zero-valued WWIGR vectors on a
real field case which made analysing simulation results needlessly
difficult.
This commit extracts a helper class, GroupTreeWalker, from the
current implementation of 'calculateAllGroupGuiderates()'. This is
in preparation of adding a similar approach to extracting WxIGR for
all wells for which at least one group in the upline has an entry in
GCONINJE.
The user can add visitor operations for wells and groups, typically
with side effects, and then choose whether to run a pre-order walk
(visit groups before their children) or a post-order walk (visit
children-i.e., wells, before their parents).
The class ISTLSolverEbos has all features of the removed class, and
is not much more complex. The flow_blackoil_dunecpr is the only
program using it, and is redundant.
This guarantees, under the assumption that the group tree does not
have cycles, that we do not accumulate group-level guide rate values
until all of its children are fully evaluated. We use an iterative
depth-first post-order tree traversal with an explicit stack instead
of a recursive implementation.
The previous implementation, which tried to do the same kind of
child-to-parent accumulation, might visit a parent group multiple
times which in turn might lead to losing updates. This is a more
formalised approach to the value accumulation than was originally
employed.
We still request Standard version 1.2 only.
We need to use KernelFunctor instead of make_kernel.
In addition cl::Sources now works on std::string and
does not support std::pair<const char*, in> anymore.
With dune-fem the type of the grid view is
Dune::Fem::AdaptiveLeafGridPart and not the LeafGridView
of the grid. The old approach therefore did not compile
as we passed the wrong view.
In some models there will be only a few cells with rather high pore volume representing the numerical aquifer. Including them (as non-violated cells) in the ratio will make the ratio lower than without the aquifer there and might lead to accepting vectors as converged when they should not.
This is needed for distributed wells to save most of the code
from checking whether a perforation is in the interior.
We add new methods compressedIndexForInterior that return -1
for non-interior cells and use that for the wells. This restores
the old behaviour before 1cfe3e0aad
We used to tie reporting these quantities to whether or not a group
had any guide rates for production (GuideRate::has()), but this is
clearly insufficient for injection guide rates.
This commit adds an overload set named
loadRestartGuideRates
which, collectively, initialises the contained GuideRate object
using guide rate values from the restart file. This is necessary,
but not quite sufficient, to restart models in prediction mode with
group-level constraints.
Mostly for readability in preparation of initialising the guide rate
object with values from the restart file. The new stages, each with
its own 'loadRestart*Data()' member function are
- Connection
- Segment
- Well
- Group
While here, also switch to using std::any_of() in place of a raw
loop.
The output layer expects its input values to be strictly SI, but we
know that the GuideRate container's values are in output units.
Forgotten in PR #3467 (commit 517db198f8).
This commit moves the bodies of the various 'dynamicDispatch_<>()'
cases out to separate helper functions. Not only does this reduce
the number of nested conditionals, it also helps reasoning about
each case in isolation and aids future maintenance.
As multisegment wells may throw in applyUMFPack this is now needed and
the exception needs to communicated to all processes. We do this in
the linearize method of the well model.
Before this change this is what could happen:
- The process with the exception would have chopped the time step
- The others would have successfully setup the systems and entered the
linear solve
This poduced a deadlock. One processes was waiting in
OPM_END_PARALLEL_TRY during the setup of the shorter time step and in
collective communication during the setup of the linear solver for the
unchopped time step.
