[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

[w00tguy]

This is unbelievably cool. I didn't think this was possible as a mod. All these curvy lines and new terms are blowing my mind.

[horace]

it crashes 1.7.3

 

[pleroy]

22 minutes ago, horace said:

it crashes 1.7.3

Which is exactly as expected, see the announcement post.

[eggrobin]

For the new moon (lunation number 242), the new release (Ferrari) is out.

• Support for KSP 1.7.3 has been added.
• Some bugs reported by @scimas have been fixed.

 See the change log for more details.

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

[Riven]

First post in a looong time - never really had the time to play KSP at all for the last couple years, and I demand as much realism as possible so when I ran into issues and mod conflicts, I kinda... gave up several times as the 20m+ load times were just too much.

Anyways, I did a cursory search of this thread for a way to display predicted orbital parameters such as inclination, and I couldn't find anything immediately. Should I pull out an orbital dynamics textbook to hand calculate approximate plane change burns in two-body? I'm willing to do it to brush up on orbital dynamics, but am I overlooking an obvious setting or option that will display a patched conic approximation of a maneuver as in stock to check my work (or if I become lazy which is more likely)? I understand that it's an n-body propagator (amazing at that) but still.

[eggrobin]

 

20 minutes ago, Riven said:

Anyways, I did a cursory search of this thread for a way to display predicted orbital parameters such as inclination, and I couldn't find anything immediately. Should I pull out an orbital dynamics textbook to hand calculate approximate plane change burns in two-body? I'm willing to do it to brush up on orbital dynamics, but am I overlooking an obvious setting or option that will display a patched conic approximation of a maneuver as in stock to check my work (or if I become lazy which is more likely)?

There is currently nothing that will show a good corresponding two-body orbit. At any time, the game is made to believe that the vessel is following its osculating orbit, so your usual orbital element displays (Kerbal engineer, MechJeb, etc.) will show the osculating elements, which may help; however, the osculating elements are subject to short-period variations that can be misleading as to the true nature of the orbit (in particular the osculating eccentricity and argument of periapsis of near-circular orbits will be wildly inaccurate, to the point of being entirely useless: for TOPEX/Poseidon, the osculating eccentricity ranges between 0.000'2 and 0.001'2, whereas the  proper (“mean”) eccentricity is less than 0.000'11.).

As @pleroy previously mentioned,

On 7/6/2019 at 2:01 PM, pleroy said:

1. The orbit needs to be characterized and its mean properties determined.  This is not easy in an N-body universe because there is a zoo of interesting orbits that must be considered, and therefore just finding an approximate ellipse requires care.  @eggrobin has been spending the last 5-6 months looking into this specifically for perturbed Keplerian orbits, e.g. LEO; he read a treatise on the topic and numerous research papers, and is just starting to reach the point where he has an idea how to do that in the game.

I am working on something (the Ferrari change log mentions the ground track recurrence analysis), but this is nontrivial.

Edited July 31, 2019 by eggrobin
example

[Delay]

@eggrobin Well, it would at least be possible to show the inclination in degrees.

Nodes display the vertical velocity and apsides display the tangential velocity. I assume that it would be possible to calculate the velocity of the spacecraft at any point in time, so sin^-1(vertical/tangential) would yield the inclination.

The idea is you'd have inclination displayed on the nodes alongside the vertical velocity.

Edited July 31, 2019 by Delay

[eggrobin]

@Delay, that would just be the osculating inclination at the node (assuming that we are in the body-centred inertial frame, otherwise it is a largely meaningless angle).

As previously discussed, osculating elements are not that useful when it comes to describing your orbit, because they vary wildly along the orbit; arguably the inclination is less affected than the other elements, but I would rather have a consistent approach when it comes to displaying this information, and keep the stuff on the nodes about strictly instantaneous properties at that node (apsis distances, velocities, etc), and display global properties of the orbit (including mean elements) separately.

[Riven]

31 minutes ago, eggrobin said:

There is currently nothing that will show a good corresponding two-body orbit. At any time, the game is made to believe that the vessel is following its osculating orbit, so your usual orbital element displays (Kerbal engineer, MechJeb, etc.) will show the osculating elements, which may help; however, the osculating elements are subject to short-period variations that can be misleading as to the true nature of the orbit (in particular the osculating eccentricity and argument of periapsis of near-circular orbits will be wildly inaccurate, to the point of being entirely useless: for TOPEX/Poseidon, the osculating eccentricity ranges between 0.000'2 and 0.001'2, whereas the  proper (“mean”) eccentricity is less than 0.000'11.).

Okay, understood, because there are other bodies influencing the osculating elements of the craft. Just a rough estimate to the nearest degree in GEO and lower is all I need where I can refine from there, which I can do as an exercise as pointed out by @Delay. I desperately need to review orbital dynamics from the basics anyways. Amazing propagator and keep up the work here and in astrophysics.

[Eriksonn]

@eggrobin Over the past few days i have been making a mini mod thing for automatically generating the spherical harmonics needed to allow some of the stock bodies to have geopotentials.(My current "test subject" is Minmus) At this point in time i have managed to generate a suitible(i think) config file with the same format as the one in Principia/real_solar_system/gravity_model. 

principia_gravity_model
{
	Body
	{
		Name = Minmus
		geopotential_row
		{
			degree = 1
			geopotential_column
			{
				order = 0
				cos = 2.01267793181124960E-004
				sin = 0.00000000000000000E+000
			}
			geopotential_column
			{
				order = 1
				cos = -1.67248927462036320E-003
				sin = 2.96599647369928530E-003
			}
		}
		geopotential_row
		{
			degree = 2
			geopotential_column
			{
				order = 0
				cos = 8.05394019210287260E-003
				sin = 0.00000000000000000E+000
			}
			geopotential_column
			{
				order = 1
				cos = -2.80339441217786760E-003
				sin = 1.38156354030291020E-003
			}
			geopotential_column
			{
				order = 2
				cos = -5.70133104974222470E-003
				sin = 3.12729158537247910E-003
			}
		}
        ...up to degree 10...

However, i am now having 2 problems. One is that i dont know where to put this new file(i am calling it gravity_model_extension). Can i still have it in my own mod folder and somehow link it to the principia folder, i have tried adding an @ to the of start principia_gravity_model, but that didnt work either. Two is does my file contain enough information as is or do i need more? (as i saw that the gravity_model file contained lots of other information like gravitational_parameter and reference_radius. Do i need that too, or am i good with what i have?)

Edited August 3, 2019 by Eriksonn

[RealTimeShepherd]

Hi

I have a question, please bear with me!

I'm using Principia with RO/RSS. I have managed an Apollo style moon landing and return, and the mod is awesome. I particularly enjoyed how much it improves orbital rendezvous by showing you your path relative to the target!

Anyway, I'm now working on interplanetary transfers and I'm struggling as I can figure out the strength of the burn and the time to execute it, but not the direction.

Currently, I'm putting all of the Δv into one direction (tangent for example), then looking at the predicted PE to my target. Then I'm moving the other sliders to try and reduce the magnitude of the PE

I end up increasing the velocity along the other dimensions (normal/anti-normal/binormal/anti-binormal etc) but then I find myself going back to deduct Δv from the original vector (tangent)

OK, so my question is, could we have an option to select and then lock the total (Manoeuvre) Δv, then when one slider is adjusted, the others auto adjust themselves in order to maintain a fixed total Δv?

It really feels like this would make my life a whole lot easier!

Hope that makes sense, and big thanks for an awesome mod

[scimas]

That would work for two dimensions, for example if your burn was only along tangent and binormal. How do you decide which one to change in three dimensions? If you adjust the normal component, should the mod auto adjust tangent or the binormal component to keep the total Δv constant?

I would say don't try to get the first manoeuvre perfect, you usually can't execute it to the predicted accuracy anyway. Rather make a manoeuvre that takes you close-ish to the planet and plan more manoeuvres along the way to fine tune it.

[RealTimeShepherd]

Well, I guess you could either lock one of the other dimensions, or split the cost between them, I'd be happy with either.

Personally, I find planning a Mars orbit and return mission from a single launch using RO/RSS and Principia to be so difficult in terms of carrying enough Δv, even with aerocapture, that I am keen to minimise any waste, so I will be spending 20 minutes crafting that burn to get the lowest possible PE on the target planet...

It is of course possible that I'm doing it entirely wrong!

[Eriksonn]

@eggrobinSo i think that i have finished my little mod for adding geopotentials to the stock system(or rather any system except RSS). It generates a single config file that links to the principia_gravity_model config that is used by principia for the RSS geopotentials. It generates up to degree 10, wich i think should be good enough, and as i am doing it for every body(everything is the default, although a whitelist is also an option) i dont want to have too high degree as i am not sure how performace intensive this operation is(i havent gotten any more lag than usual on max warp using this, so i think it is fine). In this image i am orbiting in a circular 15km orbit around minmus, but due to the hills and flats, the orbit gets destabelized, and eventually crashes into minmus.

Here is the same orbit from the side, to show that it also affects inclination.

It even works with modded planets/moons. This one has a very oblate shape, leading to a very high precession rate of about 40 degrees per orbit.

Now i think that i will make my own thread for this little mod when i am feeling done with it(should be soon i hope), and then i can make a link to it from here. I hope that it is ok for me to do this and if you want you can maybe mention my mod in a more direct way, so that others can see it. Becauce i think that having stock geopotentials is a very neat and exciting thing to be able to have. I hope that this sounds like an interesting concept. Tell me if you have any questions about anything.

[Delay]

I couldn't just add that to an already running career, right? The orbits would be very messed up.

Edited August 7, 2019 by Delay

[Eriksonn]

I think that you could add it to an existing one(it wont crash or anything), but then you have to be real quick to save some of your stuff depending on where they are.

On minmus for example, yes it gets messed up at 15km, but once you extend the orbit to 30km or so, it quickly gets stable again. So only very low orbits around very lumpy things will be at risk. So a low orbiting minmus sat might need fixing, but a space station around duna is probably safe. Even the mun is quite safe, becauce it isnt as lumpy as minmus, so a mun station is also probably good.

Edited August 7, 2019 by Eriksonn

[eggrobin]

28 minutes ago, Delay said:

I couldn't just add that to an already running career, right? The orbits would be very messed up.

This would have no effect: Principia creates the ephemeris (and the celestial bodies) when a new game is started, and never reads the configurations again.

[Delay]

10 minutes ago, eggrobin said:

This would have no effect: Principia creates the ephemeris (and the celestial bodies) when a new game is started, and never reads the configurations again.

But I guess I could make a new save, copy all spacecraft and science etc. there and adjust the orbits slightly to make them stable, right?

Just a hypothetical. I wouldn't want to change something in my save anyways.

[eggrobin]

On 8/3/2019 at 2:36 PM, Eriksonn said:

@eggrobin Over the past few days i have been making a mini mod thing for automatically generating the spherical harmonics needed to allow some of the stock bodies to have geopotentials.

This sounds cool; I would be interested in knowing how you generate that; computing the gravitational field from the shape of the body is not trivial, even making simplifying assumptions about internal structure.

Quote

One is that i dont know where to put this new file(i am calling it gravity_model_extension)

The best practice is to put the files of your mod in the directory of your mod (so GameData\NameOfYourMod\whatever.cfg).

Quote

 i have tried adding an @ to the of start principia_gravity_model, but that didnt work either

The @ thing is ModuleManager syntax.

This means that

1. you need to have ModuleManager (it can be redistributed with your mod, most mods that patch configs do that);
2. you need to look at the ModuleManager documentation to see what you want to do with that syntax (if I recall correctly, @principia_gravity_model:FOR[NameOfYourMod] should do the job, but I am no ModuleManager expert).

Quote

Two is does my file contain enough information as is or do i need more? (as i saw that the gravity_model file contained lots of other information like gravitational_parameter and reference_radius. Do i need that too, or am i good with what i have?)

The specification for these files can be found in https://github.com/mockingbirdnest/Principia/wiki/Principia-configuration-files (using the terminology from that page, you want sufficient principia_gravity_model configurations for the relevant bodies), which means that the gravitational_parameter and reference_radius are not required (the in-game gravitational parameter and radius will be used if they are omitted).

On 8/7/2019 at 11:19 PM, Eriksonn said:

 It generates up to degree 10, wich i think should be good enough, and as i am doing it for every body(everything is the default, although a whitelist is also an option) i dont want to have too high degree as i am not sure how performace intensive this operation is(i havent gotten any more lag than usual on max warp using this, so i think it is fine). 

We support up to degree and order 30; we have found that this was needed to accurately capture the behaviour of orbits around the Moon (the Moon is very lumpy). For the Earth, we only go to degree and order 10. You should probably inspect the coefficients that you generate and handwave a cutoff from that (if the coefficients remain very large at high degrees, go to high degrees, otherwise ignore higher degrees).

Note that we do have a cutoff in-game, so the higher degrees have more a limited range (and thus should only incur a computational cost where they matter).

Quote

In this image i am orbiting in a circular 15km orbit around minmus, but due to the hills and flats, the orbit gets destabelized, and eventually crashes into minmus.

Here is the same orbit from the side, to show that it also affects inclination.

It even works with modded planets/moons. This one has a very oblate shape, leading to a very high precession rate of about 40 degrees per orbit.

Again, this looks cool.

[Eriksonn]

On 8/10/2019 at 12:11 AM, eggrobin said:

The best practice is to put the files of your mod in the directory of your mod (so GameData\NameOfYourMod\whatever.cfg).

I already fixed the config files, otherwise i wouldnt be able to make take those screenshots. But i apparently forgot to edit that question.

On 8/10/2019 at 12:11 AM, eggrobin said:

This sounds cool; I would be interested in knowing how you generate that; computing the gravitational field from the shape of the body is not trivial, even making simplifying assumptions about internal structure.

I simply(the math wasnt simple...) get the terrain height for each latitude and longitude, and then use the "discrete inverse spherical harmonic equation" on the whole body to get the coefficents. This is the main code for this:

for (int i = 0; i < ResolutionWidth; i++)
{
    for (int j = 0; j < ResolutionWidth / 2; j++)
    {
      	  //get the longitude and latitude of the current point on the surface
          double Longitude = Math.PI * 2 * (i / (double)ResolutionWidth);
          double Latitude = Math.PI * 2 * (j / (double)ResolutionWidth);
		  //get the terrainheight from the center of the body, scaled by radius
          double CurrentRadius = 1+Body.TerrainAltitude((j*360.0 /ResolutionWidth) - 90, i * 360.0 / ResolutionWidth) / Body.Radius;
		  //a scaling factor that accounts for increased density of sample points close to the poles, and also for the total surface area of the body
          double AreaScale = (Math.Sin(Latitude)) / (ResolutionWidth * ResolutionWidth * Math.PI);
          for (int n = 0; n <= MaximumDegree; n++)
          {
             for (int m = 0; m <= n; m++)
              {
                 //save the total scaling factor so that i dont have to use it twice
               	 //(TODO)as both the P and Normalization functions contain factorial terms that gets messed up if MaximumDegree>10,
                 //i should "bake in" these functions into the for loops themselves, so that i can support higher degrees than 10
                 double Q = AreaScale * CurrentRadius * P(n, m, Latitude) * Normalization(n, m);
                 //I am using a precomputed lookup table for the cos() and sin() functions to be more performace friendly. 
                 //A little optimazaiton never hurts ;)
                 CosArray[n][m] += Q * CosTable[i, m];
                 SinArray[n][m] += Q * SinTable[i, m];
              }
          }
     }
}

On 8/10/2019 at 12:11 AM, eggrobin said:

You should probably inspect the coefficients that you generate and handwave a cutoff from that (if the coefficients remain very large at high degrees, go to high degrees, otherwise ignore higher degrees).

That is a good idea, as currently everything has the same degree. Once my mod can handle it, I will have to look at some higher degrees to see what the trend is. I am already ignoring Stars and planets like Jool as they have no surface and is perfectly round(interestingly though, my program did generate some low but noticable factors even for Jool, especially the n=2,m=0 cos factor was alot higher than any other factor for Jool, but still lower than any other body. It seems like the algorithms is biased to the poles for some reason, but the error went down significantly by adding more sample Points(default is now 200x100, but can be changed in the Settings.cfg))

 

On 8/10/2019 at 12:11 AM, eggrobin said:

Note that we do have a cutoff in-game, so the higher degrees have more a limited range (and thus should only incur a computational cost where they matter).

That sounds good, that (probably) means that I wont need to worry about giving geopotentials to too many things at once.

[scimas]

@Eriksonn As far as I understand, your mod is going to do its job only once (when its installed in a save). So it wouldn't be a problem if it did more computation than strictly necessary. Since you're facing the problem of different density of points near the poles vs near the equator, one easy (conceptually) solution would be to sample the points thrice. Once with the regular latitude, longitude (what you're already doing). The other two times use coordinate systems that are orthogonal to the original and each other. So the "north pole" would be at the original equator at 90 degrees separated longitudes. That should give you a good enough uniform sampling density, and then simply take the mean of the generated coefficients.

I think that should work, if I'm not making any mistake. Looking forward to the mod!

[eggrobin]

@Eriksson I have not checked the correctness of your code.

However, I believe that there is an issue with the general approach: what you are doing is computing a spherical harmonics expansion for the topography (the shape of the ground), rather than the gravitational field (the shape of would-be sea level). In other words, if you correctly compute that which you are trying to compute, you will end up with a gravity field such that the geoid and the topography are the same, i.e., where the ground is (locally) horizontal everywhere. This should not be the case (the sides of mountains are not horizontal, that's how things go downhill). Instead, the geoid tends to be smoother than the topography. For an illustration of this principle, see figure 1 of Franz Barthelmes (2013), Definition of functionals of the geopotential and their calculation from spherical harmonic models: theory and formulas used by the calculation service of the ICGEM.

Further, something about the numbers you list in your earlier post give me pause.

On 8/3/2019 at 2:36 PM, Eriksonn said:

@eggrobin

principia_gravity_model
{
	Body
	{
		Name = Minmus
		geopotential_row
		{
			degree = 1
			geopotential_column
			{
				order = 0
				cos = 2.01267793181124960E-004
				sin = 0.00000000000000000E+000
			}
			geopotential_column
			{
				order = 1
				cos = -1.67248927462036320E-003
				sin = 2.96599647369928530E-003
			}
		}
		geopotential_row
		{
			degree = 2
			geopotential_column
			{
				order = 0
				cos = 8.05394019210287260E-003
				sin = 0.00000000000000000E+000
			}
			geopotential_column
			{
				order = 1
				cos = -2.80339441217786760E-003
				sin = 1.38156354030291020E-003
			}
			geopotential_column
			{
				order = 2
				cos = -5.70133104974222470E-003
				sin = 3.12729158537247910E-003
			}
		}
        ...up to degree 10...

 

You have coefficients for degree 1. These correspond to a translation of the geoid; if the geopotential is computed around the centre of mass, they are 0; Principia makes the assumption that they are, and ignores them. However, in your case, they are not only nonzero, but they are fairly large (about the same order of magnitude as, say, C₂₂); this indicates that, if your calculations are correct, you are computing the spherical harmonics with respect to something fairly far from the centre.

Note that Principia also ignores degree 2, order 1, as, for bodies whose axis of figure is close to the axis of rotation (which is most often the case), these coefficients are tiny. This may not be the case for arbitrary planets. Note that if it is not the case, it is possible that the rotation of the planet would be chaotic.

[Eriksonn]

Just now, scimas said:

As far as I understand, your mod is going to do its job only once (when its installed in a save)

It actually has nothing to do with saves, it generates one single config file that then works on any save. I have put a small boolean variable in the settings file if one wants to re-run it as it needs to be re-run if the solar system changes(Becauce of planet packs and the like)

 

2 minutes ago, scimas said:

Since you're facing the problem of different density of points near the poles vs near the equator

I sortof fixed that by simply increasing the density of my sample points, so now that problem is negligable compared to the "usual" values that occur simply by the lumpyness of the planet/moon itself. (the "problem" is now about 10 times smaller than what the other values usually are)

[Eriksonn]

@eggrobin Hmm, so you are saying that having the geoid be equal to the terrain height is a bad approximation for a constant-density body? I will take a look at that link you gave and see if i can find something interesting.

About the coefficients, I already guessed that the degree 1 coefficients were not useful as they would make the body have a center of mass that is not aligned to its rotation axis, and that makes no sense. So I have
 already removed degree 1 from my config output.(the one about Minmus that you referenced is abit outdated) That degree 2, order 1, I did not know was problematic, but i guess that i can remove that one too, if principia dont care about it either. (Although it would be interesting to know why it is problematic/doesnt matter)

29 minutes ago, eggrobin said:

this indicates that, if your calculations are correct, you are computing the spherical harmonics with respect to something fairly far from the centre.

I am just using the Body.TerrainAltitude() function to get my terrain height, and i would strongly guess that for most bodies their center of mass is not necceraily aligned with their "origin" as the game sees it. As I have already removed the degree 1 component, I am not sure how much of a problem that is.

Edited August 11, 2019 by Eriksonn

[eggrobin]

Quote

@eggrobin Hmm, so you are saying that having the geoid be equal to the terrain height is a bad approximation for a constant-density body?

Indeed: if the geoid is equal to the terrain height, there is no such thing as downhill (everything is horizontal), which should intuitively be pretty disturbing when you are standing on the slopes of Minmus.

As an extreme example, consider a cube of uniform density; figure 1 of Chappell, Iqbal, and Abbott (2012), The gravitational field of a cube, shows the shape of a lake on one of the faces of the cube (lakes, being fluid, lie on an isopotential).

Note that the shape of the lake (and thus the geoid) resembles a sphere far more than the face of the cube, whose corners are mountains.

Edited August 11, 2019 by eggrobin