[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

[nilof]

Question:

2014-02-19

I have successfully implemented the integration of proper acceleration for the active vessel when off-rails.

Further experimentation on proper acceleration has led me to the following conclusions:

• There is a bias in proper acceleration coming from some improperly initialised variable in KSP. Indeed, when loading a vessel in LKO, I observe a strong bias in proper acceleration (~20 mm s^-2). This bias is observed independently of the way proper acceleration is computed (differentiating position twice, differentiating any of the numerous velocities, etc.) and geometric accelerations have been checked from first principles (the difference in geometric acceleration depending on the point of the vessel it is computed at is negligible). The bias is reduced to below 1 mm s^-2 when warping then coming out of warp. It should be noted that the strong bias is not seen in Vessel.perturbation, but Vessel.perturbation consistently has a bias of 4 mm s^-2. As I have attempted to compute the proper acceleration in many different ways and all were consistent with each other and inconsistent with Vessel.perturbation, I assume Vessel.perturbation is mostly nonsense.
  
• Accelerations below 1 mm s^-2 are biased, unavoidable, unusable in stock, and should be clamped to 0. The acceleration from low-thrust engines will have to be fetched by hand.
  

Is this still a problem in the current implementation? Many interesting high power SEP designs have accelerations in the 0.5 mm/s^2 to 5 mm/s^2 range, so thrust at these accelerations is something that Realism Overhaul players will likely be interested in. Is the limitation only when off-rails, or does it prevent low-thrust acceleration from being implemented on-rails/during time warp?

[kikill]

hi

i get this error when i build Principia :

error C1083: Impossible d'ouvrir le fichier include : 'serialization/quantities.pb.h' : No such file or directory C:\Workspace\ksp\Principia\quantities\quantities.hpp 9 1 ksp_plugin

i followed the steps described in github https://github.com/mockingbirdnest/Principia/blob/master/documentation/Setup.md

i'm on windows 7, vs2013 express

any clue on what point did i miss ?

thank you guys

edit:

in vs2013, i can see the file in the panel "Solution Explorer", under "serialization/Header Files". But it won't open, like the 3 other .pb.h files (vs 2013 says it can't find them)

Edited February 19, 2015 by kikill

[eggrobin]

Is this still a problem in the current implementation? Many interesting high power SEP designs have accelerations in the 0.5 mm/s^2 to 5 mm/s^2 range, so thrust at these accelerations is something that Realism Overhaul players will likely be interested in. Is the limitation only when off-rails, or does it prevent low-thrust acceleration from being implemented on-rails/during time warp?

It's only a problem off-rails. I think I know how to fix the ~20 mm s^-2 acceleration due to badly initialized things. Thrust during timewarp is unrelated to this (but won't be implemented soon, things like predictions are a bigger priority).

hi

i get this error when i build Principia :

error C1083: Impossible d'ouvrir le fichier include : 'serialization/quantities.pb.h' : No such file or directory C:\Workspace\ksp\Principia\quantities\quantities.hpp 9 1 ksp_plugin

i followed the steps described in github https://github.com/mockingbirdnest/Principia/blob/master/documentation/Setup.md

i'm on windows 7, vs2013 express

any clue on what point did i miss ?

thank you guys

edit:

in vs2013, i can see the file in the panel "Solution Explorer", under "serialization/Header Files". But it won't open, like the 3 other .pb.h files (vs 2013 says it can't find them)

Your errors seem to say that the protocompiler (which creates these .pb.h and .pb.cc files) didn't run. Did you follow the setup a while ago? It changed recently, protobuf is now a dependency, and you need to build it to have the protocompiler.

Looking at the build output, rather than just the list of errors, will probably yield more information.

[kikill]

i've followed the recent setup, but indeed, protobuf wasn't built twice.

now i get Principia, thank you !

[eggrobin]

i've followed the recent setup, but indeed, protobuf wasn't built twice.

now i get Principia, thank you !

You're welcome!

