-
Notifications
You must be signed in to change notification settings - Fork 67
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
Fixes to the special case with almost only water #803
Conversation
jenkins build this please |
benchmark please |
Benchmark result overview:
View result details @ https://www.ytelses.com/opm/?page=result&id=2058 |
jenkins build this please |
jenkins build this please |
I have looked the test failures. At-least the following 3 test failures needs to be addressed as they dont finish |
For the almost only water case the primary variables are p, sg and sw. 1) Use sw>=1-1e-6 as threshold for defining almost only water 2) Chop the water saturation at 1.01 and not 1.0 in order to improve convergence 3) Restrict update of rs/rv, rsw/rvw and zfraction in the extended blackoil model by the saturation scaling factor from the Appleyard-chopping.
jenkins build this please |
jenkins build this opm-simulators=4666 please |
benchmark please |
Benchmark result overview:
View result details @ https://www.ytelses.com/opm/?page=result&id=2096 |
For what it's worth, the performance improvements here are very impressive. Seems like we have a candidate for improved numerics. I am ready to test this more broadly at our end, what do you think? |
Yes, that would be nice. These changes will need some broad testing before it can be merged. |
I will split this PR in order to test the individual parts. |
Finally got to test this extensively. The results are very promising, but I do have a couple of models with convergence issues. Give me a hint when we can pick up this one again. |
I am now happy with the changes here. They enable convergence on select cases that were unable to run in Flow before. The impact during ensemble testing are also positive in the sense that we do not see deterioration on cases where Flow runs fine today. From our end, the changes here are ready for merging. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few comments, I am a bit hesitant to merge this as-is.
@@ -548,25 +546,30 @@ public: | |||
|
|||
// special case cells with almost only water | |||
// use both saturations (if the phase is enabled) | |||
// to avoid a singular matrix. | |||
// almost is defined as sw >= 1.0-1e-6. | |||
static const Scalar thresholdWaterFilledCell = 1.0 - 1e-6; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Still in Draft, but I will make a few comments.)
Why not use the eps argument as before? Do we need to use eps 0 for other reasons?
if constexpr (waterEnabled) { | ||
(*this)[Indices::waterSwitchIdx] = 1.0; | ||
(*this)[Indices::waterSwitchIdx] = std::min(1.01, sw); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is very unfortunate if we have to let saturations go outside physical constraints, especially by so much. Is this change crucial? If so, could 1 + eps be used here instead of 1.01?
Thanks for the testing. I think the two first part i.e. PR #809 and #816 is ready to go inn. This does not change the physical constraint of the model buts adds it as a extra parameter. For #817 I am still doing some testing to understand the test failures. @atgeirr This PR is for testing. Please review #809, #816 and #817 instead. |
For the almost only water case the primary variables are p, sg and sw.