Competing Kernels
Last updated 29 October 2013
What constitutes competition?
Within the SPICE system there is a notion of "competing kernels." The circumstances leading to competition are different for binary kernels versus text kernels, while the end result is quite similar. When competition exists, one datum or set of data wins out over (we say takes precedence over) another.
The following very brief explanations of "competition" are simplifications. Those interested in the exact details should examine Appendix A of the SPICE Kernel Required Reading technical reference document.
Competition in binary kernels (most often SPKs or CKs) occurs when two kernels with the same or overlapping time spans contain data for the same object. (This is a substantial simplification, but conveys the general idea.)
Competition in text kernels (most typically PCKs, FKs, and IKs) occurs when two kernels contain the same keyword in any KEYWORD = VALUE assignments.
For binary kernels, the last loaded kernel takes precedence. For text kernels, a competing assignment in the last loaded kernel takes precedence over a similar (same keyword) assignment in an earlier loaded kernel.
Why is understanding this important?
Suppose you select both the MRO and the Solar System Kernels sets. In this case you will have loaded two ephemeris (SPK) files for Phobos and Deimos:
- mar063.bsp from the MRO kernel set
- mar097.bsp from the Solar System Kernels set
These two SPK files have somewhat different ephemerides for Phobos and Deimos. Maybe it makes no difference to you which of the two files takes precedence. Then, no problem. But suppose you are trying to replicate some previous results, or build on some previous analysis. In this case you may wish to be sure you are using the previously used ephemeris file. The one that WGC will use is the one from the last loaded of the two meta-kernels.
A similar complexity can arise for the orientation or size/shape of a planet or satellite, if two different PCKs are loaded that contain some of the same keywords, but having different value assignments. There is no easy answer to avoiding such a problem—the user need carefully look at (read) the actual kernels being loaded, and be aware of the SPICE kernel loading precedence rules, to ensure the desired data will be used in WGC computations.
Practical Advice
In general, when loading two or more named kernel sets, try to load them in the following order. (Skip any not needed.)
- Load Solar System Kernels first to give them the lowest priority
- Load Ground Station Kernels next to give them higher priority
- Load kernel set(s) for older missions (e.g. MGS) next, with even higher priority
- Load kernel set(s) for more recent missions (e.g. MRO) next, with almost the highest priority
- Load Latest Leapseconds Kernel last, with the highest priority
Finally, should you wish to use the latest body size, shape and orientation data obtained from the IAU and published in the most recent SPICE Planetary Constants Kernel (PCK), then...
- Load Latest Planetary Constants Kernel, thus overriding those contained in the mission kernel set(s).
This advice won't always work but in most cases it will guarantee that the aggregate loaded kernel set maintains consistency between the spacecraft trajectory and the natural body ephemerides included in the archives, and that the latest LSK is always used instead of the older LSKs provided in the archives. Because there are often many different body-fixed reference frames (often referred to outside of SPICE as "coordinate systems") and body size and shape models, you need to pay extra special attention to the PCK data you are using within WGC!