Calculating The Required Speed For Circular Orbit

[Bill Phil]

I made a thread about it earlier. Look it up...

That is not G in earth units. It's scaled to give you the same mass as the sun but smaller radius. It's also for true masses.

[Beale]

I made a thread about it earlier. Look it up...

That is not G in earth units. It's scaled to give you the same mass as the sun but smaller radius. It's also for true masses.

This thread? I can't really find any value in it?

But why should the G constant matter, with size? If I was using real mass units, then for sure it would be 6.674E-11?

If there really was a 33 metre sun (Even if impossible), then surely the constant of gravity is same.

And: V^2/r = GM/r^2

So I can multiply GM divided by distance to the power of two, divide this, then find the square root for velocity?

Edited April 8, 2015 by Beale

[Bill Phil]

The last post in that thread.

The G constant matters with size because it's multiple units. Mass, volume, time. So, a different size with the same mass will have either higher density, or a different G value.

[Beale]

The last post in that thread.

The G constant matters with size because it's multiple units. Mass, volume, time. So, a different size with the same mass will have either higher density, or a different G value.

A constant of 11440?

If we can throw density out of the window (It's not important for the software) Can I use a different method?

[Teamwork]

Forgive me if this may be mentioned in a previous post, but what exactly is being scaled down in this mock solar system? I know you mentioned the diameter of the sun was 33 meters, but does that mean every thing else is scaled down (like the sun's mass is significantly lower, ect).

[Kerbart]

Keeping the units in Earth masses and using 1.02762349819005e-23

Unfortunate results?

I'm not sure what the picture that I'm looking at is supposed to mean but if those lines are proportional to the velocity of the planets you have a bigger problem than figuring out what value G should be. The velocities should be decreasing with the distance to the sun, not increasing.

[K^2]

Beale, why are you dividing by (dist*dist + EPS*EPS), instead of just (dist*dist)? Is this to protect from division by zero? If so, I'm pretty sure it's too large for your scaled-down system. That would both explain why orbits have funny shapes and why your initial velocity computations were wrong.

[Starwhip]

Oh. I think I know what's wrong.

Gravity's force is inversely proportional to the square of the distance between two objects, correct? Your objects are only a few meters (maybe a few hundred) apart. That's a problem. In real life they are MANY millions of kilometers apart.

[BlueCosmology]

Oh. I think I know what's wrong.

Gravity's force is inversely proportional to the square of the distance between two objects, correct? Your objects are only a few meters (maybe a few hundred) apart. That's a problem. In real life they are MANY millions of kilometers apart.

He said he's scaled G.

[Beale]

Forgive me if this may be mentioned in a previous post, but what exactly is being scaled down in this mock solar system? I know you mentioned the diameter of the sun was 33 meters, but does that mean every thing else is scaled down (like the sun's mass is significantly lower, ect).

The masses are scaled to X*EarthMasses, so the sun has a "mass" of 330000.

I'm not sure what the picture that I'm looking at is supposed to mean but if those lines are proportional to the velocity of the planets you have a bigger problem than figuring out what value G should be. The velocities should be decreasing with the distance to the sun, not increasing.

I did notice this, the bodies needed higher velocities at higher orbits, but i thought that was correct (Surface relative velocity?)

Oh. I think I know what's wrong.

Gravity's force is inversely proportional to the square of the distance between two objects, correct? Your objects are only a few meters (maybe a few hundred) apart. That's a problem. In real life they are MANY millions of kilometers apart.

He said he's scaled G.

G is set to IRL.

It should work, regardless of distance right?

IRL you could set up a pea orbiting a bowling ball in theory eh? That's essentially what I'm trying to simulate I guess.

Beale, why are you dividing by (dist*dist + EPS*EPS), instead of just (dist*dist)? Is this to protect from division by zero? If so, I'm pretty sure it's too large for your scaled-down system. That would both explain why orbits have funny shapes and why your initial velocity computations were wrong.

That... That has fixed it.

As far as I can see. (Ignore Jupiter ahaha!)

The EPS was a leftover from an old Python(IIRC) implementation of N-body that adapted, I don't really understand what it meant (This would be really helpful to understand).

K^2, you are my hero!

KSP Community, I love you, seriously. You've saved me a great deal of headache.

[K^2]

The EPS was a leftover from an old Python(IIRC) implementation of N-body that adapted, I don't really understand what it meant (This would be really helpful to understand).

Well, dividing by distance^2 + epsilon^2 makes sure that you are never dividing by a number smaller than epsilon^2. Without it, two bodies can pass really close to each other, resulting in huge forces, which will eject both bodies from the system. If you've ever seen galaxy simulations which spray "stars", that's basically what's happening. Adding epsilon^2 regulates the interaction. But it only works if typical distances are much, much greater than epsilon. If original simulation you've grabbed this from dealt with Solar System scales, and units were meters, than 3E4 is just 30km. You don't expect things to typically get within that range of each other. But your simulation has a totally similar scale, and so that epsilon started to interfere with dynamics. You can try simply tunning it down to see what happens. You should be able to get it low enough to where things still move in proper orbits, but where it prevents you from dividing by a value that's too small when two planets "collide".