[WIP][1.8.1, 1.9.1, 1.10.1, 1.11.0–2, 1.12.2–5] Principia—version ‎‎Kronecker, released 2024-11-01—n-Body and Extended Body Gravitation

[AndreyATGB]

I really, really look forward to this mod...

Granted I can barely do the math for KSP as is, but it is fun to make it hyper-realistic and watch your own spectacular failures, lol.

Will this work with RSS if/when complete? Or would that break the implementation of either this or RSS?

It works fine with RSS, the issue is that the simulations slow down with increasing time warp. In fact it works better with RSS since the real solar system is actually stable unlike Kerbol's.

[Semmel]

When this mod gets live, there are some problems with gameplay that need solving. Assuming of course you dont want to babysit every single probe.

* Since orbits are a lot more unstable, it will be hard to get probes into stable 2-body situations. Like for example L1, L2 and L3 points are instable and require active correction.

* Geo/Kerbo-synchronous orbits will decay over time, there needs to be active control to keep them stable.

These points are especially relevant for Remote Tech since you need a fleet of communication satellites.

[eggrobin]

When this mod gets live, there are some problems with gameplay that need solving. Assuming of course you dont want to babysit every single probe.

* Since orbits are a lot more unstable, it will be hard to get probes into stable 2-body situations. Like for example L1, L2 and L3 points are instable and require active correction.

* Geo/Kerbo-synchronous orbits will decay over time, there needs to be active control to keep them stable.

These points are especially relevant for Remote Tech since you need a fleet of communication satellites.

See the OP,

Stationkeeping, to deal with orbital decay and unstable weakly bound orbits;

[rdwulfe]

I'm delighted to see this still being worked on. I look forward to the future of this mod. Personally, I'd be utterly happy with a partial N-body simulaton, where only the craft has to deal with multiple-body calculations, and the planets and moons are considered "good enough". <shrug> Doing the whole thing? NEAT!... If my computer doesn't melt.

[eggrobin]

I'm delighted to see this still being worked on. I look forward to the future of this mod. Personally, I'd be utterly happy with a partial N-body simulaton, where only the craft has to deal with multiple-body calculations, and the planets and moons are considered "good enough". <shrug> Doing the whole thing? NEAT!... If my computer doesn't melt.

As discussed several times in the thread (although apparently not in the OP; I need to restructure that OP a bit anyway, the pile of status updates is getting unwieldy), the movement of the planets *has* to be redone in order for physics not to break down: if bodies orbit centres of other bodies, rather the barycentre, you're going to have a hard time finding L4 and L5 (just compute the potential in the rotating frame for that, its gradient only vanishes in 3 points rather than 5). The additional cost is not very large: B(B-1)/2 force computations, vs. the BV required to integrate the vessels; remember that the number of bodies is small and fixed.

[ghimb2000]

Is it wishful thinking to think this will be eventually implemented into stock KSP? *crosses fingers*

[fibonatic]

Is it wishful thinking to think this will be eventually implemented into stock KSP? *crosses fingers*

I do not think so, since having to deal with orbits which might not be stable over a long period can be annoying in terms of gameplay, because you can only control one craft at the time. And as simulations have shown, not all moons of Jool are stable. I am unsure if there might be a possibility for any of the unstable moons to collide with any other body (or probably pass through each other) and I am unsure how the physics engine would handle such an event. So at least the N-body gravitation implementation would significantly affect the gameplay. The improved integrator on the other hand would nice to have in stock instead of the default unity one, since it does not really affect gameplay besides making the physics calculation more accurate.

[NeilC]

First off, eggrobin this is a fantastic thread! Good work! I really appreciate the effort you put into your explanation documents and your extensive references. I'm one of those engineers with funny conventions so I can't pretend to follow your Grassmann algebra, but I know enough about RK solvers to follow most of the papers cited in broad strokes. This thread taught me a lot. Kudos, I'm looking forward to seeing this project develop.

