[LGR] Disable Static Well filtering for Inactive cells

[arturcastiel]

PR #6739 disables a LGR test that causes out-of-bounds memory access issues.
In this PR we reenable SPE1CASE1_CARFIN_GR test case.

[arturcastiel]

jenkins build this please

[arturcastiel]

@akva2 is there a way for me to run this multiple times to check this?

[akva2]

that's something you do on your machine. use valgrind.

[GitPaean]

@akva2 is there a way for me to run this multiple times to check this?

You can also use the debug code from #6739 (comment) before going ahead to valgrind. Valgrind is slower but it will be the final check.

[arturcastiel]

that's something you do on your machine. use valgrind.

this I have tried locally and it is fine.

[blattms]

We have added a test case T1A_NOPINCH_ACTIONX_COMPDAT in OPM/opm-tests#1487 that could be used as a regression test for connections in inactive cells appearing due to ACTIONX.

I would recommend to first add that regression test.

[GitPaean]

We have added a test case T1A_NOPINCH_ACTIONX_COMPDAT in OPM/opm-tests#1487 that could be used as a regression test for connections in inactive cells appearing due to ACTIONX.

I would recommend to first add that regression test.

can you review and get that PR in first?

[GitPaean]

We have added a test case T1A_NOPINCH_ACTIONX_COMPDAT in OPM/opm-tests#1487 that could be used as a regression test for connections in inactive cells appearing due to ACTIONX.

I would recommend to first add that regression test.

At the same time, this case is using ACTIONX to create new COMPDAT keyword and the PINCH happens before that. It is different from filtering the connections after processing the grid.

[bska]

this case is using ACTIONX to create new COMPDAT keyword and the PINCH happens before that. It is different from filtering the connections after processing the grid.

True. On the other hand, we don't really need to create new connections in an action block in order to get into a situation that the current filterConnections()-based approach doesn't handle. Suppose we have have something like

SCHEDULE
-- ...
ACTIONX
  'A' 123 /
  WWCT P > 0.42 /
/
UDQ
  ASSIGN WUHOO 1.23 /
/
ENDACTIO

-- ...

DATES
  1 JAN 2026 /
  4 FEB 2026 /
/
COMPDAT
  'P' ... /
/
DATES
 5 FEB 2026 /
 1 MAR 2026 /
/
-- ...

in which the COMPDAT definition on the 4th of February happens to involve a grid cell that gets deactivated in some way. The filterConnections() call will remove that connection as part of its normal operation. Now suppose the A action triggers on the 21st of January 2026. Our action implementation will replay the SCHEDULE section starting from that date which will rerun the COMPDAT keyword on the 4th of February. Even though the action does not involve the P well at all, our simulator will behave as if the original filterConnection() call didn't happen. Whether or not we successfully handle this case is entirely independent of filterConnections().

[arturcastiel]

jenkins build this please

[GitPaean]

I think I should have discussed with you first. Somehow I decided to go ahead to do the removal work through #6806 and OPM/opm-common#4975 .

Sorry about that.

[bska]

Somehow I decided to go ahead to do the removal work through #6806 and OPM/opm-common#4975.

I merged those two PRs since they were slightly more complete than the current proposal. Please rebase this work on top of the current master branch to have (only) the commit that re-enables the regression test.

[arturcastiel]

jenkins build this please

[bska]

Thanks a lot for the updates. This looks good to me now and I'll merge into master.