Are patched conics (and by induction, KSP) "useless" for simulating ion propulsion?

Question

My previous KSP question What can the KSP game actually teach about spaceflight and orbital mechanics, and what are its limitations? resulted in some really productive discussions and under-the-hood exploration of the KSP game and its utility for learning orbital mechanics, as well as seven excellent answers and almost seventy surviving comments.

In the spirit of full disclosure, I'm allergic to both any computer language with curly braces, and to patched conics. Ironically, I did once have an allergic reaction to Space Food Sticks as well, but I've never had the opportunity to see if I still have that allergy today. I don't think my question is biased or leading in any way, but instead will hopefully lead to some thoughtful as well as scientifically correct answers.

Answers to Going from LEO to lunar using only low-thrust ion propulsion - can it be done? include the SMART-1 spacecraft with

a nominal thrust of 68 mN, hence an acceleration of 0.2 mm/s² or 0.7 m/s per hour

and another example of a spacecraft that uses ion propulsion for orbital maneuvers and moving from orbit around one body to that of another is the Dawn Spacecraft currently orbiting Ceres:

With the propellant it carries, Dawn can perform a velocity change of more than 10 km/s over the course of its mission, far more than any previous spacecraft achieved with onboard propellant after separation from its launch rocket. However, the thrust is very gentle; it would take four days at full throttle to accelerate Dawn from zero to sixty miles per hour (96 km / hour).

The simplest implementation of patched conics assumes instantaneous impulse maneuvers, rather than days or weeks or even longer periods of very low, continuous thrust.

Question: So for simulated travel from orbit around one body to orbit around another, are patched conics (and by induction, KSP) "useless" for simulating ion propulsion?

If so, then is there in fact any scenario for which it is not (useless for simulating ion propulsion)?

For the purposes of this question, "simulate" is distinct from "animate". I'm more interested in how well the trajectory of a patched conics calculation matches reality rather than if KSP would provide a convenient viewing venue.

Mark's comment that 'KSP doesn't do patched conics for vehicles under acceleration' may be highly relevant to the "by induction" aspect of the question if this applies to the ion engine propulsion.

Answer 1

You are kind of having an XY-problem in the sense that you are asking the wrong question.

Patched conics applies to vehicles moving under the influence of gravity and only gravity. Patched conics simply does not deal with vehicles under acceleration (or any other non-gravity force).

Therefore yes, you can obviously not use patched conics to predict the orbit of a vessel under acceleration, not without some other form of numeric integration for the duration of the burn. You can apply it before and after, but not during the burn.

The way KSP solves this is by simply numerically advancing the game state during the burn. In KSP, a vessel can be in one of two modes - it can either be "on rails", or in "physics mode". When a vessel is "on rails", patched conics is used to determine how the orbit propagates.

Obviously, there are rules for when the game can put a vessel "on rails", and one of them is that it can not be under acceleration, for the reasons explained above.

So the actual question you are asking is whether or not the physics engine KSP uses - which is the physics engine Unity uses (the game engine KSP is written in) is accurate enough for it.

Unity uses PhysX. PhysX is designed as a gaming engine, running at 60FPS. It is not meant as a scientific accurate simulation engine. It does not use numerically stable integrators, the way KSP re-parents the reference frame is not numerically stable, especially not over the course of days, floating-point errors will add up over those time scales and other problems, like small violations of conservation of energy will add up.

In short: It might even be possible to get a flight path somewhat close to what would be reality, but if you need really precise numbers, you should use a proper math/astrodynamic library that was designed for this and doesn't need to run for multiple days to simulate the burn.

The general principles are all correct, but KSP simply isn't concerned with the small nuances of floating-point precision errors, or absolutely strict observance of conservation laws, or even numerically stable integration.

You can learn a great deal about ion drives with KSP. You can learn that Hohmann transfers do not really work with them, and that you need to plan trajectories quite differently then when using a higher thrust engine, but that using them comes with extremely high delta-v.

