On 14 Nov 2013, at 00:55, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 7 Nov 2013, at 20:36, Frank Löffler knarf@cct.lsu.edu wrote:
Hi
So far, Ian ran tests on datura and I ran the testsuites, on my workstation. The gcc build shows no failures at all, but the intel suite shows 9, but in part different than the one on datura.
http://einsteintoolkit.org/release-info/parse_testsuite_results.php
In the following I try to give a short summary of some of the failures:
Exact/KS-tilted fails on my workstation. This has always been a fragile test.
This is likely due to the Exact thorn. It also fails on Stampede. I have added an EinsteinExact version of this test, and this passes on my laptop, on datura, and on stampede. I propose we remove the Exact version of this test, since the tested functionality is available in EinsteinExact, and Exact is anything but…
Some of the RotatingSymmetry180/90 testsuites fail on my workstation, due to tolerance, as suggested by the results. These are the Kerr testsuites, and at the same time the corresponding Kerr-EE suites succeed, suggesting a similar issue as with other Exact testsuites: insufficient accuracy of the initial data itself - or in other words a tolerance problem.
So, in short: apart from a hydro problem on datura we see the 'usual' Exact-related problems, a failure in balsara4_1d and in the testsuites of Multipole.
However, we need more results. Please test other machines as well!
Is your workstation optionlist in simfactory? What optimisation settings are you using?
The following tests:
E2xeon_test_rdbh (from RotatingDBHIVP) Kerr (from RotatingSymmetry180) Kerr-rotating-180 (from RotatingSymmetry180) Kerr-rotating-90 (from RotatingSymmetry90)
pass on stampede if I replace
-Ofast
with
-O3
-Ofast expands to -O3 -no-prec-div. -no-prec-div allows the compiler to replace x/y with x * (1/y) for speed reasons. This is advertised as potentially being less accurate, as opposed to just being different at the floating point level:
All tests pass on stampede if I use:
-O0 -fp-model strict -fp-model source
This at least gives us confidence that the problems on stampede are related to optimisation and floating point issues (though we pretty much knew this already).