[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

[Eriksonn]

@eggrobin Ah, that makes sense. I made this little diagram for myself, and now it makes perfect sense why having the geopotential be equal to the terrain is a bad idea.

Now i need to throw myself back into the sea of strange math(ie, the link you gave me) to find a way to get the correct smooth version of the geopotential

Edited August 11, 2019 by Eriksonn

[Sigma88]

just in case you want to try this in ksp, I have a PQS mod for those types of planets

https://github.com/Sigma88/PQSGroundCube/tree/master/[Source]/Distribution

 

not sure it still works

Edited August 11, 2019 by Sigma88

[pleroy]

21 hours ago, Eriksonn said:

Now i need to throw myself back into the sea of strange math(ie, the link you gave me) to find a way to get the correct smooth version of the geopotential

There is also interesting work by Fukushima on this topic.  We use his numerical libraries in Principia.

[Jim DiGriz]

@Eriksonn following some references from that Fukushima paper led to this paper:

https://link.springer.com/article/10.1007/BF00053511

Which derives the gravitational field of a uniform density arbitrary shaped object using Polyhedron.  Just skimming it it seems more accessible to someone with college calculus.  It does it all analytically requiring no numerical integration or quadratures.

My guess at a textbook that would cover integrating the series coefficients as integrals over the mass distribution would probably be (following the references in that paper above, and then following the recommendations on amazon to find something newer):

https://www.amazon.com/Geodesy-Wolfgang-Torge/dp/3111174549/

Also I suspect that any graduate level classical mechanics course would cover that as well, but likely not in as much depth.

I don't think there's going to be any undergrad text which cover it AFAIK.  Certainly it wasn't covered in any classes of mine.  Doesn't even seem like Arfkin + Webber covers it although it covers spherical harmonics and legendre functions so the basic math is probably there, but their slant is more towards quantum mechanics applications.

[AloE]

@pleroy  Is there a way I could make KerBalloons v0.4.4 balloon craft 'work' or be excluded from Principia?  I really would like to use them especially in the TRAPPIST1 system which obviously requires Principia.  The Balloons work OK in SLIPPIST1 (& Kerbin) but just bounce on the launchpad when I add Principia (I think is because KerBalloons.dll controls their in-flight characteristics including ascent rate, etc thus conflicts with Principia...but maybe that really is no different than autopilot of an engine?)  Currently I am mostly still using Principia Fatou since that is the last support for KerbalEDU 1.4.5 since TeacherGaming has not yet updated KerbalEDU...I very much appreciate your thoughts.

 

[Eriksonn]

@eggrobin I have read through that link that you sent, but i have reached a dead end, as that whole paper seems to assume that i have the disturbing potential as well as the topography, and i only have the topography. But it should be possible to get the geoid with only the topography, atleast if constant density is assumed. I tried to do a brute force approach, but that was very slow, and i am not confident in its accuracy. Most of the papers i find on this seems to either use ground measurements of the gravity or computing other values that i dont care about, by using the geoid as a given. So i am abit stuck right now...

[eggrobin]

@Eriksson What about the Fukushima paper linked by @pleroy, or the ones that @Jim DiGriz linked? Those are specifically about computing the gravitational field given the shape.

@AloE Kerballoons is using Rigidbody.AddForceAtPosition instead of Part.AddForceAtPosition, which means that Principia cannot learn about those forces, and therefore cannot make them affect the trajectory; this is the same issue that we found in FireSpitter earlier:

In order to be compatible with Principia, a mod that imparts a net force to the vessel must do so with Part.AddForceAtPosition (or Part.AddForce) instead of Rigidbody.AddForceAtPosition (or Rigidbody.AddForce); the force can then be handled by the game (and any mods) instead of being passed directly to Unity.

This should be a pretty simple change: all usages of AddForceAtPosition are actually on the RigidBody of a part (part.RigidBody.AddForceAtPosition), so dropping the .RigidBody would do the trick.

[ZAJC3W]

May i have GUI suggestion? Add close window buttons(to all windows) so we don't have to search for button that opened them. It can get tedious when planning manoeuvres. 

[Delay]

1 minute ago, ZAJC3W said:

It can get tedious when planning manoeuvres

Indeed, especially when you have both reference frame windows open (one for the maneuver and one for the display) and can't figure which one it is.

[AloE]

On 8/16/2019 at 9:32 PM, eggrobin said:

Kerballoons is using Rigidbody.AddForceAtPosition instead of Part.AddForceAtPosition...dropping the .RigidBody would do the trick.

cloned the KerBalloons source, made the edit you recommended, built the dll, flew a high balloon with Principia (TRAPPIST1) ;-)  Thanks so much!

KerBalloons with Principia

 

[pleroy]

On 8/19/2019 at 8:20 PM, AloE said:

cloned the KerBalloons source, made the edit you recommended, built the dll, flew a high balloon with Principia (TRAPPIST1) ;-) 

Nice!  Make sure that you send a pull request to the author of KerBalloons to move the fix upstream: the next user of KerBalloons and Principia will thank you.

[CrickCrickBang]

