Tobias Ribizel

Add tuning to reduction kernels and improve tuning

2

This uses the tuning parameter #692 to enable tuning the oversubscription parameter for kernel reductions, and adds vendor BLAS reductions to the benchmark TODO: - [ ] Tune CUDA -...

We rarely document which operators support in-place operations `A->apply(x, x)`, but we should do that at some point. A possible solution would be comparing the pointers b and x to...

Document precision and determinism guarantees in Ginkgo

3

Motivated by #741: Our SpMV formats and BLAS operations have different properties in terms of bitwise equivalence (determinism) and precision in general. It would make sense to document them more...

Data validation and invariants

4

We had some discussions about specifying and validating data structure invariants, so I'll list them here: ### Matrix formats * All formats: values contain no NaN or Inf values *...

We had this discussion on Slack already, but I wanted to keep this documented: Currently `LinOp::apply(alpha,a,beta,b)` computes `b

Test solvers and preconditioners with complex values

1

We currently don't do any solver and preconditioner tests with complex values. For generality, we should change that! Some implementations contain bugs in that regard. Examples: https://github.com/ginkgo-project/ginkgo/blob/500d4a5719ab0b60f76f7f5cbc6f77fd6254f544/reference/solver/gmres_kernels.cpp#L90

Unifying kernel tests

2

At the moment, all of our non-reference kernel tests are basically the same (except for the templated tests, but I will get to that): We generate some random matrices or...

`GKO_` has a lot less potential for typos than `GINKGO_`, which is especially important when you have to set many options at configure-time. I would thus propose to replace the...

Improve ILU preconditioner interface

5

Currently, `preconditioner::Ilu` has some shortcomings, as it only supports ILU(0), doesn't allow setting factorization parameters, needs multiple template parameters to statically ensure equal `value_type` for its components, and at its...

Add configuration option to choose `#include <...>` vs. `#include "..."` based on path

3

The clangd `IncludeFixer` uses `#include ` for system headers (`-isystem`) and `#include "..."` for everything else (relative path or `-I`. I think it would make sense to make it configurable...