Skip to content
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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

totto82
Copy link
Member

@totto82 totto82 commented Feb 19, 2025

If the well stagnates 5 times with full damping we give up. (and hope it convergence at the next newton iteration).

@totto82
Copy link
Member Author

totto82 commented Feb 19, 2025

jenkins build this failure_report please

@totto82
Copy link
Member Author

totto82 commented Feb 20, 2025

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.

@steink
Copy link
Contributor

steink commented Feb 20, 2025

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.

@totto82
Copy link
Member Author

totto82 commented Feb 21, 2025

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.

@totto82
Copy link
Member Author

totto82 commented Feb 21, 2025

jenkins build this failure_report please

@totto82
Copy link
Member Author

totto82 commented Feb 21, 2025

I tried to write something aligned with what @steink suggested.

@totto82
Copy link
Member Author

totto82 commented Feb 21, 2025

jenkins build this failure_report please

@totto82 totto82 changed the title stop MSW iterations if stagnate_count>5 modify stagnation and oscillation code for MSW Feb 21, 2025
@totto82
Copy link
Member Author

totto82 commented Feb 21, 2025

I have dome preliminary testing that looks promising. I will undraft and ask for review

@totto82 totto82 marked this pull request as ready for review February 21, 2025 11:36
@totto82 totto82 requested a review from steink February 21, 2025 11:36
@steink
Copy link
Contributor

steink commented Feb 26, 2025

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?

@totto82
Copy link
Member Author

totto82 commented Mar 3, 2025

jenkins build this failure_report please

@totto82
Copy link
Member Author

totto82 commented Mar 3, 2025

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?

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.

@steink
Copy link
Contributor

steink commented Mar 5, 2025

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.

@totto82
Copy link
Member Author

totto82 commented Mar 5, 2025

jenkins build this failure_report please

@totto82
Copy link
Member Author

totto82 commented Mar 5, 2025

jenkins build this failure_report please

@totto82
Copy link
Member Author

totto82 commented Mar 5, 2025

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?

@steink
Copy link
Contributor

steink commented Mar 5, 2025

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.

@totto82
Copy link
Member Author

totto82 commented Mar 5, 2025

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.

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants