OPM
Also solve std for every inner iterations as default
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.
Note that this fixes the issue of repeatedly shutting off NORNE_ATW2013_3B_STDW.DATA as reported by @erikhide in https://github.com/OPM/opm-simulators/pull/6067
vow, then my guess is that it improves the well solve for the well under THP target?
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.
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.
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".
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.
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.
@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.
let me have a look.
It was mentioned that it made some running worse, was there any update regarding that?
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.
Did you check the results related to UDQ_WCONPROD?
I confirmed the jenkins comparison locally.
And also 01_udq_pyaction.pdf I confirmed this one in locally.
did not check all of the regression tests.
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.
Using --check-group-constraints-inner-well-iterations=false (or applying https://github.com/OPM/opm-simulators/pull/5924) seems to fix 02_udq_wconprod (only time-stepping differences remain, visually identical results with shorter time steps).
I think the issue is related to control switching. https://github.com/OPM/opm-simulators/pull/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.
@vkip comment strengthens my suspicion that it is related to well-switching.
Let's merge #5924 first.
Sounds good, hopefully many of the test failures here disappear after that.
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.
With PR
CASE: TIME(s) Newton
NORNE_ATW2013_1A_STDW: 72.15 564
NORNE_ATW2013_1B_STDW: 120.06 1158
NORNE_ATW2013_2A_STDW: 117.10 1155
NORNE_ATW2013_2B_STDW: 129.01 1361
NORNE_ATW2013_3A_STDW: 90.65 700
NORNE_ATW2013_3B_STDW: 87.41 657
NORNE_ATW2013_3C_STDW: 109.75 901
NORNE_ATW2013_4A_STDW: 82.55 664
NORNE_ATW2013_4B_STDW: 130.64 972
With Master
CASE: TIME(s) Newton
NORNE_ATW2013_1A_STDW: 64.58 520
NORNE_ATW2013_1B_STDW: 85.83 721
NORNE_ATW2013_2A_STDW: 72.76 574
NORNE_ATW2013_2B_STDW: 87.64 731
NORNE_ATW2013_3A_STDW: 86.13 684
NORNE_ATW2013_3B_STDW: 94.18 749
NORNE_ATW2013_3C_STDW: 88.32 670
NORNE_ATW2013_4A_STDW: 79.86 665
NORNE_ATW2013_4B_STDW not finished (stopped it after 44 minutes, but based on earlier runs it will finish in the end)
For Norne: With PR:
================ End of simulation ===============
Number of MPI processes: 4
Threads per MPI process: 2
Setup time: 3.21 s
Deck input: 1.74 s
Number of timesteps: 351
Simulation time: 130.71 s
Assembly time: 21.55 s (Wasted: 0.3 s; 1.3%)
Well assembly: 2.58 s (Wasted: 0.0 s; 1.7%)
Linear solve time: 52.55 s (Wasted: 0.6 s; 1.2%)
Linear setup: 24.69 s (Wasted: 0.4 s; 1.5%)
Props/update time: 13.48 s (Wasted: 0.2 s; 1.5%)
Pre/post step: 31.94 s (Wasted: 0.0 s; 0.0%)
Output write time: 7.21 s
Overall Linearizations: 1652 (Wasted: 21; 1.3%)
Overall Newton Iterations: 1302 (Wasted: 21; 1.6%)
Overall Linear Iterations: 2576 (Wasted: 19; 0.7%)
Error summary:
Warnings 169
Info 2538
Errors 0
Bugs 0
Debug 0
Problems 1
With Master:
================ End of simulation ===============
Number of MPI processes: 4
Threads per MPI process: 2
Setup time: 3.77 s
Deck input: 1.90 s
Number of timesteps: 351
Simulation time: 135.67 s
Assembly time: 23.54 s (Wasted: 0.3 s; 1.4%)
Well assembly: 2.78 s (Wasted: 0.0 s; 1.5%)
Linear solve time: 53.24 s (Wasted: 0.7 s; 1.3%)
Linear setup: 25.04 s (Wasted: 0.4 s; 1.7%)
Props/update time: 14.04 s (Wasted: 0.2 s; 1.5%)
Pre/post step: 33.35 s (Wasted: 0.0 s; 0.0%)
Output write time: 7.48 s
Overall Linearizations: 1643 (Wasted: 21; 1.3%)
Overall Newton Iterations: 1293 (Wasted: 21; 1.6%)
Overall Linear Iterations: 2535 (Wasted: 18; 0.7%)
Error summary:
Warnings 169
Info 2536
Errors 0
Bugs 0
Debug 0
Problems 1
I will make a new attempt for this release. The way the inner solve code is written now, we really want to solve the STD wells for all Newton iterations. Yes, the run time increases for 1B, 2A, and 2B, but I will argue that that is better than the unfinished simulation of 4B. I have looked through the test failures, and I didn't spot anything that makes me nervous. This PR affects the convergence and thus the time-stepping, which again affects the results. The problematic cases we looked at the last time we investigated this, i.e., the UDQ tests, behave much better now.
It has been en effort crossing many years. I am not familiar with the significance of the NORNE cases, while it looks like systematically slower with the iteration for standard wells.
For Norne, the difference is within the fluctuation, the PR increases the iteration number a little bit, which is not a concern.
How does it behave in other field cases?
I do not think I can make the decision alone, so I invited @atgeirr @bska also join the discussion.