# Simulating an orbit, primary is not at focus

I've been toying around with some -very- simple orbital simulators, mostly using preexisting physics libraries (I took a layman's stab at doing it with vectors too). The thing that is confusing me is that my orbits do not behave as in reality - the primary is always at the center of the ellipse rather than at one of the foci. I get the same result regardless of the engine or library I use.

I've simply been putting in a primary and an orbiter, with the primary at the center of the layout. I plug in the formula $$F = G\frac{m_1m_2}{r_1^2}$$ with the force directed towards the primary. I've tried adjusting the time step, but I get the same result. I'm simply confused as to what would cause this.

Update

You're right, I was multiplying, I just didn't know it (something about the way the Construct2 interpreted my commands). I had it configured to apply the force which was essentially G(arbitrary) / distance * distance (didn't like it when I tried ^2). When I put distance squared in a variable and then divided by it things worked.

Now I had tried this before in Panda3d with the same problem, so I'll have to go back and look at that.

-

## 1 Answer

A few basic checks:

• What size time steps are you taking? Way too big will lead to wild errors. Way too small and changes in velocity and position will be incorrect due to roundoff errors (finite precision).
• Is the primary mass much larger than the orbiter? In real life, the Moon and Earth orbit around a common inertial center. Since the Earth is much heavier, we can declare it stationary at the risk of small errors. I don't think this explains your odd results, however. But it could be a helpful clue to know who is not guilty. (What was the famous Sherlock quote?)
• What initial velocity are you giving the orbiter?
• Do you have a choice of integration method? I can't imagine the wrong choice giving the result you get, but still, clues help...
• You really are telling it inverse square, right? And it's inverse, right? If you multiply not divide by r squared, that will explain centered ellipses.
-
I've been using the frame rate as the time step for now. I've also tried fixing the time-step to an arbitrary number, in fractions of a second, with the same result. At the moment, the force is applied every frame (this is a really arcade-y, proof of concept). The primary is a fixed point. The force is exerted on the orbiter in the direction of the primary. I've picked some arbitrary numbers to plug into the formula. For instance, masses are left out, g is divided by the distance squared. –  T. Mcleod Mar 28 '13 at 17:11
The initial velocity is actually zero, I have it so the orbiter can be controlled (so I can experiment more). I can get into an orbit easily. As for integration method, I really am not well enough educated. At the moment I am using different physics engines to do the hard work for me. –  T. Mcleod Mar 28 '13 at 17:21