This was moved to assemble() some time ago but according to my logic it
belongs in the solve method since this is only a trick to solve the well
equations simultaneously with the reservoir equations.
A buggy side effect of the currect implementation was that the well
residual was considered in the convergence test. I.e. this move changes
the convergence behaviour of the simulator.
Updating the solution variable in updateState() was conceptually wrong
and lead to incorrect results if the linear solver failed before the
updateState() method was called. i.e. in the first iteration.
The wellModel is now persistent over the time steps,
with an update method called every reportStep/episode.
This allows the following simplifications:
1. move the wellState to the WellModel
2. add a ref to the ebosSimulator to the wellModel
3. clean up the parameters passed to the wellModel methods
4. move RESV handling to the WellModel and the rateConverter
5. move the econLimit update to the WellModel
the ThreadManager from ebos was not called which resulted in some
havoc when attempting multi-threaded runs.
v2: use opm_get_max_threads() directly. thanks to [at]akva2 for the heads-up.
it seems like most build systems pass a -DHAVE_CONFIG_H flag to the
compiler which still causes `#if HAVE_CONFIG_H` to be false while it
clearly is supposed to be triggered.
That said, I do not really see a good reason why the inclusion of the
`config.h` file should be guarded in the first place: the file is
guaranteed to always available by proper build systems, and if it was
not included the build either breaks at the linking stage or -- at the
very least -- the runtime behavior of the resulting libraries will be
very awkward.
3x3 matrix block inversion in FieldMatrix is numerically unstable
including version 2.5.0. Therefore the previous if clause was wrong
as it activated the use of FieldMatrix already for 2.5.0 (the version
in Debian stable). With this commit we use MatrixBlock for version 2.5.0.
since I has not figure out a way to detect/catch the singularity of the
matrix with UMFPack, currently, we only check the validity of the
results to make sure inf or nan not enter other part of the simulation.
It can easiliy results in assertion failure, and causes the running to
be terminated. After all, it mostly likely is a numerical issue
generated during the non-linear iteration process.
When there is not ms well involved, all the ms well related is not
initialized. It causes problem when we want to add ms well after some
time of running.
The bug fix the running with model 2.
