Cleanup: simplify standard well equations

[michal-toth]

I just stumbled upon this while studying cprw solver. The code can be simplified in two ways:

1. The vector rhs has exactly one nonzero element equal to 1. The for loop accumulating elements multiplied by rhs can be thus simplified to an assignment.
2. The transposed inv_diag_block matrix does not have to be constructed. We access its elements, so swapping indices suffices.

[michal-toth]

jenkins build this please

[blattms]

benchmark please

[ytelses]

Benchmark result overview:

Test	Configuration	Relative
opm-git	OPM Benchmark: drogon - Threads: 1	1.001
opm-git	OPM Benchmark: drogon - Threads: 8	1.053
opm-git	OPM Benchmark: punqs3 - Threads: 1	0.998
opm-git	OPM Benchmark: punqs3 - Threads: 8	0.991
opm-git	OPM Benchmark: smeaheia - Threads: 1	1.04
opm-git	OPM Benchmark: smeaheia - Threads: 8	1.121
opm-git	OPM Benchmark: spe10_model_1 - Threads: 1	1.004
opm-git	OPM Benchmark: spe10_model_1 - Threads: 8	0.984
opm-git	OPM Benchmark: flow_mpi_extra - Threads: 1	1.004
opm-git	OPM Benchmark: flow_mpi_extra - Threads: 8	1.173
opm-git	OPM Benchmark: flow_mpi_norne - Threads: 1	1.001
opm-git	OPM Benchmark: flow_mpi_norne - Threads: 8	1.085
opm-git	OPM Benchmark: flow_mpi_norne_4c_msw - Threads: 1 - FOPT (Total Oil Production At End Of Run)	1
opm-git	OPM Benchmark: flow_mpi_norne_4c_msw - Threads: 8 - FOPT (Total Oil Production At End Of Run)	1

• Speed-up = Total time master / Total time pull request. Above 1.0 is an improvement. *

View result details @ https://www.ytelses.com/opm/?page=result&id=2712

[blattms]

However, I think it is not executed at all in the normal case,

Whether this is called is subject to the add_well property in the json-tree of the CPR preconditioner (see PressureBhpTransferPolicy.hpp#L203) and that seems to be true for our default, see setupPropertyTree.cpp#L144.

[blattms]

I take back my statement above, That is the condition that the function is called, but here is another if around this particular statement, indeed.

[hnil]

The use_well_weights has to be considered experimental. It is a test to try to make quasiimpes type weights for the well system i.e. get a uniform method to get weights. However the work on it was abandoned since it is not obviouse how to do it for multisegment wells. Also in the case of multi segment wells the cprw is a bit different than nomral, since it combine the full well into one node i.e. it both "coarsen" in dofs( only use one degree of freedom for the full well) and in variables(only keep bhp/pressure for the full well). The branch may be removed, but it also maybe usefull for extending the cprw.

[michal-toth]

The use_well_weights has to be considered experimental. It is a test to try to make quasiimpes type weights for the well system i.e. get a uniform method to get weights. However the work on it was abandoned since it is not obviouse how to do it for multisegment wells. Also in the case of multi segment wells the cprw is a bit different than nomral, since it combine the full well into one node i.e. it both "coarsen" in dofs( only use one degree of freedom for the full well) and in variables(only keep bhp/pressure for the full well). The branch may be removed, but it also maybe usefull for extending the cprw.

Thank you for the clarification. I wanted to make a regression test for this case and was surprised how horrible the performance with use_well_weights is in parallel (sequential is fine). Since it is experimental, unfinished, and no longer in development we should consider removing this branch of code, e.g. by constexpr if(false) in case we want to keep the code around.