[Users] Test failures in CT_MultiLevel

[Eloisa Bentivegna]

On 14/10/15 20:40, Ian Hinder wrote:

> The second problem is that when I switch to OpenBLAS in the test
> parameter files, all tests pass except for
> CTThorns/CT_MultiLevel/test/boostedpuncture.par, which fails with 
> 
>    ml_bssn-ml_ham.d.asc: substantial differences
>       significant differences on 56 (out of 109) lines
>       maximum absolute difference in column 13 is 16.796401082424
>       maximum relative difference in column 13 is 10.214243488001
>       (insignificant differences on 45 lines)
>    ml_bssn-ml_ham.x.asc: substantial differences
>       significant differences on 88 (out of 182) lines
>       maximum absolute difference in column 13 is 5.30707663071086
>       maximum relative difference in column 13 is 0.897391183181081
>       (insignificant differences on 94 lines)
>    ml_bssn-ml_ham.y.asc: substantial differences
>       significant differences on 88 (out of 182) lines
>       maximum absolute difference in column 13 is 5.30900732375572
>       maximum relative difference in column 13 is 0.897408813491657
>       (insignificant differences on 94 lines)
>    ml_bssn-ml_ham.z.asc: substantial differences
>       significant differences on 56 (out of 109) lines
>       maximum absolute difference in column 13 is 5.30900949367607
>       maximum relative difference in column 13 is 0.8974032303582
>       (insignificant differences on 53 lines)
> 
> All other solution variables are within tolerance, suggesting that the
> solver is getting the right answer, though ml_ham would be more
> sensitive to small solution differences anyway.  None of the other
> CT_MultiLevel tests seem to be checking ml_ham, so it might be that if
> ml_ham was checked, it would also differ.  Could this be related to the
> McLachlan rewrite, or is the Hamiltonian constraint expected to be the
> same across the rewrite?  It could be the usual roundoff-error problem,
> but the differences listed are quite large.  Or maybe this comes from
> the method used by the elliptic solver, which may not be 100%
> deterministic due to thread ordering in the Gauss Seidel method?

Hi Ian,

thanks for detecting this. As this is meant as a general-purpose solver,
not all the tests involve McLachlan (or even General Relativity). So you
are right: what you see may be a generic problem with the computation of
the Hamiltonian constraint, and not something specific to the puncture test.

The test, however, passes (at least on my workstation) using
BLAS/LAPACK, so the McLachlan rewrite does not necessarily have to be
responsible for the differences you see. Do you know if there are other
tests that compute ml_ham and are affected by a swap between the two
library implementations?

As for the first point you raise, I have just pushed a change following
Roland's suggestion to remove the redundant "ActiveThorns" line from the
test parfiles.

Best,
Eloisa