Can't wait to try this out in my 3.2x scale game. I also use Orital Decay so I'm wondering if someone knows what the outcome of the two together will be? I'm willing to test it but was wondering if anyone has experience with the two yet. v1.7.1

[pleroy]

On 8/18/2019 at 1:03 PM, ZAJC3W said:

May i have GUI suggestion? Add close window buttons(to all windows) so we don't have to search for button that opened them. It can get tedious when planning manoeuvres. 

Good idea.  Created #2295 to track this.

[FreeThinker]

On 8/16/2019 at 9:32 PM, eggrobin said:

In order to be compatible with Principia, a mod that imparts a net force to the vessel must do so with Part.AddForceAtPosition (or Part.AddForce) instead of Rigidbody.AddForceAtPosition (or Rigidbody.AddForce); the force can then be handled by the game (and any mods) instead of being passed directly to Unity.

This should be a pretty simple change: all usages of AddForceAtPosition are actually on the RigidBody of a part (part.RigidBody.AddForceAtPosition), so dropping the .RigidBody would do the trick.

Intresting but what if you tried to change the orbit of a vessel to simulate persistant thrust. Currently I use the following method to Perturb a orbit:

        // Perturb an orbit by a deltaV vector
        public static void Perturb(this Orbit orbit, Vector3d deltaVV, double universalTime)
        {
            // Transpose deltaVV Y and Z to match orbit frame
            Vector3d deltaVV_orbit = deltaVV.xzy;

            // Position vector
            Vector3d position = orbit.getRelativePositionAtUT(universalTime);

            // Update with current position and new velocity
            orbit.UpdateFromStateVectors(position, orbit.getOrbitalVelocityAtUT(universalTime) + deltaVV_orbit, orbit.referenceBody, universalTime);
            orbit.Init();
            orbit.UpdateFromUT(universalTime);
        }

How to achieve the same with Principia installed?

 

Edited August 22, 2019 by FreeThinker

[eggrobin]

11 hours ago, CrickCrickBang said:

Can't wait to try this out in my 3.2x scale game. I also use Orital Decay so I'm wondering if someone knows what the outcome of the two together will be? I'm willing to test it but was wondering if anyone has experience with the two yet. v1.7.1

Principia and Orbital Decay (or any other mod that alters the orbits) are fundamentally incompatible.

On 8/19/2016 at 2:02 PM, eggrobin said:

I don't think this will work with any mod that alters the orbits (the changes will simply be ignored, since we persist our own Cartesian state and simply force the game to put things in the right place by setting the orbits).

More importantly though, it seems that @Whitecat106's mod and ours have roughly the same goals, so you probably don't want to have both installed: @Whitecat106 appears to be working on multibody and extended/inhomogeneous body gravitation, and we have atmospheric decay as one of our (rather long-term) aims.

@Whitecat106, you might want to put this mod in your list of known incompatibilities, since we're likely to attract the same users.

@Papa_Joe, since you are the new maintainer of Orbital Decay, please note the above; it may be useful to document this incompatibility. 

 

5 hours ago, FreeThinker said:

Intresting but what if you tried to change the orbit of a vessel to simulate persistant thrust. [...] How to achieve the same with Principia installed?

You cannot; this is inherently at odds with what Principia does, because keeps an internal dynamical state that it gets propagated by numerical integration, and overrides what stock orbits do.

Any changes to the orbits would have to be done as part of the numerical integration, and considerations of complexity as well as performance mean that they have to be done by Principia.

To quote some related past discussion to that effect:

On 12/17/2017 at 8:32 PM, Jim DiGriz said:

You're not suggesting anything that isn't obvious.  Orbital decay, stationkeeping and low-thrusting-spacecraft-on-rails are all mod ideas that have occurred to everyone that has used Principia.  The mod authors are a busy with issues more directly related to the N-body physics simulation though.

[...] The problem is more that you need a mod which looks at the actual principia orbit (not the [osculating] orbit) and applies a perturbation to the orbit and drains some RCS, and can handle that process through timewarping (which is why decay, stationkeeping and low-thrust probably all should go into the same mod) [...].

On 12/17/2017 at 11:10 PM, pleroy said:

