Calculating The Speed Of A Moon?

[Beale]

Hello!

Somewhat of a follow up to my last thread.

Is there a general method for finding the velocity needed for a moon to enter circular orbit around a planet?

My English isn't always so great when it comes to technical stuff, so here is an image:

This is for a 2D N-body sim.

All Planets and moons are initialized on a 1-dimensional straight line distance from the sun along the Y axis, so when started V can assumed to be only speed along the X axis.

Or, more specifically:

For the moon, am I just setting VX (As in only sideways initial velocity like a planet) or do I need a VY component?

Sorry, I hope I make myself clear what I'm asking!

Currently I've basically attempted to 'guess' the needed velocity. You can imagine how that has resulted, at best the moon is a temporary satellite before either drifting or being violently gravity-assisted outwards.

Edited May 5, 2015 by Beale

[ZetaX]

The VY component is 0. If it were not your moon would, at least initially, move towards or away from the planet, which is contradicting it being a circle (which means that the distance to the planet is always the same).

But note that this is just "close to a circle" anyway, because the sun will have an effect on the orbit.

Edited May 5, 2015 by ZetaX

[LordFerret]

https://www.shodor.org/succeedhi/succeedhi/orbits/Notes-content.html

and

http://www.dummies.com/how-to/content/how-to-calculate-centripetal-acceleration-of-an-or.html

[Beale]

The VY component is 0. If it were not your moon would, at least initially, move towards or away from the planet, which is contradicting it being a circle (which means that the distance to the planet is always the same).

But note that this is just "close to a circle" anyway, because the sun will have an effect on the orbit.

Good to know, thanks for the info.

https://www.shodor.org/succeedhi/succeedhi/orbits/Notes-content.html

and

http://www.dummies.com/how-to/content/how-to-calculate-centripetal-acceleration-of-an-or.html

Great thanks for the links!

I'll give them a read through, though... They look a bit intimidating!

Any particular part of the pages I should put my attention for a method?

Edited May 5, 2015 by Beale

[Beale]

Hi!

Nope, neither of the links offer quite what I'm after.

They are based on orbital periods which I don't have, but rather do have position, masses and distances.

If I make sense.

More phrasing: what X velocity needed so that moon is naturally "captured" into orbit.

[Brotoro]

Need to know the mass of the planet.

[Beale]

Need to know the mass of the planet.

It's 1 Earth mass, but what I'm after is a general method, rather than calculating a specific instance.

[UmbralRaptor]

I'd lean towards conservation of energy or Vis-Viva, using either to generate an ellipse with a semi-major axis inside the Hill sphere, or better still inside the sphere of influence of the planet.

It's not completely guarenteed in the long run (because N-body), but should be stable for a while.

[Brotoro]

If the planet mass is m, and the moon is a distance r away from the planet (center to center), then the circular orbit speed of the moon will be SQRT(Gm/r) around the planet. Add that to the planet's orbital speed around the star, SQRT(GM/R), and you'll have the moon's velocity relative to the star at the point shown in your diagram.

[Beale]

I'd lean towards conservation of energy or Vis-Viva, using either to generate an ellipse with a semi-major axis inside the Hill sphere, or better still inside the sphere of influence of the planet.

It's not completely guarenteed in the long run (because N-body), but should be stable for a while.

Thanks for the links.

With the info, I can add SOI rendering, which will be quite nifty!

I was a little worried about SOIs, they seem to be rather small (because things are probably closer to the sun than they should be).

Still, this may be fixed by reducing the suns mass.

Stability: Long term not absolutely needed.

Cheers!

If the planet mass is m, and the moon is a distance r away from the planet (center to center), then the circular orbit speed of the moon will be SQRT(Gm/r) around the planet. Add that to the planet's orbital speed around the star, SQRT(GM/R), and you'll have the moon's velocity relative to the star at the point shown in your diagram.

Ah!

A nice solution, many thanks for this Brotoro, much!

Kind regards.

Edited May 5, 2015 by Beale

[Bill Phil]

Orbital speed required at the "moon"'s distance to the planet, and the current speed of the "moon" relative to the planet. Get the difference of the two and that should be it....

[arkie87]

Hi!

Nope, neither of the links offer quite what I'm after.

They are based on orbital periods which I don't have, but rather do have position, masses and distances.

If I make sense.

More phrasing: what X velocity needed so that moon is naturally "captured" into orbit.

You have the formula right there in your picture: V=sqrt(G*M/R)=sqrt(g*R)

[YNM]

You can use the relative velocity. As lomg as it's less than escape velocity it should be in orbit. Except it's very far, that is. To determine how far until it escapes (even when the relative velocity is small enough), Hill sphere would be the best way to do it, or the closest (to the planet) lagrange point of the planet.

[K^2]

