# Are elliptical orbits really elliptical?

I have wondered for a long time how elliptical orbits can work. It seems awkward for a freely-moving object to come very close to a source of gravity and then return to the exact point where it started. I started to wonder even more after playing with the Box2D physics engine recently and finding that when I caused one object to be pulled toward another one, it didn't trace out a full ellipse. Instead, when the orbiting body approached the stationary body, it swerved in a different direction and started tracing out a new ellipse over there. The resulting orbit resembled the Treyarch logo, which I now suspect was inspired by physics demos in the company's early history.

So what I want to know is whether real-life "elliptical" orbits are really doing this. I suppose that if you apply relativity, it could still be called an ellipse.

For the record, I know that Box2D is only a rough approximation of physics.

-
On a related note, there is also this en.wikipedia.org/wiki/… – joshphysics Aug 2 '13 at 17:22
I guess that would be the "tiny deviations" that Guillermo's answer referred to. And Box2D was blowing them out of proportion by rounding. – Wutaz Aug 2 '13 at 17:35
Off topic: the Treyarch logo is a trefoil knot. – ZachMcDargh Aug 2 '13 at 19:23
@Wutaz Unless you put in the general relativity yourself ;) I assure you the simulation is not able to compute apsidal precession. That's just an example of how one can get a similar phenomenon using different laws of physics. The only "tiny deviations" in pure Newtonian mechanics are the result of (1) other bodies in the system or (2) the bodies not being perfect, rigid spheres. – Chris White Aug 2 '13 at 20:13
Were you only using 2 objects? This sounds like an example of the 3 body problem. Also, how large was the second object? This may be (as one Guillermo pointed out) a result of inaccuracies, but I would like to add in the wobble effect as a possible culprit. Also, if you get too close to the center of a massive object, (such as a black hole) you will have some odd effects (I once was using my own custom physics engine and forgot to add a collider to one of them, also didn't give any initial velocity. An interesting effect). – Garan Aug 2 '13 at 21:49

As Guillermo Angeris correctly pointed out, this is essentially a numerical roundoff problem, not a physical situation.

As a physical example, there are sungrazing comets that get very close to to Sun, yet they maintain their original elliptical (or hyperbolic) orbit, without the orbit precessing a full third of a circle as you seem to be seeing.

Computationally, there are a few interesting issues. As Kyle pointed out in a comment, many integration schemes are indeed unreliable in that roundoff error (which is always present in floating-point computations) can accumulate in a runaway feedback. Indeed I often advise using leapfrog methods over Euler (used by Box2D) or even Runge-Kutta (see for instance What is the correct way of integrating in astronomy simulations? over at the Computational Science Stackexchange).

However, I suspect your problem is even simpler, in the sense that even an unstable numerical scheme should work for one or two orbits. Given that everything is going wrong in just one pass, it seems that your timesteps are simply too large. A brief glimpse at the Box2D documentation suggests you don't change the timestep mid-simulation, so I presume you are just using a good value to simulate the whole process in reasonable time. The problem is that when gravitating bodies get close in their orbit, they move quickly, sometimes very quickly. The way the code works is it updates each object's position and velocity at each timestep, where the new velocity is determined by the force. As far as I can tell, this is done in line 206 of b2Island.cpp (v. 2.2.1):

v += h * (b->m_gravityScale * gravity + b->m_invMass * b->m_force);


Without looking at your code, I am guessing you simply calculate the gravitational force the body should feel at that moment, and have the simulation chug away. The problem is this moves the orbiting object in a straight line for the next timestep, and that straight line takes it too far away from the gravitating mass for that mass to properly curve its orbit into a closed ellipse. The quick schematic below shows the blue object moving to the tip of the red arrow, rather than staying on the path.

Physically, your timestep should be smaller than any timescale you encounter in the problem. Now for an orbit conserving angular momentum, the product of the orbiting body's mass, tangential velocity $v$, and distance from the other object $r$ should be constant: $v \sim 1/r$. At the same time, the acceleration $a$ it feels is given by Newton's law of gravity: $a \sim 1/r^2$. So one natural timescale in this problem is $$t \sim \frac{v}{a} \sim \frac{1/r}{1/r^2} \sim r$$ (omitting dimensional constants), which goes to show that if your timescale is just barely small enough and then you tweak the orbit so as to half the periapsis distance (distance of closest approach), then you would expect to need timesteps at least twice as small in order to preserve the integrity of the simulation.

-
I switched my accept to this answer because it's more complete. I actually feel a little dumb now for forgetting to consider the effect of step length and that computers prefer straight lines. – Wutaz Aug 3 '13 at 13:55

"The resulting orbit resembled the Treyarch logo, which I now suspect was inspired by physics demos in the company's early history."

Yes, indeed they are elliptical, but there are also extremely tiny deviations from this general case (which are extremely difficult to observe, in general, even after some time). It's important to note that computers have a fixed accuracy (i.e. limited by the mantissa and exponent) used for computation, and, frequently, when dealing with precise computations, even these small errors will amplify to large results, as is commonly studied in computational sciences.

So, overall, the orbits are indeed an ellipse--up to very, very, very tiny fluctuations from this, relative to orbit---, but what you are observing in your physics simulation is a rounding error due to the maximum precision for the type of data structure used to hold the position and other variables of importance in the simulation.

-
And if you want to prove this to yourself, have your non-stationary object zoom really close to your stationary object. You'll see larger and larger deviations, and very wild behaviour. – Jerry Schirmer Aug 2 '13 at 17:17
Well, getting it closer was difficult to do, since it was quite cose to begin with, but I did notice that making it farther away reduced the swing. I never realized that rounding could have such drastic effcts. Good thing my program isn't going to involve obiting when it's done. – Wutaz Aug 2 '13 at 17:28
There are neat things you can do to help deal with rounding issues. Some integration schemes are set up so that the rounding error tends to cancel out over the course of an orbit; these tend to suppress the orbital precession. For instance, leapfrog is better than a similar Runge-Kutta method in the sense that it is symplectic. – Kyle Oman Aug 2 '13 at 18:37

Elliptical orbits are only truly elliptical if the mass they orbit around is truly a point pass, or perfectly symmetrical.

True point masses exist only in models. Therefore, perfectly ellptical orbits also exist only in models. If a spacecraft orbits Earth, for example, the local gravity field changes continously. The Earth is not a sphere, the Earth is not a spheroid, but the geoid has a rather complicated shape. As a result, there are ever so slight variations in the orbit.

This is not just some theoretical consideration. In fact, the GOCE spacecrafts use this exact principle for the purposes of Earth observation! For example, by measuring slight changes in gravity, they can measure ocean currents and moving ice caps. The differences are very small, and you're going to need very high precision to simulate it, but they're real and cannot always be neglected in the real world.

-

If you use Newton (left), there should be no perihelion shift. If you use Einstein (right), there is one:

The equations of motion are not so different, if you differentiate by proper time the only difference between Newton and Schwarzschild is the red term in

$$\color{black}{\ddot{r}(t) = -\frac{G\cdot M}{r(t)^2} + r(t)\cdot \dot{\theta}(t)^2} \color{red}{ - \frac{3\cdot G\cdot M\cdot \dot{\theta}(t)^2}{c^2}} \color{black}{ \text{ , } \ddot{\theta}(t) = -2\cdot \dot{r}(t)/r(t)\cdot \dot{\theta}(t)}$$

and the additional factors in the initial conditions, $\dot{\theta}(0) = \frac{{v_0\perp}}{r(0)\cdot \color{red}{\sqrt{ 1-v_0^2/c^2}}}$ and $\dot{r}(0) = \frac{{v_0\parallel}\cdot \color{red}{\sqrt{1-r_s/r_0}}}{ \color{red}{\sqrt{ 1-v_0^2/c^2}}}$

so it is very well possible that your simulator takes relativity into account. The only thing that takes more CPU ressources is to render in coordinate time instead of the free falling particle's proper time, but it's still possible.

-