Hi,
Here a quick update over the current testsuite status:
Builds using gcc succeed in all tests - maybe in part because test data might actually have been produced using this. The problems we see usually come from the Intel compiler, but for different reasons.
Using default (simfactory) options, we have a couple of failures on most machines using the Intel compiler.
First, assuming an Intel compiler version > 11, all tests pass with fp-model set to precise. This is encouraging, as it means that the remaining failures there are caused by inaccuracies introduced by the compiler, which indicates one or multiple of three things (or both). Either the error-tolerance is set too low on the tests, the tests themselves have conceptional accuracy problems (e.g. the ones using Exact), or the simfactory compiler options are simply too inaccurate.
We have adapted some of the tests falling into the first category already. We have replacements for most tests using Exact already (which pass) and might therefore drop the old and known-to-be-problematic Exact testsuites before the release (we know that the problem is in Exact itself, which isn't as exact as the name implies). We are unlikely at this point to suggest to change compiler options. Most people wouldn't be using the precise options for the Intel compiler in their productions runs, and this environment is the one we have to test.
Another issue is the Intel compiler version 11. This seems to cause segfaults in some suites, especially hydro suites, and at the moment we suspect the usage of cray pointers to be the culprit. Higher compiler versions seems to be fine, but some machines don't have that option. This includes queenbee - the machine used for the Einstein Toolkit test accounts and the new users tutorial. We need to find a fix for this.
IDAxiOffBrillBH and RotatingDBHIVP suites seem to have problems on Loewe (and one of them on stampede). Only someone with access to Loewe could have a look at what happens there.
The only remaining problem I can see besides all these is the balsara4_1d test, and Roland is going to look into that.
Given this, I suggest to properly fix the tests, one way or another, and postpone the release at least to next week - and depending on availability of the people involved (SC13 next week) maybe the week after that (but don't count on it).
Frank