If the planet mass is m, and the moon is a distance r away from the planet (center to center), then the circular orbit speed of the moon will be SQRT(Gm/r) around the planet. Add that to the planet's orbital speed around the star, SQRT(GM/R), and you'll have the moon's velocity relative to the star at the point shown in your diagram.

It might be worth pointing out that this isn't an exact answer. It's a good starting point, and might be all you need for a sim, but it won't be quite right. For starters, reduced mass is giong to be a factor here. Even if the star is taken to be stationary, planet is clearly being simulated. So planet's-to-moon's mass ratio is going to be important.

But even outside of that, you're firmly in the 3-body world here. Even with a stationary star, the planet-moon system experiences a periodic perturbation. If they are close to resonance, big trouble. If not, it will still cause a slight change in moon's period. So even with reduced masses in place, the orbital velocity will be slightly off.

You can imagine how that has resulted, at best the moon is a temporary satellite before either drifting or being violently gravity-assisted outwards.

And that's likely to keep happening.

a) I'm pretty sure your simulation will have significant errors.

At that scale, there is going to be significant interaction between the two orbits.

Either one of these might have been alright, but toghether, you're pretty much guaranteed an ejected moon.

[Beale]

Orbital speed required at the "moon"'s distance to the planet, and the current speed of the "moon" relative to the planet. Get the difference of the two and that should be it....

You can use the relative velocity. As lomg as it's less than escape velocity it should be in orbit. Except it's very far, that is. To determine how far until it escapes (even when the relative velocity is small enough), Hill sphere would be the best way to do it, or the closest (to the planet) lagrange point of the planet.

So the Moon's X velocity should have add to it the relative velocity between the two bodies? Sorry I don't follow quite completely.

I'm trying to calculate the hill sphere, but don't quite understand the mathematic notation (Specifically the Square root with a power of 3 on it?).

Thanks for the help

You have the formula right there in your picture: V=sqrt(G*M/R)=sqrt(g*R)

Yes, this works if the earth was standing still and I was calculating the speed of the Moon alone, but relative to the sun is what is needed.

If I understand you right.

It might be worth pointing out that this isn't an exact answer. It's a good starting point, and might be all you need for a sim, but it won't be quite right. For starters, reduced mass is giong to be a factor here. Even if the star is taken to be stationary, planet is clearly being simulated. So planet's-to-moon's mass ratio is going to be important.

But even outside of that, you're firmly in the 3-body world here. Even with a stationary star, the planet-moon system experiences a periodic perturbation. If they are close to resonance, big trouble. If not, it will still cause a slight change in moon's period. So even with reduced masses in place, the orbital velocity will be slightly off.

And that's likely to keep happening.

a) I'm pretty sure your simulation will have significant errors.

At that scale, there is going to be significant interaction between the two orbits.

Either one of these might have been alright, but toghether, you're pretty much guaranteed an ejected moon.

I've applied Brotoro's methods and reproduce the problems you describe unfortunately.

The Moon typically makes one, two or even three (unpredictable!) orbits around the Earth before drifting away.

I think perhaps the Earth does not provide much at all influence (hill sphere?) to hold it correctly, even in very close orbits.

Strangely, reducing the mass of the sun, even drastically does not seem to increase the Earth's influence...

I'm a little confused about your point A, that seems a little abrasive... Unless I'm reading you wrong.

Edited May 7, 2015 by Beale

[K^2]

Gravity is notoriously difficult to deal with numerically. Even if you have prior experience with numerical methods in differential equations, unless you studied numerical methods in gravity extensively, it is very unlikely that your simulation is up to the task. Don't take it the wrong way. It is a deceptively hard problem.

Your description makes it sound even more unstable than it needs be, though. How do you update position and velocity in your simulation?

[Beale]

Gravity is notoriously difficult to deal with numerically. Even if you have prior experience with numerical methods in differential equations, unless you studied numerical methods in gravity extensively, it is very unlikely that your simulation is up to the task. Don't take it the wrong way. It is a deceptively hard problem.

Your description makes it sound even more unstable than it needs be, though. How do you update position and velocity in your simulation?

Okay, no worries. Is a more than fair point, I am very much an amateur here.

I'm using a Barnes-Hut approximation to update the forces acting on the body (But since there are no largely clustered objects, might just consider it a direct approach).

The force calculation:

	
public void addForce(SimBody _bodyTwo)
	{
		SimBody _bodyOne = this;
		double dx = _bodyTwo._rx - _bodyOne._rx;
		double dy = _bodyTwo._ry - _bodyOne._ry;
		double dist = Math.sqrt(dx*dx + dy*dy);
		double F = (G * _bodyOne._mass * _bodyTwo._mass) / (dist*dist);
		_bodyOne._fx += F * dx / dist;
		_bodyOne._fy += F * dy / dist;
	}

