[WIP DO NOT MERGE] switch kostrzewa/ddalphaamg to etmc/ddalphaamg

[kostrzewa]

Let's see what this does to the tests.

[kostrzewa]

@mtaillefumier In this test PR I updated DDalphaAMG in the workflow to use the latest commit of github.com/etmc/DDalphaAMG and to compile it with -std=gnu99 -Wall -pedantic -O3 -mavx2 -ffast-math -mfma -mtune=haswell -march=haswell -fopenmp. This results in 1b2935a which passes the test.

In c49d206 I've removed the -ffast-math flag, let's see if it behaves the same way as the test in #664

[kostrzewa]

Removing --fast-math in the DDAlphaAMG compile seems to produce a similar change in dH (column 3 of output.data) -- at least for line 16 -- as you have observed in #664.

What is a bit surprising is that unlike in #664, the last trajectory (line 20) of output.data is consistent with the reference one...

[kostrzewa]

Increasing the solver precision (de86ab6) in the input file used for the DDalphaAMG test increases the number of failures.

I think this is a situation where we should probably replace the reference files (doc/sample-output) and to choose a sensible solver precision in the input file (doc/sample-input/sample-hmc-ddalphaamg-tmcloverdetratio.input).

[kottnad]

cscs-ci run default

[chaoos]

So -ffast-math is one issue, but not the only difference. If we compile it in the exact same way, tests should agree without changing solver precisions, no? We only demand relative agreement up to 1e-4, which is not too precise anyways. If we just push the solver precision to 1e-24 or 1e-26 (I assume stuff is in double precision, so we can), these numbers would not agree better, since the reference number is imprecise, right?

[mtaillefumier]

I would agree that we should obtain the same answer if we build the library with the same parameters. Side note, I already changed the repository target in the cmake PR #664.

[kostrzewa]

If we compile it in the exact same way, tests should agree without changing solver precisions, no?

I'm not sure how and with which commit of DDalphaAMG I generated the reference output at the time so I'm not too surprised that we see deviations.

I agree that without threading we should obtain agreement again if we increase the solver precision throughout and regenerate the reference data (which should ideally be done on a different machine).