On Newtonian trajectories vs. patched conics

[a humble lich]

I would like to be involved with this too. I don't have any experience writing mods for KSP and my C is rusty, but I do have a lot of experience doing dynamical simulations.

[Mattasmack]

In this case your code would help a lot to me. I know C/C++ just as good as I do C#, so language is not a problem at all. If for some reason you'd prefer your code not to be published, feel free to PM me a link to it.

I'm hesitant to distribute it widely because it's raw and still a work-in-progress -- in most aspects, I tried things (like different integration schemes) until I found something good enough and then just went on to the next step. It's by no means optimal and it's not in a state that I wouldn't be embarrassed to show to the public. But if we are to work on a mod together I'll still be able to fix things up as necessary and improve it. In any case, it's also totally uncommented at the moment, which does not aid understanding. Let me comment it and then I'll send it to you.

[Mattasmack]

I'd like to follow up a little regarding L-points, since they came up several times in the thread.

In my first look at Kerbin's L4 point, I simply looked at a system consisting of Kerbol (stationary, at the origin of my coordinate system) with Kerbin circling it in the orbit specified by the Kepler orbital elements given for it in the KSP wiki. When I placed an object where the L4 point ought to be and simulated its trajectory for the next 50 Ms (579 days, or 5.4 Kerbin years), its motion relative to the L4 point looked like this:

In the figure, the origin is the supposed L4 point and is where the trajectory started. This is not plotted in a rotating reference frame, so the spiraling outwards is actually the object drifting downwards (towards Kerbol) and then ahead in its orbit. At the end of the simulation, it's some 64 Mm away from the starting point -- small compared to the orbital radius of ~ 13.6 Gm, but the object is definitely departing the vicinity. I played around with different starting velocities (but not really with different starting positions) and couldn't get any significant improvement over what's shown above.

My explanation for this behavior was that Kerbol and Kerbin weren't actually moving as they should under Newtonian mechanics: Kerbol should not be stationary, instead it and Kerbin should both orbit their barycenter. The difference puts Kerbol about 41 km away from where it should be, and stationary instead of moving at about 3 cm/s through its little orbit. It's a small difference, but I think it is enough to upset the balance of forces that creates the L4 and L5 points in 'real life' (following Newtonian mechanics). Other possibilities include that I simply have a bug in my code, or that the spiral shown above is due to numerical drift. To test my explanation, I redid the simulations but with Kerbol following a small Kepler orbit around the origin, 180 degrees out of phase with Kerbin. This time, when I placed an object at the L4 point and ran the simulation for 50 Ms, I got this result:

Once again the object is drifting away from the L-point, but at the end of the simulation it's only drifted by ~ 70 m! This still isn't numerical drift -- I ran multiple simulations with different error limits and got the same result each time. Instead, it's probably due to my not getting the two orbits of Kerbin and Kerbol exactly right to enough decimal places.

In any case, I think this proves that the approach I described in my original post can't naturally produce L4 and L5 points as they are usually known. The motion of the planetary bodies in their Keplerian orbits just isn't correct for them to form. A full n-body simulation of the Kerbol system would probably be needed to get Lagrange points without resorting to gimmicks.

[Gravitas Shortfall]

Once again the object is drifting away from the L-point, but at the end of the simulation it's only drifted by ~ 70 m! This still isn't numerical drift -- I ran multiple simulations with different error limits and got the same result each time. Instead, it's probably due to my not getting the two orbits of Kerbin and Kerbol exactly right to enough decimal places.

In any case, I think this proves that the approach I described in my original post can't naturally produce L4 and L5 points as they are usually known. The motion of the planetary bodies in their Keplerian orbits just isn't correct for them to form. A full n-body simulation of the Kerbol system would probably be needed to get Lagrange points without resorting to gimmicks.

Hmm, that doesn't seem right to me. Langrange points are a solution to the 3-body problem, but our solar system has plenty of langrange points despite having 8 planets countless other smaller bodies. The gravity of Jupiter is going to give the Sun a different path through space than you'd expect if the only bodies in the solar system were the Sun and Earth, but the Earth lagrange points still 'work'. Mind you, I haven't done all the simulations you have, so I'm just going off intuition. Maybe I'll try running some numbers of my own later.

