Remove filterconnections call

[joakim-hove]

Followup to: OPM/opm-common#1059

[GitPaean]

sorry if I am not following this closely. But what is the plan to handle the well connections that specified in a cell that is removed due to MINPV and PINCH?

[atgeirr]

I'll try to answer that: the filtering is unnecessary because the EclipseGrid object already deactivated cells due to MINPV before we constructed the Schedule object, and filtered them at Schedule construction time. At least that is the hope, we now want to test that this holds in practice and did not forget about something.

[GitPaean]

Thanks. It sounds good and I can make some test running from my side.

[blattms]

I have the feeling that some part (maybe MSW) in a parallel run is relying on connections being filtered.
At least that would be an explanation for #2101

[GitPaean]

I have the feeling that some part (maybe MSW) in a parallel run is relying on connections being filtered.

I am not totally sure about what you mean here. Basically, if a connection is filtered, it will not enter the well model. When we remove the connections, we should make all the usage might be related consistent, which means the connection is filtered everywhere.

[blattms]

Did anybody test this on model2?

[GitPaean]

Did anybody test this on model2?

Some relisations of model 2 are the reason to introduce the filtering of connection to deactivated cells.

As reported in OPM/opm-common#1059 , yes.

I believe that was a serial running.

[joakim-hove]

Did anybody test this on model2?

yes - @GitPaean did and found one realization failing; I got that realization and investigated further. To me it actually seemed like a bug/unexpected behavior deep down in the C code processing the grdecl input; at that stage I lost steam - but it is still on my intend-ot-look-more-into list.

@GitPaean

I believe that was a serial running.

yes - the failure I found was not related to parallell.

[blattms]

@atgeirr Well, it turns out that we are creating the grid only after creating of the schedule, The schedule is created at flow.cpp#L349 and passed to ebos somewhere further down. Setting the deck is done in function flowEbos*SetDeck before creating the simulator (and the actual grid) in the next function call (flowEbos*Main). That seems to be a rather unnatural way to construct things. All members that can be set externally in EclBaseVanguard are static to be able to construct them before the actual instances.

[GitPaean]

We will probably do this following the discussion in #6787 . Some other PR will be opened based on this one or a totally new one.