# JPL Horizons - "highly accurate measurements of planetary positions" - how do they do it?

According to JPL Horizons, with regard to their planetary position calculations,

... we integrate the equations of motion in Cartesian coordinates ($$x,y,z$$), and we adjust the initial conditions in order to fit modern, highly accurate measurements of planetary positions.

So, for example, the $$x$$ component of Jupiter's position vector on 2027-Oct-06 00:00:00.0000 TDB is -760195921115.2376 metres. To this non-astronomer, that is a mind bogglingly precise figure. How on Earth (no pun intended) do astronomers make measurements of planetary position accurate to 0.0001 metres?

• Behind the scenes, Horizons uses the SPICE library and its "kernels" which are developed independently of Horizons. In the header, Horizons usually tells you which kenel file was used to generate the ephemeris. Jun 25, 2022 at 16:33
• The output you received was -7.601959211152376e08; the units were in kilometers. When you ask for "vectors" you'll notice that the output always lines up very nicely. That's because JPL Horizons outputs state vectors "in all their 16 decimal-place glory". The accuracy of those positions and velocities is a different matter, and are not particularly easily computed. The accuracy (or lack thereof) depends on the source(s) that Horizons used to compute those vectors and on time. Jun 25, 2022 at 21:20

The JPL ephemerides are good, but they certainly are not precise to the fraction of a millimetre!

From the Horizons docs:

## Statement of Ephemeris Limitations

To produce an ephemeris, observational data (optical, VLBI, radar & spacecraft) containing measurement errors are combined with dynamical models containing modeling imprecisions. A best fit is developed to statistically minimize those errors. The resulting ephemeris has an associated uncertainty that fluctuates with time.
[...]
Cartesian state vectors are output in all their 16 decimal-place glory. This does not mean all digits are physically meaningful. The full-precision may be of interest to those studying the ephemerides or as a source of initial conditions for subsequent integrations.

For details on how the Ephemerides are produced, including some information on how the integration is fitted to observational data, please see

The JPL Planetary and Lunar Ephemerides DE440 and DE441, Ryan S. Park et al 2021 AJ 161 105.

https://doi.org/10.3847/1538-3881/abd414

I'd like to mention that there are some objects in space for which we do have remarkably precise distance information. Most notably, there are the Lunar Laser Reflectors. This gives us pretty good location data for the Moon; OTOH, knowing the locations of a bunch of reflectors doesn't give us the location of the Moon's centre of mass to the same precision. At this level of precision, the Moon is definitely not a rigid homogeneous sphere. Park et al discuss the features of the model used by JPL of the Moon's interior.

Also, we can get pretty good position info from spacecraft, from the time it takes for a radio signal to travel from Earth to the craft (and back). This data has improved our precision of various distances in the Solar System.

• You beat me to it! Plus 1, and my answer that I was just about to post is gone. It might help to highlight Cartesian state vectors are output in all their 16 decimal-place glory. Jun 25, 2022 at 15:04
• Much appreciated, @David. Jun 25, 2022 at 15:17
• In other words, you need to know how many of those digits are significant. Jun 26, 2022 at 4:31

@PM2Ring's answer does a great job of explaining that folks who do careful numerical integration keep a large number of digits beyond the final accuracy because if they didn't, after tens of thousands or even millions of integration steps computer round-off error would accumulate and threaten to dominate as a source of error.

Since I don't yet know how many steps they use per year of simulated time, I've just asked

Further, for most computer architectures and libraries we don't have the option to use exactly the number of digits of accuracy we need. Instead there are standards that define 32, 64, and 128 bit binary representations of floating numbers for example, and computers and their numerical processors are built around these.

It's dangerous to write anything about this topic without an expert dropping by and correcting this or that because numerical precision is such a critical issue, but to illustrate I'll type numpy.finfo(float) into Python and get for example

finfo(resolution=1e-15, min=-1.7976931348623157e+308, max=1.7976931348623157e+308, dtype=float64)

We can see that the computer uses 64 bits for mantissa, exponent, and two signs. Sixteen decimal places (your number) eats up roughly 53 bits out of 64, the rest go to the exponent and two signs.

