[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

[eggrobin]

I must say I think you're overdoing the performance thing. Using an entirely different, even non-CLI language with platform-specific binaries, with all the trouble of interfacing it correctly and testing the release on every supported platform for every release, is a huge sacrifice just for 30%... I don't like C# either, and write all my performance-critical code in c++1y, but for KSP modding I'd just stick to C#...

As explained earlier, the main reason for using C++ is not performance but language features (I want strongly-typed quantities and reference frames). It greatly helps with testing, since Google's glog, gtest and gmock libraries can be used, as well as benchmarking (using google/benchmark).

Performance is a critical concern here, and if I were to use CLR, I would need to write unsafe C# or C++98/CLI (75% speedup in my benchmarks). I'd also like to avoid doing calculations in both languages (especially since unchecked quantities and reference frames get messy in C#), so the idea is to do as much as possible in C++.

Writing everything in C#, and then, after everything is stable and tested, putting a few performance-critical loops (< 100 lines of code) into a native dll, with a fallback to the original C# code if the native dll fails/is not available would have seemed like a far more reasonable approach to me.

This was my original intent (first with C#, then with C++/CLI), but I drifted away from it for the aforementioned reasons. Having to reimplement things in both C# and C++ would be a right mess, and I would not be able to have decent abstractions with thunks so far down.

Portability should not be a significant concern here (beyond making a couple of builds), except perhaps when it comes to multithreading. It's mostly a question of handling 64 vs. 32 bits, and I get significant performance and readability improvements.

Moreover, the quantities, geometry, integrators and physics library can be useful on their own, whereas they would be messy (quantities could not exist, and geometry would be next to useless, therefore integrators and physics could not be strongly typed) and underperformed in C#.

How come your figures for '57 varieties of UNIX'? As far as I see it, it comes down to win32, win64, osx (does 32 even exist?), linux32 (barely anybody uses that anymore), linux64. I _think_ linux binaries even work on most BSDs these days.

http://en.wikipedia.org/wiki/Heinz_57,

.

Yes, the number is smaller, but I'm not familiar with compatibility details between unix binaries.

What about the GNU standard library/compiler? It has been ported to Windows in the form of mingw32/mingw64, works pretty well, and _should_ be 1:1 interchangable with LLVM (just replace 'g++' with 'clang++' in the Makefile). In my experience, gcc binaries even are a little bit faster than clang's (and a lot faster than Microsoft's).

GCC tends to have long-lasting bugs regarding standard compliance (It's not just a C++ thing. Nota bene, I'm not talking about extensions, I'm talking about bugs in the implementation of the standard). MSVC has the same problem (it's rather worse) of course.

GCC is also notorious for its sybilline error messages (it's even worse than MSVC) when templates are involved.

Certainly for Macintosh, LLVM is the way to go. In term of convenience of development, having a standard-compliant compiler that gives meaningful error messages is nice.

Since we are following the Google C++ styleguide and Google is developing clang-based utilities for that (include-what-you-use, clang-tidy), it makes sense to head towards clang.

(peeks at the github) wow, that's a lot of commits; congratulations. You really _are_ putting a _lot_ of effort into this... (bows in awe)

Thanks! Bear in mind though that I also tend to commit often and make tiny commits

Something that's not visible in the Principia repository is the google/benchmark port to Windows, which was done by pleroy.

Edited June 27, 2014 by eggrobin

[rhoark]

I was interested in using F# for my project, as it has a well regarded type system for physical units. The free version is apparently only for web apps somehow. I decided to muddle through with C# rather than commit an open-ended amount of time to figuring out how to hook F# to KSP.

[eggrobin]

I was interested in using F# for my project, as it has a well regarded type system for physical units. The free version is apparently only for web apps somehow. I decided to muddle through with C# rather than commit an open-ended amount of time to figuring out how to hook F# to KSP.

It's fairly trivial to make F# work with KSP (VB is however not an option because neither Unity nor KSP are CLS-compliant).

If I recall correctly F# supports units, rather than physical quantities per se (with our quantities library, principia::si::Metre and principia::uk::admiralty::Fathom have the same type, principia::quantities::Length).

EDIT:

Here's an F# plugin. You need to include FSharp.Core.dll with your plugin (part of the F# Redistributable Package) for it to work.

namespace FSharp
open UnityEngine
[<KSPAddon(KSPAddon.Startup.MainMenu, false)>]
type HelloWorld() = class
    inherit MonoBehaviour()
    member this.OnGUI() =
      if HighLogic.LoadedScene.Equals GameScenes.MAINMENU then
        GUI.Button(Rect(100.0f, 80.0f, 120.0f, 30.0f),
                   "Hello from F#!") |> ignore
    end

Edited June 27, 2014 by eggrobin
and here's how.

[eggrobin]

(Emphasis mine)

You actually want to do ~116 builds? I mean, automation helps, but the sheer amount of binaries would be...impressive. I use manjaro and personally would be okay with building myself from a Makefile (which would propably be the same at least for everyone using the gcc toolset).

I'll have to work with people who actually have the various unixes to test these builds (and maybe build them). 57 is made up though, see post #276.

[Garek]

Another thing which came to my mind: what about savegame compatibility?

If one starts a savegame now, with the regular patched conics, and later, when this mod is ready installs it, what would happen to crafts already in space?

I'm especially interested in

a) craft that is meant to stay in a certain orbit over an extended period of time, e.g. stations, communictation satelites. So 'closed' orbits around a primary body, clear of any orbiting moons etc.

a savegame using RSS instead of the stock System, if that makes a difference (I'm really not a astrophysicist )

[eggrobin]

Another thing which came to my mind: what about savegame compatibility?

If one starts a savegame now, with the regular patched conics, and later, when this mod is ready installs it, what would happen to crafts already in space?

I'm especially interested in

a) craft that is meant to stay in a certain orbit over an extended period of time, e.g. stations, communictation satelites. So 'closed' orbits around a primary body, clear of any orbiting moons etc.

a savegame using RSS instead of the stock System, if that makes a difference (I'm really not a astrophysicist )

I don't know, I haven't thought about persistence yet. I'd like to persist the state of the system myself (in cartesian coordinates in the integration frame, in double-double precision) to avoid loss of precision (keeping the error from Kahan summation). If I just store the conics it depends on whether I interpret them as barycentric or primary-centric.

[Yoggy]

I'll have to work with people who actually have the various unixes to test these builds (and maybe build them). 57 is made up though, see post #276.

I use 64-bit Ubuntu 12.04 and can help with building/testing.

[Chuban]

Count me in if you need any help testing. I'm using 64-bit Ubuntu 14.04.

[eggrobin]

Status update:

I wrote the second explanatory post, on Hamiltonian mechanics (PDF).

Prerequisites are chapters 4, 8, and sections 11-4 and 11-5 of Richard Feynman's Lectures on Physics.

The next post will be on symplecticity and the leapfrog integrator.

[BlazingAngel665]

After the wonderful excursion into the realm of energy conservation to limit error accumulation in the orbit (I think I understood that) I am thoroughly impressed with you grasp of these topics, and thank you for your dedication to this project. I can't wait to to take Principia for a spin around the Kerbol system.

[db48x]

Status update:

I wrote the second explanatory post, on Hamiltonian mechanics (PDF).

Prerequisites are chapters 4, 8, and sections 11-4 and 11-5 of Richard Feynman's Lectures on Physics.

The next post will be on symplecticity and the leapfrog integrator.

A good read. You remind me that I need to get back in to Structure and Interpretation of Classical Mechanics; I put it down because I really needed to set up the software environment and play with it.

[Fred4106]

I noticed the last post was 24 days ago and the last commit was 20 days ago. Is this still an active project?

[eggrobin]

I noticed the last post was 24 days ago and the last commit was 20 days ago. Is this still an active project?

Absolutely, I discussed some changes to NBodySystem and Body, and a new class, Trajectory, in order to have the requisite abstractions to keep several alternative trajectories (predicted, actual, manoeuvre nodes, etc.) with pleroy last weekend. Actual coding on my part has halted due to exams, and will resume in September. pleroy might find some time to implement these API changes, which I could then review.

[thorfinn]

You understand that there are George R.R. Martin levels of anticipation around here for this.

:D

[CaptainKipard]

The Krakens are coming.

Anyway. More of that maths stuff and things.

[Fred4106]

Absolutely, I discussed some changes to NBodySystem and Body, and a new class, Trajectory, in order to have the requisite abstractions to keep several alternative trajectories (predicted, actual, manoeuvre nodes, etc.) with pleroy last weekend. Actual coding on my part has halted due to exams, and will resume in September. pleroy might find some time to implement these API changes, which I could then review.

Is there a guide/readme out there to get everything to build on windows (8.1). I have a pretty solid math and programming background and I would like to help out if I could. I spent about an hour trying to set everything up, but I did not get very far.

[Mr Shifty]

You understand that there are George R.R. Martin levels of anticipation around here for this.

:D

I think this potential mod is more interesting for being able to draw trajectories in the rotating reference frame of particular bodies than it is for being able to implement n-body physics. Once n-body is working, everyone will jump on board for 2 days, figure out that the lack of station keeping capability makes most of the L-point rendezvous useless and that there's really nothing there except space, and the hullabaloo will die out. Orbiter's had n-body physics (and non-spherical gravity and exosphere drag and gravity gradient torque and solar radiation pressure and etc etc) for ages and no one goes to the L-points there. I'd be way more excited if someone was working on axial tilt.

[thorfinn]

figure out that the lack of station keeping capability makes most of the L-point rendezvous useless

Well, he wants to give us a station keeping capability (There has been some discussion of different algorithms for loosely coupled and tightly coupled orbits, see posts around here)

Actually the part that interests me most is also not the n-body, but the forces integration in timewarp: which means realistic ion/plasma engines with operation times of months, realistic NTR maneuvers which don't keep you in front of the screen for half an hour, and with the help of Ferram also almost-real time aerobrake calculations, impact point calculation in atmosphere, maybe even a plane autopilot could be possible...

[CaptainKipard]

Orbiter's had n-body physics (and non-spherical gravity and exosphere drag and gravity gradient torque and solar radiation pressure and etc etc) for ages and no one goes to the L-points there.

Aren't L points crucial for continuous system-wide comm coverage? This could be fun for Remote Tech 2 users.

[Mr Shifty]

Well, he wants to give us a station keeping capability (There has been some discussion of different algorithms for loosely coupled and tightly coupled orbits, see posts around here)

Actually the part that interests me most is also not the n-body, but the forces integration in timewarp: which means realistic ion/plasma engines with operation times of months, realistic NTR maneuvers which don't keep you in front of the screen for half an hour, and with the help of Ferram also almost-real time aerobrake calculations, impact point calculation in atmosphere, maybe even a plane autopilot could be possible...

OK, that actually does sound quite interesting. I've thought this project looked cool for quite awhile because the trajectories it can draw, but the continuous forces integration makes it very exciting. (But I couldn't care less about n-body physics or L-points.)

Aren't L points crucial for continuous system-wide comm coverage? This could be fun for Remote Tech 2 users.

In real life, there are 3 scientific probes orbiting at ESL1 and 1 at ESL2. Those are the only probes currently orbiting around any L-point. None of them are communications satellites.

[CaptainKipard]

In real life...

What are you talking about?

Because I'm talking about system-wide communications in Kerbal Space Program, i.e. from planet to planet. You can use L points 4 an 5 to relay signals between opposite sides of the sun. Actually not as crucial as I thought.

[AndreyATGB]

Is there a guide/readme out there to get everything to build on windows (8.1). I have a pretty solid math and programming background and I would like to help out if I could. I spent about an hour trying to set everything up, but I did not get very far.

Do this first.

Then, download the repo and open the .sln file. You're gonna need to right click on references and add mono/unity-engine to integrators, Principia and Newtonian physics. You can then build-> run solution. It will output dll's in the respective folders of the things you compiled, but I think all 3 necessary are in Principia.

[eggrobin]

Is there a guide/readme out there to get everything to build on windows (8.1). I have a pretty solid math and programming background and I would like to help out if I could. I spent about an hour trying to set everything up, but I did not get very far.

Do this first.

Then, download the repo and open the .sln file. You're gonna need to right click on references and add mono/unity-engine to integrators, Principia and Newtonian physics. You can then build-> run solution. It will output dll's in the respective folders of the things you compiled, but I think all 3 necessary are in Principia.

This won't build any of the C++ (which consists in tests and benchmarks only, the plugin is not done yet), only the C# prototype (which is obsolete).

You can try these convoluted instructions (I want to put more of that into the patch file so that it's not 24 steps long, but that's not a very high priority). They work on Visual Studio 2013 Ultimate, perhaps they will work with Express too. You need 2013, since you need C++11 support.

Edited July 30, 2014 by eggrobin

[Mr Shifty]

What are you talking about?

Because I'm talking about system-wide communications in Kerbal Space Program, i.e. from planet to planet. You can use L points 4 an 5 to relay signals between opposite sides of the sun. Actually not as crucial as I thought.

My point was that L-points are not very useful for communications satellites, which explains why we don't now have and never have had any communications satellite at real-life Lagrange points. Think of this: imagine you could put comms satellites in a stable orbit at the Kerbin-Mun Trojan points. These points lie nearly on the Mun's orbit, but 60° ahead of or behind the Mun. So, even with satellites at both points, there would still be a 60° region opposite Kerbin that is invisible to the satellites. The current RT solution of putting satellites on the Mun's orbit, but just outside its SOI works better because it covers more of the Mun's surface.

Lagrange points are only relevant for a particular two body system and only stationary within the rotating reference frame of that system. A Jool-Sun L4 point, for instance, would rotate around the Sun (or rather around the Jool-Sun barycenter) with Jool. It would not be stationary with respect to any of the other planets, so you couldn't use it as a reliable relay. RT2 has a couple of late-tech dishes that can reach from one side of Eeloo's orbit to the other, so nothing inside the kerbal solar system is out of their range.

Edited July 30, 2014 by Mr Shifty

[Fred4106]

This won't build any of the C++ (which consists in tests and benchmarks only, the plugin is not done yet), only the C# prototype (which is obsolete).

You can try these convoluted instructions (I want to put more of that into the patch file so that it's not 24 steps long, but that's not a very high priority). They work on Visual Studio 2013 Ultimate, perhaps they will work with Express too. You need 2013, since you need C++11 support.

I might not know enough about math to help with the actual project, but Ill work on the patch file when I get home tonight.