More robust tests for lalpulsar/bin/Weave
Description
The tests under lalpulsar/bin/Weave
include 3 tests (testWeave_interpolating.sh
, testWeave_non_interpolating.sh
, testWeave_single_segment.sh
) which compare the output of the Weave code against reference results. These work brilliantly on my laptop, but tended to fail with other platforms/compilers.
This MR is a attempt to make those tests more robust. The changes are:
- The Weave output FITS files no assign a unique serial number to each template, so that when comparing results from identical command lines one can match up the (integer) serial numbers instead of using the (floating-point) sky position, frequency, etc. which may not match exactly. This is potentially a backward-incompatible change for anyone using Weave output files, particularly if they're assuming the table columns have a particular order (instead of e.g. checking the actual column headings), so should be advertised to the CW group.
- Lots of hacking on
XLALWeaveResultsToplistCompare()
, the function that compares toplists, to try to coax it into being more robust. For example, all the detection statistic (F-statistic, line-robust, etc.) values in a toplist are now compared as a single vector instead of individually. - Relaxing of various tolerances to get the comparisons passing on a wider variety of platforms. The
testWeave_interpolating.sh
test was particularly troublesome in this regard.
In the end this was mostly successful; I got all the tests passing except for testWeave_interpolating.sh
on a) MacOSX, and b) with the Intel compiler. In the end the results on those platforms were just too different from the reference results for any useful comparison (and I'm not entirely sure why; the differences seemed greater than one could expect from round-off errors). So I've just disabled testWeave_interpolating.sh
on MacOSX and/or with icc
.
API Changes and Justification
Backwards Compatible Changes
-
This change does not modify any class/function/struct/type definitions in a public C header file or any Python class/function definitions -
This change adds new classes/functions/structs/types to a public C header file or Python module
Backwards Incompatible Changes
-
This change modifies an existing class/function/struct/type definition in a public C header file or Python module -
This change removes an existing class/function/struct/type from a public C header file or Python module
If any of the Backwards Incompatible check boxes are ticked please provide a justification why this change is necessary and why it needs to be done in a backwards incompatible way.