[Spice_announce] Changes to the SPICE SPK Subsystem
Charles H. Acton
Charles.H.Acton at jpl.nasa.gov
Mon Aug 27 14:25:01 PDT 2007
Planned SPICE Toolkit Upgrade Affecting the SPK Subsystem
===========================================================================
Overview
--------------------------------------------------------
NAIF plans to upgrade the algorithms used by the SPICE Toolkit's SPK
subsystem to improve the accuracy of certain velocity results returned by
that subsystem. NAIF is considering two implementation approaches,
described below. SPICE users who wish to offer comments on the pending
changes should send their comments by September 7, 2007 to NAIF group
supervisor Chuck Acton at
Charles.H.Acton at jpl.nasa.gov
Users could also send their comments to the open forum
"spice_discussion" Mailman list if they so choose:
spice_discussion at jpl.nasa.gov
NAIF will implement the SPK subsystem changes in the next official
Toolkit release, tentatively scheduled for December 2007. Making the
changes by one of the methods described herein is mandatory to properly
support the geometric event finding subsystem currently under
development, as well as to carry through on NAIF's policy of delivering
high accuracy computations for all Toolkit users.
The new algorithms improve the accuracy of velocities that are corrected
for light time alone, or both light time and stellar aberration. The new
algorithms use the same non-relativistic models for aberration
corrections as do the current SPK algorithms, but the new
implementations of the velocity calculations are more accurate.
The proposed changes will improve the accuracy of certain derived
quantities, including range rates and times of periapse or apoapse, when
aberration corrections are used. These changes will improve current
SPICE computations as well as being necessary for implementation of the
upcoming geometric event finding subsystem.
The changes will not affect the computation of aberration-corrected
position vectors, nor will they affect uncorrected (``geometric'')
states (position and velocity).
A few examples of the magnitudes of improvements afforded by the new
algorithms are shown below. All velocities are inertially referenced.
-- Range rate of the light time corrected position of the Moon as
seen from the DSN station DSS-25: 1 cm/sec
-- Range rate of the light time and stellar aberration corrected
position of the Moon as seen from DSS-25: 13 cm/sec
-- Range rate of the light time corrected position of Mars as seen
from DSS-25: 55 cm/sec
-- Range rate of the light time and stellar aberration corrected
position of Mars as seen from DSS-25: 1.6 m/sec
-- Range rate of the light time corrected position of Cassini as
seen from DSS-25: 9 cm/sec
-- Range rate of the light time and stellar aberration corrected
position of Cassini as seen from DSS-25: 3.4 m/sec
-- Velocity of the Neptune barycenter, as seen from DSS-25,
corrected for light time: 25 cm/sec
-- Velocity of the Neptune barycenter, as seen from DSS-25,
corrected for light time and stellar aberration: 400 m/sec
Negative effects of the changes are
-- Velocity computations using stellar aberration corrections
would be slower; the extent of the effect varies considerably
depending on the inputs to the computations, but tests indicate
that some common computations would be slower by a factor of 2.
But take note: since computation of aberration-corrected states
is usually a small fraction of the computational workload of
SPICE-based applications, the effect on the speed of
SPICE-based applications would not necessarily be substantial,
and in a majority of cases would likely not be discernable at
all.
Also note, the effect on speed of an application that simply
``reads'' state vectors from an SPK file would be nil since
aberration corrections are not used for this purpose.
-- The upgraded algorithms would change outputs of some
SPICE-based user applications. In these situations, a user's
regression tests could be affected.
-- If a user's application counts on the specific, current
implementation of velocity aberration corrections, a problem
could occur.
NAIF believes any possible negative consequences are outweighed by the
benefits of improved accuracy. But since some SPICE users may prefer to
have their applications perform exactly as before after re-linking
against a new SPICE Toolkit, NAIF is considering two implementation
approaches, one of which retains the current behavior of the SPK system
as the default.
Overview of Proposed SPK System Changes
--------------------------------------------------------
NAIF will implement the changes on parallel for all SPICE Toolkit
languages: Fortran, C, IDL, and MATLAB. For simplicity, in the
discussion below, SPICE module names will be shown only in Fortran.
The planned changes principally affect the velocity outputs from the SPK
API routines SPKEZR and SPKEZ. These routines correct states for
aberrations when any of the following correction flags
LT
LT+S
CN
CN+S
XLT
XLT+S
XCN
XCN+S
are used.
The two implementation approaches under consideration are described
below. Lists of benefits (which are perhaps incomplete) and costs are
included.
NAIF's Preferred Implementation Approach
Keep the set of aberration flag string values accepted by the SPK
routines SPKEZR and SPKEZ exactly as shown above, but change the
meanings of these flags: when these flags are passed to SPKEZR or SPKEZ,
use the new algorithms to compute aberration-corrected velocities.
Benefits:
-- Applications that use aberration-corrected velocities would
automatically produce more accurate results when re-linked with
the upgraded version of SPICE.
-- The SPICE SPK system interface would avoid an increase in
complexity: SPICE users wouldn't need to learn about a larger
set of aberration correction algorithms and flags used to
invoke them.
-- Documentation and example code illustrating use of the SPK API
routines SPKEZR and SPKEZ would remain as is, with the
exception of text discussing aberration-corrected velocity. In
particular, the already extensive SPK system documentation
won't have to be expanded to discuss means of invoking the new
algorithms.
Fewer documentation changes mean less work both for SPICE
developers and for readers of SPICE documentation.
Costs:
-- Slower execution speed when stellar aberration corrections are
invoked and full states (i.e. velocities as well as positions)
are being requested. (Maybe a negligable amount compared to
overall program execution time.)
-- Some outputs from some SPICE-based applications will change.
Some user's regression tests could fail as a result.
-- No convenient way is provided to invoke the old-style
aberration correction algorithms for velocity.
Alternative Implementation Approach
Add new aberration correction flags to the set shown above; the new
flags would invoke the improved algorithms. Keep the meanings of the
current flags exactly as is.
The specific flags that would be used to invoke the new algorithms have
not been decided, but one way of generating such strings would be to
prefix the light-time correction specification within each existing
value with the letter V, yielding
VLT, VLT+S, XVLT, XVLT+S, etc.
The sets of benefits and costs are basically the inverses of the sets
for the preferred approach.
Benefits:
-- Applications that use aberration-corrected velocities would
behave exactly as before when re-linked with the upgraded
version of SPICE.
-- SPICE SPK system execution speed would remain as before.
-- Any user's application that takes advantage of the specific,
current implementation of velocity aberration corrections would
perform as before.
Costs:
-- The source code of SPICE-based applications using
aberration-corrected velocities would have to be updated to
take advantage of the more accurate algorithms. The cumulative
cost of such updates could be substantial.
-- The SPICE SPK system interface would suffer an increase in
complexity: SPICE users would need to learn about and select
from a larger set of aberration correction algorithms and flags
used to invoke them.
-- The already extensive SPK subsystem documentation would
increase to describe use of the new aberration corrections.
Considerable SPICE development effort would be diverted to
updating documentation, delaying work on other tasks such as
the geometric event finder and shape model subsystems.
New Algorithms
--------------------------------------------------------
Below we briefly describe the differences between the old and new
aberration correction algorithms.
Light time
The current SPK light time correction algorithms introduce errors by
ignoring the rate of change of light time with respect to time. This
occurs in two places:
-- In computation of light-time corrected velocity referenced to
inertial reference frames
-- In computation of light-time corrected velocity referenced to
non-inertial reference frames centered at an object other than
the observer.
The new light time algorithms correct both of these errors.
Stellar aberration
SPICE supports stellar aberration correction only when light time
correction is used as well.
Currently, the velocity returned when light time and stellar aberration
corrections are used is identical to that returned when only light time
correction is used.
The new algorithm computes light time and stellar aberration-corrected
velocity as the derivative with respect to time of light time and
stellar aberration-corrected position.
Contact Info
===========================================================================
Interested SPICE users should send their comments by September 7, 2007
to NAIF group supervisor Chuck Acton at
Charles.H.Acton at jpl.nasa.gov
More information about the Spice_announce
mailing list