I do not think so, since having to deal with orbits which might not be stable over a long period can be annoying in terms of gameplay, because you can only control one craft at the time. And as simulations have shown, not all moons of Jool are stable.

I'm pretty sure this is an issue with the setup of orbital parameters in KSP, not a fundamental issue. If you changed the parameters a bit, it's definitely possible to set up a Jool system that would be stable for hundreds of years. Jupiter's moons really are in a 1:2:4 resonance, and I think the universe's symplectic n-body integrator is almost as accurate as eggrobin's.

I think things only go haywire in the Jool nbody video because the orbital parameters used are the ones in stock KSP that produce a "resonance" in the 2-body solution - that is, they are set up to have 1:2:4 orbital periods around jool using the 2-body assumption, without taking the interactions between moons into account. Of course this would be unstable when you suddenly add in the interactions! They need initial orbits that give them a 1:2:4 period AFTER taking n-body perturbations into account. (As an aside, it would be interesting to see how far off the initial conditions could be and still have the moons correct themselves. The resonance must be a low-energy state compared to the surrounding parameter space, otherwise Jupiter's system would never have settled there. That implies there's a basin in which the initial conditions can lie, and still evolve to the same final orbits)

So at least the N-body gravitation implementation would significantly affect the gameplay. The improved integrator on the other hand would nice to have in stock instead of the default unity one, since it does not really affect gameplay besides making the physics calculation more accurate.

Though I don't think N-body gravity would significantly affect any planetary orbits in terms of gameplay, I do worry that making low orbits unstable would make the game less fun. I know stationkeeping is a planned feature, but that's a whole layer of complicated code that needs to be written to make Principia playable without untenable levels of orbit management.

Trouble is, the N-body solver is kinda an all-or-nothing deal:

As discussed several times in the thread, the movement of the planets *has* to be redone in order for physics not to break down: if bodies orbit centres of other bodies, rather the barycentre, you're going to have a hard time finding L4 and L5 <...>

Correct me if I'm wrong, but it's not just Lagrange points that would break: you can't have some stuff on Keplerian rails and other stuff following a path defined by conservation of energy: the Kepler bodies would break that conservation and things would go screwy. The whole Principia solver is based on symplecticity. Making it 2-body isn't "set n=2", it's "ground-up rewrite".

Eggrobin, do you see any value in using the libraries you've developed to implement an improved Kepler integrator with the same interfaces as Principia? Is that a lot of work? I'm just thinking it might help you (somewhat) as you develop the annoying and untestable part of your code that interacts with the KSP API, to have a built-in test case: you'd be solving the same case as KSP, so could check your answers against it each frame. Should be within a small tolerance, otherwise something screwed up (probably a reference frame transform which I gather are kinda obtuse in KSP).

Also, you would then have a much-improved integrator that doesn't affect gameplay at all, which would allow a playable Principia(Lite) before you've had a chance to develop stationkeeping. And would be much more likely to get integrated into stock KSP, which would be super cool.

One last thing: I just finished reading The Martian, and I really really want to play this plugin so I can build an Ion-engine Mars transfer vehicle like Hermes. SOOOOOOO cool!

[eggrobin]

First off, eggrobin this is a fantastic thread! Good work! I really appreciate the effort you put into your explanation documents and your extensive references. I'm one of those engineers with funny conventions so I can't pretend to follow your Grassmann algebra, but I know enough about RK solvers to follow most of the papers cited in broad strokes. This thread taught me a lot. Kudos, I'm looking forward to seeing this project develop.

Thanks!

Regarding Grassmann algebras, you may be more familiar with the terminology "pseudovector" or "axial vector" for bivector, "pseudoscalar" for trivector. See also [Tao 2012] in the bibliography.

Jool, Jool, Jool...

