2021.04-PRE Nigthly AQF01-CART01 Case Throws an Exception

[OPMUSER]

My test case AQF01-CAER01 case throws an exception, but runs okay with the current release.

Deck and output attached. Notice also that the exception is not in the PRT file.

AQF01-CART01-PRE.zip

AQF01-CART01.zip

===============Saturation Functions Diagnostics===============

System:  Oil-Water system.
Relative permeability input format: Saturation Family I.
Number of saturation regions: 1

Program threw an exception: Could not initialize the problem: Input argument does not correspond to an active cell

[joakim-hove]

OK; I have looked at this. The failure comes when writing the Aquifer information to the INIT file - we have aquifer connections to inactive cells, and that blows up. The reason we have the connection to an inactive cell is that the aquifer configuration is created before the grid is updated with modifiers to the ACTNUM array.

In this PR the ordering of ACTNUM deck edits and the Aquifer config is changed. Then the writing of the init file works, however the model now fails even harder in the simulator:

[ws:40009] *** Process received signal ***
[ws:40009] Signal: Segmentation fault (11)
[ws:40009] Signal code: Address not mapped (1)
[ws:40009] Failing at address: (nil)
[ws:40009] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7f5940857730]
[ws:40009] [ 1] /home/hove/work/OPM/opm-simulators/build/bin/flow(_ZN3Opm10EclProblemINS_10Properties4TTag22EclFlowOilWaterProblemEE30updateCompositionChangeLimits_Ev+0x6c9)[0x5606d2521ad5]
[ws:40009] [ 2] /home/hove/work/OPM/opm-simulators/build/bin/flow(_ZN3Opm10EclProblemINS_10Properties4TTag22EclFlowOilWaterProblemEE22initialSolutionAppliedEv+0x3c)[0x5606d25100a2]
[ws:40009] [ 3] /home/hove/work/OPM/opm-simulators/build/bin/flow(_ZN3Opm20FvBaseDiscretizationINS_10Properties4TTag22EclFlowOilWaterProblemEE20applyInitialSolutionEv+0x24c)[0x5606d2507eb8]
[ws:40009] [ 4] /home/hove/work/OPM/opm-simulators/build/bin/flow(_ZN3Opm12FlowMainEbosINS_10Properties4TTag22EclFlowOilWaterProblemEE18setupEbosSimulatorEv+0x81)[0x5606d2501b23]
[ws:40009] [ 5] /home/hove/work/OPM/opm-simulators/build/bin/flow(_ZN3Opm12FlowMainEbosINS_10Properties4TTag22EclFlowOilWaterProblemEE8execute_EMS4_FivEb+0x80)[0x5606d25006b6]
[ws:40009] [ 6] /home/hove/work/OPM/opm-simulators/build/bin/flow(_ZN3Opm12FlowMainEbosINS_10Properties4TTag22EclFlowOilWaterProblemEE7executeEv+0x33)[0x5606d25003b3]
[ws:40009] [ 7] /home/hove/work/OPM/opm-simulators/build/bin/flow(_ZN3Opm20flowEbosOilWaterMainEiPPcbb+0x5e)[0x5606d24b974e]
[ws:40009] [ 8] /home/hove/work/OPM/opm-simulators/build/bin/flow(_ZN3Opm4Main16dispatchDynamic_Ev+0x360)[0x5606d1a07c4c]
[ws:40009] [ 9] /home/hove/work/OPM/opm-simulators/build/bin/flow(_ZN3Opm4Main10runDynamicEv+0x36)[0x5606d1a078e4]
[ws:40009] [10] /home/hove/work/OPM/opm-simulators/build/bin/flow(main+0x46)[0x5606d19f1623]
[ws:40009] [11] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f593b36b09b]
[ws:40009] [12] /home/hove/work/OPM/opm-simulators/build/bin/flow(_start+0x2a)[0x5606d19f0b3a]
[ws:40009] *** End of error message ***
Segmentation fault

this crash I have not investigated. @GitPaean?

[GitPaean]

I can help to look into this case.

[bska]

For what it's worth, I've been using the following workaround for the INIT-file writing whilst developing the restart-output capabilities. I'd be happy to let go of it if we guarantee that Aquancon never generates a connection to an inactive cell

