Fix Version/s: None
Currently, the `test_te1` assertion tests for exact equality. Due to the floating point nature of these outputs and how they're generated on machines of varying architecture, exact equality cannot be guaranteed. Therefore, this ticket will replace the test for exact equality with the `assertAlmostEqual` constraint.
I suspect that this is a recurrence of
DM-29030, where treecorr needs the parameter brute=True in unit tests to reduce machine-dependent variation. If that doesn't work, we should probably drop this test (it's not worth this level of false-positive test failures).
DM-29030 explain why a binary installation on Springdale 7.9 fails the unit test at Princeton, but not on a freshly installed Springdale 7.9 VM? The underlying HW used is different but similar in architecture (x86_64). I would expect the conda/release install to yield reproducible results on Intel/AMD x86_64 unless there's something different in the run time setup.
Some environment override, different libraries picked up.
I have pushed a fix to the branch that sets brute=true in treecor, and makes the tests pass on jenkins, lsst-devl, and at least one machine that they were previously failing on. If someone wants to try the branch on any of the machines that were previously failing, I'd be interested to know if they still produce different results.
Implementing assertAlmostEqual, loosening the test conditions and understanding why tiger fails the test are three different tickets in my opinion.