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 _______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
