an empty string is interpreted as "write the output files into the
same directory as the input". this is the current 'flow' default
behavior, plain ebos uses "." as the default location for output,
i.e., the current directory from which the simulator is run from.
this class is only used by the legacy simulators, `flow` uses the
`EclWriter` class provided by eWoms. In turn, this class uses the
new-and-shiny "tasklet" mechanism.
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
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
