Open OPMUSER opened 2 years ago
Okay, thanks to Jan Inge Logstein we have the answers.
For the first ACTIONX block, the answer is:
11-MAR-2021 0.188912
16-MAR-2021 0.202601
16-MAR-2021 0.203970
18-MAR-2021 0.208077
22-MAR-2021 0.220397
This is different to OPM Flow that applies NEXSTEP to the next reporting time step, that is:
1-APR-2021 0.246407
1-APR-2021 0.247775
3-APR-2021 0.251882
Note both simulators trigger ACT-01 on March 16, 2021. So there is an inconsistency here. I wounder if this is because we used the NO option here.
The second ACTIONX block gives:
1-SEP-2021 0.665298
2-SEP-2021 0.668036
5-SEP-2021 0.676249
10-SEP-2021 0.689938
15-SEP-2021 0.703628
20-SEP-2021 0.717317
25-SEP-2021 0.731006
28-SEP-2021 0.739220
1-OCT-2021 0.747433
2-OCT-2021 0.750171
E100 applies NEXTSTEP to the reporting time step, with the YES option which is correct, whereas as OPM Flow ignores this.
Now in the deck on Nov 1, 2021 NEXTSTEP is set to 2.5 days and both simulators give the same results.
For the deck on Dec 1, 2021 NEXTSTEP is set to 10 days and E100 has:
1-DEC-2021 0.914442
11-DEC-2021 0.941821
16-DEC-2021 0.955510
21-DEC-2021 0.969199
26-DEC-2021 0.982888
31-DEC-2021 0.996578
Whereas, OPM Flow appears to ignore this.
In summary, I think some of the issues are associated with the TUNNING keyword always taking precedence over the NEXTSTEP keyword, when in fact NEXTSTEP overrides TUNNING(TSMAXZ). And likewise TUNNING(TSINIT) always takes precedence over NEXTSTEP(NSTEP1),
Did you run with --enable-tuning=true
?
Please keep in mind that Flow ignores all explicit TUNING-related timestepping controls unless the user supplies --enable-tuning=true
when launching the simulator. I don't think we'll change that aspect of how Flow operates.
Good point, as I have messed up with this before. But no I did run with --enable-tuning=true
as you can confirm with the maximum time step size of 5.0 days as stipulated by TUNNING(TSMAXZ).
I have tested this with flow 2024.04-pre
.
Flow now agrees and gives the following for the first ACTIONX block:
2021-03-11 00:00:00 0.18891171
2021-03-16 00:00:00 0.20260096
2021-03-16 12:00:00 0.20396988
2021-03-18 00:00:00 0.20807666
2021-03-22 12:00:00 0.220397
Flow now agrees and gives the following for the second ACTIONX block:
2021-09-01 00:00:00 0.66529775
2021-09-02 00:00:00 0.66803557
2021-09-05 00:00:00 0.67624915
2021-09-10 00:00:00 0.68993843
2021-09-15 00:00:00 0.70362765
2021-09-20 00:00:00 0.71731693
2021-09-25 00:00:00 0.73100615
2021-09-28 00:00:00 0.73921973
2021-10-01 00:00:00 0.74743325
2021-10-02 00:00:00 0.75017112
However, flow still seems to override NEXTSTEP=10 with TUNING(TSMAXZ)=5 following Dec 1, 2021:
2021-12-01 00:00:00 0.91444218
2021-12-06 00:00:00 0.9281314
2021-12-11 00:00:00 0.94182068
2021-12-16 00:00:00 0.9555099
2021-12-21 00:00:00 0.96919918
2021-12-26 00:00:00 0.98288846
2021-12-31 00:00:00 0.99657768
Just mentioning OPM/opm-common#3954 here as it might be related (and actually wrong?)
First I don't have a E100 run to compare with but I have this in an ACTIONX block:
And I get this in the RSM file:
When I expected this:
For the half day time step.
The second ACTIONX block is:
So one day time steps from September 1, 2021 until it is reset in the deck on Nov 1, 2021 to 2.5 days. I get this in the RSM file:
That is 5.0 day time steps as per what is set on the TUNNING keyword.
For the deck change on Nov 1, 2021 to 2.5 days, this partially works as you can see below, but then reverts to the TUNNING value of 5.0 days. Is this because the simulator is ignoring the NEXSTEP(NSTEP2) = YES option?
Then on December 1, 2021 in the deck we have:
And we get:
Which again is using the TUNNING keyword's 5.0 day limit.
Note E100 will ignore NEXTSTEP(NSTEP1) if the value is less than the equivalent value on the TUNNING keyword, but is silent on the maximum value. Once I have an E100 run we can check the latter point.
Test deck attached.
ACTIONX_NEXTSTEP.zip