# Determining the dominant body in a basic planetary system simulation

TheHarvesteR
Hi,

I have a question/doubt/general-lack-of-understanding here:

I have a simulated solar system here, with simplified orbital mechanics. The main simplification is that at anyone time, only one celestial body exerts gravitational forces on the spaceship.

So, my problem is: What would be the most correct way to determine when to switch dominant bodies?

Currently, what I'm doing is running through all of them, and calculating the gravity acceleration vector for each body, based on the inverse-square relation of G force magnitude and distance.
Then, I apply the greatest force I've found, and set the body from which it came as the dominant one.

I thought this would be a good approximation, but it seems this method doesn't quite match the calculations of the body's own sphere of influence, or it's hill sphere, or any obvious multiple or fraction of those radii...

So I decided it's about time I asked for help on this. ;)

The way I see it, I either need to figure out a better rule for determining the dominant body, or find a way to correctly calculate the point of the switchover.

Also, I have in this same simulation an osculating orbit solver, that is used to predict (and also propagate) the orbits of all objects in the system. Now that I started thinking about this, I've seen closed orbits that lead to outside the sphere of influence of the central body... Is that correct? Shouldn't any orbit that has a higher Apoapsis than the sphere of influence be hyperbolic or parabolic? Or are those concepts unrelated?

So, any help at this point will be greatly appreciated.

As always, thanks in advance!

Cheers

## Answers and Replies

Gold Member
If you are simulating motion by direct numerical integration of the equations of motion then you should sum up gravitational force from all the bodies and not just use the greatest one. Using spheres of influence is mostly common if you are doing patched conics, that is if you use Kepler's equations (i.e. conical sections) to model the motion about the celestial body that contains the spaceship in its sphere of influence and then "patch" it into a different orbit around another primary when the sphere of influence change.

TheHarvesteR
I'm not using direct numerical integration here... well, not all the time.

On high time-compression rates, I disable the numerical integration, and put everything into a propagated orbit. That keeps things stable and predictable, which is more important than accuracy here.

That's why I need to restrict the integrated part of the simulation to the same rules as the 2-body orbital propagation. It's preferable to have them approximated but with matching rules, than to use a full integration that won't match the on-rails orbits.

So, I take it I should use the sphere of influence as the threshold for dominant body selection then?

Cheers

Gold Member
So, I take it I should use the sphere of influence as the threshold for dominant body selection then?

In short, yes. You may want to search your references for the "method of patched conics" if you are not already familiar with that concept. It seems there are at least two textbooks on Scribd that makes a decent explanation of the method.

TheHarvesteR
Hi again.

Just wanted to follow up. I changed the dominant body detection method to a recursive sphere of influence detection scheme here, and it works ok.

However, the problems I was having with reference frame oscillation (the ship would go in and out of a moon's orbit, for instance, and sometimes would get stuck at the threshold), still persisted.

After checking and re-checking the entire code, I couldn't find anything that seemed wrong with it, so I decided to add a 5-second period where the ship is locked against changing reference frames again, just to see what exactly was going on at the moment of transition, and found that with this safeguard in place, there were no problems at all really.

Well, I think this will do for now! :)

Just one more question though... About spheres of influence and eccentricity... My (uneducated) assumption would be that whenever your Ap reaches the central body's SOI radius, it would become an escape trajectory with ecc >= 1. In practice, this isn't what I see... I see highly eccentric closed orbits that do lead far outside the sphere of influence radius.

Is there something wrong with my math? Or is this normal?

Again, many thanks for the help!

Cheers

Gold Member
My (uneducated) assumption would be that whenever your Ap reaches the central body's SOI radius, it would become an escape trajectory with ecc >= 1.

This is not so. For instance, if a spacecraft in orbit around a planet has apoapsis just outside the SOI of that planet, the planet and the spacecraft , when outside the SOI, will still be experiencing more or less the same gravitational force from the distant Sun and thus the forces from the Sun more or less cancels out in the relative motion between the planet and the spacecraft .

Spheres of influence are mostly useful when you have an object on a "sure" escape trajectory in or out of a planet, for instance like when you are planning an interplanetary trajectory. Using patched conics for general simulation in the situation you mention (i.e. when the spacecraft spends relative long periods of time in regions of space where the magnitude of gravitational forces from multiple bodies are comparable) is probably going to produce some pretty inaccurate results compared with a fully numerical integration.

For satellites in Earth orbit one often applies corrections to the satellites orbital elements due to perturbative forces from the Sun, Moon and planets (in addition to those from the uneven Earth potential and atmospheric interaction). It may be that it is possible to do something similar for your orbits near the SOI boundary but I guess it will be difficult to establish the validity of such corrections unless you can find some specifically derived for usage on those orbits. And I'm willing to bet that such an approach will require far more theoretical work and difficult code implementation than a simple numerical trajectory integrator.

Staff Emeritus