With regards to the comments: As said before, PhysX runs on 60FPS. KSP will take the orbital state vectors after each frame, calculate all needed parameters for the patched conics approximation and give you an updated trajectory. However, KSP will only deliver the trajectory as if the vessel would not continue to accelerate. It is an instantaneous snapshot of the vessels current state. KSP supports modding, and mods have already replaced the stock system with a complete n-body simulation. This mod is called Principia. So it might completely be possible to include trajectory predictions for long burns in KSP with a mod, but that is simply not something the stock game deals with.

Answer 2

A more in-depth error analysis would be needed, but I think you can keep the patched conics assumption (that is: consider only one main attractor in any given moment) and at the same time apply a continuous thrust that renders the orbit non Keplerian. For the case of interplanetary orbits, most of the trajectory will be in the Sun sphere of influence, so if the thrust forces are significantly bigger than the attraction of the planets, you would still make a good approximation.

_{BTW, talking about curly braces...}

Answer 3

I'm going to answer the question "Is KSP (as an example of an application with patched conics) useless for simulating ion propulsion?

With the answer being - not entirely.

What KSP will teach you (if you stick to reasonable spacecraft) is that ion propulsion requires different sorts of maneuvers to those of higher-thrust spacecraft. Continuous thrust is indeed the way to go, as fuel efficiency and the Oberth effect are less relevant, leading to gradually increasing approximately circular orbits to escape velocity, rather than the increasing eccentricity of classical rocketry. Likewise, all maneuvers simply take much longer. On the other hand, ion spacecraft have monstrous amounts of Delta-V compared to other craft, and are thus obviously well suited to long-range missions with lightweight probes.

The game doesn't support low-thrust spacecraft particularly well, though. Most importantly, the game uses timewarp to speed up long-duration spaceflight, with years passing by in minutes. But significant timewarp only works with spacecraft not under thrust. A maneuver that takes hours of thrust takes hours of game-time. A pure calculation wouldn't have this restriction, but KSP simulates the stresses of the spacecraft while under thrust (so as to allow unplanned disassembly), as well as the possibility of collisions with other objects. Low thrust spacecraft aren't much fun from a gameplay perspective.

Does KSP teach you about low thrust spacecraft less comprehensively than reading, or maths? Probably not. Can it teach a teenager (or adult) something approximately accurate about the difference between low and high thrust spacecraft as a side effect of playing a game? Absolutely.

Answer 4

As a comment above pointed out, KSP uses patched conics for celestial bodies and spacecraft on rails / under high timewarp and uses RK4 for spacecraft under thrust / up to 4x physics warp.

The engine would be capable of doing numerical integration of low thrust trajectories under physics warp. The problem is that there is no model of a finite burn in KSP and the feature that is really lacking is a steering model. If you had a steering model then the engine could numerically integrate the trajectory of the spacecraft under thrust just fine. The question to answer is "over the course of the hours long burn, what direction is the spacecraft pointing as it goes around its orbit?" along with "and how do you pick the correct direction and duration of the burn in order to wind up where you want to go?". If you added a duration to a maneuver burn, along with maybe a button to make the supplied vector switch between inertially fixed or relative to the Frenet (prograde/normal/binormal) frame then you have a crude steering model. That could be used with an integrator along the lines of RK4 to render the predicted burn and terminal orbit.

A big complication emerges though in figuring out how to decrement the fuel resources on the craft and change the mass during the burn. While the vehicle in KSP is "on rails" under high timewarp it is in a state of being "unloaded" and lacks any parts at all. Mods like Kerbalism (possibly only Kerbalism gets this correct right now AFAIK) have to take the vessel object and serialize it into ConfigNodes in order to get at the actual parts on the vessel and change resources and then deserialize it back. That has nothing to do with the celestial mechanics simulation though.

Based on prerelease videos it sounds like KSP2 may have implemented something a lot like this, with finite burns with a simple steering model on top of a patched conics planetarium (although the Rask and Rusk binary planet system may have some limited N-body interactions within the SOI of those planets if I'm guessing correctly), combined with fixing the issues with resource consumption under high warp.

And I suggest you get over your "allergy" to patched conics and curly braces. Initial guess generation of interplanetary transfers usually uses the solution of patched conic approximations (and you'll miss out on languages like Rust). If you can't learn to solve problems with patched conics you probably won't be successful jumping directly to N-body problems (and biases like that ensure that you'll always be a critic).