matrix_add_well_contributions=true will add to both the preconditioner matrix
and the matrix of the linear operator. preconditioner_add_well_contributions=true
will only add the contributions to the preconditioner matrix.
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
Calling wells()->number_of_wells on nullptr causes segmentation fault. This
occurs when running a deck without wells. Allowing WellsManager::init to
continue for decks without wells enables the well struct to be set.
Authored by Sveinung Rundhovde & Lars Petter Hauge
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
