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
Seperating the updateWellStateWithTarget from updateWellControls, will
update the controls when any of the control constraints gets broken.
The reason is that the updated well control can still break some of
other the contstaints. We need to choose one control to make sure all the
constraints are honored.
Using &stdwells.wells() throws an assertion for null pointers
without -DNDEBUG, but was used nevertheless. That prevented running
models without wells.
The wells pointer might be null and we need to access its number of
phases in the constructor to store it. With this commit we prevent that
storage and simply ask the well struct whenever we need the number of
phases. Of course the code using it needs to check that there are wells
but that is done in most parts of the opm-simulators currently
(MultiSegmentWells and Solvent are/might be an exception).
The changes are:
- Make the WellOps struct public (needed by transport solver).
- Make it possible to store and retrieve total reservoir volume
perforation fluxes with getStoredWellPerforationFluxes(), controlled
by a flag set by setStoreWellPerforationFluxesFlag(), defaulting to
false (needed by pressure solver).
As for each well only one process is responsible, the output process
does not see all wells. Ergo some well switching information was never
printed in a parallel run.
Therefore with this commit the well switching
message is printed regardless on which process it appears.
updateWellControls()
updateWellState()
addWellControlEq()
The change of function computeWellConnectionPressures() is not done
completely. Should find a solution later.
the results look okay, while the running for flow_solvent needs further
investigation even the results with flow_solvent actually look okay.
With two different version of
computePropertiesForWellConnectionPressures, flow_solvent produces the
same results. This is something needs further investigation.
The current implementation requires a copy of
computeWellConnectionPressure in StandardWells and StandardWellsSolvent.
That means probably we need to introduce the asImpl() for the Wells.
