[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

[FanaticalFighter]

I downloaded and compiled the .dlls. (actually, I downloaded, tried to read the code, didn't get it at all, then compiled and ran xD)

Anyway, I wanted to ask, why are the projections so... triangly? For me, most orbits (LKO, LMO) are pretty much straight lines going through the planet and making a star-ish pattern. ??

[bulletrhli]

I downloaded and compiled the .dlls. (actually, I downloaded, tried to read the code, didn't get it at all, then compiled and ran xD)

Anyway, I wanted to ask, why are the projections so... triangly? For me, most orbits (LKO, LMO) are pretty much straight lines going through the planet and making a star-ish pattern. ??

How do you even compile the code

[eggrobin]

I downloaded and compiled the .dlls. (actually, I downloaded, tried to read the code, didn't get it at all, then compiled and ran xD)

Anyway, I wanted to ask, why are the projections so... triangly? For me, most orbits (LKO, LMO) are pretty much straight lines going through the planet and making a star-ish pattern. ??

I'm downsampling by a factor of 100 to plot the trajectories in order to improve performance and reduce memory usage (I probably don't need to for such short predictions, but I didn't really think about it when I typed 100; I need that for predictions over a decade). As a result, fast orbits look polygonal (you get 1 point every ks). Eventually, smarter downsampling (velocity-dependent) should be implemented, as well as something more advanced than LineRenderers. In the meantime, I have pushed a new version that should somewhat alleviate this (by reducing the downsampling to 100 seconds from 1000 seconds).

The barycentric coordinates are also somewhat broken (you'll occasionally see obvious jumps in the trajectory). I suspect this comes from Unity's Quaternion. I am using Quaternion rather than QuaternionD because the obsolete radian-based methods are not implemented for QuaternionD; I don't trust either---why should I trust something that thinks constantly converting between radians and degrees is a good thing---, I'll just write my own versor.

Edited February 11, 2014 by eggrobin

[Taki117]

Stupid Question: Does this fix the SoI's making Lagrange points possible?

[rhoark]

I'd leave station keeping as an exercise for the user, with kOS and NeverUnload. Enabling the physics is enough without doing the pilot's job for them.

[mikeydz]

Once this progresses into a playable state, yes. Lagrange points will become possible. Eagerly waiting and watching this.

[eggrobin]

I'd leave station keeping as an exercise for the user, with kOS and NeverUnload. Enabling the physics is enough without doing the pilot's job for them.

There would be quite a bit of stationkeeping to do (maintaining a couple dozen LKO satellites in LKO with orbital decay, keeping stuff around Lagrange points etc.), so this would get quite tedious. Moreover, stationkeeping has to be done quite regularly. If you had to do it yourself (or, even if that were automated by kOS, if kOS did the stationkeeping by loading the vessels), you couldn't timewarp for very long, rendering interplanetary missions impractical. In addition, NeverUnload is not a solution: the floating origin stays where it is and Unity physics is done in single precision, so if the active vessel is on Duna, a vessel performing stationkeeping in LKO would jump 2km at a time. Needless to say, instead of performing a minor correction to its orbit, it would end up in a random orbit (or crash on Kerbin). Finally, stationkeeping is way harder than you seem to think, see thorfinn's post. You can't conceivably write the gradient descent you'd need to minimise this cost function in kOS, not to mention an integrator. You'd need a full-fledged programming language and a few weeks of careful coding (not counting the time to do research, and assuming you have experience in numerical math) in order to write your stationkeeping algorithm. You'd basically be writing a 1000-line plugin that does stationkeeping. While this is fun, and I recommend you read the papers and my eventual implementation, I'm not sure this is a good idea from a gameplay perspective.

As a conclusion: you need stationkeeping, you need it to be automated, you can't load the vessel to do stationkeeping and kOS wouldn't do as programming language.

Edited February 12, 2014 by eggrobin

[ddenis]

Just one very important thing to consider which could be lost and about which I haven't found anything in the thread.

Science will require some work on it too.

Because now High Orbit science is defined by the sphere of influence in which the vessel is, but what will be with N-bodies? Would the vessel still have such parameter, it would be measured by distance to body?

[AndreyATGB]

Just one very important thing to consider which could be lost and about which I haven't found anything in the thread.

Science will require some work on it too.

Because now High Orbit science is defined by the sphere of influence in which the vessel is, but what will be with N-bodies? Would the vessel still have such parameter, it would be measured by distance to body?

SOIs are a real thing, I don't see the problem. An SOI is by definition when a planet is affecting you the most (the point after which the Earth has more effects than the Sun is considered Earth's SOI).

[ddenis]

SOIs are a real thing, I don't see the problem. An SOI is by definition when a planet is affecting you the most (the point after which the Earth has more effects than the Sun is considered Earth's SOI).

I, also, don't see problems, just added one thing just to not forget. If author hasn't considered it before.

[thorfinn]

It might just be a slightly squashed sphere from now on

[eggrobin]

Just one very important thing to consider which could be lost and about which I haven't found anything in the thread.

Science will require some work on it too.

Because now High Orbit science is defined by the sphere of influence in which the vessel is, but what will be with N-bodies? Would the vessel still have such parameter, it would be measured by distance to body?

From the game's point of view, the SOIs are still here and the biomes should still work like they did. It's just that I'm moving stuff around instead of letting the game do its thing, and I'm ignoring SOIs.

An SOI is by definition when a planet is affecting you the most (the point after which the Earth has more effects than the Sun is considered Earth's SOI).

It's actually really messy to define properly. There are mostly three definitions for the SOI of a body---for concreteness, let's call it Earth (in a system with two massive bodies: the Earth and the Sun),

• The sphere of attraction is the region in which the force exerted by the Earth is greater than that exerted by the Sun. It is tiny and mostly useless (the Moon is outside of Earth's sphere of attraction with respect to the Sun).
  
• The sphere of action, or Laplace sphere (Laplace 1799) is a tad more complicated to define, and finding the definition on the internet takes a while: look at the unperturbed problem of a (massless) test particle orbiting the Earth, and consider the position r_Earth of the test particle relative to the center of the Earth. The particle undergoes some acceleration r"_Earth = a_Earth. Now add the Sun. Call p_Earth the resulting change in the second derivative of r_Earth (it's the perturbation due to the Sun of the 2-body approximation of the relative motion of the test particle and the Earth). Similarly, define a_Sun and p_Sun. The sphere of influence of the Earth is the region where the acceleration to perturbation ratio for the Earth is smaller than the corresponding ratio for the Sun, namely,
  a_Earth/p_Earth < a_Sun/p_Sun.
  In this region, the 2-body approximation around B₁ is better than the 2-body approximation around B₂.
  The sphere of action is larger than the sphere of attraction. This is the SOI used by KSP.
  
• The proper definition for the Hill sphere is slightly more involved. The idea is that when your orbital energy (in the corotating frame of reference for the CR3BP) is low enough (and you're close to the Earth), there is a bounded region around the Earth that you can't leave. If you keep increasing your orbital energy, there's a point where this region will include the Lagrange point L1 and will suddenly expand so that you are able to reach the sun: when you have this orbital energy, conservation of energy does no longer prevent you from escaping the Earth. Just before this happens, the region around the Earth that you can't leave (which extends up to L1) is the Hill sphere; it's the region inside the equipotential through L1 (on the Earth side).
  If you want to visualise this, look at the image below (the rotational potential of the CR3BP) and imagine having a horizontal surface of water that rises on this weird hill with two holes. Say you are on a boat in the tiny lake around Earth. The area where there is water is the area where your orbital energy allows you to go (by trading kinetic energy for potential energy).
  You could be in the lake around the sun, but there is a mountain pass at L1 between the two lakes preventing you from going from one to the other. As the water (the orbital energy) rises, there is a moment where the lowest point of that mountain pass (L1) is submerged. From then on there is nothing preventing you from going to the Sun. Just before the lakes merge, the lake around Earth is its Hill sphere. Page 580 of this paper by Ross & Scheeres 2007 shows the shape of the forbidden regions depending on the energy (C_J = -2 H, where H is the energy, because astronomers are weird and count the energy backwards). The Hill sphere is larger than the Laplace sphere.
  
  

It should be noted that Jupiter has quite a few satellites outside of its Hill sphere, so having an energy below that of L1 is not a required condition for having a stable orbit.

The Laplace sphere is mostly useful for determining which patched conic approximation to use (this is why it was defined together with the patched conic approximation by Laplace in his Traité de mécanique céleste).

It might just be a slightly squashed sphere from now on

Indeed, none of these are actually spheres (the first two get more spherical as the ratio of the small mass to the larger goes to 0, but the Hill sphere remains pinched at L1).

Edited February 13, 2014 by eggrobin

[FanaticalFighter]

BTW, eggrobin, how are you handling maneuvre nodes for Principia?

[CaptainKipard]

I'm eagerly waiting for a mod that sees Kerbol gain a companion star with its own planets and whatnot.

[eggrobin]

BTW, eggrobin, how are you handling maneuvre nodes for Principia?

By adding them to the 'further modding' list.

There are quite a few things I will want to show on the predicted trajectory using interactive markers (you should be able to click on them to get more details).

Examples include aerodynamic events (free molecular flow to fluid flow transition, Mach numbers, instability), stationkeeping burns, long-duration burns (start and end). A maneuver node can be such a marking. When tweaking it, the new trajectory is computed using the dynamic integration (I really don't like this name, can someone come up with something nicer?). As for the interface for tweaking it, I think I'll go with a window and sliders; the current system has ergonomic issues. An interesting question is that of the axes. In stock KSP, we are always in a Keplerian orbit, so it makes sense to see burns as a linear combination of prograde, radial and normal. This will also work for strongly bound orbits. For weakly bound orbits, other axes may be useful.

I'm eagerly waiting for a mod that sees Kerbol gain a companion star with its own planets and whatnot.

Remember that double precision limits the size of the system. The resolution with a 53-bit mantissa at the aphelion of Pluto is 0.8 mm, so you can't do much bigger.

If I were to use extended precision (which is slower, as x87 is a scalar FPU, but I don't know how critical performance will end up being), the resolution at 1 light-year would be 0.5 mm. This would be much nicer for RSS.

If performance really isn't an issue, I could try double-double (implemented in software, so an order of magnitude slower), which would give me an error of 0.01 mm at the edge of the observable universe (though for systems that big you'd really want GR, and I don't want to look at the curvature of that rabbit hole).

I could talk about IEEE 754 quads, whose error at the edge of the observable universe would be 87 nm, but this is getting rather silly unless you're interested in molecular dynamics at the scale of superclusters.

Anyway, I'm not currently in the planet-making business, and I hear PFCE is rather buggy (e.g. compatibility with FAR or lack thereof). I'm not sure if the problem of making a fully functional star, i.e., a star which is a light source, feeds the solar panels, etc. has been solved either.

Edited February 15, 2014 by eggrobin

[FanaticalFighter]

@Eggrobin:

So essentially, you're telling me that we'll have finite burns maneuver nodes? I can't stop grinning at that, that'll make ion engine probes and long nuclear burns so much easier to predict. But then, with long duration burns, you'll want to decide whether the orientation of the craft remains fixed, or keeps pointing prograde, or what not. (For example, does the craft point at a fixed point in space while burning, or does it change its orientation to stay exactly on, say prograde or something)

[eggrobin]

@Eggrobin:

So essentially, you're telling me that we'll have finite burns maneuver nodes? I can't stop grinning at that, that'll make ion engine probes and long nuclear burns so much easier to predict. But then, with long duration burns, you'll want to decide whether the orientation of the craft remains fixed, or keeps pointing prograde, or what not. (For example, does the craft point at a fixed point in space while burning, or does it change its orientation to stay exactly on, say prograde or something)

This pretty much has to exist since thrust through timewarp is planned. I guess I'll need to have a few options as far as orientation is concerned (thrust through timewarp has to be automated, since you can't control the ship directly during timewarp).

[thorfinn]

Remember that double precision limits the size of the system. The resolution with a 53-bit mantissa at the aphelion of Pluto is 0.8 mm, so you can't do much bigger [...]

I think he was talking about a multiple star system, that shouldn't have such pressing issues: the other stars would be within a few dozen AU, and Kerbal-scaled AU at that.

If separated star systems were ever to be implemented, I think that making each system its own island and considering interstellar flight a special case would be the sensible choice: there is literally nothing of interest in the void between stars after all...

[eggrobin]

Status update:

I have finally managed to work on this a bit over the weekend.

Extensive experimentation has failed to yield a better velocity, so we are stuck with computing the proper acceleration from the rather mysterious Vessel.obt_velocity for now (for some reason in whatever reference frame this velocity is in, the geometric accelerations are as expected, except for the Coriolis acceleration which is halved ).

This yields roughly the same results as Vessel.perturbation without the moving average.

The same experiments have further shown that a naïve low-pass filter will not be enough to remove Unity's silliness. For instance, one finds the proper acceleration is strongly correlated with the rotation rate of the ship. Smarter post-processing will be needed.

I shall now attempt to actually integrate whatever proper acceleration I have managed to grab.

I also wrote the first explanatory post, which describes ODEs and Runge-Kutta methods (PDF).

I have tried not only to explain how Runge-Kutta methods work (this can easily be found on Wikipedia) but why they have this structure.

Hopefully you will find it interesting.

[Tuna-Fish]

Remember that double precision limits the size of the system. The resolution with a 53-bit mantissa at the aphelion of Pluto is 0.8 mm, so you can't do much bigger.

If I were to use extended precision (which is slower, as x87 is a scalar FPU, but I don't know how critical performance will end up being), the resolution at 1 light-year would be 0.5 mm. This would be much nicer for RSS.

If performance really isn't an issue, I could try double-double (implemented in software, so an order of magnitude slower), which would give me an error of 0.01 mm at the edge of the observable universe (though for systems that big you'd really want GR, and I don't want to look at the curvature of that rabbit hole).

In my experience, a ghetto double double (11 bit exponent, 106 bit mantissa, implemented as a sum of two doubles, the smaller of which always has an exponent 53 less than the bigger) is nowhere near order of magnitude slower than x87 80bit, and can in some situations be faster, depending on the compiler, as the x87 stack is not always handled gracefully.

Something like representing location as a double double and velocity as a double would give you much greater precision than plain doubles while still not being that much slower.

X = Xa + Xb

X' = X + Vx

X'a = Xa + Vx

X'b = Xb + (Vx - (X'a -Xa))

(Ordering of operations is significant)

This has only 4 times the math of the x87 version, and consumes and reads/writes as much memory (as 80-bit numbers need to be 128-bit aligned). If you can do SIMD, putting Xa and Ya in the same tuple (and Xb and Yb in the next) halves the arithmetic operations needed.

Edited February 17, 2014 by Tuna-Fish

[thorfinn]

The same experiments have further shown that a naïve low-pass filter will not be enough to remove Unity's silliness. For instance, one finds the proper acceleration is strongly correlated with the rotation rate of the ship. Smarter post-processing will be needed.

Gah. Sorry. As for the correlation with angular rates, do you mean the centrifugal force due to the phisics calculations being done wrt. the root part and not the center of gravity?

[eggrobin]

In my experience, a ghetto double double (11 bit exponent, 106 bit mantissa, implemented as a sum of two doubles, the smaller of which always has an exponent 53 less than the bigger) is nowhere near order of magnitude slower than x87 80bit, and can in some situations be faster, depending on the compiler, as the x87 stack is not always handled gracefully.

[...]

If you can do SIMD, putting Xa and Ya in the same tuple (and Xb and Yb in the next) halves the arithmetic operations needed.

You make some very good points.

I guess if I need more significant digits I'll use double-double rather than extended precision then.

Gah. Sorry. As for the correlation with angular rates, do you mean the centrifugal force due to the phisics calculations being done wrt. the root part and not the center of gravity?

No, I'm compensating for the geometric accelerations applied by KSP. What I mean is what you see when you spin the ship very fast: the camera (which is centered on the center of gravity) wobbles because Unity doesn't conserve momentum in its interactions between rigid bodies.

It seems most of the biases I was measuring when the ship was not rotating very quickly were coming from the reaction wheels though; I'm not sure if that's because I have a joystick or whether it's a deeper bug, but with reaction wheels enabled, a test ship (Mk1 - FL-T200 - LV-T30) picks up angular momentum quickly without input (SAS off), while this phenomenon is much slower with reaction wheels disabled.

Ignoring the reaction wheels issue (which may well occur between the chair and the keyboard), it seems a low-pass filter for rounding errors, with a band-stop around the rotation rate and a maybe a high-pass on torque might do the trick. I'll see about what post-processing I want to do later on, this will require quite a bit of logging and data analysis.

FFT is hard; let's go integrating.

Edited February 17, 2014 by eggrobin

[nhnifong]

If you don't mind dumbing it down a little bit, does this recent update mean that you are now working on the problem of sustained acceleration under timewarp? Such as with ion engines?

[eggrobin]

If you don't mind dumbing it down a little bit, does this recent update mean that you are now working on the problem of sustained acceleration under timewarp? Such as with ion engines?

No, it means I'm working on the problem of making this playable, i.e., of making rockets useful. Currently, off-rails thrust is ignored. This means you can't change your orbit. I'm trying to grab whatever acceleration comes from your engines/getting out and pushing/decoupling etc. and to change your trajectory accordingly. Remember that in this mod, I'm the one moving stuff around, not Unity (this also applies to off-rails), so I have to fetch these accelerations in order for them to affect the trajectory.

On-rails (timewarp) thrust is a feature I will work on once the basic stuff works, like the rest of the 'further modding' section.

[TimMartland]

Wow. Dubstep orbits.