OPM
Modified version of safer well state
Revised and rebased, based on #5990 originally. Removed some changes to simplify investigation.
For now, just for testing.
I think this should be ready now. I have addressed the assert() issue pointed out by @GitPaean above. The major changes are:
- Ensure that WellInterface::initializeProducerWellState() [new name for updateWellStateRates()] is called when initializing a well from scratch, also rewrite that function to evaluate at bhp limit or 1 bar instead of 0 bar (from default-initialized primary variables).
- Store well primary variables in SingleWellState, and restore from that class if they are set (and have the right size), when in the update() methods of the (Standard and Multisegment)PrimaryVariable classes.
I checked the regression failures a little bit, not exhaustive. Most of the cases look fine. while the mpi.compareECLFiles_flow+WVFPEXP-02 , mpi.compareECLFiles_flow+MOD4_UDQ_ACTIONX,
maybe also mpi.compareECLFiles_flow+MSW-2D-VERT-02
can get some checking.
Thanks to @GitPaean for testing, and pointing out some errors that are now hopefully fixed.
most of the regression failures look fine, the following ones have something to look at,
09_multiply_tranxyz_model2.pdf
14_udt_udt-1d-03.pdf
15_wvfpexp_02.pdf
36_network_balance_01.pdf (same with other few network models.)
The regression failure looks similar while there are more regressions. I will pick a couple to investigate some to see what is the problem.
The one I will look at 02_editnnc, 09_multiply, 15_wvfpexp_02, maybe also the network one.
The number of the regression failures, 191, stays unchanged and let me check the detailed comparisons.
https://ci.opm-project.org/job/opm-simulators-PR-builder/8015/#showFailuresLink
11_udt-1d-03
some bumps at the end
multiple cases in this series the guide rates are different,
e.g. 15_0a4_grctrl_lrat_lrat_ggr_base_model2_stw
multiple wells in this case 16_model4_udq_group
some chopping in this case, 17_6_endscale_model2
some chopping in this case also, 26_1_multregt_model2
the network cases have different guide rates, 34_network-01_standard
not saying there are problematic, while worth looking into a little bit.
11_udt-1d-03
some bumps at the end
This one is using UDT and UDQ to control the opening of the well, while somehow not sure why the wells is re-opened after 24 Jan 2023. There is not useful information in the DBG and PRT files.
The schedule looks like the following,
DATES
2 JAN 2023 /
/
-- Reduce BHP limit as pressure drops
UDT
'TU_FBHP' 1 /
'LL' 100.0 500.0 / -- FOPR values
100.0 180.0 / -- WBHP values
/
/
UDQ
ASSIGN WU_WBHP 0 /
DEFINE WU_WBHP0 WU_WBHP /
DEFINE WU_WBHP ((TU_FBHP[WOPR] UMIN WBHP) UMIN WU_WBHP0) UMAX 10.0 / -- MIN BHP = 10
/
WCONPROD
'PROD1' 'OPEN' ORAT 500.0 4* WU_WBHP /
'PROD2' 'OPEN' ORAT 500.0 4* WU_WBHP /
/
DATES
15 FEB 2023 /
/
11_udt-1d-03 some bumps at the end
This one is using UDT and UDQ to control the opening of the well, while somehow not sure why the wells is re-opened after 24 Jan 2023. There is not useful information in the DBG and PRT files.
Basically, it shows that the local solve can open a well being STOPPed, which should be a fallout in the logic. The logic related to wellIsStopped and others are rather complicated.
Basically, it shows that the local solve can open a well being STOPPed, which should be a fallout in the logic. The logic related to
wellIsStoppedand others are rather complicated.
This would be an issue unrelated to this PR then, but something we should figure out and fix.
For the following case,
e.g. 15_0a4_grctrl_lrat_lrat_ggr_base_model2_stw=
It looks like that at the start of the simulation, the simulator mistakenly thinks some wells are under zero rate target due to the uninitialized well state, it is also the change that removing !zero_target makes the major difference, while it might be a good thing because the master branch mistakenly think the wells under zero rate target (from the mistaken calculation of the group target based on the uninitialized well rate and potentials (did not go through all the logics))
Likely the other guide rate related regression are also due to this.
some chopping in this case also, 26_1_multregt_model2
This one is due to different time stepping and no other abnormality is observed.
multiple wells in this case 16_model4_udq_group
This looks like due to different time stepping at the end the wells are under different controls. I will not investigate more in details due to capacity.
- Tested suggestion to set
ws.primaryvar.resize(0);at the top of 'updateWellStateWithTarget' in order to force updating of primary variables together with doingupdatePrimaryVariables(simulator, well_state, deferred_logger);at beginning ofiterateWellEqWithControl/iterateWellEqWithSwitching(both std/ms versions) to ensure consistency. This removed all singularities for the case I'm looking at.
the regressions look good. I think we can update_data now from my side.
Good. Confirmed that I now get identical results with my previous testing