Use scale-relative tolerance for null-mode filtering

[harryswift01]

Summary

This PR is one step towards resolving #436, regression tests intermittently failing on CI but passing on rerun. It fixes a genuine numerical bug in the entropy calculation's null-mode filtering. This is not a complete fix for #436, some intermittent failures may still occur from a separate, unrelated cause that will be addressed separately.

Changes

Scale-relative null-mode filtering in vibrational entropy

• Uses a symmetric eigensolver (numpy.linalg.eigvalsh) instead of a general one, since the matrices involved are always symmetric.
• Replaces a fixed near-zero tolerance with one scaled to the eigenvalue spectrum's own magnitude, the same approach numpy.linalg.matrix_rank uses to separate numerical noise from a genuine near-zero value.
• Updates a regression baseline and its unit tests that had been relying on the old, fixed-tolerance behaviour.

Impact

• Fixes a case where numerical noise was being counted as a real physical contribution to entropy, producing an inflated result.
• No other behavioural changes intended; CodeEntropy's own calculation logic is otherwise unchanged.
• Some intermittent CI failures may persist after this PR, from a separate cause being tracked and addressed separately.

[jimboid]

This fix looks like it will fix the issue with random failing tests. One thing to note, pinning coretype to haswell like that has unintended consequences. Haswell is intel chip architecture, does it fail gracefully on arm and amd chips which are becoming more common on cluster machines and cloud?

[skfegan]

Looks like it will work. It makes sense to take advantage of the symmetry of the matrices.

[harryswift01]

This fix looks like it will fix the issue with random failing tests. One thing to note, pinning coretype to haswell like that has unintended consequences. Haswell is intel chip architecture, does it fail gracefully on arm and amd chips which are becoming more common on cluster machines and cloud?

I agree with this, I'm not 100% happy with this direction either so what I have done for now is reverse the pinning of the coretype and just left the initial fix. I've done this because I have done some more digging around and I have identified that there is a similar issue in MDAnalysis's principal_axes code, specifically it uses np.linalg.eig instead of np.linalg.eigh on a matrix that's always symmetric, which is the exact same class of numerical instability as the fix in this PR. MDAnalysis have already identified and fixed this themselves (switching to eigh), but have yet to release a version containing the fix. Once that version is out, I think we should stop seeing these intermittent failures.

[jimboid]

sounds good to me. Sarah is happy to too, so think you should merge.