Skip to content

Also solve std for every inner iterations as default #6098

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

totto82
Copy link
Member

@totto82 totto82 commented Mar 20, 2025

In master, we always solve inner iterations for MSwells but not StdWells. The lack of inner iterations for StdWells can lead to convergence issues for Newton. This changes the default value to 99 and removes the check for MSWells, thus allowing not to solve MSWells during some Newton iterations.

@totto82
Copy link
Member Author

totto82 commented Mar 20, 2025

jenkins build this failure_report please

@totto82
Copy link
Member Author

totto82 commented Mar 20, 2025

Note that this fixes the issue of repeatedly shutting off NORNE_ATW2013_3B_STDW.DATA as reported by @erikhide in #6067

@GitPaean
Copy link
Member

vow, then my guess is that it improves the well solve for the well under THP target?

@@ -851,7 +851,7 @@ namespace Opm

// only use inner well iterations for the first newton iterations.
const int iteration_idx = simulator.model().newtonMethod().numIterations();
if (iteration_idx < this->param_.max_niter_inner_well_iter_ || this->well_ecl_.isMultiSegment()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we go this direction, we probably want to do it differently here.
iteration_idx by default will be maximum 20. We probably can remove this if condition or using some other if condition if I did not read the code wrong.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it could be useful to keep the option of not solving with inner iterations for all Newton iterations.

@totto82
Copy link
Member Author

totto82 commented Mar 20, 2025

I have started testing the Norne prediction cases with STW, and the results are not conclusive. In some cases, Newton's convergence gets worse. I will have to dig deeper into these cases to understand what happens.

@GitPaean
Copy link
Member

In some cases, Newton's convergence gets worse.

Norne had this problem from many years ago, not sure whether it is still the case though.

@erikhide
Copy link
Contributor

I have started testing the Norne prediction cases with STW, and the results are not conclusive. In some cases, Newton's convergence gets worse. I will have to dig deeper into these cases to understand what happens.

Note that some of the Norne prediction cases fail when using the current master. I've tested alternative time stepping approaches which seem to work better (i.e. the simulation doesn't fail). An early version is available using --time-step-control="general3rdorder".

@totto82
Copy link
Member Author

totto82 commented Mar 21, 2025

benchmark this please

@totto82
Copy link
Member Author

totto82 commented Apr 2, 2025

jenkins build this failure_report please

@totto82 totto82 added this to the Release 2025.04 milestone Apr 2, 2025
@totto82
Copy link
Member Author

totto82 commented Apr 2, 2025

I think we should try to get this in before the release, as not solving the well with inner equations may lead to the stagnation of simulations.

@totto82
Copy link
Member Author

totto82 commented Apr 3, 2025

Some spikes in the results are the most worrying differences. I have tried to reproduce them locally:
udq_wconprod: WOPR:OPL02. Both master and PR give the same results locally (no spike)
editnnc_model2: WGIP:INJ1. Both master and PR give the same results locally (with spike)
I.e., the spikes are probably caused by something else.

From my point of view, this should be merged. We would like to use the new local solve approach in the simulator at every iteration, as well as for standard wells.

@totto82
Copy link
Member Author

totto82 commented Apr 4, 2025

@GitPaean, what do you think? Should we merge this before the release? I think so, as it improves the convergence in most cases. If it doesn't, it points to other issues that must be solved. If this leads to a problem for particular models, we have a simple workaround of passing the old default parameters.

@totto82
Copy link
Member Author

totto82 commented Apr 4, 2025

jenkins build this failure_report please

@GitPaean
Copy link
Member

GitPaean commented Apr 4, 2025

let me have a look.

It was mentioned that it made some running worse, was there any update regarding that?

@GitPaean
Copy link
Member

GitPaean commented Apr 4, 2025

I confirm that editnnc_model2: WGIP:INJ1. produces a spike both on the master and this PR locally.

But it is a weird case, that INJ1 is either GAS or WATER injection history matching mode, while the most of the time (or all the time of reference results), WGIP for INJ1 is zero, which is rather strange. DBG and PRT file does not mention anything related to this.

@GitPaean
Copy link
Member

GitPaean commented Apr 4, 2025

Did you check the results related to UDQ_WCONPROD?

02_udq_wconprod.pdf

I confirmed the jenkins comparison locally.

@GitPaean
Copy link
Member

GitPaean commented Apr 4, 2025

And also
01_udq_pyaction.pdf
I confirmed this one in locally.

did not check all of the regression tests.

@totto82
Copy link
Member Author

totto82 commented Apr 4, 2025

Did you check the results related to UDQ_WCONPROD?

It seems super-sensitive to small perturbations in the time-stepping. I will dig deeper to see if I can solve the underlying issue.

@vkip
Copy link
Member

vkip commented Apr 4, 2025

Using --check-group-constraints-inner-well-iterations=false (or applying #5924) seems to fix 02_udq_wconprod (only time-stepping differences remain, visually identical results with shorter time steps).

@totto82
Copy link
Member Author

totto82 commented Apr 4, 2025

I think the issue is related to control switching. #6145 seems to fix it. However, so does restricting the timestep and reducing the maximum number of well switching per step. So I could just be random, but I don't think it is directly related to this PR. i.e., I think we can merge this and update the data. I also tagged #6145 for the release. It fixes an output bug, but we may need to change the default maximum value of switching as we expect more switching during local solves.

@totto82
Copy link
Member Author

totto82 commented Apr 4, 2025

@vkip comment strengthens my suspicion that it is related to well-switching.

@totto82
Copy link
Member Author

totto82 commented Apr 4, 2025

Let's merge #5924 first.

@vkip
Copy link
Member

vkip commented Apr 4, 2025

Let's merge #5924 first.

Sounds good, hopefully many of the test failures here disappear after that.

@totto82
Copy link
Member Author

totto82 commented Apr 22, 2025

There are still some issues for Norne that need to be solved before this can be merged. I will keep it open, but remove the release tag.

@totto82 totto82 removed this from the Release 2025.04 milestone Apr 22, 2025
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.

4 participants