remove the functions related to Schedule::filterConnections()

[GitPaean]

was trying to rebase #1059 , while it turns out be more work than just making a new one.

The PR is following the discussion in OPM/opm-simulators#6787 .

[GitPaean]

jenkins build this opm-simulators=6806 please

[GitPaean]

jenkins build this opm-simulators=6806 please

[GitPaean]

the function

opm-common/opm/input/eclipse/Schedule/Well/WellConnections.hpp

Line 135 in 5b16aa4

void filter(const ActiveGridCells& grid);

is only used by the test

opm-common/tests/parser/ConnectionTests.cpp

Line 449 in 5b16aa4

BOOST_AUTO_TEST_CASE(ApplyWellPI) {

Should we keep the test or modify the test? I believe it is a question for @bska

[bska]

Should we keep the test or modify the test? I believe it is a question for @bska

I need to think about it, but my first hunch is to adapt the test function to the new reality of filterConnections() not existing.

[GitPaean]

Should we keep the test or modify the test? I believe it is a question for @bska

I need to think about it, but my first hunch is to adapt the test function to the new reality of filterConnections() not existing.

I updated the test without using the filter() function and remove the function WellConnections::filter() .

I thought for some, it is also okay to keep the function and not change the test, so I make this change in a separate commit, so it is easier to revert or modify.

Now I consider the PR is ready for review.

[GitPaean]

jenkins build this opm-simulators=6806 please

[bska]

I updated the test without using the filter() function and remove [that function]. I thought for some, it is also okay to keep the function and not change the test, so I make this change in a separate commit, so it is easier to revert or modify.

I prefer the current version. The filter() operation really doesn't make any sense when we have event driven actions that will just undo whatever filtering we'd applied previously. Essentially, the filter() operation assumes that the Schedule object is unchanging once constructed and that assumption doesn't hold anymore when we have actions.

I'll merge this and its downstream counterpart into the master branch.