Fix core computations in SkyPoint and StarObject, and a few other improvements.
There are quite a few changes here.
-
First and most importantly, fixes and improvements on
SkyPoint
core computation routines (SkyPoint::nutate
andSkyPoint::aberrate
), fixing regressions I introduced in 2016 as a result of shoddy algebra work. This now obviates the need oflibnova
versions since we achieve sub-arcsecond parity withlibnova
now (at least for the test-cases intest_skypoint
) everywhere including near the poles. We also do better thanlibnova
with aberration. This fixes issue #67 (closed). -
Secondly, I fix proper motion issues in
StarObject
. Firstly, the definition of proper motion used by most sources includes thecos(declination)
factor into the RA proper motion quoted. This is true of HIPPARCOS and SIMBAD, and it also seems to be true of our data sources (see point 5). Therefore I believe the change introduced in e4b6b189 is actually a regression, even though it comes from the right mathematical intuition, because of this widespread convention. The "Explanatory Supplement to the Astronomical Almanac" (referred to as "Seidelmann"), in my reading, does not explicitly mention this convention, but quotes the results assuming this convention, as does "Astronomical Algorithms" (referred to as "Meeus"). Moreover, the formula for interpolation used mixed conventions. It rescaled the RA component of the proper motion bycos(dec)
while computing magnitudes, but (I think) not so when computing direction. The solution in this MR is to replace it with the "official" formulation from Seidelmann. Seidelmann explains that ideally, we should be capturing the effect of the motion in the radial direction as well, but that is a bigger undertaking. I just treatedr
as constant (zero radial velocity) and canceled it out in the formulas. To compute the angles from the 3-D spatial vector that results, one usesatan2
: The 3-D spatial vector has unconstrained radius in the linear approximation applied in Euclidean space, so we must project it back to the surface of the sphere. Usingatan2
to recover the angles does this for us by making the result insensitive to the norm of the vector. The other change to Seidelmann's formula is to "absorb" thecos(dec)
factor into the proper motion, since this is the convention we should adopt in KStars (as described above).
All of this means, proper motion handling may have been wrong in KStars for the last 10 years (we aren't too far from J2000.0 though), and no one took notice...
- ... which means that we must add tests. Introducing
test_starobject
, which does end-to-end testing starting from catalog coordinates to fully corrected (i.e. proper motion + precession + nutation + aberration) equatorial coordinates for a given epoch. To generate test case data from an independent professional source, I just picked some stars from the FK5 catalog and punched them into Apparent Places of Fundamental Stars. The problem is that this only spans 1998--2021. If someone has access to the print editions before 1998, kindly add more test cases, while ensuring that the coordinate frame is FK5 throughout. :-)
The tests pass to sub-arcsecond accuracy! Perhaps the main sources of error come from the nutation and aberrations being approximate formulas, and from discrepancies in proper motion values (I got them from SIMBAD, it is not guaranteed that AIAPFS is using the same source).
-
To further strengthen the tests in
test_starobject
, I brought in the ERFA library as an optional test-only dependency of KStars. It is only used in the tests, and if available (would appreciate if more people could check this). ERFA aims to be as close as possible to SOFA which are IAU-blessed implementations of fundamental algorithms. I have thereafter implemented tests that checkStarObject::getIndexCoords
(the poorly-named proper motion method) against ERFA's implementation of proper motion. The tests pass with negligible error, but this of course does not guard against the garbage-in, garbage-out paradigm of supplying incorrect inputs to ERFA. However, the decreasing test error against the "Apparent Places of Fundamental Stars" with each subsequent fix supports that the proper motion implementation is implemented correctly (to the approximation where radial velocity is ignored). -
I also made some UI improvements to the Details Dialog that I used to verify the hypothesis about our catalogs' proper motion convention:
- Fixed the labels for fields that had
KSHelpLabel
- Added proper motion display for stars
- Fixed the font for Illumination / Proper Motion field There still are discrepancies in our proper motion values displayed from the catalogs (issue #125), but not enough to indicate an incorrect convention.