How STK Automatically Loads SPICE Files

While satellites propagated by the SPICE propagator enable you to read in a specified SPICE file, planets and central bodies do not. Rather than specifying a file, they rely on STK's automatic loading mechanism, which begins when a scenario is created or loaded.

STK loads SPICE files located in following folders, in this order:

  1. <STK install folder>\STKData\Spice
  2. C:\ProgramData\AGI\STK <Version>\Spice
  3. <STK user area>\Config\Spice
  4. <STK scenario folder>\Spice

When you close the scenario, STK unloads all SPICE files.

You must be careful concerning the use of multiple SPICE files that contain ephemeris for the same object. When an object's ephemeris is not uniquely determined (e.g., there are multiple definitions of the ephemeris of the object at a given time because of multiple files containing overlapping data), SPICE itself resolves the conflict, using the latest file loaded that can handle the ephemeris request. Thus, in these cases the order of file loading is important. Although you can adjust file ordering through the Spice move Connect command, it is a best practice to resolve these conflicts outside of STK by using SPICE files that do not have overlapping ephemerides.

Be especially careful when loading SPICE files to avoid, if possible, loading new ephemeris for objects that have already been loaded by STK at startup. The SPICE BodyList report (available from the scenario) lists all the bodies loaded into SPICE, the files that contain ephemeris for each body, and a status (Active, Superseded, Partially Superseded) indicating whether a segment is used to handle ephemeris requests over its interval.

Consult STKData\Spice\ReadMe\ReadMe.txt located in the STK installation directory for information regarding which ephemerides are loaded by STK at startup. You can use SPICE utilities, provided by NAIF of JPL (the maintainers of the SPICE capability), for this purpose.

Asteroid numbering in SPICE

The convention used for numbering asteroids was updated by NAIF in 2023. The old convention was to assign a seven-digit number based upon the official or provisional five-digit designation for the asteroid. The updated convention is to use an eight-digit (or sometimes nine-digit) identifier, where already cataloged asteroids would use a number very similar to their seven-digit number. For example, the old number for Donaldjohanson is 2052246, while the updated number is 20052246. SPICE ephemeris files (*.bsp) may have been created using either convention, but going forward new files produced by JPL will use the updated convention.

STK ships asteroids.bsp containing a set of asteroids. This file uses the old convention for numbering asteroids. This file will be updated to use the new convention at the next major STK release.

As of STK 12.10, STK treats the old number and the updated number as being equivalent, in that both identifiers really indicate the same object. You should be aware, however, that this treatment may have consequences on the use of loaded SPICE ephemeris files (*.bsp).

  • When the set of SPICE ephemeris files contains data using only the old convention, STK will allow both the old and updated convention to indicate the asteroid.
  • Similarly, when the set of SPICE ephemeris files contains data using only the new convention, then STK will allow both the old and updated convention to indicate the asteroid. In this case, you must have removed asteroids.bsp from the SPICE install directory and provided one or more SPICE ephemeris files that use the new convention.
  • When the set of SPICE ephemeris files contains data using both conventions, then it is possible that different ephmerides may be provided for the same asteroid at the same time using the two different identifiers. In this case, STK ignores any SPICE ephemeris data associated with the old convention. STK continues to allow both the old and updated convention to indicate the asteroid, but only recognizes the loaded SPICE data associated with the new convention.