After the force is calculated, the position is updated via the force * delta time.

	
public void update(double _deltaTime) 
	{
		_vx += _deltaTime * _fx / _mass;
		_vy += _deltaTime * _fy / _mass;
		_rx += _deltaTime * _vx;
		_ry += _deltaTime * _vy;

		updateTrail();
	}

_vx & _vy = Velocity values

_rx & _ry = position values

I think the delta-time will lose accuracy as the simulation is "speed up", but the unpredictable orbit of the moon is noticed in (painstakingly) observing it at a much lower delta tick.

I decide potentially to just set the Moon and other Moons "on-rails". It's a less elegant solution, but I'm focusing more on aesthetics and education (Can't teach the Moon takes 28 days to orbit if it is flying away ).

Edited May 7, 2015 by Beale

[K^2]

Ok, this is called Forward Euler method, and it is the cause of it being as bad as it is. Try applying Velocity Verlet. The standard description is a bit confusing because of velocity update, but basically, you want following scheme.

a_new = F/m

v = v + dt * (a_old + a_new)/2

x = x + dt * v + dt * dt * a_new/2

a_old = a_new

Do this for x and y for each time step. a_old can start out as 0, but then you need to maintain it from step to step.

The beauty of this method is how simple it is, yet, it makes a huge improvement. I would still expect the moon to drift off, but it should take much longer. An even better improvement can be gained by going to 4th order Runge-Kutta (RK4) method, but it is also significantly harder.

Real NASA-grade simulations usually use relatively low order implicit methods specifically designed for this. They involve some crazy math.

[Beale]

Ok, this is called Forward Euler method, and it is the cause of it being as bad as it is. Try applying Velocity Verlet. The standard description is a bit confusing because of velocity update, but basically, you want following scheme.

a_new = F/m

v = v + dt * (a_old + a_new)/2

x = x + dt * v + dt * dt * a_new/2

a_old = a_new

Do this for x and y for each time step. a_old can start out as 0, but then you need to maintain it from step to step.

The beauty of this method is how simple it is, yet, it makes a huge improvement. I would still expect the moon to drift off, but it should take much longer. An even better improvement can be gained by going to 4th order Runge-Kutta (RK4) method, but it is also significantly harder.

Real NASA-grade simulations usually use relatively low order implicit methods specifically designed for this. They involve some crazy math.

This is wonderful, thank you most kindly for info and method, I'll give this a try.

The further methods, though I doubt I will go near implementing them, will be excellent topics to bring up in the report on simulation I write .

Thanks & Kind regards.

Edit: Small clarification,

"v" is vx for X and vy for Y, or should be a product of vx and vy?

I.E.

a_new = F/m
vx = vx + dt * (a_old + a_new)/2
x = x + dt * vx + dt * dt * a_new/2
a_old = a_new

Edited May 7, 2015 by Beale

[Meithan]

I came to this thread too late because K^2 has already provided great info. Just two things:

1) If you're simulating a small number of bodies, efficient algorithms like Barnes-Hut are unnecessary: you can just directly calculate the forces using Newton's law of gravitation. You can save somw work by avoiding doing double calculations: if you already calculated the force caused by A on B, don't compute the force by B on A, just use the previous result with a negative sign.

2) As K^2 pointed out, the Euler algorithm is a bad idea for N-body simulations. The velocity-verlet, on the other hand, is pretty good for simple simulations. I've done toy simulations of our solar system for 10,000 years using the velocity-verlet, and it's pretty stable. The first image shows the Sun, the inner planets and Jupiter. The second image shows the relative error in the total mechanical energy of the system after 1000 years. As you can see, it's tiny (no larger than 1 part in 10^9).

Now, as K^2 mentioned, your simulation has three bodies, two of which are big, in close proximity, so the system might be both inherently unstable and hard to simulate accurately. Beware.

Keep us posted on your results.

[Beale]

I came to this thread too late because K^2 has already provided great info. Just two things:

1) If you're simulating a small number of bodies, efficient algorithms like Barnes-Hut are unnecessary: you can just directly calculate the forces using Newton's law of gravitation. You can save somw work by avoiding doing double calculations: if you already calculated the force caused by A on B, don't compute the force by B on A, just use the previous result with a negative sign.

2) As K^2 pointed out, the Euler algorithm is a bad idea for N-body simulations. The velocity-verlet, on the other hand, is pretty good for simple simulations. I've done toy simulations of our solar system for 10,000 years using the velocity-verlet, and it's pretty stable. The first image shows the Sun, the inner planets and Jupiter. The second image shows the relative error in the total mechanical energy of the system after 1000 years. As you can see, it's tiny (no larger than 1 part in 10^9).

http://i.imgur.com/ToBNJRIt.png http://i.imgur.com/NN8SlT7t.png