@Jim DiGriz has actually a very good point.  For things like station-keeping and orbital decay, code would need to be executed inside the inner loop of the integrator.  The time budget there is less than 100 ns (that's nanoseconds) so there is no way to do a kRPC call, or even a P/Invoke cross-language call (especially with the complex serialization involved).  Everything would need to be done in C++ using the Principia abstractions and linked into the Principia DLL.  When you do this, well, you are just beefing up Principia and not interfacing with another mod.  I am not saying that we won't be doing this one day, but not using 3rd party mods.

The interested reader might want to look at the PRs that fix #1628 in the new Christoffel release.  It took me many pull requests and close to three weeks to just figure out if a vessel is inside a celestial during the force computation and bring that information up to KSP.

 

[FreeThinker]

On 8/22/2019 at 6:01 PM, eggrobin said:

You cannot; this is inherently at odds with what Principia does, because keeps an internal dynamical state that it gets propagated by numerical integration, and overrides what stock orbits do.

Any changes to the orbits would have to be done as part of the numerical integration, and considerations of complexity as well as performance mean that they have to be done by Principia.

Ok, but wouldn't it be possible for Principa to expose a method that would allow appling an force to part, which would work durring either real time or timewarp?

Something like

void ApplyForce(Part part, Vector3D forcevector);

The force would then be applied by Principia durring the numerical integration step .

Edited August 24, 2019 by FreeThinker

[Delay]

@pleroy @eggrobin

My antivirus is falsely detecting all dlls of the ferrari release as potential malware, claiming the files are less than 1 week old. I just freshly downloaded it.

Of course I trust you that there is no malware hidden in any of the dlls, but the given release date and the file's age don't line up at all. I'm asking for reassurance that these files are indeed the way you uploaded them.

[pleroy]

1 hour ago, Delay said:

@pleroy @eggrobin

My antivirus is falsely detecting all dlls of the ferrari release as potential malware, claiming the files are less than 1 week old. I just freshly downloaded it.

Of course I trust you that there is no malware hidden in any of the dlls, but the given release date and the file's age don't line up at all. I'm asking for reassurance that these files are indeed the way you uploaded them.

The Ferrari archive has the following hashes on my machine:

&"C:\Program Files (x86)\File Checksum Integrity Verifier\fciv.exe" -md5 -sha1 "principia ferrari for 1.7.3.zip"
//
// File Checksum Integrity Verifier version 2.05.
//
                MD5                             SHA-1
-------------------------------------------------------------------------
5395878d78edb96effb71112a93f6026 28b629b6c0cf439c29e6eacbc15750bf31b86f8f principia ferrari for 1.7.3.zip

The date of most of the files in the archive is 2019-07-31 (with times like 13:38, 14:14 and 14:23).  A few are older.

I uploaded the archive to VirusTotal and the results seem clean.

I suspect a false positive, although the part about "less than 1 week old" is weird.

[Delay]

Mine has the same hash and literally opens the same VT page. False positive it is, then.

About that "less than one week old": I use.... Norton... as my totally reliable antivirus product. I don't know where they're getting their numbers from, could be a mistake on their end.

[ZAJC3W]

Norton... no comments.

As per less than week old, downloaded zip will have creation date set to time of downloading, at least when downloaded in opera or chrome.

 

[Delay]

4 minutes ago, ZAJC3W said:

Norton... no comments.

Yep. From the same company who made KillCIH in the late 90s...
But I usually don't download anything that even looks remotely dodgy in any imaginable way, so it's doing an okay job when I actually need it.

And I use Firefox, and it never showed this.
Now that being said, nearly no file actually triggers a false positive, so I don't know how old they think these zips are.

[Jim DiGriz]

On 8/22/2019 at 10:15 AM, FreeThinker said:

Ok, but wouldn't it possible for Principa to expose a method that would allow appling an force to part, which would work durring either real time or timewarp?

Something like

void ApplyForce(Part part, Vector3D forcevector);

The force would then be applied by Principia durring the numerical integration step .

Would need to supply a `Vector3d force_function(double time, Vector3d pos, Vector3d vel)` (so passing a function handle rather than Vector3d forcevector) at a minimum so that the supplied force would be a function of time and could be a function of the dynamics.  Because you need to supply more than just the force on the next physics tick, and you want to do more than supply a constant force for all time of the simulation -- you want to be able to say things like "apply a force that acts opposite the velocity vector".

Edited August 23, 2019 by Jim DiGriz

[eggrobin]

40 minutes ago, Jim DiGriz said:

Would need to supply a `Vector3d force_function(double time, Vector3d pos, Vector3d vel)` (so passing a function handle rather than Vector3d forcevector) at a minimum so that the supplied force would be a function of time and could be a function of the dynamics.  Because you need to supply more than just the force on the next physics tick, and you want to do more than supply a constant force for all time of the simulation -- you want to be able to say things like "apply a force that acts opposite the velocity vector".

Indeed; and at this point, we run into the code complexity of threading that callback all the way down to the integrator; further, even if we did that, there is the aforementioned performance problem:

On 12/17/2017 at 11:10 PM, pleroy said:

code would need to be executed inside the inner loop of the integrator.  The time budget there is less than 100 ns (that's nanoseconds) so there is no way to do a kRPC call, or even a P/Invoke cross-language call (especially with the complex serialization involved).

In addition, the integration method¹ that we use for long-term vessel trajectories only works if the forces that it is applying depend solely on the position of the vessel, not its velocity; and it only has nice properties if these forces derive from a potential. This in turn means that we would need to switch to a different kind of integration method (which would likely have to be slower to have comparable accuracy), again inducing lots of complexity.

TL;DR: thrust in timewarp is not trivial, and will not happen soon; it cannot be a simple “apply force” binding like the ones found in Unity or KSP.

⸻
¹ A symmetric linear multistep method, whose underlying one-step method is conjugate-symplectic.

Edited August 24, 2019 by eggrobin
tyop

[Delay]

Short update: Now the ferrari release works without any problems, no false positives this time...

[That John]

does this mod add such things as orbital decay? if so im getting it