while a lot of new stuff have not entered, since many of the essential
parts are in different files now. Rebasing will not incoporate the new
stuff automatically.
the involvement of the group control in updateWellControls() makes the
solution of well equations for each well individually more troublesome.
As a result, we will still makes the solveWellEq in all the wells level.
They should only be used to change the order related to the reservoir
variables, so they should be same for all the well models and should be
put in the WelInterface.
It does not compile. Now it is pretty clear that anything related to
Evalulation should go to each individual well model (StandardWell or MS
well ) and not stay with the Wells.
The specialization is added in the ISTLSolver, not in fmatrix.h in dune-
common since 1) we need it now 2) the special treatment of singular and
near singular matrices may be specifiy to the solvent model.
1) Use the solution variable directly in RelativeChange(...)
2) Add a method in the RateConverter that takes the simulator instead of the state.
3) Pass the reservoir pressure directly to the well initialization.
4) Move convertInput(...) to SimulatorFullyImplicitBlackoilEbos.hpp.
This code is only used to convert the initial reservoir state.
5) Modify updateState(...). The solution variable is updated directly and adaptPrimaryVariable(...)
from ewoms is used to switch primary variables. An epsilon is passed to adaptPrimaryVarible(...) after a switch
of primary variables to make it harder to immediately switch back.
The following code used by flow_ebos still uses the reservoirState
1) the initialization
2) restart
3) output of the initial state
4) the step methods in AdaptiveTimeStepping and NonlinearSolver.
The reservoirState is not used by this methods, so after the initial step, an empty reservoirState is passed around in the code.
We do this by switching to output the global index of the cells.
In a first step the problematic cell indices are gather on process 0.
Then they are logged there.
This should prevent spurious ouput at the end of PRT and DEBUG files after the
simulation time is printed. This happened previously for some parallel
runs of model 2. Unfortunately, it seems these problems do not appear any
more for the current master. At least I could not reproduce them.
As implemented with a relative limit, even with 1e9 default limit it
would still be impossible to get away from a zero value. It is
possible that the limits may return later, implemented in a less
buggy way, however for now they do not seem necessary.
