OPM
remove 16 days restriction for timestep in predicition mode
This PR is for testing. Both the time-stepping, convergence and well models has improved since this hard-coded limit was enforced. Is it time to remove it? The initial testing I have done indicates so, but more testing is needed.
For clarification, the 16-day limitation was imposed to obtain comparable results for the targeting field case at that time. It was not due to stability reason.
The commercial simulator typically uses much smaller time steps for prediction cases, I guess the reason is that you will be able to do more accurate prediction. Even for commercial simulators, with different time steps the results for prediction case can be significantly different due to closing and opening wells at different orders and different timing. For prediction cases, smaller time steps and more stable simulation will be much more preferable. Because the closing and opening wells can be determined within much smaller time intervals (just like a ruler's smallest unit decides how accurate/precise the ruler is).
Benchmark result overview:
| Test | Configuration | Relative |
|---|---|---|
| opm-git | OPM Benchmark: flow_mpi_extra - Threads: 1 | 0.995 |
| opm-git | OPM Benchmark: flow_mpi_extra - Threads: 8 | 0.998 |
| opm-git | OPM Benchmark: flow_mpi_norne - Threads: 1 | 0.995 |
| opm-git | OPM Benchmark: flow_mpi_norne - Threads: 8 | 0.986 |
- Speed-up = Total time master / Total time pull request. Above 1.0 is an improvement. *
View result details @ https://www.ytelses.com/opm/?page=result&id=1077
Benchmark result overview:
| Test | Configuration | Relative |
|---|---|---|
| opm-git | OPM Benchmark: flow_mpi_extra - Threads: 1 | 1.018 |
| opm-git | OPM Benchmark: flow_mpi_extra - Threads: 8 | 0.98 |
| opm-git | OPM Benchmark: flow_mpi_norne - Threads: 1 | 1.028 |
| opm-git | OPM Benchmark: flow_mpi_norne - Threads: 8 | 1.047 |
| opm-git | OPM Benchmark: flow_mpi_norne_4c_msw - Threads: 1 | 1.048 |
- Speed-up = Total time master / Total time pull request. Above 1.0 is an improvement. *
View result details @ https://www.ytelses.com/opm/?page=result&id=1110
Nice improvement on the prediction case! Good motivation for replacing this feature with something more sophisticated.
Do we know why we are missing OPM Benchmark: flow_mpi_norne_4c_msw - Threads: 8?
Do we know why we are missing
OPM Benchmark: flow_mpi_norne_4c_msw - Threads: 8?
Sorry, did not see that one. Probably it timed out, i.e., take too long to finish or did not finish at all. Have you tried to run it locally?
It runs throw with 8 cores locally, but number of problems is increased. There are lot of convergence issues related to wells for both the single and the mpi run. I suggest we wait to merge this until we have improved the convergence. We may also want to consider to use a smaller value for target newton iterations or improve the timestep estimator further.
We may also want to consider to use a smaller value for target newton iterations
This will reduce the time step more quickly due to target newton iteration numbers, is this what you want to achieve?
With more cases we have seen now, we should try to remove the 16 days constraints in some way.
16 days constraints were introduced back then for some cases (group control related), the reference running were performed with much smaller time steps (smaller than 16 days due to their time stepping algorithms), then without this constraint, it was hard to have comparable results. With the time stepping algorithms back then, we obtained much larger time steps.
Now we see for many cases, the reference running were performed with much larger time steps. Maybe we should try to remove this 16-day time step constraint. while I not sure how to proceed with the testing.