Re: [Users] Test failures

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:

   -prec-div
   -no-prec-div
          Improves precision of floating-point divides.

          Architectures: All

          Arguments:

          None

          Default:

          -prec-div         The compiler uses this method for floating-point divides.

          Description:

          This option improves precision of floating-point divides. It has a slight impact on speed.

          With  some  optimizations,  such  as  -msse2  (Linux* OS) or /arch:SSE2 (Windows* OS), the compiler may change float-
          ing-point division computations into multiplication by the reciprocal of the denominator. For example,  A/B  is  com-
          puted as A * (1/B) to improve the speed of the computation.

          However,  sometimes  the  value  produced by this transformation is not as accurate as full IEEE division. When it is
          important to have fully precise IEEE division, use this option to disable the floating-point  division-to-multiplica-
          tion optimization. The result is more accurate, with some loss of performance.

          If  you  specify  -no-prec-div (Linux* OS and OS X*) or /Qprec-div- (Windows* OS), it enables optimizations that give
          slightly less precise results than full IEEE division.

Looking through the optionlists, we very rarely use this. -Ofast is used only in these cases:

simfactory/mdb/optionlists/bluewaters-gnu.cfg:CXX_OPTIMISE_FLAGS = -Ofast -funroll-loops simfactory/mdb/optionlists/compute-intel.cfg:CXX_OPTIMISE_FLAGS = -Ofast simfactory/mdb/optionlists/compute.cfg:CXX_OPTIMISE_FLAGS = -Ofast -funsafe-loop-optimizations simfactory/mdb/optionlists/hopper-intel.cfg:CXX_OPTIMISE_FLAGS = -Ofast simfactory/mdb/optionlists/stampede-hybrid-mic.cfg:CXX_OPTIMISE_FLAGS = -Ofast simfactory/mdb/optionlists/stampede-hybrid.cfg:CXX_OPTIMISE_FLAGS = -Ofast simfactory/mdb/optionlists/stampede-mic.cfg:CXX_OPTIMISE_FLAGS = -Ofast simfactory/mdb/optionlists/titan-intel.cfg:CXX_OPTIMISE_FLAGS = -Ofast

I suggest that for the release, we replace -Ofast with -O3 in the above machines, and make sure we don't use -no-prec-div.

After the release, I think we should come up with a standard set of optimisation settings that we use for all machines. If there is a good reason to choose something else for a specific machine, then fine, but this should be documented in the optionlist; I expect that the choices at the moment are fairly arbitrary.

The tolerance in one case would have to have been increased from the Cactus default 1e-12 to 1e-8 for the test to pass with -Ofast.