Speed-up RBF matrix assembly

[davidscn]

Main changes of this PR

Speed up matrix assembly of the RBF matrices by a factor of ~2.2 for compute intensive RBFs and ~6 for simple RBFs (measured for matrix A).

Motivation and additional information

The matrix assembly is a considerable factor in the computeMapping step (depending on the system size). For small systems, the assembly step is dominant, for big system, the decomposition is dominant. These changes lead for the computeMapping step in a speedup of ~2.2 - 6.2 (for 150 vertices) to ~1.13 - 1.06 (for 13.300 vertices). Therefore, the interesting region for partition of unity mapping is accelerated considerably. In addition, there are several considerations to improve the decomposition strategies as well, which will make the overall relevance of an improved assembly more significant (see eg davidscn#3 ).

Depends on #1319.

Author's checklist

• I added a changelog file with make changelog if there are user-observable changes since the last release.
• I ran make format to ensure everything is formatted correctly.
• I sticked to C++14 features.
• I sticked to CMake version 3.16.3.
• I squashed / am about to squash all commits that should be seen as one.

Reviewers' checklist

• Does the changelog entry make sense? Is it formatted correctly?
• Do you understand the code changes?

[fsimonis]

We should consider using Eigen::Index for the iteration instead of hard coding the type.
Alternatively, we could use auto boost irange to hide both the type and the iteration.

[davidscn]

We should consider using Eigen::Index for the iteration instead of hard coding the type.
Alternatively, we could use auto boost irange to hide both the type and the iteration.

Thinking about it: how about using auto (which should in principle resolve to Eigen::Index) ?

[fsimonis]

The problem with using auto in for loops is that normally the end value has the desired type, but you need the type in the initializer of the for construct.

Defining the end outside the loop and then using decltype is one option.
Using some abstraction that captures the type like boost::irange is another possibility.

[davidscn]

Ah I see (and didn't know that). Then I will use the boost solution, thanks!

[davidscn]

We should consider using Eigen::Index for the iteration instead of hard coding the type.
Alternatively, we could use auto boost irange to hide both the type and the iteration.

For the sake of completeness let me add that we cannot exceed int in the current implementation though, because that's what we use in many places in preCICE, e.g., the mesh data structures.

[davidscn]

@fsimonis had a brief look at it.