[Hannu]

It sounds strange for me too that so small disturbation would ruin Lagrange's point. Can you continue this simulation until you see clearly that object escapes from L4? If I look a map of troijan asteroids on Jupiter's orbit, they are spread over very large area. It is about 10 % of radius in radial direction and 40 degrees in angular. In Kerbin's scale it would mean about 1 Gm x 10 Gm kidney shaped area. If it is easy, can you also plot a diagram in rotational coordinates so than shape of orbit around L4 can be seen?

[NovaSilisko]

Unfortunately I feel like no matter how technically possible this might be, the time to actually implement it is long gone... the game's become firmly set into using patched conics, and that's one hell of a hairball to untangle in the name of a bit of realism added.

[SkyRender]

It would be best if KSP does not model actual gravitational perturbations. The game is difficult enough for newcomers as it is. Having to babysit every craft's orbit constantly would kill a lot of the fun of a complex space program.

[haltux]

I'm not sure why the continued calls for n-body physics in KSP. It's already drastically scaled down. All of the bodies are unrealistically dense. None of the planets have axial tilt. And all of this was done to make the game more accessible; n-body physics adds a bunch of complication (for the developers) that would only produce a tangible benefit to a very small sub-set of players. And it goes against the design philosophy of the game, which is to sacrifice realism to conceptual simplicity. It's very nice that you can use analytic equations to solve all orbits in KSP; means that it provides an entry point for the use of maths for someone who might not have seen the utility of algebra before.

It would be best if KSP does not model actual gravitational perturbations. The game is difficult enough for newcomers as it is. Having to babysit every craft's orbit constantly would kill a lot of the fun of a complex space program.

Most people don't care because they have no idea what difference it would make. But my intuition (which honestly could be wrong) is that n-body physics would significantly improve the gameplay.

It would add some kind of uncertainty to the game, would make things less predictable and less established forever, would induce unexpected and surprising trajectories which will never happen with conics patch.

[Mattasmack]

Hmm, that doesn't seem right to me. Langrange points are a solution to the 3-body problem, but our solar system has plenty of langrange points despite having 8 planets countless other smaller bodies. The gravity of Jupiter is going to give the Sun a different path through space than you'd expect if the only bodies in the solar system were the Sun and Earth, but the Earth lagrange points still 'work'. Mind you, I haven't done all the simulations you have, so I'm just going off intuition. Maybe I'll try running some numbers of my own later.

That is true ... my thinking was that leaving Kerbol stationary isn't just a periodic perturbation (as is Jupiter's influence on the Sun in your example) but is fundamentally nonphysical, so who knows what impact it has. But you certainly have a point.

It sounds strange for me too that so small disturbation would ruin Lagrange's point. Can you continue this simulation until you see clearly that object escapes from L4? If I look a map of troijan asteroids on Jupiter's orbit, they are spread over very large area. It is about 10 % of radius in radial direction and 40 degrees in angular. In Kerbin's scale it would mean about 1 Gm x 10 Gm kidney shaped area. If it is easy, can you also plot a diagram in rotational coordinates so than shape of orbit around L4 can be seen?

I'll try doing that when I have a chance. Running the simulation for longer is no problem, it goes very quickly. I haven't displayed anything in a rotational frame because when I looked at it I said 'bah, more trig!' and went and did something else instead. But I suppose I can just take the arctangent of the vector from the origin to the supposed L4 point to get the rotation angle; it's not really a 3D problem. I'll do that when I have a chance, hopefully today.

It would be best if KSP does not model actual gravitational perturbations. The game is difficult enough for newcomers as it is. Having to babysit every craft's orbit constantly would kill a lot of the fun of a complex space program.

That's one of the reasons I said the Newtonian mechanics should only kick in above a certain altitude from each body. The altitude can be set high enough that low-altitude orbits and other common orbits such as geosynchronous ones (at least for some bodies) will still be computed with patched conics and be perfectly repeatable.