I should add something to the protobuf patch someday so that it builds things in the correct order, incorect build order is why it has to be built twice...

[kikill]

houston, i got a problem

principia is built, i have two dll : ksp_plugin_adapter.dll 24ko and principia.dll 974ko.

but in vs2013 :

2 Warnings = can't find Microsoft.VisualStudio.Coverage.Analysis

1 Error = VisualStudio namespace doesn't exist

output:

========== Génération : 11 a réussi, 1 a échoué, 0 mis à jour, 0 a été ignoré ==========

(11 success, 1 fail, 0 update, 0 ignore)

and KSP don't load Principia

how can i add that namespace in vs2013 express ?

[eggrobin]

houston, i got a problem

principia is built, i have two dll : ksp_plugin_adapter.dll 24ko and principia.dll 974ko.

but in vs2013 :

2 Warnings = can't find Microsoft.VisualStudio.Coverage.Analysis

1 Error = VisualStudio namespace doesn't exist

output:

========== Génération : 11 a réussi, 1 a échoué, 0 mis à jour, 0 a été ignoré ==========

(11 success, 1 fail, 0 update, 0 ignore)

and KSP don't load Principia

how can i add that namespace in vs2013 express ?

You can't (you probably need VS2013 pro or ultimate to have it), but you don't need it, Microsoft.VisualStudio.Coverage.Analysis is used in the coverage analyser which is just an utility with which we check how well the code is covered by the unit tests.

ksp_plugin_adapter.dll and principia.dll (from Release/GameData/Principia) are the DLLs you need (you should put them, unsurprisingly, in GameData/Principia in your KSP install). You should, of course, use the 32-bit version of KSP (principia is a 32-bit native DLL).

By the way, no need to translate the build output, I'm French.

[kikill]

ok ! thank you very beaucoup for your explanations

i used to see your plugin window showing on the main menu, i thought it wasn't loaded.

i've just checked and Principia was there, so everything is fine !

merci

[dq1]

Hey I recently found this plugin and I really want to test it... I tried the compiling but somehow I failed with VS (2010), and I dont really have the nerves to try further. Is someone so kind and can upload the already compiled dll file? Why doesnt the developer itself publish a dll file, I think there are enough people who want to test that mod too...

[eggrobin]

Hey I recently found this plugin and I really want to test it... I tried the compiling but somehow I failed with VS (2010)

As stated in the first line of the instructions for building principia, you need VS 2013 (an Express will apparently do, since kikill managed to compile things with that, for 2013 you could also use Community nowadays).

and I dont really have the nerves to try further. Is someone so kind and can upload the already compiled dll file? Why doesnt the developer itself publish a dll file, I think there are enough people who want to test that mod too...

I'm pretty sure I'm animate, and that it should therefore be the developer himself.

I will not be linking binaries from the fora until I'm confident that it will be stable enough not to flood me with annoying bug reports. In addition releasing too early, with a slower than ideal version, would foster the rampant misconceptions about this problem being unsolvable.

If you really want to try it out (only on Windows with 32-bit KSP at the moment), you can follow closely the instructions I linked, and things should work (read the last few posts for some caveats).

It may (and some builds have been known to) crash intempestively, corrupt your save, summon great old ones, etc.

Edited March 14, 2015 by eggrobin

[blackrack]

So I have followed all the instructions carefully, but at the end of the compilation I have the principia.dll file but not the ksp_plugin_adapter.dll file.

Am I missing something?

[eggrobin]

So I have followed all the instructions carefully, but at the end of the compilation I have the principia.dll file but not the ksp_plugin_adapter.dll file.

Am I missing something?

Possibly, have you tried looking at the build output?

[eggrobin]

Status update:

Serialization has been implemented, and rudimentary predictions have been added.

