OPM
Include rejection of time step if tolerance test fails
Most of the work published on adaptive time stepping includes a test for deciding whether or not to reject the most recent time step. This is usually done by taking the relative change or some error estimate and comparing this to one or more threshold value(s). If the change/error is too large, the time step is rejected, and we try again with a shorter time step. In other words, we discard the computations and move back to the previous point in time. Currently, however, this is not done in OPM, and my belief (still only a hypothesis) is that this has contributed to the lack of robustness in the "pure" PID controller implementation.
Note that the OPM Flow Reference Manual includes a footnote reference to "Algebraic Flux Correction III. Incompressible Flow Problems. Uni Dortmund, Turek and Kuzmin, January, 2006 (DOI: 10.1007/3-540-27206-2_8)" in which the method clearly states that a failure to satisfy the tolerance test should result in a rejection of the time step.
I have implemented such a rejection of time steps now. It seems to be working as it should, but please let me know if I should change something.
Much appreciated! Just for clarity: Is this work intended as a replacement for, or perhaps a continuation of, #4855 and/or #4856? Or maybe it's entirely independent of those two existing PRs?
This is meant to solve an independent problem in the adaptive time stepping.
The pull request does in fact include the changes done in #4855, but the new changes related to rejection of time steps are independent of that. They are also completely independent of #4856.
This is meant to solve an independent problem in the adaptive time stepping.
Okay, understood.
The pull request does in fact include the changes done in #4855, but the new changes related to rejection of time steps are independent of that.
Very good. Then I think we should maybe change the state of this PR to draft/work-in-progress pending #4855 so we don't inadvertently merge this in conflict with that work. Would that be okay with you?
Very good. Then I think we should maybe change the state of this PR to draft/work-in-progress pending #4855 so we don't inadvertently merge this in conflict with that work. Would that be okay with you?
Sure! That's probably a good solution.
Very good. Then I think we should maybe change the state of this PR to draft/work-in-progress pending #4855 so we don't inadvertently merge this in conflict with that work. Would that be okay with you?
Sure! That's probably a good solution.
Cool–I've marked it as such now.
Benchmark result overview:
| Test | Configuration | Relative |
|---|---|---|
| opm-git | OPM Benchmark: drogon - Threads: 1 | 1.015 |
| opm-git | OPM Benchmark: drogon - Threads: 8 | 0.991 |
| opm-git | OPM Benchmark: punqs3 - Threads: 1 | 0.981 |
| opm-git | OPM Benchmark: punqs3 - Threads: 8 | 1.003 |
| opm-git | OPM Benchmark: smeaheia - Threads: 1 | 0.975 |
| opm-git | OPM Benchmark: smeaheia - Threads: 8 | 1.003 |
| opm-git | OPM Benchmark: spe10_model_1 - Threads: 1 | 0.996 |
| opm-git | OPM Benchmark: spe10_model_1 - Threads: 8 | 1.004 |
| opm-git | OPM Benchmark: flow_mpi_extra - Threads: 1 | 0.997 |
| opm-git | OPM Benchmark: flow_mpi_extra - Threads: 8 | 1.006 |
| opm-git | OPM Benchmark: flow_mpi_norne - Threads: 1 | 1.013 |
| opm-git | OPM Benchmark: flow_mpi_norne - Threads: 8 | 0.99 |
| opm-git | OPM Benchmark: flow_mpi_norne_4c_msw - Threads: 1 | 0.808 |
| opm-git | OPM Benchmark: flow_mpi_norne_4c_msw - Threads: 8 | 0.893 |
- 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=2497
