Incorporating JPL ephemerides in Orbiter

[Chode]

I've made significant progress in using the ephemerides created by JPL for making
ephemeris modules for Orbiter. What prompted this was my dissatisfaction with the
results I was getting from a module I was creating for Nereid when compared to data
retrieved from the JPL Horizons ephemeris service. My ephemeris for Nereid was based on a
2009 paper which fit a somewhat simple model to the results of a JPL integration (which was
fit to observational positions) of the orbit of Nereid. This model gave orbital elements
for the orbit with respect to the Laplacian plane of Neptune+Nereid, allowing the orbit
to precess at a constant rate. It looks like this model results in a rather poor fit for the
integration, probably because it does not model the perturbations on the orbit caused by Triton well.
A little background on the JPL ephemerides:
The group within JPL that produces the ephemerides is called the Solar System Dynamics group,
and one of their responsibilities is to produce accurate ephemerides needed for navigation,
observation, and communication for spacecraft on NASA interplanetary missions. The approach
they use is to numerically integrate the paths of the bodies in a system using the best
physical data they can create (state vectors, velocities, masses, non-spherical gravity
components, etc.) and calculating the most important interactions between bodies in detail
(mutual attraction, tidal interactions, etc.)
The results are compared to real-world observations (Earth-based and spacecraft), and the model is
adjusted to get a good fit. The results are state vectors as a function of time (positions and velocities)
for the bodies included in the system, which are reduced in size by fitting a high order
piecewise polynomial to the vectors. This data is publically available on JPL or NAIF websites,
and is presented in a form that is directly useable by a software suite called SPICE, which can
be used for mission planning (navigation, tracking, communication, etc.).
One could use the spice software library to retrieve vectors within an Orbiter module, but I have
taken a nore direct approach (and simpler for a hack programmer like myself), which is to use
a utility to dump the data in the ephemeris file to a text file, re-format it
(and reduce it in size) to make it easier to incorporate into an Orbiter module.

So, what data can I get from JPL for Nereid?
The file that contains the data I need is called nep081.bsp, which is a binary file
about 116 Meg in size.
This is the result of an integration that explicitly includes Neptune, the Sun, and the
satellites Triton, Nereid, and Proteus. It covers the time period from 1900 to 2050. A few
utilities that I found on the JPL SPICE site come in handy at this point. A utility called "brief"
gets a summary of what is in the file. A utility called "spkmerge" can extract the data for a
subset of bodies in the file to a new file. Another utility called "spy" can dump the data from that
file to a text file. In examining the data, and from various guides and documents on the JPL site,
I found that the data is presented as a number of segments (13698 in the case of Nereid) each containing
the data for computing the position and velocity vectors for a 4 day interval. The data for each segment
includes: the Julian Date of the midpoint of the segment, the time span of the interval, and 66
coefficients that allow the computation of position and velocity vectors within that segment.
The state vectors are computed as a sum of Chebyshev polynomials using these coefficients. I wrote a
little utility that reads the data, and creates a new file that is smaller by eliminating the time info
and reducing the order of the fit from 10 to 5, but still retaining the property that each segment joins
smoothly to the next segment, so there will not be discontinuity in the positions or velocities at
segment boundaries. This file is about 7.5Meg in size. I've done some simple tests that compute state
vectors for Nereid from this data, and it agrees with data retrieved from Horizons down to the meter level
(likely because they use the same ephemeris data in nep081.bsp).

I am now writing an Orbiter module that reads this file and uses it to compute the position and velocity
required by Orbiter. One problem to solve is what to do about times before and after the time interval
of the data.

I would appreciate any feedback, ideas, critiques, etc. on this subject.

 

[Keithth G]

As I understand it, you wish to extend the Nereid ephemeris beyond the date rand 1950 to 2050.

The easiest way of doing this, I think, is to perform a co-integration of the motion of Neptune, the Sun, and the satellites Triton, Nereid, and Proteus using JPL constants (e.g., body masses, etc.) in the barycentric reference frame of the Neptune system. One would need to play around with the initial state vectors to ensure a minimal least squares difference between the trajectories produced by one's co-integration calculations and those of JPL's ephemeris calculations over the period 1950 to 2050. This is a little intricate to set up, but quite do-able.

Once one has calculated the right initial state vectors for all of the bodies in the Neptunian system, one can then extend the co-integration as far back in time (and as far forward in time) as you deem appropriate.