diff --git a/src/opm/output/eclipse/WriteInit.cpp b/src/opm/output/eclipse/WriteInit.cpp
index 2addf7df9..5699ffd80 100644
--- a/src/opm/output/eclipse/WriteInit.cpp
+++ b/src/opm/output/eclipse/WriteInit.cpp
@@ -577,6 +577,10 @@ namespace {
             const auto& connections = aqu.connections();
             const int exp2_id_1 = 1 << (id - 1);
             for (const auto& con : connections) {
+                if (! grid.cellActive(con.global_index)) {
+                    continue;
+                }
+
                 const size_t active_index = grid.activeIndex(con.global_index);
                 aquifern[active_index] += exp2_id_1;
             }
@@ -595,6 +599,10 @@ namespace {
         for (const auto& [id, cons] : cons_data) {
             const int exp2_id_1 = 1 << (id - 1);
             for (const auto& con : cons) {
+                if (! grid.cellActive(con.global_index)) {
+                    continue;
+                }
+
                 const size_t active_index = grid.activeIndex(con.global_index);
                 aquifera[active_index] += exp2_id_1;
             }

[bska]

In this PR the ordering of ACTNUM deck edits and the Aquifer config is changed. Then the writing of the init file works, however the model now fails even harder in the simulator:

Backtrace with demangled symbols

---

[ws:40009] *** Process received signal ***
[ws:40009] Signal: Segmentation fault (11)
[ws:40009] Signal code: Address not mapped (1)
[ws:40009] Failing at address: (nil)
[ws:40009] [ 0] /lib/x86_64-linux-gnu/libpthread.so.0( 0x12730)[0x7f5940857730]
[ws:40009] [ 1] /home/hove/work/OPM/opm-simulators/build/bin/flow(Opm::EclProblem<Opm::Properties::TTag::EclFlowOilWaterProblem>::updateCompositionChangeLimits_() 0x6c9)[0x5606d2521ad5]
[ws:40009] [ 2] /home/hove/work/OPM/opm-simulators/build/bin/flow(Opm::EclProblem<Opm::Properties::TTag::EclFlowOilWaterProblem>::initialSolutionApplied() 0x3c)[0x5606d25100a2]
[ws:40009] [ 3] /home/hove/work/OPM/opm-simulators/build/bin/flow(Opm::FvBaseDiscretization<Opm::Properties::TTag::EclFlowOilWaterProblem>::applyInitialSolution() 0x24c)[0x5606d2507eb8]
[ws:40009] [ 4] /home/hove/work/OPM/opm-simulators/build/bin/flow(Opm::FlowMainEbos<Opm::Properties::TTag::EclFlowOilWaterProblem>::setupEbosSimulator() 0x81)[0x5606d2501b23]
[ws:40009] [ 5] /home/hove/work/OPM/opm-simulators/build/bin/flow(Opm::FlowMainEbos<Opm::Properties::TTag::EclFlowOilWaterProblem>::execute_(int (Opm::FlowMainEbos<Opm::Properties::TTag::EclFlowOilWaterProblem>::*)(), bool) 0x80)[0x5606d25006b6]
[ws:40009] [ 6] /home/hove/work/OPM/opm-simulators/build/bin/flow(Opm::FlowMainEbos<Opm::Properties::TTag::EclFlowOilWaterProblem>::execute() 0x33)[0x5606d25003b3]
[ws:40009] [ 7] /home/hove/work/OPM/opm-simulators/build/bin/flow(Opm::flowEbosOilWaterMain(int, char**, bool, bool) 0x5e)[0x5606d24b974e]
[ws:40009] [ 8] /home/hove/work/OPM/opm-simulators/build/bin/flow(Opm::Main::dispatchDynamic_() 0x360)[0x5606d1a07c4c]
[ws:40009] [ 9] /home/hove/work/OPM/opm-simulators/build/bin/flow(Opm::Main::runDynamic() 0x36)[0x5606d1a078e4]
[ws:40009] [10] /home/hove/work/OPM/opm-simulators/build/bin/flow(main 0x46)[0x5606d19f1623]
[ws:40009] [11] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main 0xeb)[0x7f593b36b09b]
[ws:40009] [12] /home/hove/work/OPM/opm-simulators/build/bin/flow(_start 0x2a)[0x5606d19f0b3a]
[ws:40009] *** End of error message ***
Segmentation fault

[GitPaean]

I'd be happy to let go of it if we guarantee that Aquancon never generates a connection to an inactive cell

I am not totally sure what you mean here. If an inactive cell should not be connected to an aquifer and if (! grid.cellActive(con.global_index)) { happens, it means something is wrong, right? How can we let it go?

[bska]

I'd be happy to let go of it if we guarantee that Aquancon never generates a connection to an inactive cell

I am not totally sure what you mean here.

I mean that I have a case that I've been using for restart purposes for which Flow's internal representation of Aquancon connects to inactive cells. Specifically, the conditionals mentioned earlier trigger for multiple individual Aquancon:AquancCell objects. As it happens, this case has ACTNUM=1 for all cells, but a number of aquifer cells specified in AQUANCON have zero pore-volume. Apparently, the cell deactivation happens after the AquiferConfig object is formed.

[GitPaean]

Apparently, the cell deactivation happens after the AquiferConfig object is formed.

Thanks for the explanation. It is something we need to fix in the aquifer implementation. We need to use the processed grid to generate connections.

[GitPaean]

The failure comes when writing the Aquifer information to the INIT file - we have aquifer connections to inactive cells, and that blows up. The reason we have the connection to an inactive cell is that the aquifer configuration is created before the grid is updated with modifiers to the ACTNUM array.

It is correct. With master branch 20 connections are generated. From the deck, it looks like it should be 19 connections.

[GitPaean]

With @joakim-hove 's fix, the segmentation fault is at the following in eclproblem.hh, which is not related to aquifer,

lastRs_ is not initialized.

                if (oilVaporizationControl.getOption(pvtRegionIdx) || fs.saturation(gasPhaseIdx) > freeGasMinSaturation_)
                    lastRs_[compressedDofIdx] =
                        Opm::BlackOil::template getRs_<FluidSystem,
                                                       FluidState,
                                                       Scalar>(fs, iq.pvtRegionIndex());

[GitPaean]

In the implementation of flow, only when we have both Oil and Gas phase, we will consider DRSDT. This deck is a oil-water two phase case, in theory, DRSDT is of no use, and flow does not guard against this situation.

[GitPaean]

For this situation, oil-water case with keyword DRSDT, it is the following options that we can do

1. we fix flow to handle this situation (it is not hard in eclproblem.hh)
2. we terminate the running when we see we are specifying DRSDT with oil-water case, and giving proper message.
3. we ignore the DRSDT keyword when we see it is an oil-water case, and give a proper warning message and continue running.

In my opinion, they are all viable options. Please suggest and feel free to provide a fix if you want to. @joakim-hove @bska @atgeirr @totto82

[joakim-hove]

I'd be happy to let go of it if we guarantee that Aquancon never generates a connection to an inactive cell

The dance between property initialization and grid initialization is complex; the current PR fixes one situation and this:

As it happens, this case has ACTNUM=1 for all cells, but a number of aquifer cells specified in AQUANCON have zero pore-volume. Apparently, the cell deactivation happens after the AquiferConfig object is formed.

Is obviously another case. Anyway - I would say we are getting there.

[joakim-hove]

In my opinion, they are all viable options. Please suggest and feel free to provide a fix if you want to. @joakim-hove @bska @atgeirr @totto82

I am happy to provide a opm-common based solution, but I can not judge whether that will be the best approach.

[totto82]

I suggest we do both. A nice message telling the user to remove DRSDT or ignore it in opm-common. And some guards in eclproblem. Ala

if (!lastRs_.empty() && oilVaporizationControl.getOption(pvtRegionIdx) || fs.saturation(gasPhaseIdx) > freeGasMinSaturation_)

it is not hard in eclproblem.hh

@GitPaean Can you provide a PR for eclproblem.

[alfbr]

I suggest we do both. A nice message telling the user to remove DRSDT or ignore it in opm-common.

The segmentation fault needs to be fixed, but isn't it up to the simulator to decide how to handle the situation (ignore and run or stop simulation, give helpful message)? If so, having the parser decide how to handle this situation is a straitjacket. We have an ongoing effort to handle unsupported features in flow more generally: https://github.com/OPM/opm-simulators/pull/3061

It seems we are now facing the situation of handling unsupported combinations of keywords. This is a general problem we can design for.

[OPMUSER]

The commercial simulator just runs, no warnings - see attached

AQF01-CART01.zip

We should do the same.

[alfbr]

The commercial simulator just runs, no warnings - see attached

AQF01-CART01.zip

We should do the same.

Thanks for sharing, then simply fixing the segfault is probably fine at this point. Whether to emit a message to the user can be decided later anyway. Handling unsupported combinations of keywords has not been started yet, so that is actually a relief.

[GitPaean]

Okay. I will create a PR to fix the segmentation fault. I think some message to tell the users to improve the deck can be something good, but maybe for future. With helpful message, it can also be easier to debug.

[GitPaean]

https://github.com/OPM/opm-simulators/pull/3133 is created to handle the segmentation fault. The case runs now with https://github.com/OPM/opm-common/pull/2379 and https://github.com/OPM/opm-simulators/pull/3133 .

Not sure whether https://github.com/OPM/opm-simulators/pull/3133 breaks anything. Let jenkins check it out.

[GitPaean]

With https://github.com/OPM/opm-common/pull/2379 and #3133 merged. I believe this issue can be closed safely.