martin-ueding
commented
7 years ago Now all tests are enabled again. The BiCGStab API has changed a bit, so minor changes were required. As expected, nothing works any more. There are slight deviations (around 1e-08) in some spinors, so that is not good, but not that bad either, I guess.
The BiCGStab tests do not converge, but that seems to be unsurprising with that particular algorithm.
My current issue is the redundancy of the code. There are so many copies of the code that generates the random gauge field, generates the clover field. Also the part that compares the spinor is redundant but not copied exactly. Ideally, I would refactor everything to use the new Google Test structure. But my time is limited. So I will do the following:
- [x] Write a function/class that generates a random gauge field and the matching clover term using the QDP++ methods.
- [x] Write a function that compares QDP++ spinors and gives a nice presentation of the differences.
- [x] Use the RAII containers for the spinors, gauges, clover terms in order to remove all this manual resource handling.
This should reduce the code size already and make it more reliable. Especially since all problems use the same gauge field, one does not test with a unit gauge field without noticing.
In the tmLQCD interface we currently see that the solver for Wilson works, for Wilson twisted mass it does not converge. We assumed that all the QPhiX code had been properly tested against QDP++. On further inspection we saw that not all the tests are run. Sometimes they are commented out with
#if 0, sometimes they only run on certain architectures.I had disabled the tests on the scalar architecture because they failed. Since the tests on AVX did not fail, it seemd okay. However, different tests run on AVX compared to scalar, so actually passing the AVX build+test does not really say anything.
In order to get strong tests, I will enable all the tests that we have and run them all. Especially the Wilson twisted mass test fails for the first ten-ish elements, but nothing else. That is very dubious and we need to fix that before we can meaningfully advance with the tmLQCD interface.