-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
modify stagnation and oscillation code for MSW #6020
base: master
Are you sure you want to change the base?
Conversation
jenkins build this failure_report please |
For discussion. Does damping give a positive effect for stagnating solution or only for oscillating solution? I didn't check all the details here, so the change here is only based on the observation that no stagnating wells seems to recover after repeated stagnations so no need to waste iterations. |
In my experience, stagnation only happens when a well is forced to use a non-feasible control (there is no valid solution). E.g. for a producer, too high bhp/thp resulting in chopping rates at zero, or too high rate resulting in chopping bhp/segment pressures at minimal value. For these cases, there is of course no remedy (except allowing a control switch). For oscillations, damping should help. For the version with switching, especially for bad initial guesses and bad explicit lookup rates, one may end up in stop/open oscillations, but I dont think these are captured in the current oscillation detection. |
This agrees with by experience too. I will update with the PR with code that distinguishes between oscillation and stagnation. For oscillations damping is applied. For stagnation we give up if it stagnate repeated times. |
jenkins build this failure_report please |
I tried to write something aligned with what @steink suggested. |
jenkins build this failure_report please |
I have dome preliminary testing that looks promising. I will undraft and ask for review |
This looks fine to me, but I don't really understand why the PR uses more time-steps than master for a couple of the tests. The PR should only influence the logic around stagnation and not the relaxation procedure, right? |
jenkins build this failure_report please |
Almost. It removes the usage of relaxed tolerances. This is based on earlier comments from you that this may cause more problems than it solves. I can put it back if you want. |
I see. So that has an effect on some of the tests, but it's not clear to me whether it is an improvement or not. Not sure, maybe it's best to just put the relaxed tollerances back for now, and disregard my previous statement. In that case, I expect tests should be all fine. |
jenkins build this failure_report please |
jenkins build this failure_report please |
Adding back the relaxed tolerance fall-back didn't change much on the test failures. i.e. with this PR we still use more time-steps after some well event for 01_9_4b_grpctl_msw_model2. We have had problems with instabilities for this test before. I will do some more testing. @steink Are the other test failures ok? |
OK, that's a bit surprising, so agree with you that this is most likely due to the test beeing rather sensitive/unstable. I'm good with merging. |
I am focusing on 1. April when the deviation happens. For 01_9_4b_grpctl_msw_model2 the relaxation seems to have some effect on a stagnating well in the initial solve of one of the well (PROD2). When the actual newton iterations starts all wells converge smoothly. In master newton converge after 18 iterations at this timestep while with this PR it does not converge and need to cut the timestep. Interestingly when I change the maximum Newton to 25. I dont get any failures with this PR but master fails at 1. April. |
If the well stagnates 5 times with full damping we give up. (and hope it convergence at the next newton iteration).