WIP: Helper method to compute the matrix blocklevel

The following is only a prototype to probe whether the general idea is well-received by the dune-istl community. See the end of the text for a few things that need to be improved.

All ISTL vectors and matrices have to export the 'blocklevel' integer. It is used to determine the nesting depth of a given vector or matrix.

As it turns out, the vector blocklevel field is never actually used within dune-istl. The matrix blocklevel is used a few times. However, with C++11 and beyond it is quite easy to compute the vector and matrix nestings depths without requiring the blocklevel field from each and every vector and matrix implementation.

This patch adds a little helper method matrixBlockLevel that computes the nesting depth of a given matrix type. The method is contained in the Imp namespace, to keep it out of the official dune-istl API. That is a decision to be debated, however.

Before merging, the following details should be improved:

• The new method uses if constexpr, which is not allowed in the Dune core yet.
• It uses MatrixType::block_type. A more general implementation would use the return type of operator[].operator[] here.

In general I think such method would be very helpful.

Still some comments:

• Your implementation is C++-17, so I'd prefer a TMP or an overload to achieve the same
• There was once a "feature". You could force ISTL to directly invert at a particular level by explicitly choosing a different blocklevel. I doubt anybody ever used this feature, but that was one design goal. We should discuss whether we still want something like this. This might require a slightly different semantic. The lowest level would be the one, which is either a number type, or some special tag is specified...

• Your implementation is C++-17, so I'd prefer a TMP or an overload to achieve the same

Agreed. I did mention this in my original post. Feel free to beat me to it.

• There was once a "feature". You could force ISTL to directly invert at a particular level by explicitly choosing a different blocklevel. I doubt anybody ever used this feature, but that was one design goal. We should discuss whether we still want something like this. This might require a slightly different semantic. The lowest level would be the one, which is either a number type, or some special tag is specified...

The feature is still there, and it should work as before with this patch. Whether we want this at all is a separate discussion.

I like this approach very much . Changing this to C++14 should be simple. Once we implement this it would be nice to also implement

• maximalMatrixBlockLevel(), minimalMatrixBlockLevel(), hasUniformMatrixBlockLevel() for use with MultiTypeBlockMatrix (where the block_level member could never be implemented),
• corresponding *VectorBlockLevel() methods (maybe we don't need *Matrix* and *Vector* at all),
• corresponding methods taking a single argument of the desired matrix/vector type, to rely on template parameter deduction.
• return values of the type Dune::index_constant<i> instead of a plain int value i to make the single-argument versions useful despite them not being compile-time expressions in general.

To clarify my comment: This does not mean 'Hey @oliver.sander please also implement these methods.' I happily volunteer to do this myself, once there is consensus that we want to follow this approach and deprecate the block_level member.

It seems that the vector block level is never actually used within dune-istl.

still ist would be good to provide methods for both

Christian

added 177 commits

• 5cd945e4...9a64dc8c - 176 commits from branch master
• 45d3791b - Helper method to compute the matrix blocklevel

Compare with previous version

added 87 commits

• 45d3791b...8cd7d792 - 86 commits from branch master
• 4985a29a - Helper method to compute the matrix blocklevel

Compare with previous version

added 48 commits

• 4985a29a...4396b671 - 47 commits from branch master
• 0db085df - Helper method to compute the matrix blocklevel

Compare with previous version

mentioned in issue #89 (closed)

mentioned in commit 213fcaa4

mentioned in merge request !375 (merged)

As C++-17 is now required for the core... is this ready to merge? Or what is the state?

@christi I added a proposal that also works for MultiTypeBlockMatrices in !375 (merged)

mentioned in commit 0860cb49

mentioned in commit 85c3cd9d

Closing this, because !375 (merged) is much better.

closed

mentioned in commit 5cb9e992

mentioned in commit ebbc083e