OPM
Fix oscilations
WIP
-
ads iterations to the well/group constrain check. replaces the remaining parts of https://github.com/OPM/opm-simulators/pull/3410/files
-
Keep well at individual controls when oscillating. See discussion in https://github.com/OPM/opm-simulators/pull/5599
Needs a lot more testing....
This PR with --shut-unsolvable-wells=false restore Norne results
Looking into this. Currently a well that has reached it's maximum switching limit is not only prevented from switching control, but also status (e.g., to stop). This leads to convergence failure for e.g., non-feasible bhp. This is a problem with master and not the PR, but probably good to fix in the current PR. Will do some experimentation and propose a fix.
@totto82 could you make the following small update: https://github.com/OPM/opm-simulators/commit/aec51705bb01951f87351562213d73f93018f093 ? This will prevent forcing a non-operable well to be open in cases the control mode is forced (prevents well convergence failures).
@totto82 could you make the following small update: aec5170 ? This will prevent forcing a non-operable well to be open in cases the control mode is forced (prevents well convergence failures).
Thanks. I have updated accordingly
PR fails to complete simulation for MOD4_UDQ_ACTIONX, however I'm not able to reproduce this behaviour locally. Will dig a bit more to try figure out what's going on.
Found an issue which by coincidense resulted in failed simulation of MOD4_UDQ_ACTIONX for this PR. Will attempt to fix this separately.
https://github.com/OPM/opm-simulators/pull/5634 has been merged, so I think this should fix the trouble for MOD4_UDQ_ACTIONX for this PR. I think the changes here looks good except the comment above. In my opinion maximum-number-of-well-switches can safely get a default value of 10.
For testing purposes this now includes https://github.com/OPM/opm-simulators/pull/5902 and https://github.com/OPM/opm-simulators/pull/5900