Light Time/Stellar Aberration Correction Errors
ISIS uses the NAIF SPICE toolkit for calculating much of our geometry properties. One of the quantities computed is the position of a target body (planet, asteroid, etc...) relative to an observer (typically a spacecraft) while considering light time (planetary aberration) and stellar aberration corrections.
In our ISIS implementation, we had the target and observer swapped in the NAIF SPICE toolkit routine (spkezr_c) which, depending upon the observing conditions, can result in significant positional errors (in the MESSENGER case, a 1 kilometer error in s/c position in body fixed coordinates, and several hundred meters on the ground have been reported by an external source).
Furthermore, the NAIF SPICE routine (surfpt_c) currently used in ISIS providing surface intercept positions is not considering light time and stellar aberration affects. Higher degree of accuracy can be attained when using the surface intersection location (on the ellipsoid) whilst applying these aberration corrections. There is a different routine (sincpt_c) that provides this computation. Applying this correction also affects ground position accuracy.
The impact of the correction of these issues is expected to be significant, but not fully quantifiable until the corrections have been made.
NOTE: This error also exists in ISIS2 and PICS.
Steps to reproduce:
#1 Updated by Tammy Becker over 6 years ago
This issue was discussed in the Software Steering Committee; current and historical information; as well as solution was presented by Debbie Cook.
Impact will be on every mission/instrument that uses the light time correction.
Missions such as Lunar Orbiter will not be affected; this correction is 'turned off'. ApolloMetric/Pan probably should not be using this correction either.
All Level0/1 images will need to be re-spiceinit-ed when implemented.
#4 Updated by Debbie Cook about 6 years ago
I created 4 versions of isis for quantifying the light time correction problem:
Under each of these directories is an isis build with limited functionality (level 1 processing only) and a test directory. The test directory contains subdirectories for Dawn, LRO, Messenger, Mex (HRSC), MocWA, Themis, and Vims. Each of the mission-specific test directories contains at least one test image. I reduced test images that were large or multi-band to a single band that would run in less than a day. I modified phocube to produce a LT correction band and changed its defaults to LT, altitude, slant range, latitude, and longitude. For each test image I created a geometry cube with these 5 bands under the four isis builds.
The m00909-switchObserverTargetLTsurface results can be considered to be the desired output. The LT/aberration corrections are done with observer and target switched and the distance used is from the observer to the surface of the target.
The m00909-switchObserverTargetCNsurface results are the most accurate. The CN implementation is identical to the LT version above, but uses Naif's CN calculation for aberration. This causes the algorithm to iterate more. For most cases the single iteration of the LT algorithm is sufficient. I created this version to test if the increased accuracy was significant for any of our data/processing. Naif recommends the CN correction when the observer is "far" from the target and when the viewing geometry is near to tangential.
The m00909-switchObserverTarget results have the LT calculation calculated in the right direction, but still to the center of the body instead of the surface.
For many cases this correction alone handles the bulk of the error in Isis.
I created the m00909-existingIsis results for comparison purposes only.
If you would like to do your own testing, you can setisis to any of these 4 versions and run level1 programs (campt, phocube, etc.) Be aware that both the LT and CN versions are using sincpt to get accurate results with respect to LT, but they are VERY SLOW.
#5 Updated by Debbie Cook about 6 years ago
The light time/aberration calculation errors in Isis originated as far back as Pics. When we first started using Naif to compute spacecraft positions, I don't think we were applying light time corrections. I do remember using light time corrections for Nims back in the 90's and correctly specifying observer/target to get the stellar aberration correction right. I don't know why I missed the error in all the other Pics and Isis code.
We have 3 problems in the use of light time/aberration corrections in Isis currently.
1) In the computation of the spacecraft position, the observer and target are switched. If a light time correction is applied, the target body's velocity will be used to determine the stellar aberration correction component of the LT value returned by Naif instead of the observing spacecraft's velocity.
2) The spacecraft position from 1) is rotated to body-fixed and used in surfpt to calculate the intercept with the triaxial ellipsoid target body. The light time/aberration correction computed in 1) is NOT applied in Isis when rotating the J2000 spacecraft position to body-fixed. surfpt does no other light time correction. In other words, the light time correction is not only incorrectly computed in 1), but it not applied in determining the intercept. In order to apply LT, the body-fixed rotation matrix used to rotate the spacecraft position needs to be retrieved at time et - LT, where et is the time of the observation and the time used to retrieve the spacecraft position.
3) Even if we did apply the light time/aberration correction in 2), because surfpt does no adjustment to the spacecraft vector, we are using the distance to the center of the target body to determine the light time component of the LT value returned by Naif instead of the distance to the surface. Naif has a newer routine (sincpt) that is highly accurate and intersects triaxial ellipsoid bodies accounting for LT correctly to the surface. Isis can't use sincpt for every pixel because it is slow (60x) and requires the kernels to be loaded. To be able to be reentrant and thread-safe, Isis loads kernels into tables in the cube labels.