Hello all,
We quickly discussed the failing tests, and given that the option list used (https://bitbucket.org/ianhinder/cactusjenkins/raw/d7021a52bd83448db589b2346c...) is not using -ffast-math or -mmarch=native the working assumption is that the occurrence of the failures is due to to an updated OS and newer compiler. Erik asked if we had a docker container for the Jenkins test slave, which we were not sure (there is a docker image at https://bitbucket.org/ianhinder/et-jenkins-slave though it is not clear if this is the one used).
after the call of course I realized what may cause differences even without -march=native or -ffast-math: the explicit vectorization in thorn Vectors depends on the machine architecture so different hardware (eg AVX2) will produce different vector code and thus different answers. Though given the thorns affected (GRHydro and SphericalHarmonicRecon) I doubt that it is the thorn's code itself but rather eg McLachlan or the fftw library (for the PITTNull code). This *may* cause differences though a different compiler *will* cause differences (in particular a different Fortran compiler).
Yours, Roland
On Mon, Mar 6, 2017 at 10:55 AM, Roland Haas rhaas@illinois.edu wrote:
Hello all,
We quickly discussed the failing tests, and given that the option list used (https://bitbucket.org/ianhinder/cactusjenkins/raw/
d7021a52bd83448db589b2346c43441682eecabb/build.cfg)
is not using -ffast-math or -mmarch=native the working assumption is that the occurrence of the failures is due to to an updated OS and newer compiler. Erik asked if we had a docker container for the Jenkins test slave, which we were not sure (there is a docker image at https://bitbucket.org/ianhinder/et-jenkins-slave though it is not clear if this is the one used).
after the call of course I realized what may cause differences even without -march=native or -ffast-math: the explicit vectorization in thorn Vectors depends on the machine architecture so different hardware (eg AVX2) will produce different vector code and thus different answers. Though given the thorns affected (GRHydro and SphericalHarmonicRecon) I doubt that it is the thorn's code itself but rather eg McLachlan or the fftw library (for the PITTNull code). This *may* cause differences though a different compiler *will* cause differences (in particular a different Fortran compiler).
That's a good point.
-erik
commits@lists.einsteintoolkit.org
-
Erik Schnetter -
Roland Haas