Now, as K^2 mentioned, your simulation has three bodies, two of which are big, in close proximity, so the system might be both inherently unstable and hard to simulate accurately. Beware.

Keep us posted on your results.

Hi!

No, all input is appreciated regardless of chronological order, many thanks

On 1: Yep, I learned this a little too late - begin this project a little naive, and research I found gave me the impression that Barnes-Hut was better for performance (I'm developing cross-platform, so was considering lower-spec phones and tablets). At the end, now I am simulating maybe 20 bodies maximum (Planets + The Moon + Asteroid and Kuiper belt objects), though the user has opportunity to add up to 300 extra bodies to the sim during run-time.

On 2: Very nice to see this, it is encouraging. This is MatLab? My major hope is "stability" for maybe only ~10 orbits or so, to see this produce 10,000 years ( I'm not aiming for this though ) of stability is nice.

On distance, Ideally I would make things at a larger scale, it is unfortunate that my graphics rendering API only supports float values for rendering and approximation errors mean vertex distortion when meshes are a long distance away, take example of Pluto: (This video is out of date, ignore silly UI).

Have I the time, this could be adapted to a "local-space" type system to avoid such issues, and move to a larger scale, but it's unfortunate.

Edited May 7, 2015 by Beale

[Meithan]

On 1: Yep, I learned this a little too late - begin this project a little naive, and research I found gave me the impression that Barnes-Hut was better for performance (I'm developing cross-platform, so was considering lower-spec phones and tablets). At the end, now I am simulating maybe 20 bodies maximum (Planets + The Moon + Asteroid and Kuiper belt objects), though the user has opportunity to add up to 300 extra bodies to the sim during run-time.

20 bodies is definitely doable by direct force calculation; 300 I'd say so too, depending on what system it's running on, what programming language and how small you want the timesteps to be.

On 2: Very nice to see this, it is encouraging. This is MatLab? My major hope is "stability" for maybe only ~10 orbits or so, to see this produce 10,000 years ( I'm not aiming for this though ) of stability is nice.

No, it's a Fortran code I wrote plotted with gnuplot.

Keep in mind the solar system is pretty stable: the orbits are nearly circular and they're pretty far apart. Close encounters are the bane of numerical N-body simulations: they'll quickly make the numerical error really bad.

If you're getting close encounters you'll probably need to make the timestep (how much each step of the calculation advances time) smaller, or even 'adaptive' (automatically adapt to be small when bodies are close and large when they are far away). But that's another story, I'd get the basic velocity verlet working first.

On distance, Ideally I would make things at a larger scale, it is unfortunate that my graphics rendering API only supports float values for rendering and approximation errors mean vertex distortion when meshes are a long distance away, take example of Pluto: (This video is out of date, ignore silly UI).

The KSP devs ran precisely into this problem. An adaptive resolution mesh for the planets and movable coordinate origin are ingredients of the solution.

[K^2]

I've found that there are energy gains even with nice circular orbits over rime, but yeah, it is nowhere near as bad as elliptic ones. Maybe it is good enough.

Yes, v is vx for x and vy for y. Same with acceleration and force.

[Meithan]

I've found that there are energy gains even with nice circular orbits over rime, but yeah, it is nowhere near as bad as elliptic ones. Maybe it is good enough.

If the integrator is symplectic, and the velocity verlet is an example of one, then by design the energy errors should be bounded and quasi-periodic, and not add up over time -- that's the beauty of symplectic integrators. See the energy error graph I posted earlier: the energy fluctuates almost periodically (the "main" oscillation seems to have a period very similar to that of Mercury, about 1/4th of year) but the error never becomes greater than 10^-9 -- and in principle this would hold for indefinitely long periods of time.

With Runge-Kutta integrators, which are not symplectic, the story is different, and the energy error will build up over time, which is why they're not preferred to study the long-term stability of gravitational systems. In practice, though, a fourth-order Runge-Kutta integrator with its gradually accumulating error should still yield better results than the second-order velocity verlet if the integrated time is not too long, simply because the error is considerably smaller in the first place (due to the method being of higher order).

Edited May 7, 2015 by Meithan

[K^2]

If the integrator is symplectic, and the velocity verlet is an example of one, then by design the energy errors should be bounded and quasi-periodic, and not add up over time -- that's the beauty of symplectic integrators. See the energy error graph I posted earlier: the energy fluctuates almost periodically (the "main" oscillation seems to have a period very similar to that of Mercury, about 1/4th of year) but the error never becomes greater than 10^-9 -- and in principle this would hold for indefinitely long periods of time.

Verlet is not symplectic with 1/r potential. No known method is. Verlet is symplectic with r² potential, such as Hooke's law used in collisions, which is why it's a favorite in game dev. But no method is symplectic for all potential types.