yeah, with a proper interpretation of the orbital parameters (pre-Pol, but this shouldn't matter), Scott showed the system was stable, see the OP (this question seems to come up fairly often, I need to make the OP more readable at some point).

Though I don't think N-body gravity would significantly affect any planetary orbits in terms of gameplay, I do worry that making low orbits unstable would make the game less fun. I know stationkeeping is a planned feature, but that's a whole layer of complicated code that needs to be written to make Principia playable without untenable levels of orbit management.

unstable low orbits are in the far future (I need to discuss that with ferram4, it's aerodynamics), I guess that update will have to come with basic stationkeeping.

Trouble is, the N-body solver is kinda an all-or-nothing deal:

Correct me if I'm wrong, but it's not just Lagrange points that would break: you can't have some stuff on Keplerian rails and other stuff following a path defined by conservation of energy: the Kepler bodies would break that conservation and things would go screwy. The whole Principia solver is based on symplecticity. Making it 2-body isn't "set n=2", it's "ground-up rewrite".

Yes, see also below, it's a completely different kind of problem. I took Lagrange points as an example since it's fairly easy to work out analytically (and people seem to get excited about those).

Eggrobin, do you see any value in using the libraries you've developed to implement an improved Kepler integrator with the same interfaces as Principia?

The whole point of using the 2-body problem is that you don't integrate it, you solve it exactly (well, you have to solve Kepler's equation, but no numerical integration is involved). This is what KSP does. One could make bodies orbit barycentres rather than centres, by essentially rewriting KSP's Orbit class, but I'm not interested in doing that (it's a completely different exercise).

I'm just thinking it might help you (somewhat) as you develop the annoying and untestable part of your code that interacts with the KSP API, to have a built-in test case: you'd be solving the same case as KSP, so could check your answers against it each frame. Should be within a small tolerance, otherwise something screwed up (probably a reference frame transform which I gather are kinda obtuse in KSP).

This is why I have strongly-typed reference frames. Obtuse is probably an understatement.

Also, you would then have a much-improved integrator that doesn't affect gameplay at all, which would allow a playable Principia(Lite) before you've had a chance to develop stationkeeping.

As discussed above, it would not be an integrator, and stationkeeping will not be necessary for relatively low orbits (or anything where one massive body dominates) for a while.

I wonder what the point of a mod that doesn't affect gameplay at all actually is ...

And would be much more likely to get integrated into stock KSP, which would be super cool.

A couple of things should be said here:

- This mod is almost entirely in C++ (not C++/CLI, the interfacing is done via P/Invoke). KSP is not, virtually no other mod is. I'd say that makes this mod one of the hardest to integrate in their codebase.

- I have no reason to want this to become stock: The best I could hope for is that I could somehow disable the stock implementation and replace it with my own to keep modding. See ferram4's concerns about improved aerodynamics in stock.

Note:

I will not be actively developing this mod until mid-February because of exams (the astute reader may have noticed that this happens every 6 months).

Edited January 3, 2015 by eggrobin

[NeilC]

Thanks!

Regarding Grassmann algebras, you may be more familiar with the terminology "pseudovector" or "axial vector" for bivector, "pseudoscalar" for trivector. See also [Tao 2012] in the bibliography.

Heh, nope I'm afraid I don't recognize any of those terms. Closest I could come was "Wedge product... that must be kind of like a general cross product?" I'm afraid my brain gets firmly locked into 3D geometry, as a mechanical engineer I've never studied these concepts in a general way - 4D applications don't come up very often in our courses. Thanks for the paper suggestion though, I'll check it out.

unstable low orbits are in the far future (I need to discuss that with ferram4, it's aerodynamics), I guess that update will have to come with basic stationkeeping. <...> stationkeeping will not be necessary for relatively low orbits (or anything where one massive body dominates) for a while.

Neat, I was afraid perturbations from the Mun would be significant enough to lower a ~100km periapsis below 70km within, say, a round-trip trip to Duna. Glad to hear it isn't so!

The whole point of using the 2-body problem is that you don't integrate it, you solve it exactly (well, you have to solve Kepler's equation, but no numerical integration is involved). This is what KSP does. <...> I wonder what the point of a mod that doesn't affect gameplay at all actually is ...

Right, of course, the "conics" part of patched conics - sorry, momentary brain fart. I guess what I was thinking of improving was the "patching" part of patched conics where KSP is just terrible at predicting intercepts, periapsis after frame change, etc. That would be the gameplay value: say, being able to reliably predict a mid-course correction burn to set up a Duna aerobrake before entering its SoI. But you're right: that's just numerics, not integration. No overlap with your project, poor suggestion...

This is why I have strongly-typed reference frames. Obtuse is probably an understatement.

Wow, that is a whole mess of crazy. Left-handed co-ordinate frames seem to abound in computer graphics applications, but I'll never understand why...

A couple of things should be said here:

- This mod is almost entirely in C++ (not C++/CLI, the interfacing is done via P/Invoke). KSP is not, virtually no other mod is. I'd say that makes this mod one of the hardest to integrate in their codebase.

- I have no reason to want this to become stock: The best I could hope for is that I could somehow disable the stock implementation and replace it with my own to keep modding. See ferram4's concerns about improved aerodynamics in stock.

For sure, totally fair! But since this is the first thread I've seen approaching an n-body solver for KSP with anywhere near this rigor, I have plenty of reason to want it to become stock! Didn't mean to assume anything about your motivations, just thought I'd ask the question. Thanks for answering.

Note:

I will not be actively developing this mod until mid-February because of exams (the astute reader may have noticed that this happens every 6 months).

Good luck on your exams! May the coffee and skittles be with you.

[eggrobin]

Heh, nope I'm afraid I don't recognize any of those terms. Closest I could come was "Wedge product... that must be kind of like a general cross product?"

It's either the cross product, or the dot product, depending what you put in it: vector wedge vector is bivector (cross on the coordinates), bivector wedge vector is trivector (dot). It's really an algebraic wrapper on operations you know, that keeps track of what kind of object you have (i.e. how they transform under coordinate changes). Keeping track of that also prevents you from doing meaningless operations (e.g., adding a pseudovector to a vector), much like dimensional analysis does.

I'm afraid my brain gets firmly locked into 3D geometry, as a mechanical engineer I've never studied these concepts in a general way - 4D applications don't come up very often in our courses.

But I am talking about 3D geometry here. See this wikipedia article for a physical example, and this one for the formalism.

Wow, that is a whole mess of crazy. Left-handed co-ordinate frames seem to abound in computer graphics applications, but I'll never understand why...

Using left-handed reference frames is not an issue per se, the laws of physics are the same through the looking-glass (we're not dealing with weak interaction here), but using both handednesses is mad (and can be no good reason to do so, since the laws of physics work are same through the looking-glass). In order to safely deal with both handednesses, you need to distinguish vectors and bivectors, since they transform differently.

[NeilC]

But I am talking about 3D geometry here. See this wikipedia article for a physical example, and this one for the formalism.

Thanks so much, that nailed it for me. I get why that would be really important for co-ordinate transforms.

We engineers get SUPER lazy with the things you call "Pseudovectors". Gear trains with parallel axes don't really lend themselves to learning about co-ordinate transforms... I'd just represent angular momentum as a scalar in all my calculations, and then do a manual balance pass at the end if anything was spinning in a different direction. I'm rarely asked to design a gear train as seen through a mirror.

That lazy approach leads to passing our exams with study bandwidth left over for metallurgy and thermodynamics and such, but we never learn those formalisms. Cool stuff!

[SAI Peregrinus]

You might find this paper interesting. It's a very cursory historical overview of using geometric algebra (the algebra of the wedge product) in various applications. This comment, and indeed the entire discussion on that article at HN is interesting.

[Sput42]

Pretty cool stuff. However, one thing popped into my mind - as you're using native C++ code for much of it, did you consider portability? Will your mod run in Linux versions of KSP?

[Ruedii]

Pretty cool stuff. However, one thing popped into my mind - as you're using native C++ code for much of it, did you consider portability? Will your mod run in Linux versions of KSP?

Mono can compile C++ to the MonoVM. However, I hope he is doing this.

[eggrobin]

Pretty cool stuff. However, one thing popped into my mind - as you're using native C++ code for much of it, did you consider portability? Will your mod run in Linux versions of KSP?

This means there will be separate x86 and AMD64 builds for each target operating system (Microsoft Windows and 57 varieties of Unix), possibly more if we decide to do specific optimisations for Intel chips (though ICC is not cheap).

The dependencies are open-source Google libraries, which are portable, and we try to make our code portable too.

It's been a ridiculously long time since I've made one of these, and I should have made one in December when I got intrinsic acceleration working...

Retroactive Status Update:

antedated 2014-12-13

Support for intrinsic acceleration has been added. Refactoring will be needed, but it works, as demonstrated by the following plane change manœuvre:

Status Update:

The refactoring of the physics bubble has been done (and some tests have been added), as well as some cleanup in the C# adapter (including some performance improvements, a lot of the performance issues occur on the C# side since the implementation is a bit careless there).

More refactoring occurred (use of a not_null template for non-null pointers).

The next step on the path towards playability is persistence: the state of the plugin must be persisted so that we remember the states of the planets, the histories of the vessel trajectories, etc. (currently loading a save or reverting will result in either a crash or a loss of consistency due to the planets having moved around).

Persistence of our types will be achieved using protocol buffers, stored in config nodes: we don't want to use KSP's config format directly, since we have lots of highly structured data and operate far from KSP's API it would be inefficient and clumsy.

We'll probably also use protobufs for caching when implementing trajectory predictions later on.

Some work has already been done in that direction.

Here are some more screenshots, showing a flight from Kerbin to the Kerbin-Mun L4 Lagrange point (the reference frame for each screenshot is indicated in the "Traces of various description" window).

Javascript is disabled. View full album

Edited January 22, 2015 by eggrobin

[shmameron]

This is looking really good so far! Beyond getting persistence down, what are the major steps towards completion?

[Whirligig Girl]

I downloaded what there is on the github. But it's not a plugin in any usable form. I should have known. I would probably have noticed if this was released.

[NeilC]

Thanks for the update and the screenshots, eggrobin!

I'm having trouble visualizing what you call the barycentric rotating reference frame. Your pics 6 and 7 show the same trajectory in the usual Kerbin-centric and the rotating-barycentric, correct?

I understand your co-ordinate system has the origin at the barycentre, and if I'm parsing your description correctly its axes are always aligned with the kerbin-mun connection line, but I'm having trouble figuring out why that would generate the track shown.

I can see the trip out to the Mun being tough to visualize since the relative velocity in that frame would be changing throughout the track, but I must be missing something fundamental because I really lose comprehension when the orbits about the L-point come into play. Once you're near L4, shouldn't your position be (nearly) fixed in the barycentric frame? Isn't L4 fixed in a frame that's centered on the barycenter and rotating at the same rate as the Mun? Those tracks look like the craft is wandering within ~1/16th of an orbit of L4, which seems huge. What am I missing?

Is there any insight that comes from looking at the trajectory in this frame? If so, do you think it would help to illustrate the motion of the co-ordinate system in the track plot somehow?

I hope your exams went well!

- - - Updated - - -

You might find this paper interesting. It's a very cursory historical overview of using geometric algebra (the algebra of the wedge product) in various applications. This comment, and indeed the entire discussion on that article at HN is interesting.

Thanks so much for this link, very cool read. The concept of a universal, geometric math that's taught early and often really appeals to me. Whenever I try to wrap my head around quantum mechanics I just get totally bogged down in obscure, specific notations and math that doesn't seem to have any physical interpretation. Made me drop out of the physics minor in undergrad and choose robotics instead. At least I could visualize the quaternions in forward and inverse kinematics!

[eggrobin]

Thanks for the update and the screenshots, eggrobin!

I'm having trouble visualizing what you call the barycentric rotating reference frame. Your pics 6 and 7 show the same trajectory in the usual Kerbin-centric and the rotating-barycentric, correct?

Yes (4 seconds apart, as shown by the MET).

I understand your co-ordinate system has the origin at the barycentre, and if I'm parsing your description correctly its axes are always aligned with the kerbin-mun connection line,

That is correct (although this only define one axis, so the other two are defined by making the orbit plane invariant in addition to the line through the bodies).

but I'm having trouble figuring out why that would generate the track shown.

Consider that this is the frame in which a free-return trajectory would look like a figure-eight.

Once you're near L4, shouldn't your position be (nearly) fixed in the barycentric frame? Isn't L4 fixed in a frame that's centered on the barycenter and rotating at the same rate as the Mun? Those tracks look like the craft is wandering within ~1/16th of an orbit of L4, which seems huge. What am I missing?

I I'm orbiting L4 from quite far away. Had I manœuvred more precisely, I could have come closer to L4 with a smaller velocity in the rotating frame, resulting in a tighter orbit.

Is there any insight that comes from looking at the trajectory in this frame?

My trajectory stays somewhat close to L4, rather than drifting away.

If so, do you think it would help to illustrate the motion of the co-ordinate system in the track plot somehow?

It might help to show the gravitational + centrifugal potential.

[thorfinn]

Very interesting man, I hope we will see the results soon

I have been thinking that not only Kerbin-Mun L4 and L5 should be much stabler than the real ones, but on Duna it's likely that no synchronous orbit is stable

Would any GEO satellite eventually fall into either L4 or L5? (It'll be interesting to try)

I remember you were thinking about various visualizations of gravitational potential, did you experiment with that?

[CaptainKipard]

Go math go!

[NeilC]

I I'm orbiting L4 from quite far away. Had I manœuvred more precisely, I could have come closer to L4 with a smaller velocity in the rotating frame, resulting in a tighter orbit.

<...>

My trajectory stays somewhat close to L4, rather than drifting away.

Are you making any course corrections to stay in orbit? My intuition is that if you drifted that far from the equilibrium point, you'd fall towards either Mun or Kerbin instead of continuing to orbit L4 for as long as you did.

Kerbin-Mun L4 and L5 should be much stabler than the real ones

Or maybe my intuition is just way off because everything Kerbal is much denser and closer than it is on this side of the screen. How wide and deep is the L4 potential well, anyway?

It might help to show the gravitational + centrifugal potential.

Yeah, that! This would change as the track is plotted though, right? Easy to show instantaneously, but it wouldn't help understand the overall track shape. Maybe you could allow selection of points on the track and draw phantom bodies and potential wells for the selected point? Maybe more trouble than it's worth?

[thorfinn]

Actually, after checking, I see that Ike is so huge that not even L4 and L5 are stable around Duna! (The mass ratio must be greater than 25, Ike is only 16 times lighter).

The Kerbin/Mun ratio is above 50 on the other hand. For some reason I expect the steeper gravitational gradients (compared to reality) to yield more binding potentials in the two points, but it's probably more complicated than that.

EDIT: well, according to this document (http://wmap.gsfc.nasa.gov/media/ContentMedia/lagrange.pdf) the curvature near the points depends almost only on angular velocity squared: so a more compact system like Kerbin/Mun should have steeper wells (but it's too late to think really straight I suppose)

Edited January 30, 2015 by thorfinn

[wasmic]

I have no idea what most of the stuff you're talking about here means, but I just want to say that you guys are awesome!