OPM
making the guide rates to be a vector
so we keep the ratios between the guide rates for different phases fixed after calculating the guide rates.
With the master branch, after calculating the guide rates for the nominated phase, when we need the guide rates for a different phases, we scale the guide rate for the nominated phase based on the current well rates.
The guide rates can last a certain period, and the well rates are updated each time step and each iteration, as a result, if we need guide rates other than the nominated phase, the calculated guide rates for this phase will be different between each iteration and each time steps, which is not the desirable behavoir.
With this PR, what we want to achieve is that, the guide rates for all the phases will be constant before the guide rates expire.
This PR combining with PR https://github.com/OPM/opm-common/pull/2537 is the efforts to tangle to case 9_4E_WINJ_GINJ_GUIDERATE*.
Not totally sure whether just using three phase guide rates is sufficient to handle all the possible situations for guide rates. At the same time, well potentials are currently using three-phase rates. So the limitation exists for both situations.
Ultimately, it might need to be a struct contains more information to handle all the possibilities. With that, the refactoring will be pretty focused on GuideRate itself. We can wait until we have that type of case to play with to address it.
It is very strange this case mpi.compareECLFiles_flow+3D_WECON is affected at all.
Locally, there is no any difference found.
For some cases, like the case UDQ_WCONPROD, the comparison failure is because
With this PR, the ratio between the guide rates for different phases is fixed when the guide rates are calculated. With this master branch, the ratio between the guide rates depends on the current well rates, which changes every iterations, as a result, the guide rates for phases other than the nominated phase will be different for each iteration.
The above is the expected behavoir change from this PR.
Has not checked all the test failure cases. But it looks like it is typically faster with this PR for the regression failed cases, can be due to the fixed guide rate ratios.
It is very strange this case mpi.compareECLFiles_flow+3D_WECON is affected at all.
Locally, there is no any difference found.
With rebasing and forced push, this non-produced regression test failure is gone. Will report back about other cases.
for some cases, for example, 0A1_GRCTRL_LRAT_ORAT_BASE_MODEL2_STW, (results are with tuning)
the results are looking smoother, (master is the master branch and devel is the result from this PR)
For some cases, like 0A4_GRCTRL_LRAT_LRAT_GGR_BASE_MODEL2_STW .
The results are very different.. the results from this PR is smoother, but not sure whether the result in the master branch or the results from this PR is the better one.
attached please find the comparison (master is the master branch and devel is from this PR) 0A4_GRCTRL_LRAT_LRAT_GGR_BASE_MODEL2_STW.pdf
It looks like the PR needs to adapted to the changes from the master branch. Just a record here, this PR was not marked ready for review back then is because not sure whether the results for the failed cases are better or worse without having the reference results.
It looks like the PR needs to adapted to the changes from the master branch
Yes, that's likely. I especially think that #2605 (and the downstream PR OPM/opm-simulators#3467) will impact this PR.
Not totally clear whether this PR is still relevant since there are more developments that happened later. Will investigate and come to a suggestion whether to close it or try to get it in.
But if someone has some information/ideas regarding this direction, please suggest.