I've been playing with simulations of co-orbital bodies similar to Saturn's moons Janus & Epimetheus- horseshoe orbits where the two bodies are of comparable mass- and I'm seeing some very odd patterns that I can't explain.

What "should" happen is that the body with the slightly smaller orbit will eventually overtake the outer body; when their mutual interaction becomes significant compared to their interactions with the primary, the lower body is accelerated forward into a higher orbit, while the higher body is accelerated backward into a lower orbit, they switch positions around their average orbital radius, and then separate again.

What I'm seeing in simulation, however, is a little more complicated. When I simulate the Saturn+Janus+Epimetheus system, the moons' semimajor axis very slowly migrate farther away from their average up until they swap; right around the swap, the difference in semimajor axes is maximized, and they drift closer together for half a cycle and then farther apart again before the next swap. This creates "u" and "n" shapes on the plot of semimajor axis over time, with the plots for each moon in opposite phases.

For Janus and Epimetheus, the effect is very small, but increasing the masses of the moons amplifies it, to the point that the maximum separation in orbital radii that occurs during the moons' closest approach to each other is ten or more times larger than the "normal" separation during the middle of a cycle.

There is of course the possibility that this an artifact of errors in my simulation software, but I think that is unlikely given the following:

  1. All other aspects of the Janus+Epimetheus system are reproduced perfectly- individual orbital periods are correct, average semimajor axes are correct, the frequency of the swaps is correct, and my simulation conserves energy to within less than 1 part in 1 trillion over a petasecond of simulation time (approx. 31,689 years).
  2. The effect is perfectly regular, and simulated systems remain stable. If the effect was a result of simulation errors, I wouldn't expect them to behave so nicely.

My first thought was that perhaps the semimajor axis of each moon was being affected by the added gravity of the other moon when they are on opposite sides of the primary from each other, and when they approach more closely they won't be pulling each towards the primary as strongly. That, however, should result in a uniform expansion and contraction of both moons' orbits as they get respectively closer and farther away from each other. What I actually see is that the inner moon's orbit gets smaller while the outer moons orbit gets larger, and vice-versa.

So, is this likely to just be a simulation error after all (if it helps, I am using the 4th-order Hermite integration algorithm)? If not, what is the explanation for it? Has such an effect been documented before, and if so, where?

  • 1
    $\begingroup$ Have you compared your numbers to DE431? NASA uses higher-order polynomial interpolations: 15th order for Janus and Epimetheus (and these change every 16 hours) and 12th order for Saturn (changing every 2 2/3 days): ssd.jpl.nasa.gov/pub/eph/satellites/nio/LINUX_PC/sat363.txt $\endgroup$
    – user21
    Sep 23, 2015 at 1:06
  • $\begingroup$ @barrycarter I haven't; do you know where the time series data is published? The link in that text file gives me a 404, and the same goes for everything I've so far managed to find through Google. $\endgroup$ Sep 23, 2015 at 3:39
  • $\begingroup$ If you just need numbers, ssd.jpl.nasa.gov/?horizons should do the trick. For the link I provided (if you need actual polynomials), make sure you're using FTP, not HTTP. If that doesn't work, naif.jpl.nasa.gov/naif provides an overview of the SPICE libraries and how to use them, along with http links (I think) to the actual SPICE kernel data. $\endgroup$
    – user21
    Sep 23, 2015 at 12:05
  • $\begingroup$ @barrycarter Thanks! That looks like stuff I can use. $\endgroup$ Sep 24, 2015 at 14:23


You must log in to answer this question.

Browse other questions tagged .