Having completed the co-integration, one can then generate Chebshev interpolation files for the integrated paths in the same format as JPL's ephemerides.

Finally, if one wanted to be really clever, one could include relativistic terms in the gravity model (a la JPL). However, I suspect that for the Neptune system relativistic corrections can safely be ignored.

 

[Chode]

Thanks for the feedback and suggestion.
What I am planning on doing is to compute two sets of osculating elements for the
orbit based on the state vectors at the beginning and end of the covered interval and
use these to compute the ephemeris outside the interval. This will insure that there will
be no discontinuities at the transition times and will not require more data needed
by the module.
Although extending a numerical integration forwards and backwards in time might be more
accurate, the data required to implement the ephemeris from piecewise polynomial fits is around 7M
per century (in this case), no matter how it is generated. Also, even a numerical integration can be
expected to eventually diverge from reality due to accumulation and compounding of errors.

 

[cristiapi]

[...] the data required to implement the ephemeris from piecewise polynomial fits is around 7M per century (in this case), no matter how it is generated.

For Nereid I created a 840 kB data file (Chebyshev coefficients) for 22807 days (1.3 MB/cy); I consider reasonable an RMS= 1.8 m (the 95th percentile of the errors is 1.6 m).

---------- Post added at 23:31 ---------- Previous post was at 23:23 ----------

So, what data can I get from JPL for Nereid?

If you know how to read .nio file (JPL's NAVIO format) you can get data from 30-DEC-1799 to 02-JAN-2200:
ftp://ssd.jpl.nasa.gov/pub/eph/satellites/nio/LINUX_PC/
Unfortunately, I don't know how to read NAVIO files.

 

[Chode]

I do know how to extract ephemeris data from .nio files, but I hadn't realized that some of those files had more coverage than .bsp data.

Thanks for that info.

It turns out that .nio files contain exactly the same data contained in .bsp files where they overlap and derive from the same integration.

On the subject of compacting that data, I have reduced my data requirements down to about 2.5MB/cy. Obviously, you (cristiapi) have a
method to compact the data even further.

Regards

 

[cristiapi]

I do know how to extract ephemeris data from .nio files, [...].

Please, would you be so kind to tell me how to do that?

It turns out that .nio files contain exactly the same data contained in .bsp files where they overlap and derive from the same integration.

NASA's NAIF, almost always, creates an exact copy of the .nio files, but for the Neptune ephemeris ("nep077.bsp" and "nep081.bsp") the .nio files have a wider timespan, check it out.

On the subject of compacting that data, I have reduced my data requirements down to about 2.5MB/cy. Obviously, you (cristiapi) have a method to compact the data even further.

I don't compact the original files, I use them to calculate my own Chebyshev coefficients for a given timespan and accuracy (my target accuracy is usually RMS ranging from 2 to 50 m).

Ciao, Cristiano

 

[Chode]

On reading .nio files:
There isn't much documentation publically available on the format of .nio files, so I started snooping around with a hex editor to
decode the format for myself.

What I found out:
The data at the beginning of the file contains text information about the file such as the timespan of the data, the bodies included,
the reference epoch, the master time interval, the degree of the polynomial fit for each body (NDEG), the timespan of the data blocks
for each body (timespan = master interval/NDIV).
A data block consists of:
4 bytes that I don't know what it's for.
2 doubles that contain:
the JD of the midpoint of the block (offset from the reference epoch)
the radius of the interval (half of the span of the interval)
a lot of doubles that are the coefficients of the Chebyshev polynomials for the fit of the position and velocity of the body for
that interval. The number of doubles can be computed simply as 6 x (degree of fit + 1). My utility program just reads
these and outputs them as text for further analysis/processing.
By searching the .nio file for the JD of the supposed midpoint of the first data block, I can determine the offset of the first data block from the
beginning of the file so my utility program knows where to start reading blocks. For nep081.nio, for example, I found the file contains:
36525 data blocks (788 bytes each) for Triton ( 15th order polynomial with a 4 day timespan per block) starting at offset 5736
36525 data blocks (548 bytes each) for Nereid ( 10th order polynomial with a 4 day timespan) starting at offset 2878736
292200 data blocks (788 bytes each) for Proteus ( 15th order polynomial with a 0.25 day timespan) starting at offset 48803136
36525 data blocks (548 bytes each) for Neptune ( 10th order polynomial with a 4 day timespan) starting at offset 279056736

If you need more details, please PM me.

Regards