It's pretty common to share raw output of the numerical integration by displaying all the digits. Since solar system distances when expressed in kilometers can be shown without needing scientific notation, you end up with sixteen digits displayed.

### The underlying question

How on Earth (no pun intended) do astronomers make measurements of planetary position accurate to... metres?

As pointed out, timing pulses of light reflected from the Moon doesn't directly measure the center of the moon, but measuring round trip delays and doppler shifts of microwaves from Earth to spacecraft orbiting solar system bodies for weeks, months, or even years does allow one to eventually get the distances to the gravitational centers of these bodies to meters.

That's done by simulating, varying the inputted masses and finding the best match to the data for the microwave delays and Doppler shifts collected.

We can read more about the ephemerides (pronounciation) used in JPL Horizons On-Line Ephemeris System

Since August 2013, Horizons has been using ephemeris DE431. During the week of 12 April 2021, the Horizons ephemeris system was updated to replace the DE430/431 planetary ephemeris, used since 2013, with the new DE440/441 solution. The new DE440/441 general-purpose planetary solution includes seven additional years of ground and space-based astrometric data, data calibrations, and dynamical model improvements, most significantly involving Jupiter, Saturn, Pluto, and the Kuiper Belt. Inclusion of 30 new Kuiper-belt masses, and the Kuiper Belt ring mass, results in a time-varying shift of ~100 km in DE441's barycenter relative to DE431.

Let's look at The JPL Planetary and Lunar Ephemerides DE440 and DE441 You can read about the numerical integration and accuracy, but here I'll show how the final results match to the measure data for orbiters around solar system bodies.

You can see that the residual errors are indeed of the order of a few meters. This is a result of simulating the many gravitational forces between a large number of solar system bodies (planets, asteroids, moons, etc.) and some non-gravitational effects using equations similar to $$F=ma$$ except corrected to some order for relativistic effects.

For more on that see answers to

Not shown are any of the angular determinations for orbiting spacecraft made by VLBI.

### The Moon:

Figure 4. Residuals of LLR ranges against DE440. The rms residual of the LLR ranges is about 20 cm for the early data and is about 1.3 cm for the recent data.

### Mercury:

Figure 5. Residuals of the MESSENGER range data against DE440. The rms residual of the MESSENGER ranges is about 0.7 m.

### Venus:

Figure 6. Residuals of the Venus Express range data against DE440. The rms residual of the Venus Express ranges is about 8 m.

### Mars:

Figure 7. Residuals of the Mars orbiter range data against DE440. The rms residual of the MEX ranges is about 2 m and the rms residuals of the MGS, ODY, and MRO ranges are about 0.7 m.

### Jupiter:

Figure 9. Residuals of the Juno range data against DE440. The rms residual of the Juno ranges is about 13 m.

• Regarding available computer precision: arbitrary precision math libraries exist for a lot of popular languages, so precision is really limited by the amount of available memory and desire of a developer of the system to use such a library.
– n0rd
Jun 27, 2022 at 1:56
• @n0rd I've always wondered if those are as fast as using precisions that are native to the environment that you're working on. (For numerical projects like this speed can sometimes be a limiting factor.) I've always wondered because I simply don't know, but if they turn out to be substantially slower then relevance in this context may be limited.
– uhoh
Jun 27, 2022 at 1:59
• no, of course they are not as fast as native types, what's worse, they tend to get slower with precision growth, so it is a question of what how many computations one has to make.
– n0rd
Jun 27, 2022 at 2:07
• @DavidSzwer Arecibo radio astronomy was excellent for rocky near Earth asteroids, and not only did it give distance and speed but surface images as well! There have also been direct radar ranging of Mercury and Venus for sure, probably from radio telescopes other than Arecibo, but those are not as accurate because they reflect off the wide, round, uneven front surface of the whole planet, whereas an orbiting spacecraft measured over many many orbits can find the planet's center of gravitational mass, rather than surface features.
– uhoh
Jun 27, 2022 at 9:51
• I don't have measurements. For multiplications it's more complicated, for somewhat small n the schoolbook algorithm that runs in time n^2 will be fastest, for large n (maybe 1024 bits and larger) there are more efficient algorithms. Jun 29, 2022 at 9:47