-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tests/test_Galactic.py::TestGalactic::test_proper_motion_identity failing #1759
Comments
Errors look like:
|
And 1.3e-14 deg = 5e-11 arcsec |
I don't think this is due to #1748. This test works on my system on the following setup:
But it fails on the following setup:
So probably a version issue. |
astropy v6.1.0 was tagged two days ago. So it may be an astropy-related issue. |
The test goes through when I restrict astropy<6.1.0. |
The issue seems to go away if I remove the But that causes other tests to fail. |
@dlakaplan What do you think? |
Thanks for investigating. Maybe the reason it was showing up only in some tests and not others was just a coincidence about when they started wrt when the astropy bump happened. I think the simplest fix for now would be to increase the tolerance in the failing test. 5e-11 arcsec is still very small and it would pass. Or we could restrict the astropy version until we understand the origin of the difference. If those dummy functions are the issue there might be some change to the API. |
Oddly, this test compares two copies of what should be the same coordinate against each other. But I'm finding that the distance returned is not symmetric: I think we could fix this test by reversing the order of the calculation, but I'll try to understand the origin. |
OK, narrowing things down. I think that somehow this issue relates to units & precision. It compares the RA as hourangles, not degrees. The difference there is ~machine precision (8e-16). But then it gets multiplied by 15 to get degrees, and we see a difference of ~1e-14. I don't know exactly why this computation is different here, but I think that it isn't meant to be. Whether this is an astropy bug or what it will only crop up in rare situations. So I think we can fix just by reversing the operation order. |
Fix #1759 (coordinate comparison identity)
This test evaluates a position at the POSEPOCH and compares against the baseline position. The threshold is set to 1e-11 arcsec. Normally this passes but I've been having intermittent failures. I don't know why it's intermittent (it should be deterministic) and only on some architectures. I also don't know if this is due to #1748.
Any ideas @abhisrkckl ?
The text was updated successfully, but these errors were encountered: