[Spice_announce] Changes to the SPICE SPK Subsystem

[Charles H. Acton]

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