AIAA 2008-6278
AIAA/AAS Astrodynamics Specialist Conference and Exhibit
18 - 21 August 2008, Honolulu, Hawaii
cite peer-reviewed, updated version:
Arora, N., Russell, R. P., “A Fast, Accurate, and Smooth Planetary Ephemeris Retrieval System,” Celestial Mechanics and Dynamical Astronomy, Vol. 108, No. 2, 2010, pp. 107-124,
DOI 10.1007/s10569-010-9296-0
FIRE: A Fast, Accurate, and Smooth Planetary Body
Ephemeris Interpolation System
Ryan P. Russell∗and Nitin Arora†
Georgia Institute of Technology, Atlanta, GA, 30332-0150,U.S
Precise trajectory simulations typically require an ephemeris system, i.e. some mechanism to identify planetary body states and orientations at given times. However, the
ephemeris systems most commonly used throughout industry and academia are, by design,
general in their capabilities and application. Here, we introduce a new system called FIRE
that is designed for custom trajectory applications that favor speed and smooth derivatives.
The new system minimizes the overhead associated with ephemeris calls through the use of
archived splines, a runtime ephemeris (stored in random access memory), an efficient tree
navigation algorithm, and vectorized calls. Further, our approach naturally provides first
and second time derivatives for a small additional cost. The derivative capability is particularly attractive for optimization and targeting where smooth and accurate derivatives
are important. Relative performance comparisons with the Jet Propulsion Laboratory’s
SPICE ephemeris system shows typical speed improvements of approximately two orders
of magnitude for various state and orientation calls.
Nomenclature
Symbol
a, e, i, ω, Ω, ν
A
N
y0
V
w0
h
t
t0
M
i
x, y, z
u, v, w
G
m
α
β
γ
JD
Nr
CP U
wrt
Description
Classical orbital elements
Tridiagonal matrix
Number of knot pairs
State vector
Interpolated variable at each knot
Knot to current time distance
Knot to knot distance
Current Time
Epoch time
Scaled second derivatives at knots
Current knot index
Components of position vector
Components of velocity vector
Gravitational constant (6.673E−20 km3 /kg/s2 )
Mass of the body
1st Euler angle
2nd Euler angle
3rd Euler angle
Julian Date
Normalizing factor
Central Processing Unit
With respect to
∗ Assistant Professor, Guggenheim School of Aerospace Engineering, Georgia Institute of Technology, 270 Ferst Drive, Atlanta,
GA, 30332-0150, 404-385-3342 (voice), 404-894-2760 (fax), ryan.russell@gatech.edu
† Graduate Student, Guggenheim School of Aerospace Engineering, Georgia Institute of Technology, 270 Ferst Drive, Atlanta,
GA, 30332- 404-483-7015, narora9@mail.gatech.edu
1 of 20
American Institute of Aeronautics and Astronautics
Copyright © 2008 by Ryan P. Russell and Nitin Arora. Published by the American Institute of Aeronautics and Astronautics, Inc., with permission.
cite peer-reviewed, updated version:
Arora, N., Russell, R. P., “A Fast, Accurate, and Smooth Planetary Ephemeris Retrieval System,” Celestial Mechanics and Dynamical Astronomy, Vol. 108, No. 2, 2010, pp. 107-124,
DOI 10.1007/s10569-010-9296-0
IV F
NPR
EM S
JP L
FFT
RAM
ACE
RACE
JM SS
F IRE
SP ICE
P LEP H
M IN GM
Intel Visual Fortran
Number of Points per Revolution
Earth-Moon-Sun
Jet Propulsion Laboratory
Fast Fourier Transformation
Random Access Memory
Archived Cubic Spline Ephemeris
Runtime Adaptive Custom Ephemeris
Jupiter-Moons-Saturn-Sun
Fast Interpolated Runtime Ephemeris
Spacecraft Planet Instrument C-matrix Events
PLanetary EPHemeris
Min Gm value
I.
Introduction
Solar system ephemeris body states and orientations are consistently used in a variety of aerospace applications.1,2,3,4,5,6 The importance of the solar system data, robust reliability of the current ephemeris
systems (like JPL’s SPICEa ), and the need for highly precise trajectory computations have led to wide
spread use of ephemerides amongst scientists, engineers, astronomers, and their associated softwareb . The
current state-of-the-art ephemeris system in wide use today for high precision applications is the SPICE
system provided by JPL. Similar SPICE related products from JPL such as the DE405 customized routines
by Miles Standish7 are also commonly used.
While SPICE and its derivative products are well maintained and provide invaluable capabilities to users
around the world, it is well known that ephemeris calls are generally the bottleneck to speed improvements for
precise applications. Typical trajectory simulation applications including optimization, differential correction, orbit determination, and Monte-Carlo analysis often require thousands or more trajectory propagations
using common force models and time spans. Considering each single iterate may easily require millions of
calls to an ephemeris system, an extraordinary amount of computational resources is wasted in the presence
of any unnecessary overhead. While a broad spectrum of applications are indifferent to the computational
burden of general ephemeris calls, many applications are simply bogged down. However, the extra cost
has typically been considered an acceptable trade for the precision force model afforded by the accurate
ephemerides. Therein lays the motivation of the current work: In this study we propose a new custom
ephemeris system that maintains the heavily relied upon accuracy, yet eliminates or substantially reduces
the typical computational burdens associated with ephemeris calls.
We propose FIRE, a fast and efficient ephemeris generation system. FIRE is particularly suited for
problems that favor higher speeds and smooth derivatives, such as trajectory optimization8,9,10,11 orbit determination12,4,13,14,6 and Monte Carlo sensitivity analysis.15,5 The new system generally favors speed in
sacrifice of relatively larger memory requirements. The basic structure consists of an internally formatted,
archived ephemeris (created from an already established ephemeris such as SPICE) and a problem dependent, dynamically created runtime ephemeris called the RACE. Implementing a runtime ephemeris stored
directly in RAM significantly reduces the overhead associated with retrieving the data for multiple runtime
ephemeris calls.
Various numerical techniques such as a fast and efficient cubic spline interpolation for ACE generation,
FFT for identifying base frequencies, vectorized runtime calls to reduce overheads, intelligent tree structure
evaluation to eliminate redundancy, and numerically stable floating point evaluations have been implemented.
FIRE also provides the user with accurate and analytic first and second time derivatives for all the ephemeris
states (position, velocity) and orientation matrices. This valuable derivative feature is absent from SPICE
a URL:
b URL:
http://naif.jpl.nasa.gov/naif/spiceconcept.html [cited 11 August 2008]
http://www.stk.com/products/desktopApp/odtk/index.cfm?tab=overview [cited 11 August 2008]
2 of 20
American Institute of Aeronautics and Astronautics
cite peer-reviewed, updated version:
Arora, N., Russell, R. P., “A Fast, Accurate, and Smooth Planetary Ephemeris Retrieval System,” Celestial Mechanics and Dynamical Astronomy, Vol. 108, No. 2, 2010, pp. 107-124,
DOI 10.1007/s10569-010-9296-0
where derivatives are available only through the expensive and less accurate numerical differencing method.
In this study, we use SPICE as the benchmark for our performance comparison as it is arguably the
most widely accepted ephemeris architecture publicly available. Extensive performance comparisons for
direct position and velocity calls shows that FIRE is 40-100 (approximately) times faster depending upon
the number of bodies and type of call. If only the positions of bodies are evaluated, then FIRE performs
50-140 (approximately) times faster. Further, a performance increase of 150-250 times is observed if we also
compute the rotation matrix along with the position and velocity vector.
When implemented in a common trajectory integration problem, the FIRE integration is demonstrated
to be approximately 30-40 times faster than the same integration using SPICE. For similar SPICE applications, there is little motivation for improving general algorithm efficiency because ephemeris calls dominate
such a large fraction of the total computational burden. In the case of FIRE, users are free to experience the
full benefit of improving the efficiency of their custom applications. With the times required for ephemeris
calls reduced by up to two orders of magnitude, users can no longer blame the ephemeris for major speed
bottlenecks!
FIRE currently uses the SPICE “.bsp” filesc to generate the archived cubic spline ephemeris (ACE)
although FIRE could easily be tailored to use any established ephemeris as input. We emphasize that the
FIRE system is not intended to be a replacement for the full functionality of SPICE; rather, it is intended
to replace only the state and orientation ephemeris calls for custom applications that benefit from FIRE’s
speed and smooth derivatives.
II.
FIRE Architecture and Core Numerical Computation
This section gives an overview of FIRE’s main architecture and its core routines.
The FIRE architecture is based upon the concept of increasing speed and maintaining accuracy while
sacrificing memory as efficiently as possible. It is written of in Fortran 90 using a modular approach to ease
its implementation and upgradability. Keeping in mind the flexibility of the code, the main architecture can
be broadly divided into three sub-systems:
1. Archived Cubic spline Ephemeris (ACE)
2. Runtime Adaptive Custom Ephemeris (RACE)
3. RACE loading and Runtime Vectorized Routines
The above mentioned sub-systems are computationally separate from each other, each containing its own
set of local core routines. A standard input method from a text file corresponding to a “namelist” local to
that system has been followed, thereby imparting robustness and flexibility to the code.
Even though the SPICE naming convention has been adopted for consistency, we can create our own
naming convention and our own custom bodies or spacecraft by changing the relevant inputs. Note, however,
for the tree navigation algorithm, we do require that the “tree trunk” is the main solar system barycenter
defined by a body number of zero (see Fig. 1). Details on the tree structure will be discussed in later section.
A.
Archived Cubic Spline Ephemeris (ACE)
Cubic spline interpolation is actively used in various fields like Robotics16,17 , Numerical integration18 ,
Image Interpolation19 and Animation.20 The ephemeris states of spacecraft and planetary bodies are well
behaved functions. Hence, cubic splines can easily achieve the desired accuracy and efficiency required for
interpolation. Further, cubic splines naturally provide continuous time derivatives up to second order. The
second derivative will have kinks at the knots but remain continuous while the first derivatives are smooth
c URL:
http://naif.jpl.nasa.gov/naif/spiceconcept.html [cited 11 August 2008]
3 of 20
American Institute of Aeronautics and Astronautics
cite peer-reviewed, updated version:
Arora, N., Russell, R. P., “A Fast, Accurate, and Smooth Planetary Ephemeris Retrieval System,” Celestial Mechanics and Dynamical Astronomy, Vol. 108, No. 2, 2010, pp. 107-124,
DOI 10.1007/s10569-010-9296-0
Figure 1. Sample Tree Diagram
and continuous across the full domain. Note that we interpolate on velocities separately instead of using the
first derivative of the position in order to maintain accuracy and continuous second derivatives. We choose
the cubic splines primarily because they are remarkably fast to compute and easy to store in comparison to
other popular, higher order splines such as Chebyshev polynomials and B-splines.
Even though SPICE is already based on a Chebyshev polynomial, we interpolate on the interpolated
ephemeris for ease of implementation. We note that errors in our interpolation of SPICE are on the same
order or less than those interpolation errors published by SPICE. Nonetheless, future works include interpolating on the raw currently unpublished data that SPICE uses for its interpolation.
ACE is generated by implementing an efficient cubic spline algorithm to interpolate the data generated
by an established ephemeris. We adopt a clamped cubic spline method well suited for accuracy and smoothness.21 The end conditions require the first derivative of the interpolation variable at the first and the last
knot. These derivatives, for each state and orientation angle being interpolated, are calculated using a fourth
order numerical difference scheme. For spline computation, the linear, algebraic, tridiagonal system is given
by Eq. (1).
A∗M =V
where A is the tridiagonal matrix given by Eq. (2):

