Before this patch `BCRSMatrix::addindex()` was used on individual
column indices. This is slow because each insertion does a binary
search although the inserted indices are already sorted. Bulk-inserting
whole rows with `setIndices()` improves on this significantly but still
does a non-necessary sort. The latter is avoided by the new
`BCRSMatrix::setIndicesNoSort()` method.

This is similar to `setIndices()` but does not sort indices
after insertion which allows to avoid an additional sort
on an already sorted range. The latter e.g. is the case when
using sorted containers as it is done in `MatrixIndexSet`.

Add line breaks.
Remove indentation as Doxygen treats it as <pre>.

This tests makes sure the matrices in the hierarchy get created in a deterministic way when the flag 'useFixedOrder' of the coarseningCriterion is set to true.

Lisa Julia Nebel authored 1 year ago and Lisa Julia Nebel committed 1 year ago

If set to true, the indices for the coarser grid will be created in a fixed order, making parallel runs reproducible but the runtime is possibly not ideal.
If set to false (which is the default), the order depends on the order of messages recieved from the processes responsible for the respective parts of the finer grid.
Then the indices on the coarser grid may differ from run to run.

CI failed before since the test matrix was singular.
This commit adds some regularization to pass tests on all runners.

Instead of calling the BCCSInitializer, we directly parse the matrix into
an UMFPACK compatible form. This allows us to use almost every blocked
matrix structure, such as MultiTypeBlockedMatrix. Moreover, the 'setMatrix'
method is extended by a second bitVector argument to handle exclusion of
indices. The old 'setSubMatrix' method is kept. The new interface is
inspired by the neighbored 'Cholmod' class.

The additional routines on the vector data are linear in time and have no
measurable influence on the run time of UMFPACK.

So far doxygen did not process this file since
`HAVE_SUITESPARSE_CHOLMOD` was missing.
This also adds the missing editor hints.

CHOLMOD supports this, it just wasn't exposed in the interface.
It is needed for large problems.

Using `std::uint_least32_t` instead of `std::size_t` halves the required memory
and thus also improves performance.
Notice that `std::uint32_t` is optional and `std::uint_fast32_t` is intended to be
fast in terms of computations and may have 64 bits. Here we're interested in reducing
memory and thus bandwith. Hence `std::uint_least32_t`, which is the smallest sufficient
type is most appropriate.

This replaces the `std::set` used to store the column indices for each
rows by a `std::vector` based implementation. The `std::vector` is
kept sorted when inserting such that we can avoid duplicates. This
can improve assembly time of matrices significantly (if `MatrixIndexSet` is used).

In the worst case (insertion in reverse) this may lead to O(n^2) complexity
when inserting n entries in a row compared to O(n log(n)) for `std::set`.
However, the sorted `std::vector` implementation still wins for relatively
large n. To avoid the worst case complexity when using very dense rows,
the implementation is switched to `std::set` if the size exceeds the threshold
value `maxVectorSize`. The default `maxVectorSize=2048` was selected based
on benchmark results.

The CMAKE_GUARD for multiple guarding variables requires a
porper boolean statement.

Possible bug in clang is tracked here:
https://bugs.llvm.org/show_bug.cgi?id=43124

Robert K authored 2 years ago and Andreas Dedner committed 2 years ago

use using and SizeType to size_type to adhere to istl conventions

Notice that this also fixes an incorrect `MultiTypeBlockMatrix::field_type`
in a special setting: If you have a nested matrix
`MultiTypeBlockMatrix< MultiTypeBlockVector<MultiTypeBlockMatrix<...>>>`,
the outer `MultiTypeBlockMatrix::field_type` forwards to the `MultiTypeBlockVector::field_type`
which forwards to the inner `FieldTraits<MultiTypeBlockMatrix>::field_type`.

This is to be consistent with other writers