This reverts merge request !564

Remove allocator template parameter from the classes
`base_array_unmanaged`, `compressed_base_array_unmanaged`,
`block_vector_unmanaged`, `compressed_block_vector_unmanaged`, and
`CompressedBlockVectorWindow`.
All of these classes do not manage memory on their own.
The provided allocator was only used to deduce `size_type`.
The latter is now provided as template parameter explicitely.

Notice that this (seemigly breaking) change is safe, because
all these classes are clearly marked as implementation details
that should not be used outside of dune-istl.

The `MatrixIndexSet` class provides access to an
incomplete subset of its internal data. While
the number of rows is exported, the number of cols
and the column indices per row have been missing
so far. This was an oversight, since one can hardly
use the class without this, unless one relies on
the dedicated `exportIdx()` method for `BCRSMatrix`.

With the missing data exported, one can now easily
use `MatrixIndexSet` to build patterns for
other sparse matrix classes.

No fixes necessary.

And test it!

... and move it in front of the method that calls it.
AIUI this facilitates template deduction.

Also, add a test for this.  It seems that not many people use this
method.  Otherwise the bug would have been noticed much earlier.

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.