The predictions are currently using the same integration method (McLachlan and Atela's 1992 optimal 5th order method), with the same splitting of the Hamiltonian (kinetic + potential energy), this is somewhat usable but unacceptably slow.

I am currently implementing as many symplectic integrators as I can find in order to compare them, and I will also be comparing various splittings (as as nonsymplectic methods in use for computing ephemerides). I will probably write a post about these at some point (probably an advanced one, rather than an elementary introduction, this is quite a complicated topic).

It seems that there is some interest in builds of Principia, no matter how unstable or slow they may be.

If you want to try out the current version of Principia (Bolzano) for the Windows 32-bit version of KSP, go the IRC channel linked below and ask me for a build (my nickname there is egg, or sometimes something of the form egg|<status>|egg).

CAVEAT:

The current version is

not

stable,

it can corrupt or otherwise destroy saves,

it has been known to crash, and predictions are horrendously slow.

#principia IRC channel on EsperNet.

Edited March 22, 2015 by eggrobin

[AlonzoTG]

hmmzers! I should bookmark this!

Ideas that have probably already been suggested:

OpenCL

Approximations of distant objects (At distance D, jool and it's moons becomes a single object jool + moons, obviously this would happen for pol and bop before laythe and tylo)

Even though, techincally, ksp is multi-threaded, the cpu utilization is horrible, leaving 2.8 to 6.8 unused CPUs on any reasonably game-worthy PC...

[sarbian]

[...]Approximations[...]

I don't think you know who you are talking with

OpenCL could be nice. I had some plan to test some OpenCL stuff in KSP but did not take the time yet. Main problem would be to convert the template happy Principia code

ksp is not multi-threaded. When/if KSP move to Unity 5 we will get better multi-threading.

[eggrobin]

OpenCL

I'm not familiar with this at all, there are gigantic optimizations that I know how to do before that, so I'll stick to my beloved CPU for now

Also,

Main problem would be to convert the template happy Principia code

the main reason for the switch to C++ was my template-happiness (I love strong typing).

Approximations of distant objects (At distance D, jool and it's moons becomes a single object jool + moons, obviously this would happen for pol and bop before laythe and tylo)

This sort of idea actually exists, it's the fast multipole method. In the current state of things it would only yield a relatively small speedup compared to things like picking another splitting, or choosing a better integrator (more stages, method with a processor, method optimized for near-integrable systems, etc.). It would definitely be relevant if I were to model, e.g., asteroid belts.

Regarding threading in principia, if it's possible it will be complicated, since the costly part that isn't essentially sequential is the force computation itself, but that's called often and the synchronization might be too costly. It is definitely something to consider, but not right now. Right now the way forward is being smarter with the mathematics.

I don't think you know who you are talking with

Hey, I like approximations... as long as you can show that they're best possible for a given computational cost

Edited March 23, 2015 by eggrobin

[AlonzoTG]

reading the original post for a change, some interesting things come up...

1. OpenMP -- u can tag loops and stuff for multi-processing.

2. C++AMP which might be cheap or free way to use OpenCL-like computing, I hear that is a feature in Clang.

But I definitely hear you about solving the maf first. =))))

GJ!!!!!!!!

In other news, I have some fairly perverse planetary systems in my customized install... On top of that there's StarSystems -- GALACTIC Kerbal. =P Anyway, being a moron, I'm using things like Titius-bode to make plausible planetary arrangements...

[eggrobin]

reading the original post for a change,

That post is messy, but it is a good idea to read it.

1. OpenMP -- u can tag loops and stuff for multi-processing.

For CPU threading I'd rather implement it myself using the C++11 threading libraries (we're using them already in some places) and make sure that I'm not introducing race conditions. Bear in mind that since C++11, C++ actually has portable threads.

That parallelization by pragmas also seems to violate Bob Duff's Rule of Good Taste in Pragmas.

2. C++AMP which might be cheap or free way to use OpenCL-like computing, I hear that is a feature in Clang.

It still requires to deeply change the code (and making things portable to non-AMP compilers is a little bit of work too), although some abstractions could survive, so it is nicer than rewriting everything in OpenCL.

