generally, this is a bad idea because GCC is very good at determining
which optimizations should be enabled or not and also, this may
interfere with some compilers. (e.g., it produces a warning on icc)
It turned out that applying the well part of the full matrix has to be
done after the application of the non-well interactions. Otherwise we
screw up the ordering so much that convergence suffers a lot.
Kudos got Atgeirr for inspiration based on his testing.
for example, distr = 0 1 0, for rate control, F = 1 0 0, we will get a
zero F_target, then it is wrong to do the division with F_target.
It is okay when target = 0. When target != 0, the result is already very
wrong. Non-linear iteration can send us anywhere, not sure the best
solution for this kind of strange situation.
It queries the Well whether the jacobian also contains well contributions.
If not then it applies them in the operator in addition. Thus the
well knows whether that is needed or not.
Clearing the auxiliary modules will result in the sparsity pattern being
recomputed. Previously we did this before each nonlinear solve. But for the
master branch the sparsity pattern was only computed once for the whole
simulation.
To get the same behaviour (one sparsity pattern computation) we change the
auxiliary module to include all well perforations that might become active
during the simulation and do this once up front of a simulator run.
Please note that the new matrix entries might also improve convergence for
the ILU if the well is not active.
Previously, we did this during assemble. Unfortunately, this resulted
in the sparsity pattern being recomputed every time instead of just
once for a non-linear solve.
This is only done upon request and uses the auxiliary module approach
provided by ewoms.
In the case of adding the influences we do not execute applyWellModelScaleAdd
or applyWellModel in the operator
simulator
1) Don't depend on legacy code for communicating the data::wells
2) Bugfix. Store globalIdx instead localIdx in data::wells::complitions
3) Move ThreadHandle to ebos
Currently we run into issues with the parallel AMG if
redistribution happened on the coarsest level. That is
not detected by AMG and it will construct smoothers on
all processors present before the redistribution. Some of
them will get OwnerOverlapCommunication objects that have
an invalid MPI communicator in them (MPI_COMM_NULL) and an
MPI_ERROR will be raised as we communicate in the constructor.
With this patch we detect this situaton and set the pointer to
OwnerOverlapCommunication to null to prevent communication. A
sanity check that the matrix has zero rows has been added.
