[Users] Test failures

[Ian Hinder]

On 14 Nov 2013, at 00:55, Ian Hinder <ian.hinder at aei.mpg.de> wrote:

> 
> On 7 Nov 2013, at 20:36, Frank Löffler <knarf at 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).

-- 
Ian Hinder
http://numrel.aei.mpg.de/people/hinder

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20131114/c91d62a1/attachment.bin