[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

[Peter JY]

I saw that KSP2 has added a part of N-body gravitation (Rush and Rash), in this, so is there Principia in KSP2? If have, can add the function of change the step of history path in memory（就是说能够自己来调节加载多少距离的历史路径，在游戏主界面或者在存档里能够修改这个数值都可以）?

[KSP user]

Decided to try the new Principia Fuchs to see if the bugs introduced since Frobenius version are gone. Alas, they are not really gone. All was well until I build my plane with J57 engine, and it flied almost as bad as with Frobenius. No pitch control and unrecoverable spin. Fed up with this, going back to version Frenet and won't update unless rotation control is removed from the mod. Which probably means no updates any more, ever.

EDIT: all was well? Actually not, rotation control also breaks the KCT airlaunch feature, to the point it can't be used at all. So X-planes need to be launched from the runway again, with detachable jet engines under the wings and stuff like that, to get the plane into the air and to the altitude where it should be airlaunched. Not well at all.

Edited June 15, 2020 by KSP user

[eggrobin]

1 hour ago, KSP user said:

Decided to try the new Principia Fuchs to see if the bugs introduced since Frobenius version are gone. [...] I build my plane with J57 engine, and it flied almost as bad as with Frobenius. No pitch control and unrecoverable spin.

We cannot deal with bugs that we do not know about and cannot reproduce. We only know about one remaining instance of #2519 at this time; the issue seems to have become exceptionally rare.

If you want us to investigate what happens to your plane, you may want to send it to us.

Quote

rotation control also breaks the KCT airlaunch feature

This is a known incompatibility. I believe it could be resolved on the KCT side by signalling to Principia that the craft is not ready to be managed by Principia, via the vessel situation. @siimav may have more thoughts on this.

[KSP user]

Here is a stock plane that I previously uploaded.  It flies OK in Frenet, is uncontrollable in Frobenius and just barely controllable in Fuchs.

Plane.craft

Here is how to make an unflyable plane:

- make a small and light plane

- put a short heavy engine in the back (stock Rapier or RP1 J57 work well, they weigh about 2 tons)

- give the plane standard wings arrangement with a tail (not a tailless delta)

Such planes fly well with Principia Frenet and easily perform supersonic flights up to 680m/s. But they refuse to fly since rotation control was implemented. 

I'm actually not sure if it's a bug or correct behaviour. Putting a short 2-ton weight on the rear end of a 6-ton plane doesn't sound like a good idea, the plane will have a huge moment of inertia and will be difficult to control.  But as previously noted, RP1 J57 engine is much shorter than it should be, the model looks only 2.7 meters long while in fact it's 6 meters long, so it's CoM is much farther from the plane's CoM than in reality.  And the stock Rapier is even shorter.

So what the player should do in this situation? There is no practical alternative to J57 in the game. The model is unlikely to be changed anytime soon. Stock rapier and other engines were also not designed with this issue in mind, they are now broken and unusable. I think it's a high price for observing some nice rotation effects in space, am I wrong?

 

 

[pleroy]

3 hours ago, KSP user said:

So what the player should do in this situation?

Report the bug?  I realise that you did so already back in April, but we were not aware that it was still around.  We should obviously not have this kind of non-physical behaviour, and when do we try to fix the problem in a timely manner.

3 hours ago, KSP user said:

I think it's a high price for observing some nice rotation effects in space, am I wrong?

The difficulties you are experiencing are not a physical consequence of the rotation effects, they probably stem from something that we never did right (tracking of CoM) that suddenly becomes very visible because it introduces funky rotations.  We should have both nice rotation effects and flyable planes.

Please cut us some slack.  Bugs happen, and we try really hard to find them and fix them.

Edited June 16, 2020 by pleroy

[eggrobin]

To elaborate on @pleroy’s reply, in case you are interested in the technicalities:

1 hour ago, KSP user said:

put a short heavy engine in the back (stock Rapier or RP1 J57 work well, they weigh about 2 tons)

[...]

I'm actually not sure if it's a bug or correct behaviour

It is a bug, and it is exacerbated by using these specific engines.

Quote

Putting a short 2-ton weight on the rear end of a 6-ton plane doesn't sound like a good idea, the plane will have a huge moment of inertia and will be difficult to control. 

Indeed, but that would make things laughably unflyable in stock just as much as with Principia.

Quote

RP1 J57 engine is much shorter than it should be, the model looks only 2.7 meters long while in fact it's 6 meters long

This is true of the model (note that the J57 is from AJE modified by RO, rather than being from RP-1 itself).

Quote

so it's CoM is much farther from the plane's CoM than in reality

This is not true, and this is where the bug lies: the centre of mass is offset from the model. This is what the rapier looks like on its own, with the centre of mass shown:

note that the centre of mass is quite far outside the part.

Principia has heretofore ignored that offset between the position of the part and that of its centre of mass; this went largely unnoticed before we started handling rotations, but it now becomes visible. This is tracked by issue #2560.

It looks like your plane becomes flyable once these offsets are taken into account: #2604 will fix #2560, and your plane in the process. All going well that fix should make it into the upcoming release at the end of the week.

[Delay]

10 hours ago, eggrobin said:

note that the centre of mass is quite far outside the part.

Just for the record: This was done to simulate all the usually hidden parts of the engine, i.e. turbines and what-have-you. The geometry only shows the normally exposed parts, the COM offset is supposed to take "all of the engine" into account.

[eggrobin]

3 hours ago, Delay said:

Just for the record: This was done to simulate all the usually hidden parts of the engine, i.e. turbines and what-have-you. The geometry only shows the normally exposed parts, the COM offset is supposed to take "all of the engine" into account.

Yes, it is very much a reasonable approach given the constraints of KSP.

[SynX]

KSP is based on Unity Engine. N-body gravity simulation shouldn't be too hard, as you could just add gravity as a function of mass and distance between all objects or Rigid Bodies. I believe that the sphere of influence single body gravity actually needs more coding work... you need to first judge which sphere of influence are the craft is in, and then calculate the amount of gravity acted upon you. However, that's not the case. Last time I downloaded Principia, and found out that the 600MB mod was mostly composed of codes... I don't understand that why is this such a large project, I've seen Principia videos several years ago and it's still WIP.

[hypervelocity]

1 hour ago, SynX said:

I don't understand

you're right

Edited June 20, 2020 by hypervelocity

[AloE]

18 hours ago, SynX said:

600MB mod was mostly composed of codes

I appreciated @Delay's clarification "just for the record" post above since it made clear for me a long standing question to which I had not yet dug up the answer regarding the CoM of those models.

Thus, my sharing a few thoughts & links here: @SynX...beyond the Principia concepts wiki...Principia does many very useful & important things...two of my longtime favorites being the offer of multiple reference frames & leveraging the power of a number of library tools to put celestials in an epoch with an appropriately aligned & rotated coordinate system which enables cartography & then also integrates their mutual interaction in a way that includes the use of gravity models resulting in decent precision astronomy...now Principia has made for us an orbit analysis tool & powerful physics model in timewarp...making KSP a front end for some very useful models of our 'local region of space' (especially when combined with the work of FAR & RO & OhioBob's atmospheres tools & TRAPPIST1 or RSS with some texture corrections) rather than 'only' a fun yet relatively 'haphazard toy universe' . 

I wish I had computing power & tools like this created & shared openly by thoughtful & dedicated people in such a fun package available to me when I was age 12 to 18.  I encourage, especially young students interested in computer science, mathematics, physics, astronomy, and/or astrobiology, to engage & learn & explore with these models...and to build a relationship with (& possibly even delight in) a very real process of human discovery--so effective that over millennia it has produced the collective knowledge & infrastructure/machines/processes/tools we have today--where at some point someone notices  'X thing does not work' and creative people set off to figure out why & thus make a more useful model that empowers the new observer.

Maybe, eventually, (I'll keep dreaming anyway) given all the work resulting in beautiful info about 'rotating rubble piles' like Bennu & Ryugu & Toutatis "since we know the geopotential of celestials, we could know their moment of inertia and compute their wobble" -anonymous ;-)

Edited June 20, 2020 by AloE
add links & add rotating Bennu

[eggrobin]

For the new moon (lunation number 253), the new release (Galileo) is out.

• The exceptions raised by the external API for other KSP mods now include an error message.
• Miscellaneous bugs have been fixed (most notably, the centre of mass offsets are now taken into account).

See the change log for more details.

We support two sets of versions of KSP: downloads are available for 1.9.1 & 1.8.1, and for 1.5.1, 1.6.1, 1.7.x. Make sure you download the right one (if you don't, the game will crash on load).

For the convenience of our Chinese users, the binaries can be downloaded either from Google Drive or from 腾讯微云.

This is the last release to support KSP 1.5.1, 1.6.1, and 1.7.x, as Realism Overhaul and Real Solar System now support 1.8.1.

Edited June 21, 2020 by eggrobin

[chuckstables]

Would you guys consider adding in an Ephemeris model for Real Solar System? That way we wouldn't have to simulate the full N-body dynamics of all the planets and they could just follow high fidelity trajectories that exist in a data file. There's lots of high precision Ephemeris models available for the solar system IRL for trajectory designs for missions. This could speed things up quite a bit. Just curious. Thanks!

[chuckstables]

On 6/19/2020 at 7:46 PM, SynX said:

KSP is based on Unity Engine. N-body gravity simulation shouldn't be too hard, as you could just add gravity as a function of mass and distance between all objects or Rigid Bodies. I believe that the sphere of influence single body gravity actually needs more coding work... you need to first judge which sphere of influence are the craft is in, and then calculate the amount of gravity acted upon you. However, that's not the case. Last time I downloaded Principia, and found out that the 600MB mod was mostly composed of codes... I don't understand that why is this such a large project, I've seen Principia videos several years ago and it's still WIP.

It's not really that simple. You need high fidelity symplectic integrators to get stable orbits if you are going to go the numerical route. Otherwise energy is not conserved and orbits will diverge and become horribly unstable. It's far simpler using patched conics because the orbits are known EXACTLY with mathematical functions. Once you're in a sphere of influence you use math to determine the exact shape (a conic section) of your orbit and boom; you're done. Your spacecraft is now on rails; there is no need to determine the gravitational force acting on you. There is no real numerical integration here; everything is predetermined and on rails.

If you add n-body physics your orbit is no longer known exactly. There is no closed form solution for a general n-body problem. Therefore you have to use numerical integration to approximate the 'true' orbit using a finite step size (as you can't simulate an infinite number of time-steps). Finite step sizes lead to energy not being conserved over longer time scales with most integration methods. You can get around this by using what's called a symplectic integrator, which conserves an energy-like quantity.

You also need one in this situation where you can vary the step size to account for situations where you're travelling very fast near a planet, where the step size needs to be smaller. You also need a method which is computationally efficient enough to be run in high time warp. This is difficult to do, which is why the code is probably so large. The mod dev's also needed to add accurate geopotential models for RSS, which model the real gravitational field of planets/moons using a power series with spherical harmonics. They also need to add code to efficiently evaluate the analytical derivatives of each term in the geopotential (at least I'm assuming they analytically evaluate them). This is also difficult. 

I could write a symplectic integrator in python in about 100 lines; but to get it to run in KSP let alone to run efficiently would require a lot more than that.  

Edited June 25, 2020 by chuckstables

[pleroy]

On 6/25/2020 at 10:54 PM, chuckstables said:

Would you guys consider adding in an Ephemeris model for Real Solar System? That way we wouldn't have to simulate the full N-body dynamics of all the planets and they could just follow high fidelity trajectories that exist in a data file. There's lots of high precision Ephemeris models available for the solar system IRL for trajectory designs for missions. This could speed things up quite a bit. Just curious. Thanks!

Let's ignore for a moment the inconvenience of having to special-case a solar system, of having new code paths to test, bugs that would show up only for some solar systems, etc.

The real question is: why would anyone want to trade CPU for I/O?

Computing a year of ephemeris for the real solar system takes about 10 seconds on an average computer, which means that, in the absence of vessels, we support timewarp at 3'000'000x.  A representation based on an existing ephemeris (DE431, INPOP, EPM, etc.) would take tens of megabytes per year.  That would require several seconds to load (for mysterious reasons KSP reads saves no faster than 5 MB/s even from SSD).  And then we would have to be super-cautious to be consistent with said ephemeris when it comes to masses, geopotential, and the like.  For instance, we truncate the geopotential at large distance, we might not be able to do that.

On top of this, the real cost of integration is in the vessels: we use a step size of 10 seconds whereas we use 10 minutes for the ephemeris, and many games have dozens of vessels.

On 6/25/2020 at 11:19 PM, chuckstables said:

The mod dev's also needed to add accurate geopotential models for RSS, which model the real gravitational field of planets/moons using a power series with spherical harmonics. They also need to add code to efficiently evaluate the analytical derivatives of each term in the geopotential (at least I'm assuming they analytically evaluate them). This is also difficult. 

Difficult enough that we have extensive documentation of the mathematical details, because the code is incomprehensible in isolation.

On 6/25/2020 at 11:19 PM, chuckstables said:

I could write a symplectic integrator in python in about 100 lines; but to get it to run in KSP let alone to run efficiently would require a lot more than that.  

A very insightful comment.  We have been working on this thing for 6 years but the first cut of a symplectic integrator took a few days.

[chuckstables]

9 hours ago, pleroy said:

Let's ignore for a moment the inconvenience of having to special-case a solar system, of having new code paths to test, bugs that would show up only for some solar systems, etc.

The real question is: why would anyone want to trade CPU for I/O?

Computing a year of ephemeris for the real solar system takes about 10 seconds on an average computer, which means that, in the absence of vessels, we support timewarp at 3'000'000x.  A representation based on an existing ephemeris (DE431, INPOP, EPM, etc.) would take tens of megabytes per year.  That would require several seconds to load (for mysterious reasons KSP reads saves no faster than 5 MB/s even from SSD).  And then we would have to be super-cautious to be consistent with said ephemeris when it comes to masses, geopotential, and the like.  For instance, we truncate the geopotential at large distance, we might not be able to do that.

On top of this, the real cost of integration is in the vessels: we use a step size of 10 seconds whereas we use 10 minutes for the ephemeris, and many games have dozens of vessels.

Difficult enough that we have extensive documentation of the mathematical details, because the code is incomprehensible in isolation.

A very insightful comment.  We have been working on this thing for 6 years but the first cut of a symplectic integrator took a few days.

Yeah definitely fair. I was more just curious whether it would be possible; I've always assumed that the cost of the N-body calculation for the solar system would be more than for a vessel, but that does make sense.  I'm curious; what's your time step for asteroids and "unknown" objects? Is it the 10 second one or the 10 minute one?

As an aside; I'm honestly super impressed that this mod actually exists; it's absolutely incredible. What's even more awesome is that it's free. I've gotten hours of fun times playing around trying to get quasi-frozen low lunar orbits. I was impressed to see that your selenopotential model was accurate enough to replicate the original frozen orbit of the Lunar Reconnaissance Orbiter. It's a testament to the hard work you guys put into this mod; so thank you. 

[Cade]

Everything is orbiting earth... pls help. logs:https://www.dropbox.com/s/16g2colp14szcmb/KSP.log?dl=0

[Delay]

53 minutes ago, Cade said:

Everything is orbiting earth

That's because your reference frame is Earth-inertial. Since Earth cannot move in its own reference frame, everything else appears to move around a stationary Earth.

SImply change your plotting frame to 'Sun-Centered inertial' and the Solar System will make sense again.

[scimas]

2 hours ago, chuckstables said:

what's your time step for asteroids and "unknown" objects?

KSP itself treats asteroids just like vessels. Your rocket can grab onto them and move them around anyway you like, so Principia also needs to treat them like vessels.

Actually I didn't even need to type that, I could have just linked this: Principia wiki regarding timewarp

[Cade]

50 minutes ago, Delay said:

That's because your reference frame is Earth-inertial. Since Earth cannot move in its own reference frame, everything else appears to move around a stationary Earth.

SImply change your plotting frame to 'Sun-Centered inertial' and the Solar System will make sense again.

ok, Thank you

[eggrobin]

14 hours ago, chuckstables said:

I've always assumed that the cost of the N-body calculation for the solar system would be more than for a vessel, but that does make sense.

While the cost of prolonging the ephemeris is quadratic in the number of massive bodies (whereas computing the trajectory of a vessel is linear in that number) the timescales are very different (at least in the worst case, and since it is not possible to have variable step size and symplecticity, the chosen step size must accommodate the worst case); this is a case where the constant factor matters more than the asymptotic behaviour (the number of massive bodies remains fairly small, even with RSS).

14 hours ago, chuckstables said:

I'm curious; what's your time step for asteroids and "unknown" objects? Is it the 10 second one or the 10 minute one?

As @scimas said, these are vessels.

14 hours ago, chuckstables said:

I've gotten hours of fun times playing around trying to get quasi-frozen low lunar orbits. I was impressed to see that your selenopotential model was accurate enough to replicate the original frozen orbit of the Lunar Reconnaissance Orbiter. It's a testament to the hard work you guys put into this mod; so thank you. 

We had this kind of thing in mind when choosing the number of terms in the selenopotential—we go up to degree and order 30—: it was chosen to keep the qualitative behaviour of the low orbits described in a 2006 paper by Ryan P. Russel and Martín Lara, Repeat Ground Track Lunar Orbits in the Full-Potential Plus Third-Body Problem; see figures below.

Do you have any screenshots of your frozen orbit, and of what the orbit analysis window says about it? My attempts at getting a frozen lunar orbit in-game have not been very successful.

⸻

Figures from our investigation of Russel and Lara’s Orbit C with various selenopotential truncations.

Spoiler

Same as above over 10 years.

 

[chuckstables]

3 hours ago, eggrobin said:

While the cost of prolonging the ephemeris is quadratic in the number of massive bodies (whereas computing the trajectory of a vessel is linear in that number) the timescales are very different (at least in the worst case, and since it is not possible to have variable step size and symplecticity, the chosen step size must accommodate the worst case); this is a case where the constant factor matters more than the asymptotic behaviour (the number of massive bodies remains fairly small, even with RSS).

As @scimas said, these are vessels.

We had this kind of thing in mind when choosing the number of terms in the selenopotential—we go up to degree and order 30—: it was chosen to keep the qualitative behaviour of the low orbits described in a 2006 paper by Ryan P. Russel and Martín Lara, Repeat Ground Track Lunar Orbits in the Full-Potential Plus Third-Body Problem; see figures below.

Do you have any screenshots of your frozen orbit, and of what the orbit analysis window says about it? My attempts at getting a frozen lunar orbit in-game have not been very successful.

⸻

Figures from our investigation of Russel and Lara’s Orbit C with various selenopotential truncations.

  Reveal hidden contents

Same as above over 10 years.

 

I did the frozen orbit quite a while ago so no; I don't have any pictures. That being said it wasn't perfect; it ended up being unstable over a 12 month period with no correction burns. In GMAT the orbit was stable for around 3 years from what I remember with no correction burns, but the fact that it worked with a periapsis of around 30-40 km from what I remember is remarkable. I did it before the orbit analysis window actually was introduced as well; I just went forward in time. Here's the paper I based it off of; https://lunar.gsfc.nasa.gov/library/LRO_AAS_Paper_07-057.pdf 

In particular look at pages 10-11. I think it was technically a quasi frozen orbit. Still impressive in any case. The LRO these days is in a different quasi frozen orbit with an orbit of 20km x 165km. I think they wanted the Periselene to be lower so they could get more detailed images over the poles. 

Super interesting graphic by the way! I love stuff like that. Thanks for sharing. If I can replicate it again I will take some pictures and show you. What sort of frozen orbits have you tried to replicate? Thanks for taking the time to respond; I appreciate it. 

Edited June 28, 2020 by chuckstables
Needed to add something

[Bellabong]

If I wanted a kerbin with the capability for sun-synchronous satellites could I just copy the the geopotential data from earth over to kerbin? (3.2x scale kerbin)

[chuckstables]

7 hours ago, Bellabong said:

If I wanted a kerbin with the capability for sun-synchronous satellites could I just copy the the geopotential data from earth over to kerbin? (3.2x scale kerbin)

Simple answer; No. You can't do that.

Here's why. An Nth order truncated geopotential has terms which go like 1/R^(N+1) in it, where R is the radius from the center of the planet. Therefore, for your kerbin, which has a radius about 3.125 times less than earth's, terms of order N in the geopotential will be 3.125^(N+1) times larger on your kerbin's surface than they'd be on earth's surface. For a 30th order geopotential this is about 7*10^14 times larger for the highest order terms. 

What you can do is make your own reasonable geopotential for your kerbin. For sun-synchronous orbits the most important term in the geopotential is the second zonal term, though for earth other terms contribute significantly. So you could just make a custom geopotential which only includes the J2 term (second zonal term).  

[MAFman]

Does this work for 1.10?