[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

[pleroy]

We were on vacation, this is a bulk reply to the thread regarding the ephemeris.

On 7/17/2018 at 10:45 AM, Dolin said:

In other words, does principia, at any point, neglect the influence of ships on planets and therefore shave off some computations?

Yes, we neglect the acceleration exerted by vessels on celestials and on other vessels.  It does save a lot of computations.  It's not as small as @Teilnehmer believes, even though the vessels can be 10^15 times lighter than the celestials, because vessels can be very close to each other (so the 1/r^2 factor matters).

Note that saving the state of the celestials to a file would be much slower than just recomputing the whole thing.  We are able to integrate about 3 million seconds/second, and as @scimas mentioned the file would be huge.  Just say no to disk I/O.

On 7/27/2018 at 11:36 AM, Dolin said:

I'm using RSS with a ton of mods and I see a noticeable difference in performance with and without Principia.

We'd be interested to know more about this.  We have not observed noticeable differences in performance ourselves except at very large warp factors or at very large distance from the Sun.  If you could open an issue on GitHub with details that help reproduce the problem, that would be great.

On 7/27/2018 at 2:01 PM, Johould said:

That's the ephemeris occasionally mentioned in the changelog. I don't know the exact time range or storage, but the motion of celestials is precomputed.

Right.  The ephemeris is used to (lazily) compute the trajectories of the celestials, and the trajectories of the vessels are then computed in the resulting gravitational field.

On 7/27/2018 at 9:40 PM, scimas said:

I'm not completely sure about this, but I think I remember it mentioned sometime that celestials do ignore vessel influence. Although I can't think why that would be; you are anyway computing the force on a vessel due to a celestial, the force on the celestial is just the negative of the one on the vessel..

That would defeat the purpose of the ephemeris, which is to determine once and for all the gravitational field in time and space, and then to integrate the vessels in that field.  So the two forces that you mention are computed in two completely separate steps, and possibly at different points in time.  As an implementation detail, the mass of the vessels is taken to be exactly 0 in the ephemeris so the forces are not helpful, what we need are the accelerations.

On 7/27/2018 at 9:51 PM, Johould said:

Huh, where do interpolation schemes come in? Is that just interpolation within a single time step? Sets of coefficients for polynomial interpretation is how NASA releases projected positions in the real solar system, I thought they were a bit more related.

To be a bit more specific (for RSS):

• we start from the positions and velocities, derived from JPL data, for all the celestials at a fixed point in time (1950-01-01);
• we integrate this configuration forward in time with a Quinlan-Tremaine symmetric linear multistep 12th order integrator and a time step of 10 minutes;
• for each celestial, we compute polynomials of degree between 3 and 15 to approximate the positions and velocities over 8 points (80 minutes) to 1 mm; these polynomials are constructed in the Чебышёв basis for accuracy and evaluated in the monomial basis for performance;
• when we need to compute the trajectory of a vessel, we use these interpolating polynomials to compute the position of each celestial.

[scimas]

4 hours ago, pleroy said:

That would defeat the purpose of the ephemeris, which is to determine once and for all the gravitational field in time and space, and then to integrate the vessels in that field. 

Hmm, I should read up on this. I have definitely misunderstood the concept. 

[dafidge9898]

Am I doing something wrong with maneuvers/flight planning? I plotted a 50 minute long maneuver, but when I actually executed it, it did not get me in the desired orbit. I started the burn when it told me to, then I shut off the engines after waiting the specified burn time. Here is a picture from the map view just after engine cutoff: https://imgur.com/a/JTfUmdX

I also noticed when plotting maneuvers that if RCS is on, even if active engine is selected, the flight planner still only plots the maneuver assuming the RCS thrusters are doing the work. This does not seem to be the problem in my case, seeing as with RCS on, the length of burn is approximately 1000 seconds, as opposed to 3000 seconds. 

Thank you for any help! 

 

Edit: Added information

Edited August 2, 2018 by dafidge9898

[nanomage]

23 minutes ago, dafidge9898 said:

Am I doing something wrong with maneuvers/flight planning? I plotted a 50 minute long maneuver, but when I actually executed it, it did not get me in the desired orbit. I started the burn when it told me to, then I shut off the engines after waiting the specified burn time. Here is a picture from the map view just after engine cutoff: https://imgur.com/a/JTfUmdX

I also noticed when plotting maneuvers that if RCS is on, even if active engine is selected, the flight planner still only plots the maneuver assuming the RCS thrusters are doing the work. This does not seem to be the problem in my case, seeing as with RCS on, the length of burn is approximately 1000 seconds, as opposed to 3000 seconds. 

Thank you for any help! 

 

Edit: Added information

the only idea that comes to mind is that you probably have to keep the principia gui open for it to continuously update the maneuvre marker position throughout the burn (because the burn is defined in a different frame from your navball if i understand correctly).

[scimas]

17 hours ago, dafidge9898 said:

 

Yup, agree with @nanomage. Looks like you were doing plane change burn, but didn't keep the flight planner window opened. That leads to the maneuver direction not changing during the burn.

Another cause could be that you executed a decoupling staging or enbled / disabled engines after making the flight plan. That messes up the calculations too. 

[topaxi]

Hey Guys,

 

Weird issue. I'm using Principia and a bunch of other mods. The main ones are FAR and  Kopernicus with the 3.2 rescale. I'm having this problem where, if I have Principia installed, a large plane I have won't take off. In fact it seems to just fall apart after leaving the runway. It doesn't hit anything, the wings just fall off. I've done A/B tests with various mods, and it only starts working if I get rid of Principia. Have the aerodynamics or sea level gravity been altered at all?

[MaltYebisu]

@topaxi

It is usually a good idea to upload the log file and save file to a free file sharing site like Dropbox to make it easier for people to find and reproduce the bugs one is experiencing. Please see How to get support for details on finding the log file. It is different depending on your system. 

 

A list of all the mods with version numbers might also make the troubleshooting process a lot faster. It might be really tedious to write down 90+ mods, but it saves the people trying to help you a lot of headaches. 

[dafidge9898]

On 8/1/2018 at 6:19 PM, nanomage said:

the only idea that comes to mind is that you probably have to keep the principia gui open for it to continuously update the maneuvre marker position throughout the burn (because the burn is defined in a different frame from your navball if i understand correctly).

That's one thing, it kind of just disappears after 20 minutes. The flight plan window is still open, but the actual maneuver information is gone. 

[Antstar]

So, I gave this a try maybe a year ago. I absolutely loved the concept, but found the maneuver planner pretty darn impossible to use. The slider was rather terrible for some things (the time IIRC) and desperately needed an additional way to just put in a numerical value.

There was also an issue with interplanetary transfers where I needed to set the integration intervals to like 1m for around planets (the starting one in particular), obviously not needed for interplanetary space, but then when I tried to extend this to see  where I would end up, it would eat 64GB of memory and blue screen the computer.
 

Rather than reading 12 months of release notes, just wanted to know if these have been sorted yet? Thanks heaps

Edited August 9, 2018 by Antstar

[pleroy]

 

23 hours ago, Antstar said:

So, I gave this a try maybe a year ago. I absolutely loved the concept, but found the maneuver planner pretty darn impossible to use. The slider was rather terrible for some things (the time IIRC) and desperately needed an additional way to just put in a numerical value.

There was also an issue with interplanetary transfers where I needed to set the integration intervals to like 1m for around planets (the starting one in particular), obviously not needed for interplanetary space, but then when I tried to extend this to see  where I would end up, it would eat 64GB of memory and blue screen the computer.

The UI has not changed substantially.

There have been a number of improvements and fixes regarding memory usage, but it's hard to tell if it has anything to do with what you observed: if you don't submit bug reports, there is no guarantee that bugs will get fixed.

[Johould]

How do you test integrators? Looking for a bit of background on integrators I found this article, which included a point I hadn't seen before: Most notionally symplectic integration schemes are only exactly symplectic in infinite precision, and otherwise have an error floor no better than random accumulation of roundoff errors (with an aside about "symplectic lattice" integrators), or far worse if rounoff errors are biased.

That's only relevant if you want answers better than about your numeric precision times the square root of the number of timesteps.

IAS15: A fast, adaptive, high-order integrator for gravitational dynamics, accurate to machine precision over a billion orbits

Abstract:

Spoiler

We present IAS15, a 15th-order integrator to simulate gravitational dynamics. The integrator is based on a Gauß-Radau quadrature and can handle conservative as well as non-conservative forces. We develop a step-size control that can automatically choose an optimal timestep. The algorithm can handle close encounters and high-eccentricity orbits. The systematic errors are kept well below machine precision and long-term orbit integrations over 10⁹ orbits show that IAS15 is optimal in the sense that it follows Brouwer's law, i.e. the energy error behaves like a random walk. Our tests show that IAS15 is superior to a mixed-variable symplectic integrator (MVS) and other popular integrators, including high-order ones, in both speed and accuracy. In fact, IAS15 preserves the symplecticity of Hamiltonian systems better than the commonly-used nominally symplectic integrators to which we compared it.
We provide an open-source implementation of IAS15. The package comes with several easy-to-extend examples involving resonant planetary systems, Kozai-Lidov cycles, close encounters, radiation pressure, quadrupole moment, and generic damping functions that can, among other things, be used to simulate planet-disc interactions. Other non-conservative forces can be added easily.

They designed an integrator around a non-symplectic scheme chosen so systematic error should be far below machine precision and then implemented it with much care to limiting roundoff error and avoiding biased roundoff. Without relying on a symplectic design, they felt free to include an adaptive stepsize and can support non-conservative forces like radiation pressure.

Looks pretty interesting, but perhaps higher precision and longer timescales than you want?

I also realized another thing while reading that, from their discussion of dynamic timesteps. If you need to set  a timestep to get 100 or so samples per Mun orbit, that's already much smaller than it would take to get 100 timesteps per Moho orbit. I found a few papers on multiscale integrators, but it seems like using multiple timesteps for gravitational problems is still pretty experimental.

Edited August 10, 2018 by Johould

[eggrobin]

For the new moon (lunation number 230), the new release (Desargues) is out.

No new features in this version beyond the 1.4.5 upgrade, as we have been on vacation.

 See the change log for more details.

 We support two versions of KSP: downloads are available for 1.4.5 and 1.3.1. Make sure you download the right one (if you don't, the game will crash on load).

[eggrobin]

On 8/11/2018 at 12:44 AM, Johould said:

How do you test integrators?

The first level of testing is obviously to check them on systems that can be exactly integrated, such as the harmonic oscillator.  The second level of testing is to try to replicate astronomical phenomena: Lunar eclipses, precession of the perihelion of Mercury, Молния orbits, evolution of the solar system.  The latter quickly runs into modelling errors, not integration errors: for instance: we get Phobos and Deimos wrong because we do not model the spherical harmonics of Mars (we plan to work on this soon-ish).

Beyond this, we program very defensively so bugs in the integrators will occasionally be detected as inconsistencies: see #1606 and #1867 for example of very subtle bugs that were caused by loss of accuracy in internal computations.

Quote

IAS15: A fast, adaptive, high-order integrator for gravitational dynamics, accurate to machine precision over a billion orbits

IAS15, the integrator whose claim to fame was to integrate the Tesla roadster. (https://arxiv.org/pdf/1802.04718.pdf).

What this integrator ultimately claims is that it has an unbiased one-step error approaching machine precision. However, in a system with positive Ляпунов exponent, this does not mean that the error behaves like a random walk in the long term; instead, small errors on one step get amplified even by exact evolution. This can be disregarded when the system has a very low Ляпунов exponent, which is the case of the outer planets used in their numerical experiments (see Batygin and Laughlin 2008, “On the Dynamical Stability of the Solar System”: ‘the outer solar system […] showed no sign of instability during the course of 24 Gyr’).

However, for a system that is expected to remain in a chaotic state for a long time, e.g., weakly-bound orbits, the amplification of the errors means that the actual error quickly becomes very large compared to machine precision. In that case, it is beneficial to use symplectic methods and long time steps, so as to minimize the accumulation of rounding errors (which occur per time step) and have physically plausible behaviour on the long run; See Hoover and Hoover 2015, “Comparison of Very Smooth Cell-Model Trajectories Using Five Symplectic and Two Runge-Kutta Integrators”:

Quote

Recently Hanno Rein and David Siegel developed and implemented a relatively complicated fifteenth-order integrator for gravitational problems with the provocative title “A Fast, Adaptive, High-Order Integrator for Gravitational Dynamics, Accurate to Machine Precision Over a Billion Orbits”. Evidently this integrator is not at all intended for long-time applications to chaotic problems, where errors grow exponentially with time.

Further, IAS15 does not offer a precision-cost tradeoff in the form of a tolerance or a stepsize choice: it has only one setting of “one-step error near machine precision”, see figure 7 of the IAS15 paper where it appears as a single point on the error(work) graph, instead of an error(work) function. This means that it is unsuitable in cases where one can tolerate lower precision but is constrained by performance.

Note that the claims of unbiased one-step error for IAS15 (section 3.3) do not come with a formal proof, and it is not clear why the same reasoning wouldn’t apply to many high-order methods, including the high-order symplectic or conjugate-symplectic methods that Principia supports, with the (kinetic + potential) splitting of the Hamiltonian, as opposed to the Wisdom-Holman (Keplerian + interaction) splitting. When formal results regarding the effect of rounding error are needed, it is necessary to track their amplification, rather than just the one-step error. This can be done using “coffins” in interval arithmetic, or with Kahan’s ellipsoids, and provides a formal bound (albeit often a poor one) on the true solution of the differential equation. Of course, these bounds do not take any model error into account, so the applicability to astronomy and astrodynamics is limited.

That being said, IAS15 seems to be a fairly effective high-accuracy integrator; it is popular in cases where occasional close encounters are expected and high accuracy is desirable, e.g., Silsbee and Tremaine 2018, “Producing Distant Planets by Mutual Scattering of Planetary Embryos”, as an alternative to Bulirsch-Stoer and the like, as a large-step symplectic method would yield entirely inaccurate results (although qualitatively similar thanks to the symplectic property) after a close encounter.

An alternative to this high-accuracy approach for close encounters is the hybrid symplectic method found in Chambers 1999, “A hybrid symplectic integrator that permits close encounters between massive bodies”, where a symplectic integrator is used most of the time, and one switches to a Bulirsch-Stoer method to handle close encounters with high accuracy. This method is implemented in Chambers’s own MERCURY package (whose manual mentions @illectro).

In conclusion, Hernandez 2016, “Fast and reliable symplectic integration for planetary system N-body problems” has this to say about the applicability of high-order high-accuracy nonsymplectic methods such as IAS15:

Quote

[…] a high order code like IAS15 may be most useful if both the time scale is shorter than a Lyapunov time and if extreme accuracy is needed, while a lower-order symplectic method may be favored in other cases. Even under the conditions of high accuracy and short times, a low order symplectic is reliable: we note that the errors of a symplectic method are deceptive. The errors can often be reduced to the machine precision level by applying a symplectic corrector […].

 

Quote

can support non-conservative forces like radiation pressure.

It is hard to be excited about radiation pressure on celestials in KSP ;-) See Chandler 1973, “Determination of the dynamical properties of the Jovian system by numerical analysis”, p. 69, table 5.  For vessels they could be useful (think of K2) but then vessels need non-conservative forces anyway because of the engines.

Quote

I found a few papers on multiscale integrators, but it seems like using multiple timesteps for gravitational problems is still pretty experimental.

We spent a lot of time looking at multiscale integrators.  They are not always cheap to implement (some require the computation of Jacobians) and they are generally not of high order (most of them are leapfrog-based).  More importantly they don’t produce dense output: you only get an exact output point for all the bodies at the lowest frequency of the multiscale system. So for instance if your slower integrator gets 100 points for an orbit of Pluto, you only get an exact point for the entire solar system every 2.5 years.  Not exactly useful for going to the Moon.

Edited August 12, 2018 by eggrobin
typo

[Teilnehmer]

On 8/10/2018 at 3:00 AM, Antstar said:

The slider was rather terrible for some things (the time IIRC) and desperately needed an additional way to just put in a numerical value

I already started to implement a new UI for Principia where I intended to use numeric fields with up-downs for different orders of magnitude instead of (or alongside) the sliders. I don’t have much free time now, so the development is suspended.

On 8/11/2018 at 11:30 PM, eggrobin said:

precession of the perihelion of Mercury

Wow. Does Principia simulate general relativity? Or you mean the Newtonian precession component only?

[Johould]

On 8/11/2018 at 11:30 AM, eggrobin said:

However, for a system that is expected to remain in a chaotic state for a long time, e.g., weakly-bound orbits, the amplification of the errors means that the actual error quickly becomes very large compared to machine precision. In that case, it is beneficial to use symplectic methods and long time steps, so as to minimize the accumulation of rounding errors (which occur per time step) and have physically plausible behaviour on the long run; See Hoover and Hoover 2015, “Comparison of Very Smooth Cell-Model Trajectories Using Five Symplectic and Two Runge-Kutta Integrators”:@illectro).

I thought their main point was that when the Ляпуно́в exponent costs you a bit in a relatively short time neither symplecticity nor high order are worth anything compared to higher precision numbers. Lower-order symplectic methods seemed to be a suggestions specifically for the case where you decide you don't actually care about accurate trajectories and just want statistical behavior (or go to leapfrog in quadruple precision). I don't see why getting physically reasonable samples out of an integrator would imply that the samples can be interpolated to give physically reasonable trajectories - a symplectic integrator might preserve energy just fine with a sample every two or three orbits.

On 8/11/2018 at 11:30 AM, eggrobin said:

We spent a lot of time looking at multiscale integrators.  They are not always cheap to implement (some require the computation of Jacobians) and they are generally not of high order (most of them are leapfrog-based).  More importantly they don’t produce dense output: you only get an exact output point for all the bodies at the lowest frequency of the multiscale system. So for instance if your slower integrator gets 100 points for an orbit of Pluto, you only get an exact point for the entire solar system every 2.5 years.  Not exactly useful for going to the Moon.

I haven't see that explicitly addressed in integrator designs, but it seems like a similar interpolation problem from going to ~10 minute steps in the integration of celestials to a per-frame updates on a vessel. 2.5 years : 10 minutes is a bit smaller ratio than 10 minutes : 1/60 sec. I would guess an interpolation scheme could probably be extracted from the way a multiscale integrator includes the effect of the slow-moving variables when making the faster updates, if an integrator otherwise looked good.

[eggrobin]

5 hours ago, Johould said:

I thought their main point was that when the Ляпуно́в exponent costs you a bit in a relatively short time neither symplecticity nor high order are worth anything compared to higher precision numbers.

They certainly don’t claim that high order is worthless, indeed they use it to achieve their low one-step error at a reasonable cost. As for symplecticity, you see a use for it yourself:

Quote

Lower-order symplectic methods seemed to be a suggestions specifically for the case where you decide you don’t actually care about accurate trajectories and just want statistical behavior (or go to leapfrog in quadruple precision).

In general, when it comes to the use of symplecticity and whether accuracy is preferable, this depends on your application. You have seen that it is essential for statistical studies.

If you are tracking an object, and your goal is “the most accurate prediction you can get for this particular trajectory”, and you have a separate way to keep track of chaos to say “from this point on, the prediction is worthless given the uncertainty in the initial state” (note that the uncertainty in the initial state will likely be much larger than machine precision, so you can likely get away with a less-precise method), then you want a high-accuracy integrator. However, you will eventually have to give up, even if you had a magical exact integrator, as the initial uncertainty will eventually swamp everything. For instance, in our modified “retrobop” Jool system, an initial uncertainty of 1 mm results in complete dephasing within 10 years.

Usually, for high-accuracy solar system ephemerides that you use to fly a spacecraft (e.g., the JPL planetary ephemerides), you would go for a high-accuracy method. As always, the errors from the model dominate those from the method, but similar tradeoffs exist in the model: in the case of the JPL ephemerides DE430 and DE431, the former has a model that improves accuracy near the present, but make it valid for a shorter time, whereas the latter is less accurate but valid for a longer time.

In our case, we can’t just give up on your vessel because it has been flying around for too long, nor give up on having the Jool system because it’s been five years.

If we trust a nonsymplectic evolution over long time scales, your vessel (or your celestials) might end up doing something visibly unphysical (gaining or losing energy). On the other hand, if a particular chaotic encounter is inaccurately simulated, this is virtually invisible (indeed, chaos helps in making inaccuracy irrelevant, as a small initial perturbation may result in a change much larger than the error). It is therefore appropriate, for physical verisimilitude, to favour preserving global properties over accuracy on close encounters.

Again, look at the recommendations from Hernandez 2016:

• we can’t limit ourselves to a Ляпунов time (for some vessels and for the Jool system, that will be short); we have to keep your vessels and planets flying, and they shouldn’t do visibly unphysical things on the long run;
• we do not need very high accuracy, only physical verisimilitude;
• we have a performance constraint: there can be hundreds of vessels and debris flying around, and we can’t slow the game to a crawl during timewarp.

Quote

I don't see why getting physically reasonable samples out of an integrator would imply that the samples can be interpolated to give physically reasonable trajectories - a symplectic integrator might preserve energy just fine with a sample every two or three orbits.

Since we do care somewhat about accuracy, we choose our integrator and its parameters to get tolerable errors (2.3 m over a year on Miranda for the Solar System with a 12th order method by Quinlan and Tremaine and a timestep of 10 min, 111 m over a year on Laythe for the KSP system with a 6th order method by Blanes and Moan and a timestep of 35 min), and this results in a timestep that is at least an order of magnitude below the duration of the orbits.

Quote

it seems like a similar interpolation problem from going to ~10 minute steps in the integration of celestials to a per-frame updates on a vessel. 2.5 years : 10 minutes is a bit smaller ratio than 10 minutes : 1/60 sec.

These are very different situations: in 10 min the celestials will follow fairly simple arcs that will be easily approximated by low-order polynomials; over 2.5 years, the celestials have a lot of high-frequency motion (many will orbit much faster), and that is lost to Nyquist’s theorem.

Quote

I would guess an interpolation scheme could probably be extracted from the way a multiscale integrator includes the effect of the slow-moving variables when making the faster updates, if an integrator otherwise looked good.

We don’t know how to extract anything useful from the state of the system between the nested evolution operators (all those methods work in a similar way, e.g., Saha and Tremaine 1994, “Long-term planetary integration with individual time steps”).

Edited August 13, 2018 by eggrobin

[Damien212]

Has anyone got any transfer window planning resources that work well with Principia? I've noticed that many of the standard KSP transfer window planners suffer from increasing inaccuracy the further from the epoch you are because of the discrepancy between the patched conics approximation and the RL body positions.

I figured that some RL resources might help but it seems like many only work from the year 2000 onwards. For an RSS/RO game that starts in 1950 this is no good. This site (http://clowder.net/hop/railroad/sched.html) and spreadsheet suffers from the same problem (http://clowder.net/hop/railroad/Hohmann.xls).

The ephemerides information clearly exists (https://ssd.jpl.nasa.gov/?planet_eph_export) but I don't know enough to make that information usable.

Edit: I've also been trying to learn to use GMAT but it's starting to feel like learning theoretical physics to be able to throw a ball. Great tool but super complex.

 

Edited August 22, 2018 by Damien212
fixed links

[Tonas1997]

As someone who is eager to try Principia on a RSS install, I have a couple of questions (and one suggestion):

1- Is the mod compatible with Trajectories? That is, will the projected trajectory in atmospheric flight be drawn correctly?

2- Since the orbital mechanics are overhauled by the mod, do contracts that depend on precise orbital insertion still work? Let's say a contract requires me to place a satellite on a (e.g.) 500km x 300km orbit, with an inclination of 70º. Do you know if the contract system will register and accept the parameters of a Principia orbit?

3- While transfer planners won't be pinpoint accurate when it comes to transfer windows anymore, can they still be used to obtain a reasonably accurate launch window?

__________________________________________________________________________________________________________________________________________

As for the suggestion, please note I'm not exactly an expert when it comes to KSP modding, so I apologize in advance if this comes across as naive and/or too hard to implement, but bear with me:

One of the most off-putting things about n-body physics is, in my opinion, the amount of station-keeping that is required to keep satellites, stations and relays on a particular orbit. IRL, this isn't much of an issue; those missions are, at any given point, being managed by dedicated teams that ensure orbital stability, and thus are able to plan and execute adjusting manoeuvres accordingly.

In KSP, not so much. A standard career mode will have dozens - if not hundreds! - of simultaneous satellites orbiting Earth, the Moon and so on. Making sure those missions keep a stable orbit would be too cumbersome, since cycling through every active mission gets boring pretty quickly.

In that respect, what about implementing a system similar to what Orbital Decay does? Basically, there's an option to "lock" a vessel (put its trajectory on rails) at the expense of RCS fuel, just like orbiting satellites do in real life. Eventually, fuel runs out and said satellite would begin drifting away from its intended orbit, but not before fulfilling its designed lifetime!

While this wouldn't make sense for some trajectories, like interplanetary injections, those that return to the same spot periodically within a reasonable margin - and thus can be considered orbits - could allow for background station-keeping (and considerable savings in calculations!). Nevertheless, I suspect implementing such a system would be a harrowing job, given how different the concept of trajectory is between patched-conics and n-body simulations. Just wanted to leave some food for though

Edited August 23, 2018 by Tonas1997
A cool horizontal line dividing the post in two halves

[Johould]

1 hour ago, Tonas1997 said:

2- Since the orbital mechanics are overhauled by the mod, do contracts that depend on precise orbital insertion still work? Let's say a contract requires me to place a satellite on a (e.g.) 500km x 300km orbit, with an inclination of 70º. Do you know if the contract system will register and accept the parameters of a Principia orbit?

For that you are sort of out of luck. Previous discussion in the thread says you can complete the contract only if the current stock prediction matches the target orbit.

[Tonas1997]

3 minutes ago, Johould said:

For that you are sort of out of luck. Previous discussion in the thread says you can complete the contract only if the current stock prediction matches the target orbit.

Hmm, I see. But considering most contract orbits can be reasonably approached in Principia (meaning it's fairly easy to achieve a quasi-stable orbit in LEO/MEO/GEO), and that the contracts are quite forgivable when it comes to target vs. current parameters, shouldn't be much of an issue.

[scimas]

1 hour ago, Tonas1997 said:

2- Since the orbital mechanics are overhauled by the mod, do contracts that depend on precise orbital insertion still work? Let's say a contract requires me to place a satellite on a (e.g.) 500km x 300km orbit, with an inclination of 70º. Do you know if the contract system will register and accept the parameters of a Principia orbit?

That doesn't work as you would expect. The orbit calculated by principia isn't exposed outside the mod. So the contract system just checks everything against the stock orbits. And that means that sometimes, even though your principia drawn orbit looks exactly like the one you need, the stock orbit is very different and the contract isn't fulfilled. This is usually only a problem in high orbit, not in low orbits where patched conics and n-body are more or less identical.

2 hours ago, Tonas1997 said:

(and considerable savings in calculations!)

Check out principia's faq. It turns out that n-body calculations is sometimes easier on your cpu than patched conics calculations. The faq talks about orbits of planets, not vessels, so I'm not sure whether the same argument applies or not.

[Tonas1997]

7 minutes ago, scimas said:

That doesn't work as you would expect. The orbit calculated by principia isn't exposed outside the mod. So the contract system just checks everything against the stock orbits. And that means that sometimes, even though your principia drawn orbit looks exactly like the one you need, the stock orbit is very different and the contract isn't fulfilled. This is usually only a problem in high orbit, not in low orbits where patched conics and n-body are more or less identical.

Yeah, I guess that only becomes a major problem once the vessel gets too close to another orbiting body, like the Moon. Most LEO/MEO satellites would take years to have their orbits significantly changed, and you're not required to hold it stable for long (I think 2 minutes max) sooo...

Contracts evolving heliocentric orbits can be a bit more challenging though

[hypervelocity]

@Tonas1997 1- Yes; 3- Yes

[lawndart]

One thing you learn quickly with Principia is Satellite Contracts around moons? - just say no.

[Tonas1997]

Thanks for the answers, I'm extremely inclined to trying this out on a career mode

As for that "station-keeping" feature, could it theoretically be implemented?