3.5 1


1 4 1


1 4 1
A=

. . .



. .
0
1
(1)
0









1 
3.5
(2)
The tridiagonal(A) is solved using the numerically stable tridiagonal matrix algorithm also called the
Thomas Algorithm.22 Further, M (0) and M (N ) are evaluated using the end conditions from Eqs. (3) and
(4) , while M (1) to M (N − 1) are found from the solution to Eq. (1). Note: M (1) to M (N − 1) values are
solved first and then M(0) and M(N) are evaluated, subsequently.
M (0) =
(V (1) − V (0))
3
˙ − M (1)
∗[
− V (0)]
h
h
2
4 of 20
American Institute of Aeronautics and Astronautics
(3)
cite peer-reviewed, updated version:
Arora, N., Russell, R. P., “A Fast, Accurate, and Smooth Planetary Ephemeris Retrieval System,” Celestial Mechanics and Dynamical Astronomy, Vol. 108, No. 2, 2010, pp. 107-124,
DOI 10.1007/s10569-010-9296-0
M (N ) =
3
(V (N ) − V (N − 1))
˙ )] − M (N − 1)
∗[
− V (N
h
h
2
(4)
After computing M (0) to M (N ), the spline coefficients (a,b,c,d) are evaluated using the Eqs. (5-8)
a = V (i)
b=
(V (i + 1) − V (i)) h
− ∗ (2 ∗ M (i) + M (i + 1))
h
6
M (i)
c=
2
(M (i + 1) − M (i))
d=
(6 ∗ h)
(5)
(6)
(7)
(8)
And finally the spline is evaluated using a numerically efficient form given by Eq. 9 (where y is a dummy
interpolation variable) and 1st and 2nd derivatives are calculated by Eq. (10) and Eq. (11), respectively.
y 0 = a + w0 ∗ (b + w0 ∗ (c + w0 ∗ d))
(9)
y˙0 = b + w0 ∗ (2 ∗ c + 3 ∗ w0 ∗ d)
(10)
y¨0 = 2 ∗ (c + 3 ∗ w0 ∗ d)
(11)
The distance between knots, directly affects the accuracy and smoothness of the interpolation.21 In our
case, the distance between knots is the minimum time step required for successful interpolation which is
driven by the frequency of the body having the smallest orbital period for a particular system. Take the
Jupiter system as an example containing the Jupiter barycenter, Jupiter itself, and its major moons. Io has
the smallest period of all the satellites. In this case, the frequency associated with Io will of course be observed
in the ephemerides of all bodies in the Jupiter system. Therefore, to capture the high resolution motion,
we assign all bodies a time step commensurate with Io. In fact, to obtain the final time step for the whole
Jupiter system, we divide Io’s period by N P R (number of points per rev), a user defined accuracy parameter.
This time step corresponding to the knot separation is given to all the moons of Jupiter according to
the “MINGM” criteria. The “MINGM” criteria allows a body to be considered if its Gm value is above a
predefined value. Reducing this value, increases the number of knots hence increasing the accuracy. Decreasing MINGM incorporates smaller bodies in the time step computation hence increasing the accuracy of
interpolation. A body with Gm less than the “MINGM” is assumed to have no effect on the states of the
remaining bodies in the system. Therefore its frequency signature is deemed unimportant to the dynamics
of the problem. As we will discuss later regarding the rotation states, the FFT method is an alternative
approach to choosing the knot separation.
The ability to get more accuracy by either increasing the number of points or by decreasing the MINGM
defined value can be misleading. For smooth data, if the knots are too densely populated, then the interpolating polynomial will use its high-degree coefficients, in combination with large and almost precisely canceling
combinations. This may cause the interpolating polynomial values to oscillate between its constrained points,
and hence may produce spikes which affect the well boundedness of errors. In our experiments, we find that
NPR values in the range of 20-60 gives good results.
Figure 2 - Figure 7 show the normalized dimensionless error plots for position and velocity components
along with their first and second derivatives for Jupiter’s barycenter and Enceladus (one of Saturn’s major
moons) respectively for a NPR value of 40. The epoch date is 2452276 JD. For Enceladus, only a representative plot for 50 days is shown. We use central differences of the SPICE data at a spacing of ten points
per knot for comparison purposes. We use a step size of spacing/11 for the central difference calculation.
Note that the SPICE data, to the authors knowledge, is not necessarily smooth to second order across the
5 of 20
American Institute of Aeronautics and Astronautics
cite peer-reviewed, updated version:
Arora, N., Russell, R. P., “A Fast, Accurate, and Smooth Planetary Ephemeris Retrieval System,” Celestial Mechanics and Dynamical Astronomy, Vol. 108, No. 2, 2010, pp. 107-124,
DOI 10.1007/s10569-010-9296-0
Figure 2. Error in Jupiter’s Barycenter states
Figure 3. Error in 1st derivative of Jupiter’s Barycenter states
6 of 20
American Institute of Aeronautics and Astronautics
cite peer-reviewed, updated version:
Arora, N., Russell, R. P., “A Fast, Accurate, and Smooth Planetary Ephemeris Retrieval System,” Celestial Mechanics and Dynamical Astronomy, Vol. 108, No. 2, 2010, pp. 107-124,
DOI 10.1007/s10569-010-9296-0
Figure 4. Error in 2nd derivative of Jupiter’s Barycenter states
Figure 5. Error in Enceladus states
7 of 20
American Institute of Aeronautics and Astronautics
cite peer-reviewed, updated version:
Arora, N., Russell, R. P., “A Fast, Accurate, and Smooth Planetary Ephemeris Retrieval System,” Celestial Mechanics and Dynamical Astronomy, Vol. 108, No. 2, 2010, pp. 107-124,
DOI 10.1007/s10569-010-9296-0
Figure 6. Error in 1st derivative of Enceladus states
Figure 7. Error in 2nd derivative of Enceladus states
8 of 20
American Institute of Aeronautics and Astronautics
cite peer-reviewed, updated version:
Arora, N., Russell, R. P., “A Fast, Accurate, and Smooth Planetary Ephemeris Retrieval System,” Celestial Mechanics and Dynamical Astronomy, Vol. 108, No. 2, 2010, pp. 107-124,
DOI 10.1007/s10569-010-9296-0
full time domain. Discontinuities in derivatives may exist at junctions in the SPICE interpolating functions.
While our “error” plots presume that the SPICE numerical derivatives are truth, one could argue that the
FIRE derivatives are closer to the truth in the absence of numerical differencing. In fact, for numerical
purposes regarding targeting and optimization, it is more important for the derivatives to be self consistent
rather that absolutely correct. In this regard, the FIRE derivatives are clearly preferred.
Figure 8. Fast Fourier Transformation for Moon’s three Euler angle’s
The accuracy of the spline derivatives is typically less than the accuracy of their immediate integrals.
Hence, the normalized accuracy for the zeroth, first and second derivative is generally of the order of
1E−8 (normalized dimensionless value), 1E−6 and 1E−4 respectively for bodies and is of the order of 1E−14 ,
1E−11 and 1E−7 for barycenters. The normalizing factor (N r) is calculated as per Eq. (12).
N r = max(y 0 )
(12)
For our purposes, it is very important that the zeroth derivative be accurate.
We choose Euler angles for orientation interpolation because they perfectly preserve orthogonality in the
resulting rotation matrix. Other methods such as Quaternions20,23 ,Rodrigues Parameters24,25 were investigated extensively in order to avoid the computationally expensive trigonometric calls. However, it is well
known that interpolating quaternions introduces complications including sign ambiguities and or nonorthogonality.20
Often during trajectory computations involving orientation data, rotation matrices get multiplied with the
body state vector. If the rotation matrix is not orthogonal then a scaling effect will produce significant
cumulative errors in the computed trajectory. Hence, apart from accuracy of the rotation matrix, its orthogonality is a very important issue when performing orientation interpolation.
We note that the SPICE interface with orientation data is a common rotation matrix between user
defined frames. In our custom ephemeris we are limited to obtaining rotation matrices between the IAU
defined body fixed coordinate systems and the base ecliptic J2000 inertial frame.26 Currently, a rotation
matrix between two general frames is achievable with FIRE using two separate rotation calls and a matrix
transpose and multiplication. We acknowledge that the use of Euler angles requires a sine and cosine call for
each of the three angles for every rotation matrix call to FIRE. However, we still find remarkable speedups of
9 of 20
American Institute of Aeronautics and Astronautics
cite peer-reviewed, updated version:
Arora, N., Russell, R. P., “A Fast, Accurate, and Smooth Planetary Ephemeris Retrieval System,” Celestial Mechanics and Dynamical Astronomy, Vol. 108, No. 2, 2010, pp. 107-124,
DOI 10.1007/s10569-010-9296-0
Figure 9. Relative normalized error in Titan’s Euler angles
25,000% in most cases because SPICE often requires hundreds of trigonometric calls in order to accurately
represent the orientation states26 .
FFT’s can be easily used to catch frequencies of a periodic system.27,28 In this paper, an efficient and
numerically stable FFT algorithm29,30 is used to calculate the minimum step size required for interpolation
of Euler angles. For a given angle, the frequency corresponding to the largest spike in the Fourier transformed
space is recorded and the corresponding time step is calculated. This provides us with a reliable, robust,
and efficient interpolation method, even for complex and subtle body dynamics. A representative FFT plot
for each of the three Euler angles of the Moon is shown in Fig. 8:
The rotation matrix output from the ephemeris belongs to the Right Ascension-Declination or 3 − 1 − 3
rotation group and is given by R.


cos (α) cos (γ) − cos (β) sin (α) sin (γ) cos (γ) sin (α) + cos (β) cos (α) sin (γ) sin (β) sin (γ)




R =  − cos (β) cos (γ) sin (α) − sin (γ) cos (α) cos (β) cos (α) cos (γ) − sin (α) sin (γ) cos (γ) sin (β) 


sin (α) sin (β)
− cos (α) sin (β)
cos (β)
The time derivatives for R in terms of the time derivatives of α, β, and γ are straight-forward but left
out of the text for brevity. We obtain the time derivatives of the positions and velocities directly from the
interpolation.
This 3 − 1 − 3 rotation matrix has been adopted via IAU Standards26 as well as SPICE. Here, α and β
represent the pointing direction of the north pole of the body in question, while γ represents the angular
location of the prime meridian. The angle γ can be modeled as almost a straight line by adding 2π to the
place where a jump in the angle occurs. Beware that some planets like Venus rotate in opposite direction.
For such bodies 2π is subtracted. The accuracy of the interpolation is of the order of 1E−15 (non-dimensional
error) for both the slow period angles and 1E−13 (non-dimensional error) for the fast moving angle. Relative normalized error plots for Euler angles of Titan (Neptune’s largest moon) for 50 days are shown in Fig. 9.
10 of 20
American Institute of Aeronautics and Astronautics
cite peer-reviewed, updated version:
Arora, N., Russell, R. P., “A Fast, Accurate, and Smooth Planetary Ephemeris Retrieval System,” Celestial Mechanics and Dynamical Astronomy, Vol. 108, No. 2, 2010, pp. 107-124,
DOI 10.1007/s10569-010-9296-0
ACE is stored in a structured format, consisting of numerous gravitational subsystems. Each body
of a subsystem, has up to 3 associated binary files: one for position , one for velocity, and one for rotation. The binary files contain the dependent variables and their second derivatives at all the knot points
for each interpolation variable. The spline coefficients are calculated at runtime using equations 5-8. The
independent knot (time) values are stored in an efficient manner to avoid redundancy while preserving speed.
An archived ephemeris is typically generated when using FIRE for the first time or when there is a major
update in the underlying ephemeris system used to generate ACE. The ephemeris files used for generating
the ACE for the examples in this paper include de405.bsp d , jup230.bsp e , sat242.bsp f , nep076.bsp g ,
ura083.bsp h , plu017.bsp i and pck00008.tpc j . The example ACE includes the positions and velocities of
all the planets and their barycenters, 17 planetary moons, and the rotation states for 4 bodies for a time
span of 12.5 years. In total there are 72 archived binary files that require 623 megabytes of memory.
B.
Runtime Adaptive Custom Ephemeris (RACE)
RACE is a dense array, whose main purpose is to significantly increase the speed of run-time ephemeris
state and orientation calls by eliminating the overhead arising from invoking the archived spline. RACE
also provides the user with a portability option to store as a binary file the problem specific RACE for reuse
later. Hence multiple RACEs can be generated and stored for different classes of problems.
The RACE creation, reads in the problem specific components of ACE and creates a binary run-time
ephemeris file. This run time ephemeris spans over a time specified by the user, which again is particular to
the problem being solved. Each body within the RACE has its state relative to its own native barycenter.
The size of the runtime ephemeris typically varies from approximately 5 to 100 megabytes depending upon
the accuracy of ACE and the time span and number of bodies states required for the problem. The maximum
size of RACE is the total size of the archived binary files in the ACE. This of course presumes the unlikely
scenario that all states for all bodies across the full time span of the ACE are required.
Apart from the binary RACE, another text file is created, which is used for dynamically allocating the
RACE in memory at runtime. The number of knots for all the bodies is equal to some 2k value (where k is an
integer). Hence, knowing the body and the corresponding particular interpolation variable having the largest
value of k provides a mechanism to uniquely identify the appropriate knots for each state and orientation in
a vectorized call without performing expensive searches in the RACE at runtime. This algorithm requires
one “double” to “integer” conversion and just a few elementary operations, instead of a linear or a binary
search algorithm.
We emphasize again that the RAM requirements vary from problem to problem. The RAM requirements
for even the most demanding problems rarely exceed 100 megabytes (see later example), a reasonable value
for any modern personal computer.
C.
RACE loading and Runtime Vectorized Routines
The third sub-system is invoked at runtime and performs the following two operations:
1. Dynamic allocation of the RACE in memory
2. Computing the state vectors, the rotation matrices and any derivatives by evaluating the tree navigation
algorithm (see Fig. 1)
d URL:
e URL:
f URL:
g URL:
h URL:
i URL:
j URL:
ftp://naif.jpl.nasa.gov/pub/naif/generic
ftp://naif.jpl.nasa.gov/pub/naif/generic
ftp://naif.jpl.nasa.gov/pub/naif/generic
ftp://naif.jpl.nasa.gov/pub/naif/generic
ftp://naif.jpl.nasa.gov/pub/naif/generic
ftp://naif.jpl.nasa.gov/pub/naif/generic
ftp://naif.jpl.nasa.gov/pub/naif/generic
kernels/spk/planets/a old versions/de405.bsp [cited 11 August 2008].
kernels/spk/satellites/a old versions/jup230.bsp [cited 11 August 2008].
kernels/spk/satellites/a old versions/sat242.bsp [cited 11 August 2008].
kernels/spk/satellites/nep076.bsp [cited 11 August 2008].
kernels/spk/satellites/ura083.bsp [cited 11 August 2008].
kernels/spk/satellites/plu017.bsp [cited 11 August 2008].
kernels/pck/pck00008.tpc [cited 11 August 2008]
11 of 20
American Institute of Aeronautics and Astronautics
cite peer-reviewed, updated version:
Arora, N., Russell, R. P., “A Fast, Accurate, and Smooth Planetary Ephemeris Retrieval System,” Celestial Mechanics and Dynamical Astronomy, Vol. 108, No. 2, 2010, pp. 107-124,
DOI 10.1007/s10569-010-9296-0
Loading the RACE into memory is done by a subroutine call while setting up the problem. This operation typically takes from 1 to 5 seconds depending on the size of the RACE.
In contrast to the capabilities of SPICE, the new system employs a single vectorized call for interpolation
of all of the necessary states and orientations at a particular timek . The term “vectorized call” refers to
calling all the states of multiple bodies in one call rather than calling the routines over and over for each
body state and orientation. The vector calls significantly reduce the overhead associated with the common
initialization for each body, thereby dramatically improving the performance.
In cases when an ephemeris is used in the force models for optimization and or targeting routines, continuous first and second time derivatives may be necessary for positions, velocities, and rotation matrices.
Keeping this in mind, FIRE also provides the user with set of flagged routines which can be invoked to get
the first or both the first and the second derivatives of position, velocity, rotation, or any combination of
these via only one vectorized call. These derivative data can be extremely useful for problems which are
very sensitive, like trajectories with multiple close flybys or multiple gravitating bodies31,32 .
Navigation of the tree structure (see Fig. 1) is required at runtime if the user requested reference center is
different from the body’s native barycenter (noting that all states are archived relative to their native center
only). In the case of trajectory integration applications, the reference center should be the problem specific
center of integration. Again for a general system like SPICE, there is overhead associated with evaluating
the tree at runtime for every call and every body. In the FIRE architecture, the vectorized calls provide all
the necessary states with respect to one common center. A new innovative tree navigation algorithm has
been implemented, which removes any redundant calls without sacrificing the numerical stability and accuracy of the state being calculated. Addition and subtraction of state variables are carried out by algebraic
addition of coefficients which are multiplied by equalizings constants if required. The equalizing constants
are necessary because the ACE is stored in bary-system dependent canonical units whereas the RACE can
contain bodies from multiple systems. Therefore, the coefficients from ACE must be scaled appropriately
before converting to RACE and ultimately to the user output of km and s.
Note that we experimented with precomputing the tree structure prior to runtime, thereby storing the
full RACE with precomputed coefficient additions and equilizations. In this case, RACE would be valid only
for one reference center only. Despite an improvement in runtime speeds, we choose the more general RACE
form that requires runtime tree navigation, yet users are free to call for states relative to any center.
Table 1. FIRE runtime routines and there function
Routine name
Function performed:
GETPOS
Computes XYZ states
GETPOSVEL
Computes XYZ and UVW states
GETPOSVELROT
Computes XYZ, UVW states plus the rotation matrix
GETPOSROT
Computes XYZ and the rotation matrix (specific to the input flag)
GETROT
Computes the rotation matrix
GETPOSD
GETPOSROTD
Computes XYZ states, and corresponding 1st or both 1st and 2nd derivatives
Computes XYZ, UVW states, and corresponding 1st or both 1st and 2nd derivatives
Computes XYZ, UVW states and the rotation matrix, and corresponding 1st or both 1st and 2nd derivatives
Computes XYZ and the rotation matrix, and corresponding 1st or both 1st and 2nd derivatives
GETROTD
Computes the rotation matrix, and corresponding 1st or both 1st and 2nd derivatives
GETPOSVELD
GETPOSVELROTD
FIRE, has in total eight different routines (shown in in Table 1) which can be called at runtime, four of
these give states and orientations while the remaining four additionally provide derivatives. Various combinations of “POS, VEL, ROT and D ” are used to call for appropriate data. For example, if only position
and rotation data is needed then the user would call the routine “GETPOSROT”. To obtain the derivatives
alongside the states, the user would invoke the routine “GETPOSROTD”. This provides a user friendly
interface that is consistent with the existing functionality of SPICE. We emphasize again that the derivative
k We note that the Matlab version of SPICE, called MICE, includes vectorized calls although we suspect it is simply a
wrapper around the un-vectorized SPICE.
12 of 20
American Institute of Aeronautics and Astronautics
cite peer-reviewed, updated version:
Arora, N., Russell, R. P., “A Fast, Accurate, and Smooth Planetary Ephemeris Retrieval System,” Celestial Mechanics and Dynamical Astronomy, Vol. 108, No. 2, 2010, pp. 107-124,
DOI 10.1007/s10569-010-9296-0
calls are currently unavailable in SPICE.
The overview of the complete FIRE system is given in Fig. 10
Figure 10. Overview of the FIRE system
III.
Performance
JPL’s ephemeris generation system (SPICE), is used for benchmarking the performance of the FIRE
system. The computer configuration used for benchmarking is an Alienware M5550 computer with an Intel
dual core processor (2Ghz) and 2 GB of RAM. The benchmarking is done in two ways. First, we directly call
the routine for a certain fixed number of calls and record the relative performance gain. Second, we perform
a complete trajectory simulation in the Jupiter system along with perturbing effects of the Sun and the
planets of our solar system. The code is compiled and linked on the IVF Compiler for Windows version 10.1
and has been subjected to basic default compiler optimizations. Note that we use the precompiled SPICE
library for the IVF compilerl .
A.
Performance with direct routine calls
In this comparison 3*224 (approximately 50 million) calls with random time inputs are used to evaluate
the performance of SPICE and FIRE. We use the SPICE routines “SPKEZ” for computing position and
velocity, “SPKEZP” for computing position only, and “PXFORM” for generation of the rotation matrix.
The “GETPOSVEL”, “GETPOS” and “GETPOSROT” routines are used respectively for FIRE.
Two gravitational systems are studied in this comparison, the EARTH-MOON-SUN (EMS) system and
the JUPITER-MOONS-SATURN-SUN (JMSS) system. The EMS system has only three bodies passed at
once hence highlighting the performance gain due to the use of RACE, the runtime matrix. The JMSS
system has eight bodies and thereby quantifies the performance of the full capability of the tree navigation
algorithm, vectorized calls, and RACE.
A type defined comparison bar graph system is used to illustrate performance. A logarithmic scale is
used for better readability. As shown in Table 2 and Table 3, there are a total of six types of ephemeris
calls, each with different performance characteristics due to different path lengths required in evaluation of
the tree algorithm (Fig. 1).
From Fig. 11 and Tables 4 and 5 , we demonstrate dramatic performance gains of FIRE in comparison to
SPICE. We note that the slowest call requires a full navigation of the tree algorithm. Even in this poorest
l http://naif.jpl.nasa.gov/naif/toolkit
FORTRAN PC Windows IFORT.html [cited 27 August 2008]
13 of 20
American Institute of Aeronautics and Astronautics
cite peer-reviewed, updated version:
Arora, N., Russell, R. P., “A Fast, Accurate, and Smooth Planetary Ephemeris Retrieval System,” Celestial Mechanics and Dynamical Astronomy, Vol. 108, No. 2, 2010, pp. 107-124,
DOI 10.1007/s10569-010-9296-0
Table 2. Various cases for Earth-Moon-Sun system performance comparison
System
Type1
Type2
Type3
Type4
Type5
Type6
Earth-Moon-Sun:
Moon wrt Earth-Moon barycenter (native barycenter call)
Earth and Moon wrt Earth-Moon barycenter (vectorized native barycenter call)
Earth wrt Moon (Native system call)
Earth and Moon wrt Solar-System barycenter (half tree evaluation)
Earth, Earth-Moon barycenter and Sun wrt Moon (typical call)
Earth wrt Sun (full tree evaluation)
Table 3. Various cases for Jupiter-Moons-Saturn-Sun performance comparison
System
Type1
Type2
Type3
Type4
Type5
Type6
Jupiter-Moons-Saturn-Sun:
Jupiter wrt Jupiter barycenter
Io, Europa, Ganymede, Callisto wrt Jupiter barycenter
Io, Europa, Ganymede, Callisto wrt Io
Io, Europa, Ganymede, Callisto wrt Solar-System barycenter
Io, Europa, Ganymede, Callisto, Jupiter, Sun, Saturn barycenter wrt Europa
Jupiter wrt Saturn barycenter
performing case, we still find that the FIRE routines are 35-45 times faster than SPICE. The typical FIRE
call where the vectorized routines are fully exploited and most of the bodies share a common barycenter is
demonstrated to be as much as 100 times faster.
Often a typical routine call includes the necessary position and velocity data for all the bodies along with
rotation data for some bodies. Hence, to demonstrate full performance capability of FIRE, the typical calls
have been again evaluated along with rotation matrices for Earth and the Moon in the first system and for
Jupiter and Europa in the second system. Also, we include a test with only rotation calls for completeness.
Accordingly, Tables 6 and 7 show the performance for both the systems respectively. The FIRE system for
a typical call hence is around 150-200 times faster when rotation states are included. We note that the huge
improvements when including rotation states may be overshadowed by the heavy computational burdens of
spherical harmonics or polyhedral potential calculations that typically accompany orientation state needs.
A distinguishing feature of the FIRE system is the ability provide the first and second time derivatives
of all the ephemeris states. While there is no analogous SPICE capability for comparison, we summarize
the absolute performance of the derivative calls for both examples in Fig. 12. The first derivative calls
perform typically better or equal to position-velocity calls only, and the combined first and second derivative
calls require approximately 50% more time than the first derivative only calls. We emphasize again that
numerical derivative computation using SPICE requires additional state calls, and the resulting derivatives
are substantially less accurate.
Considering the PLEPH ephemeris system7 is also in wide use, we perform preliminary speed comparisons
and find that PLEPH compiled for maximum speed is faster than the precompiled SPICE library for direct
calls by a factor of approximately six. We emphasize that PLEPH only uses DE405 (or equivalent) and
therefore does not provide orientation data or planetary moon data besides the Earth’s moon. Future work
includes more detailed studies with PLEPH and other common ephemeris readers.
14 of 20
American Institute of Aeronautics and Astronautics
cite peer-reviewed, updated version:
Arora, N., Russell, R. P., “A Fast, Accurate, and Smooth Planetary Ephemeris Retrieval System,” Celestial Mechanics and Dynamical Astronomy, Vol. 108, No. 2, 2010, pp. 107-124,
DOI 10.1007/s10569-010-9296-0
Figure 11. Performance figures for Earth-Moon-Sun and Jupiter-Moons-Saturn-Sun system
Table 4. Performance comparison ratio table for Earth-Moon-Sun system
Type
SPICE time(s)
FIRE time(s)
(SPICE time)/(FIRE time)
SPICE time(s)
FIRE time(s)
(pos)
(pos)
ratio
(pos-vel)
(pos-vel)
(SPICE time)/(FIRE time):
ratio
1
377.09
4.83
78.07
389.94
5.81
67.00
2
746.18
7.30
102.22
748.22
9.67
77.79
3
542.22
6.94
78.16
542.83
9.36
58.00
4
769.34
14.40
53.44
770.94
20.14
38.28
5
1324.65
23.36
56.70
1325.10
31.98
41.43
6
528.95
11.56
45.76
529.36
15.03
35.22
Table 5. Performance comparison ratio table for Jupiter-Moons-Saturn-Sun system
Type
SPICE time(s)
FIRE time(s)
(SPICE time)/(FIRE time)
SPICE time(s)
FIRE time(s)
(pos)
(pos)
ratio
(pos-vel)
(pos-vel)
(SPICE time)/(FIRE time):
ratio
1
381.51
4.66
82.00
391.64
5.63
70.00
2
1591.95
11.36
140.10
1608.53
15.16
106.13
3
1710.52
13.73
124.55
1724.95
17.50
98.57
4
1595.08
26.03
61.30
1645.91
36.61
45.00
5
3881.11
37.55
103.40
3907.78
51.58
76.00
6
513.99
11.63
44.20
522.28
15.14
34.40
Table 6. Typical Performance comparison ratio table for Earth-Moon-Sun system
Type
Typical call(pos and rot)
Rotation call only
Frame/Center
EclipJ2000/Earth
EclipJ2000
SPICE time (s)
5317.24
4073.24
FIRE time (s)
27.51
17.03
(SPICE)/(FIRE) time ratio
193.28
239.18
15 of 20
American Institute of Aeronautics and Astronautics
cite peer-reviewed, updated version:
Arora, N., Russell, R. P., “A Fast, Accurate, and Smooth Planetary Ephemeris Retrieval System,” Celestial Mechanics and Dynamical Astronomy, Vol. 108, No. 2, 2010, pp. 107-124,
DOI 10.1007/s10569-010-9296-0
Table 7. Typical Performance comparison ratio table for Jupiter-Moons-Saturn-Sun system
Type
Typical call(pos and rot)
Rotation call only
Frame/Center
EclipJ2000/Europa
EclipJ2000
SPICE time (s)
8083.47
4057.91
FIRE time (s)
53.63
17.64
(SPICE)/(FIRE) time ratio
150.73
230.04
Figure 12. Performance of derivative calls for Earth-Moon-Sun and Jupiter-Moons-Saturn-Sun system
16 of 20
American Institute of Aeronautics and Astronautics
cite peer-reviewed, updated version:
Arora, N., Russell, R. P., “A Fast, Accurate, and Smooth Planetary Ephemeris Retrieval System,” Celestial Mechanics and Dynamical Astronomy, Vol. 108, No. 2, 2010, pp. 107-124,
DOI 10.1007/s10569-010-9296-0
Figure 13. Evolution of orbital elements
B.
Performance during trajectory integration
Although the performance examples presented provide us with the most direct comparison between the raw
speeds of FIRE and SPICE, we now proceed to a comparison using a more realistic application. The relative
performance gains will of course not be as impressive as the previous cases because the integration is being
performed alongside both the SPICE and FIRE calls.
For comparison, a trajectory prorogation of a high-altitude Europa orbiter has been performed taking
into account the perturbing effects of Jupiter and its moons, the Sun, and all the planets. This integration
is performed for a period of 1 month. The initial conditions used are listed in Table 8.
Table 8. Initial condition (body-fixed frame at epoch) for trajectory integration
Orbital Parameter
Semi-major axis (a)
Eccentricity (e)
Inclination (i)
Argument of periapsis (ω)
Longitude of ascending node (Ω)
True anomaly at epoch (ν)
Epoch (t0)
Value
3000 (km)
0.20
35 (deg)
0 (deg)
0 (deg)
0 (deg)
2455000.5 (JD)
A variable step 8th order with 9th order error control, Runge-Kutta-Nystrom33 integrator set to a unitless
tolerance of 1E−12 is used. The size of RACE for this propagation is approximately 17 megabytes. Ephemeris
rotation calls are not included during the propagation.
Accuracy and performance of the numerical integrations are the two criteria for the comparison. Results
of the trajectory integration show that FIRE performs 37.64 times faster then SPICE. The final state vector
of FIRE was off by 0.5 meters (approximately) when compared to the final state vector obtained by using
SPICE. This is well within acceptable limits considering the spacecraft makes 150 revolutions (approximately) around Europa during the integration.
Figure 13 shows the evolution of the orbital elements for resulting trajectory while Fig. 14 gives the
17 of 20
American Institute of Aeronautics and Astronautics
cite peer-reviewed, updated version:
Arora, N., Russell, R. P., “A Fast, Accurate, and Smooth Planetary Ephemeris Retrieval System,” Celestial Mechanics and Dynamical Astronomy, Vol. 108, No. 2, 2010, pp. 107-124,
DOI 10.1007/s10569-010-9296-0
Figure 14. SPICE and FIRE position difference
instantaneous position differences between the FIRE and SPICE propagations. We note that the orbital
elements are reported in the body-fixed frame at epoch.
IV.
Conclusion and Future work
A new, fast, efficient, smooth, and accurate ephemeris interpolation system called FIRE is proposed for
general use in precision trajectory and mission design. The FIRE system is custom built for applications
traditionally bogged down by the heavy computational burden associated with typical ephemeris calls. FIRE
relies on established ephemeris systems (currently JPL’s SPICE) to build a custom archived ephemeris. We
demonstrate speed improvement of approximately two orders of magnitude for typical applications when
compared to SPICE, the industry standard ephemeris system.
Preliminary performance comparisons with the PLEPH routines indicate that the SPICE comparisons are
directly scalable by reducing the performance gains by a factor of approximately six. Future work includes
more detailed studies with PLEPH and other common ephemeris readers. The main performance gain is
achieved through the modest use of random access memory to store a custom, portable runtime ephemeris.
Further, we reduce overhead through the use of vectorized calls and a new, efficient tree navigation algorithm.
A major benefit of FIRE is that smooth, accurate, and self-consistent derivatives are natural artifacts of the
interpolation method. These derivatives are often required for trajectory optimization and other classes of
similar problems.
A variety of topics are currently being considered for future work regarding FIRE. We intend to investigate alternative interpolation schemes perhaps that may provide higher order derivatives and improved
accuracy and memory characteristics. Future archived ephemeris generation could be based on direct planetary data rather than the existing interpolated data. Significant performance improvements can achieved
by taking advantage of multi core or multi processor versions of the code. Preliminary results are promising.
The most important future work includes integration of FIRE into existing software and general testing of
the potential FIRE benefits.
FIRE has been designed specifically to facilitate problems involving long or frequent ephemeris prorogations for various classes of orbital mechanics problems. The preliminary results of this study validate FIRE’s
impressive performance. The new tool has potential value to any high precision application or software
requiring fast, accurate, and smooth ephemeris data.
18 of 20
American Institute of Aeronautics and Astronautics
cite peer-reviewed, updated version:
Arora, N., Russell, R. P., “A Fast, Accurate, and Smooth Planetary Ephemeris Retrieval System,” Celestial Mechanics and Dynamical Astronomy, Vol. 108, No. 2, 2010, pp. 107-124,
DOI 10.1007/s10569-010-9296-0
Acknowledgments
We would like to acknowledge Dr. Panagiotis Tsiotras for his valuable suggestions during this research
work.
References
1 Jacobson, R. A. and French, R. G., “Orbits and masses of Saturns co-orbital and F-ring shepherding satellites,” Icarus,
Vol. 172, 2004, pp. 382–387.
2 Giampieri, G. and Dougherty, M. K., “Rotation rate of Saturns interior from magnetic field observations,” Geophysical
Research Letters, Vol. 31, 2004.
3 Russell, R. and Lam, T., “Designing Capture Trajectories to Unstable Periodic Orbits Around Europa,” Journal of the
Guidance,Control and Dynamics, Vol. 30, 2006, pp. 482–491.
4 Russell, R. P. and Lara, M., “Long-Life Lunar Repeat Ground Track Orbits,” Journal of Guidance, Control, and
Dynamics, Vol. 30, 2007, pp. 982–993.
5 Aiello, J., “Numerical Investigation of Mapping Orbits about Jupiters Icy Moons,” AAS/AIAA Astrodynamics Specialist
Conference, Lake Tahoe, California, August 2005.
6 Lo, M., Anderson, R., Whiffen, G., and Romans, L., “The role of Invariant Manifolds in Low Thrust Trajectory design,”
AAS/AIAA Astrodynamic Specialist Conference, Vol. 288, 2004.
7 Standish, E. M., “JPL Planetary and Lunar Ephemerides,” CD-ROM, Willman-Bell Inc., Richmond, VA, 1997.
8 Russell, R., “Primer Vector Theory Applied to Global Low-Thrust Trade Studies,” Journal of the Guidance,Control and
Dynamics, Vol. 30, 2007, pp. 460–472.
9 Russell, R. P., Global Search and Optimization for Free-Return Earth-Mars Cyclers, Ph.D. thesis, The University of
Texas at Austin, 2004.
10 Hull, D. G., “Numerical Derivatives for Parameter Optimization,” Journal of Guidance, Control, and Dynamics, Vol. 2,
1979, pp. 158–160.
11 Sauer, C., “MIDAS Mission Design and Analysis Software for the Optimization of Ballistic Interplanetary Trajectories,”
Journal of the Astronautical Sciences, Vol. 37, 1989, pp. 251–259.
12 Campbell, E. T. and Speckman, L. E., “Preliminary Design of Feasible Athos Intercept Trajectories,” Planetary Defense
Conference: Protecting Earth from Asteroid, Orange County, California, February 23 - 26 2004.
13 Koon, W. S., Lo, M. W., Marsden, J. E., and Ross, S. D., “The Genesis Trajectory and Heteroclinic Connections,”
AAS/AIAA Astrodynamic Specialist Conference, 1999, pp. 451.
14 Koon, W. S., Lo, M. W., Marsden, J. E., and Ross, S. D., “Low Energy Transfer to the Moon,” Celestial Mechanics and
Dynamical Astronomy, Vol. 81, 2001, pp. 63–73.
15 Desai, P. N. and Cheatwood, F. M., “Entry Dispersion Analysis for the Genesis Sample Return Capsule,” AAS/AIAA
Astrodynamics Specialist Conference, Girdwood, Alaska, April 16-19 1999.
16 C. Lin, P. Chang, J. L., “Formulation and optimization of cubic polynomial joint trajectories for industrial robots,” IEEE
Transactions on Automatic Control, 1983, pp. 508–517.
17 Huang, Q., Yokoi, K., Kajita, S., Kaneko, K., Arai, H., Koyachi, N., and Tanie, K., “Planning walking patterns for a
biped robot,” IEEE Transactions on Acoustics, Speech and Signal Processing, Vol. 26, 1978.
18 Spedding, G. R. and Rignot, E. J. M., “Performance analysis and application of grid interpolation techniques for fluid
flows,” Experiments in Fluids, Vol. 15, 1993, pp. 417–430.
19 Unser, M., “Splines: a perfect fit for signal and image processing,” IEEE Signal Processing Magazine, Vol. 15, 1993,
pp. 22–38.
20 Shoemake, K., “Animation Rotation with Quaternion Curves,” Computer Graphics, Vol. 19, 1985, pp. 245–254.
21 deBoor, C. D., “Piecewise Cubic Interpolation,” A Practical Guide to Splines, Vol. 27, Springer-Verlag, 1978, pp. 49–107.
22 Conte, S. and deBoor, C., Elementary Numerical Analysis, 1972.
23 Shuster, M., “A Survey of Attitude Representations,” Journal of the Astronautical Sciences, Vol. 41, 1993, pp. 439–517.
24 Tsiotras, P., Schaub, H., and Junkins, J. L., “Higher-Order Cayley Transforms with Applications to Attitude Representations,” Journal of the Guidance,Control and Dynamics, Vol. 20, 1997.
25 Schaub, H. and Junkins, J. L., “Stereographic Orientation Parameters for Attitude Dynamics: A Generalization of the
Rodrigues Parameters,” Journal of the Astronautical Sciences, Vol. 44, 1996, pp. 1.
26 Seidelmann, P. K., Archinal, B. A., A’hearn, M. F., Conard, A., Consolmagno, G. J., Hestroffer, D., Hilton, J. L.,
Krasinsky, G. A., Neumann, G., Oberst, J., Stooke, P., Tedesco, E. F., Tholen, D. J., Thomas, P. C., and Williams, I.,
“Report of the IAU/IAG Working Group on cartographic coordinates and rotational elements: 2006,” Celestial Mechanics and
Dynamical Astronomy, Vol. 98, 2007, pp. 155–180.
27 Cooley, J. W., A. Peter, W., and D.Welch, P., “The Fast Fourier Transform and Its Applications,” IEEE Transactions
on Education, Vol. 12, 1969, pp. 27–34.
28 Kurtz, D. W., “An algorithm for significantly reducing the time necessary to compute a Discrete Fourier Transform
periodogram of unequally spaced data,” Royal Astronomical Society,Monthly Notices, Vol. 213, 1985, pp. 773–776.
29 Hou, H., “The Fast Hartley Transform Algorithm,” IEEE Transactions on Computers, Vol. 36, 1987, pp. 147–156.
19 of 20
American Institute of Aeronautics and Astronautics
cite peer-reviewed, updated version:
Arora, N., Russell, R. P., “A Fast, Accurate, and Smooth Planetary Ephemeris Retrieval System,” Celestial Mechanics and Dynamical Astronomy, Vol. 108, No. 2, 2010, pp. 107-124,
DOI 10.1007/s10569-010-9296-0
30 Burrus, C. and Eschenbacher, P., “An in-place, in-order prime factor FFT algorithm,” IEEE Transactions on Computers,
Vol. 29, 1981, pp. 806–817.
31 Lam, T. and Hirani, A. N., “Characteristics of Transfers to and Captures at Europa,” Celestial Mechanics and Dynamical
Astronomy, 2006.
32 Whiffen, G. J., “Jupiter Icy Moons Orbiter Reference Trajectory,” AAS/AIAA Astrodynamic Specialist Conference,
Vol. 186, 2006.
33 Gonzalez, A. and P. Martn, D. L., “On the numerical integration of orbital problems with high order Runge-KuttaNystrom methods,” Applied Numerical Mathematics, Vol. 35, 2000, pp. 1–10.
20 of 20
American Institute of Aeronautics and Astronautics