Unfortunately I feel like no matter how technically possible this might be, the time to actually implement it is long gone... the game's become firmly set into using patched conics, and that's one hell of a hairball to untangle in the name of a bit of realism added.

Ah, too bad. Well, asmi thinks it can be implemented in a mod, so we're going to give it a shot. If it goes anywhere, that will give an idea of just how difficult it is and whether the difference in behavior is enough to matter.

[Kodiak42]

Well, I read your post, had no idea what formulas you were referring to, so I looked at your website, and I had half a clue what you are talking about (I'm currently in AP call class). While there appears to be nothing wrong with your math, there is one serious side effect that might prevent this from being added to Kerbal Space Program, it means we have to worry about orbital maintenance. As you mentioned in your website, probes would have some orbital drift, which potentially means that the fuel station I sent into low Kerbal orbit might have fallen back into the atmosphere by the time I check on it after landing on Laythe. After all, Kerbal Space program is a game, not a simulator, an approximation will work if it makes the game more fun.

[Kerbart]

Most people don't care because they have no idea what difference it would make. But my intuition (which honestly could be wrong) is that n-body physics would significantly improve the gameplay.

It would add some kind of uncertainty to the game, would make things less predictable and less established forever, would induce unexpected and surprising trajectories which will never happen with conics patch.

More realism does not automatically mean more fun. For people that claim that more realism improves the game, my answer is "then stop using time acceleration, as it's highly unrealistic. And come back to me after returning your Kerbals from a manned mission to Duna"

In all fairness, that's not what you're saying here; Newtonian physics add surprising twists that are fun! I'm not so sure though, how that will work out. My gut feeling, from having simulated various systems in the past, in that when things seem stable, they usually behave stable for a very long time. Instability, though, tends to be an exponential effect. Once things start moving away from their stable behavior it gets wild very quickly.

Back to that Duna mission that needs 10,000× time acceleration to be bearable. Will you drop out of that every 10s to return to your space station in Kerbin orbit? Because once the orbit goes, it'll go rapidly and crash into the surface before you know it. That wouldn't be so much fun!

The second problem, which compounds on the first one, is numerical stability. Patched Conics have the huge advantage that orbital positions quite literally behave like clockwork. You pretty much don't need to know what happened between t1 and t2, as your position in orbit is a function of time. If it's wednesday, this must be apoapsis, those kind of things. That makes high speed time warping not so problematic. Sure, you might misscalculate an encounter with a moon an simply ignore it at 1,000,000× game speed, but at the same time you don't have to worry about your path going rogue and diving straight into Kerbol either. Without the guiding rails of Patched Conics you'll have to calculate each position based on the previous one. Warp at high speed and you're introducing approximation errors and they compound on each other one simulation timeframe after another. It surely adds unpredictability and surprise. I'm just not sure if it's the kind of surprise you want.

[Mattasmack]

Well, I read your post, had no idea what formulas you were referring to, so I looked at your website, and I had half a clue what you are talking about (I'm currently in AP call class). While there appears to be nothing wrong with your math, there is one serious side effect that might prevent this from being added to Kerbal Space Program, it means we have to worry about orbital maintenance. As you mentioned in your website, probes would have some orbital drift, which potentially means that the fuel station I sent into low Kerbal orbit might have fallen back into the atmosphere by the time I check on it after landing on Laythe. After all, Kerbal Space program is a game, not a simulator, an approximation will work if it makes the game more fun.

That's partly why I also suggested not implementing Newtonian mechanics below a certain altitude from each body. That way, your station in low Kerbal orbit is still on a patched conic rail and will follow the exact same orbit forever or until you do something to it. (The other reasons are that the perturbations to the orbit are small enough for low orbits that there's not much point to having them, and that the low orbits require smaller time steps to compute.)

More realism does not automatically mean more fun. For people that claim that more realism improves the game, my answer is "then stop using time acceleration, as it's highly unrealistic. And come back to me after returning your Kerbals from a manned mission to Duna"

In all fairness, that's not what you're saying here; Newtonian physics add surprising twists that are fun! I'm not so sure though, how that will work out. My gut feeling, from having simulated various systems in the past, in that when things seem stable, they usually behave stable for a very long time. Instability, though, tends to be an exponential effect. Once things start moving away from their stable behavior it gets wild very quickly.

Back to that Duna mission that needs 10,000× time acceleration to be bearable. Will you drop out of that every 10s to return to your space station in Kerbin orbit? Because once the orbit goes, it'll go rapidly and crash into the surface before you know it. That wouldn't be so much fun!

See my previous paragraph. Patched conics can be retained for low (and medium) orbits without losing anything interesting, so there need not be any concern about stations in low orbit or communication satellites in Kerbin-synchonous orbit drifting away from where you left them.

The second problem, which compounds on the first one, is numerical stability. Patched Conics have the huge advantage that orbital positions quite literally behave like clockwork. You pretty much don't need to know what happened between t1 and t2, as your position in orbit is a function of time. If it's wednesday, this must be apoapsis, those kind of things. That makes high speed time warping not so problematic. Sure, you might misscalculate an encounter with a moon an simply ignore it at 1,000,000× game speed, but at the same time you don't have to worry about your path going rogue and diving straight into Kerbol either. Without the guiding rails of Patched Conics you'll have to calculate each position based on the previous one. Warp at high speed and you're introducing approximation errors and they compound on each other one simulation timeframe after another. It surely adds unpredictability and surprise. I'm just not sure if it's the kind of surprise you want.

Numerical stability is not a problem. The trajectories have to be precomputed anyway to show them in map view. Simply store the trajectory (unless the player does something to cause the vessel to accelerate), and in time warp the vessel will follow that trajectory on a rail. The numerical integration should be done with an adaptive time step, where the time step is adjusted to keep the local error below a set limit anyway. Thus the player's use of time warp in the game would impact how much CPU time has to be devoted to computing the trajectories, but should have zero effect on their accuracy.

[Hannu]

If there were true newtonian physics, for example ASAS could have automatic orbit adjustment function. It would make small adjustments and keep the station on orbit (within given tolerances). Time warps could check automatically all ships at certain intervals (depending on orbits) and make adjustments. It would not be very hard to program.

[asmi]

There is another less obvious consequence of implementing this - once we have trajectories under our control, nothing prevents us from implementing auto-stationkeeping even for inactive vessels.

[LameLefty]

If there were true newtonian physics, for example ASAS could have automatic orbit adjustment function. It would make small adjustments and keep the station on orbit (within given tolerances). Time warps could check automatically all ships at certain intervals (depending on orbits) and make adjustments. It would not be very hard to program.

ASAS is reaction-wheels. That doesn't really get you translation, it gets you attitude control. You need to be able to accelerate to maintain orbit. You might could kludge together something to pretend that the reaction wheels have some kind of ability to accelerate the entire spacecraft arbitrarily, but you're ignoring physics if you think it can do so without some kind of RCS to allow for momentum desaturation maneuvers. And why go to so much trouble to more accurately model the trajectories if you're going to have to then make the cartoony-physics of ASAS even less accurate?

There is another less obvious consequence of implementing this - once we have trajectories under our control, nothing prevents us from implementing auto-stationkeeping even for inactive vessels.

Then you'll have to keep track of fuel usage over time for all those vessels, probes, stations, etc. scattered throughout the system, and find a way to alert the player in case one of them depletes the supply, won't you?

[arq]

If something like this were implemented, I think a 'stationkeeping' button would make sense to toggle patched conics/newtonian physics. For a number of reasons, it might also make sense to only enable newtonian physics on the active vessel.

Such a system would allow an interested player to toy with manuevers in newtonian physics than then toggle to patched conics when we just want something to stay put. This also means we wouldn't need to draw arbitrary boundaries between patched conic and newtonian space.

Of course, this system could easily be exploited to perform 'cheat' maneuvers in which, by toggling physics modes, could be exploited for infinite delta-v. But that's the player's issue (and it would probably make for a fun way to burn a few afternoons). Heck, you can still infiniglide, so it's not even without precedent.

[asmi]

Then you'll have to keep track of fuel usage over time for all those vessels, probes, stations, etc. scattered throughout the system, and find a way to alert the player in case one of them depletes the supply, won't you?

And what's the problem with doing just that? The biggest challenge is to find a way to relinguish trajectory control from the core system and take charge of it, if we'll manage to do that everything else will be just a technicality.

Besides, why do you think that everything will immediately fly away just once you turn on Netwonian simulation? The only noticeable difference with existing system would be when object flies near SOI border on very high orbits. Most stations are in low-to-middle orbits, and Newtonian laws will yield trajectories very similar (if not exactly the same) to Keplerian.

Edited September 14, 2013 by asmi

[HueHue]

Quick idea to cut down on processing power. I'm not a genius when it comes to programming and backend wizardry, so forgive me if I'm making a really stupid suggestion. What if you kept the planets and non-focused ships on rails, and only ran newtonian calculations on the ship you have focused?

[asmi]

Quick idea to cut down on processing power. I'm not a genius when it comes to programming and backend wizardry, so forgive me if I'm making a really stupid suggestion. What if you kept the planets and non-focused ships on rails, and only ran newtonian calculations on the ship you have focused?

They will be on rails, just different ones

[arq]

Celestial bodies really need to be on rails. If not, sooner or later something will go horribly amiss and the Kerbol system will find itself short a few moons. Plus, the effect of ships on these bodies is completely negligible.

[asmi]

Celestial bodies really need to be on rails. If not, sooner or later something will go horribly amiss and the Kerbol system will find itself short a few moons. Plus, the effect of ships on these bodies is completely negligible.

TS has told me that he actually run full n-body simulation for the whole system, and all celestials were OK, except for Jool's moons. Looks like it was made artificially unstable. I wonder what would it take to stabilize them.

But let's not get ahead of ourselves and do vessels-only sim first and see what happens. So far results are encouraging.

[LameLefty]

And what's the problem with doing just that?

Because this whole concept is adding complexity to what is (remember) a game. If you want to play around with spacecraft trajectories using "real math", get a copy of Satellite Toolkit and do it the way ULA and SpaceX do it for real. Adding this to KSP may be an amusing intellectual enterprise but (as someone who used to do real-life spacecraft engineering for a living once upon a time), it sure doesn't sound like a game anymore. If you have more than a couple of spacecraft in play and you don't set pretty wide hysteresis bands on your control and alert systems, you'll probably find that your ships are running out of fuel way more quickly than you might think.

So, that's the problem with doing just that. But whatever floats your boat.

[asmi]

Because this whole concept is adding complexity to what is (remember) a game. If you want to play around with spacecraft trajectories using "real math", get a copy of Satellite Toolkit and do it the way ULA and SpaceX do it for real. Adding this to KSP may be an amusing intellectual enterprise but (as someone who used to do real-life spacecraft engineering for a living once upon a time), it sure doesn't sound like a game anymore. If you have more than a couple of spacecraft in play and you don't set pretty wide hysteresis bands on your control and alert systems, you'll probably find that your ships are running out of fuel way more quickly than you might think.

So, that's the problem with doing just that. But whatever floats your boat.

There is a fair amount of people who want realism - I'm among them. And please don't tell me what to do and what not to do - I'll figure it out myself.

[zzz]

Only possibility for such thing if there any is by mod. SQUAD is, well, they will not make it . So it's better to just begin to make it, as Ferram did, or just to forget. Rather then arguing and reply to the same repetive nonsence there(iunless it is the aim of it, but OP looks like serious guy whow know things).

Edited September 14, 2013 by zzz

[LameLefty]

There is a fair amount of people who want realism - I'm among them. And please don't tell me what to do and what not to do - I'll figure it out myself.

Lighten up, Francis. It's just a game. If you want realism, use STK.