Note that for GPGPU, similar concerns apply as for regular threading (it's not obvious that there is much to be gained, since as soon as one gets out of the force computation things get sequential again).

In addition, bear in mind that I really need to work with (at least) double-precision floating point, which seems to be a problem for GPGPU.

Edited March 24, 2015 by eggrobin

[AlonzoTG]

Had to look up Bob Duff.

Properly implemented, OpenCL pragmas should be completely transparent. A standard debugging procedure is to simply turn them off, test, then turn them back on. The program should behave exactly the same except faster. This actually works, I've even used it! =P There are some tricks in that you need to define what is thread local and what is shared but otherwise the pragmas are invisible to the program logic!

[Astrofox]

Man, I hope to see it completed...

(I really wanted Lagrangian points and Lissajous Orbits in KSP, Thanks)

Also, do you have a test version available?

[eggrobin]

Properly implemented, OpenCL pragmas should be completely transparent. A standard debugging procedure is to simply turn them off, test, then turn them back on. The program should behave exactly the same except faster.

This is, of course, false. Even ignoring the race condition here, the intended output is n copies of "Hello, world." when one has n cores in this example.

Race conditions do of course occur, and for all practical purposes this is a threading library written in pragmas (with high-level parallelization utilities on top of that). In particular, the usual issues of synchronization and locking exist (and these are not transparent at all). While this filled the lack of portable threads back in the days of C++98, such concerns are no longer relevant with C++11 and later, which has actual threading libraries that are fully part of the language.

As for GPGPU, actual language extensions exist for that (you mentioned C++AMP), and they come, of course, with restrictions, because that's how GPUs are.

You seem to be missing the main point however, which is that whatever speedup one might get from parallelization of either kind right now is dwarfed by a couple of orders of magnitude by what we're trying to get out of the maths (with things like integrating exactly the Keplerian part, or in a completely opposite direction trying multistep methods), and have to be made after a method is chosen (the computations we'll end up doing are probably very different from what we're doing now), to see if it can be made parallel in a way that improves performance (most of these calculations are very sequential) and doesn't break abstractions.

Also, do you have a test version available?

See OP or previous page.

Edited April 7, 2015 by eggrobin

[Errol]

Ok, I've got what may be a dumb question, but here goes.

So I understand that KSP normally only simulates orbits in a 1-body system, hence the "rails". This mod is called the n-body mod, which means it simulates a vessel's orbit with respect to any n number of bodies. But part of the calculation for this is very hard on the CPU and lag inducing.

So my question is, if a player wanted to have some level of multi body simulation, without the lag, would it be possible to implement this as a 2-body simulation? So then a planet and which ever moon is closet to you will both affect you, but not other planets or their moons. Or the sun. Unless you are orbiting the sun. You get the picture. Is this beyond scope/overly complex/not relevant/nonsensical? You wouldn't be able to plan manoeuvres very far in advance, just till the next flyby of a moon, until you could see what the next 2-body system will like like. I think.

Edited April 5, 2015 by Errol

[Yargnit]

Ok, I've got what may be a dumb question, but here goes.

So I understand that KSP normally only simulates orbits in a 1-body system, hence the "rails". This mod is called the n-body mod, which means it simulates a vessel's orbit with respect to any n number of bodies. But part of the calculation for this is very hard on the CPU and lag inducing.

So my question is, if a player wanted to have some level of multi body simulation, without the lag, would it be possible to implement this as a 2-body simulation? So then a planet and which ever moon is closet to you will both affect you, but not other planets or their moons. Or the sun. Unless you are orbiting the sun. You get the picture. Is this beyond scope/overly complex/not relevant/nonsensical? You wouldn't be able to plan manoeuvres very far in advance, just till the next flyby of a moon, until you could see what the next 2-body system will like like. I think.

I've had a couple discussions with Egg on this and other CPU saving tweaks in the IRC channel. Basically what he's said is the calculations for true N-body aren't really that much more taxing than 2 bodies would be (like Kerbin-mun) And two bodies really isn't enough to be that accurate under a decent range of instances. (3 bodies would be except for the Jool system) Also planetary orbits wouldn't calculate correctly if he didn't do full N-body (The planets aren't on rails).

Also, the live N-body simulations really aren't much of a strain on the CPU overall. The much larger strain at the moment is drawing future orbital predictions, which are several orders of magnitude more taxing currently. The game can run 100k time-warp no problem will full N-body at the moment, but as soon as you look at the map screen to view the predicted flight-path the speed drops by about 50%. (Or more depending on how long/accurate you set the predictions to run) This is his current area of focus, and something he said I believe can be improved on the order of 1000x it's current speed with a new calculation method (I don't know the exact details of the method changes)

Basically, doing limited body would break certain things he doesn't want to break, and in the grand scheme of things would provide extremely small performance gains compared to other areas of potential improvement.

[eggrobin]

The answer is going to be terse, since I'm on vacation and on a phone.

Ok, I've got what may be a dumb question, but here goes.

So I understand that KSP normally only simulates orbits in a 1-body system,

2. The planet and the sun, or the moon and the planet, or the ship and some massive body, that's 2. The 1-body problem is hardly interesting, the body just moves in a straight line.

hence the "rails". This mod is called the n-body mod,

No, it's called Principia. The rest of the thread title is a description.

which means it simulates a vessel's orbit with respect to any n number of bodies. But part of the calculation for this is very hard on the CPU and lag inducing.

The simulation of the trajectories (let us not call it the orbit, that is confusing), even at high timewarp, is not all that CPU-intensive. The predictions are costly at the moment, but the use of other integration methods should improve performance by several orders of magnitude.

So my question is, if a player wanted to have some level of multi body simulation, without the lag, would it be possible to implement this as a 2-body simulation?

You mean 3.

So then a planet and which ever moon is closet to you will both affect you, but not other planets or their moons. Or the sun. Unless you are orbiting the sun. You get the picture. Is this beyond scope/overly complex/not relevant/nonsensical? You wouldn't be able to plan manoeuvres very far in advance, just till the next flyby of a moon, until you could see what the next 2-body system will like like. I think.

The penultimate sentence does not parse.

So, what you are proposing is ignoring far-away bodies, which has been suggested countless times. As I said a few posts ago, I am interested in approximations (what I currently do *is* an approximation after all), but I seek the best approximation I can have for a given computational cost. FMM-like approximations may end up being useful, but for now they are dwarfed by other things.

See also the FAQ I made before going on vacation, https://github.com/mockingbirdnest/Principia/wiki/Installing%2C-reporting-bugs%2C-and-frequently-asked-questions

I see yargnit has answered this too, albeit with some mild inaccuracies, see also that.

Edited April 7, 2015 by eggrobin
they are mild

[eggrobin]

Status update:

The new version, Borel, is out (you can get it on IRC, as previously; the same caveats apply).

Rough changelog:

• ported to 1.0.x (that only took a couple of lines);
  
• custom navball settings, so that the navball can be fixed in the reference frame in which the trajectory is plotted; the IVA navball is unaffected;
  
• when using the custom navball, the prograde/retrograde vectors are now in the correct reference frame, consistent with what is shown is map view; the rest of the Frenet trihedron (the radial and normal vectors) are unaffected at the moment and will be fixed in another version;
  
• fixed a few bugs (the tetrydsbug, the melonbug, the thutmosebug);
  
• less memory-hungry;
  
• added a setting to clip histories;
  
• added a toolbar button to show/hide the UI;
  
• the UI now acknowledges the F2 key;
  
• other things that I forgot.
  

Moreover, Norgg and armed_troop have made good progress on Linux 64-bit and Macintosh 32-bit builds respectively, so if you're on these platforms you can go on IRC and ask for a build or for build instructions.

With Windows 32-bit, Linux 64-bit and Macintosh 32-bit, we should be covering most users (I don't think it's worth doing a Linux 32-bit build).

Edited May 7, 2015 by eggrobin