Add core and reference multiprecision tests

[tcojean]

This PR adds multiprecision tests for the core and reference modules. In addition to this, all non matrix, solver and preconditioners in the OpenMP module also have multiprecision tests.

The changes are stopped here in this PR for multiple reasons:

• There is already more than 11K lines of code changes
• Some matrices, solvers and/or preconditioners have terrible OpenMP, CUDA and HIP timings which would impact very negatively the testing timings. So far, the added changes should not make the tests much slower.
• HIP and CUDA have multiple kernels which do not support complex types or int64 index types, so a significant effort is required there.

There is a lot of changes, but a lot of the changes are similar. Some changes had to be done to multiple places in order to fix issues with classes not properly supporting multiple precisions, or add new testing features. I will detail these later.

Summary of changes

• All core tests rewrote for multiple precisions
• All reference tests rewrote for multiple precisions
• Extra OpenMP tests rewrote for multiple precisions (non matrix, solver or preconditioner).
• codecov is put back into Ginkgo, and our coverage significantly improved thanks to the templated tests
• In core/test/utils.hpp, a bunch of declarations were provided for default values we want to tests, and other tools used when doing multiprecision tests.
• In core/test/utils/assertions.hpp, get_relative_error and other commonly used functions from the assertions were extended for the complex value case (using gko::remove_complex most of the time). A new assertion was added for comparing values of complex type (GKO_ASSERT_NEAR, which extends the basic gtest one ASSERT_NEAR).
• Papi required some fixes (counting the instances of Papi loggers globally instead of per template valuetype).
• Ilu required some fixes (using gko::remove_complex and removing default valuetype use of <>).

How to write templated tests

core/tests/utils.hpp always needs to be included because it provides required definitions.
In general, if only one kind of precision (e.g. value_type) is required, then normal templating can be used, otherwise, due to the use of the macro for declaring the templated values to try, a tuple which contains all the elements need to be defined, see the reference/test/matrix/csr_kernels.cpp for example.

template <typename ValueIndexType>
class Csr : public ::testing::Test {
protected:
    using value_type =
        typename std::tuple_element<0, decltype(ValueIndexType())>::type;
    using index_type =
        typename std::tuple_element<1, decltype(ValueIndexType())>::type;
};

Afterwards, the class needs to be instantiated for all precisions, which is done such as in the following way:

TYPED_TEST_CASE(Csr, gko::test::ValueIndexTypes);

Note that ValueIndexTypes is provided by utils.hpp and contains tuples of all valuetype and index type combinations.

As a requirement, the tests now need to use the macro TYPED_TEST instead of TEST_F. This has multiple implications:

• All member objects/functions have to be accessed with this->.
• All member definitions such as using need to be accessed through TestFixture::Mtx for example. The approach I used is to add to every test the required using shortcut to make the tests look nicer.
• A variable TypeParam is provided which is the template type of the test.
• Due to complexes being able to be built with {real, img} notation, our initializations of the form {{1.0, 2.0}, {3.0, 4.0}} are ambiguous (the second {). I provided a shortcut I<type> for stating that this is actually an initializer list of type T, and not a complex construction. So the following example would be replaced with:

using T = typename TestFixture::value_type;
auto mtx = gko::initialize({I<T>{1.0, 2.0}, I<T>{3.0, 4.0}}, this->exec);

Finally, I implemented a shortcut r<value_type>::value for providing depending on the type of the value a proper precision (1e-7 for float and std::complex<float>, and 1e-14 for double variants).

Sort of closes #32

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (develop@c1ac9f4). Click here to learn what that means.
The diff coverage is 98.43%.

@@            Coverage Diff             @@
##             develop     #448   +/-   ##
==========================================
  Coverage           ?   91.59%           
==========================================
  Files              ?      294           
  Lines              ?    19585           
  Branches           ?        0           
==========================================
  Hits               ?    17938           
  Misses             ?     1647           
  Partials           ?        0

Impacted Files	Coverage Δ
include/ginkgo/core/preconditioner/ilu.hpp	60.56% <0%> (ø)
reference/test/log/convergence.cpp	91.66% <100%> (ø)
reference/test/solver/bicgstab_kernels.cpp	100% <100%> (ø)
reference/test/solver/lower_trs_kernels.cpp	100% <100%> (ø)
core/test/matrix/identity.cpp	100% <100%> (ø)
core/test/solver/lower_trs.cpp	100% <100%> (ø)
omp/test/components/prefix_sum.cpp	100% <100%> (ø)
reference/test/solver/upper_trs.cpp	95.65% <100%> (ø)
core/test/base/array.cpp	100% <100%> (ø)
reference/test/matrix/sparsity_csr_kernels.cpp	97.88% <100%> (ø)
... and 56 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c1ac9f4...5b13903. Read the comment docs.

[yhmtsai]

I also compiled it on Windows. There are some problems with I<T>, std::initializer_list<T>
reference/test/base/{combination,composition,perturbation} and reference/test/matrix/dense_kernels use I<T>. Their value is not correctly set by I<T>{a, b}.
the workaround method uses I<T>({a, b}).

Also, need () for gko::Array initialization in class initialization.
In reference/core/test/utils/assertions_test, mtx13_row_ptrs{0, 3, 4} should be mtx13_row_ptrs({0, 3, 4}). Otherwise, MSVC gives the error c2059 and c2344 ( Related:
https://docs.microsoft.com/en-us/cpp/error-messages/compiler-errors-1/compiler-error-c2059?view=vs-2019)

[tcojean]

@yhmtsai Thanks for testing this. You mean that all I<T>{...} needs to change to I<T>({...}) ?

[thoasm]

LGTM!

[tcojean]

Everything should be fixed to the limits of what I think is doable. Please check the last commit.

[upsj]

Great work, LGTM! Regarding the 0 tolerance assertion: Using values that can be represented exactly in IEEE float might help here.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities (and 0 Security Hotspots to review)
0 Code Smells

0.0% Coverage
0.0% Duplication

[pratikvn]

Great work on this! LGTM!