eggrobin

2018-10-09 For the new moon (lunation number 232), the new release (Διόφαντος) is out. Nothing new this time; we have been working on improved gravity models, but they are not ready yet. 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).

It's only 54 km/s in the radial direction, the rest is from tangential motion. I was mostly mentioning relative velocity because of relativistic effects, since you generally work with time scales in which the system of interest is at rest: people use geocentric coordinate time (Temps-Coordonnée Géocentrique, TCG) or its linear scaling terrestrial time (Temps Terrestre, TT) when working with satellites of the Earth, but barycentric coordinate time (Temps-Coordonnée Barycentrique, TCB), the time coordinate of the barycentric celestial reference system (BCRS) when working with missions in the solar system. Hypothetical inhabitants of the TRAPPIST-1 system would similarly work with the time coordinate of a reference system in which the TRAPPIST-1 system is at rest, rather than one in which it moves at considerable speed, so that it is hard to assign precise and useful meaning to "the time at which the light left TRAPPIST-1": "the time at which the light left TRAPPIST-1 in the BCRS" is well-defined, but: odd from the perspective of the denizens of TRAPPIST-1e who would see BCRS clocks moving past them at 80 km/s, and therefore running slow by about 1 s per year; not useful from the perspective of our solar system, where it takes 40 years for that to actually be observed. "the time at which the light left TRAPPIST-1 in a reference system in which the barycentre of the TRAPPIST-1 system is at rest" is not well-defined (since TRAPPIST-1 clocks and BCRS clocks tick at different rates in either frame, you need to decide when they are aligned, which makes your dates essentially arbitrary). As a result, we use "the time at which the light reached Earth in the terrestrial frame", which at least is useful from an observational standpoint. Note of course that TT is different from UTC, so what you see is not quite civil time.   maybe I just could not find it over at github...what epoch formats are currently supported by RSSTimeFormater? I see that RSSTimeFormater does ok with the following in the "Trappist1.cfg" file I added epoch = 2014-12-08T12:00:00  but it does not like the epoch format I see in trappist_initial_state_jd_2457000_000000000.cfg => game_epoch = JD2457000.0 as epoch = JD2457000.0 or epoch = 2457000.0 for example in my "Trappist1.cfg" The example format strings are for the dateFormat setting, which, as you have seen, controls the format in which RSSTimeFormatter shows the date. dd/MM/yyyy will give you French-style dates, dd.MM.yyyy Swiss and German-style ones, yyyy年M月d日 Chinese-style ones, etc. It is unrelated to the epoch setting. The epoch setting will take whatever DateTime.TryParse will accept. DateTime.TryParse does not accept Julian dates (.NET is not an astronomy framework). In practice, I recommend using ISO 8601 extended format calendar dates, i.e. things like 2014-12-08T12:00:00, since this is unambiguous and also works for Principia.

This is a good idea, we should recommend it. The TRAPPIST-1 for Principia config isn't currently intended to support RSSTimeFormatter (although it probably should), so it has no configuration for it. KSP configuration is just a matter of having some cfg file with the right nodes somewhere under GameData, which file it comes from matters little (it can have an effect on the order of ModuleManager patches, but this is fairly advanced KSP configuration). Yes, at least if you want Swiss-style dates. :-) In particular, `epoch` should be equal to the `game_epoch` setting from Principia's principia_initial_state. An important note is that the time shown will be the time on Earth in Temps Terrestre (TT) at which the system will be seen in that configuration from Earth, and that there are about 40 light-years between from here to TRAPPIST-1; further TRAPPIST-1 is moving at about 80 km/s with respect to the solar system.

For the new moon (lunation number 231), the new release (Descartes) is out. Important note for mac users: Principia no longer supports macOS El Capitan, as that version is no longer supported by Apple. We now require macOS Sierra or later. As a consequence, we can use shared_mutex on mac, so there should be noticeable performance improvements for macOS users. We have added generalized Runge-Kutta-Nyström methods, which allow for a more accurate prediction of burns that are fixed in the Frenet frame. 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).

Note that the inclinations are not Principia-specific: RSS also uses equatorial coordinates (so as to have Earth's tilt). What Principia changes with respect to tilt is that the coordinate system changes when the main body does, always being equatorial for the current main body. It will likely not have escaped your attention that merely changing the inclinations is not a correct change of coordinate system, and that the resulting orbits will be highly inaccurate (although with Principia you only get osculating orbits anyway, so accuracy is likely a lost cause). What prevents your trajectory optimization tool from working with equatorial coordinates? These are just ICRS axes after all, nothing outrageously exotic.

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: 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. 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. 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. 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”).

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. 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”: 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: 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. 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.

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).

For the new moon (lunation number 229), the new release (Δημόκριτος) is out. Vessels are now managed by Principia when they are in the atmosphere, which means that atmospheric flights have Principia histories and predictions in map view. The “Trappist-1 for Principia” mini-mod has been improved to better reflect the physical properties of the celestials. See the change log for more details. We support two versions of KSP: downloads are available for 1.4.4 and 1.3.1. Make sure you download the right one (if you don't, the game will crash on load).

For the new moon (lunation number 228), the new release (Dedekind) is out. This release fixes a memory leak which could lead to increases in memory usage to the tune of 1 GiB / min when using the flight plan. Further, we are releasing a mini-mod that turns @GregroxMun's SLIPPIST-1 into the real TRAPPIST-1 system; the 7-planet resonant chain of that system makes it interesting from the perspective of n-body gravitation. The configuration is computed by transit-timing variation based on the transit timings from the recently-published paper The nature of the TRAPPIST-1 exoplanets by Grimm et al. See the change log for more details. We support two versions of KSP: downloads are available for 1.4.3 and 1.3.1. Make sure you download the right one (if you don't, the game will crash on load).

Indeed. We have no plan to model tides in the foreseeable future. It does model oblateness, that's the "extended-body" part in the title (they are modeled as oblate bodies rather than point masses, and that is the extent of the "extended" for now). Not yet at least. For high-order gravity models, we would need to think about a practical way to limit the range, as we don't want to have to compute high-order lunar gravitation all the way to Jupiter. Note that this is relevant even for the orbit of Phobos, as Mars has a pretty misshapen gravitational field.

This is a good idea. Detailed reply in the pull request, let’s keep the discussion in one place.

For the new moon (lunation number 227), the new release (Darboux) is out. This release: uses a new implementation of the cube root which is more accurate and faster than most, as part of an ongoing effort for Principia to use its own implementation of elementary functions; adds Gipfeli compression and arena allocation when saving and loading, reducing save file size by about 2.5× and scene load times by about 2× for large saves; adds support for KSP 1.4.3. See the change log for more details. We support two versions of KSP: downloads are available for 1.4.3 and 1.3.1. Make sure you download the right one (if you don't, the game will crash on load). Darboux does not support KSP 1.2.2, as Realism Overhaul and Real Solar System now support 1.3.1.

For the new moon (lunation number 226), the new release (Cramer) is out. This release: fixes a bug which caused manoeuvre nodes to jump at the time of ignition, especially on ejection and capture burns. Thanks to @Kobymaru and @EstrelaGaliza for reporting and helping diagnose this bug. adds support for KSP 1.4.2. Note that you may need to install a newer C++ runtime; see the change log for more details. We support three versions of KSP: downloads are available for 1.4.2, 1.3.1, and 1.2.2. Make sure you download the right one (if you don't, the game will crash on load). Cramer will not support 1.4.3, as Principia has special handling to work around ladder-related bugs, so we will need to test the new release to see if changes are needed. This is the last release to support KSP 1.2.2, as Realism Overhaul and Real Solar System now support 1.3.1.

Here is your problem, we do not support KSP 1.4.2 in Coxeter (you should see a message to that effect in the FATAL log, which you can find in the glog directory as detailed in the FAQ). The next release, Cramer, which will be released on the new moon on the 16th of April, will target 1.4.2. As documented in the OP and the release posts, using the Principia with the wrong version of KSP results in a crash on load. Principia is extremely monolithic; either everything works or nothing does. You do not have axial tilt unless you have all of Principia. Please do not mess with the file organization, you will leave your install in a broken state and produce hard-to-diagnose bugs. The only additional requirement, besides dropping the right version in GameData, is that the Visual C++ Redistributable Packages (or libc++abi on *nix) be installed, as documented in the FAQ.

It is really hard to actually interfere with principia (see also how Principia nullifies Hyperedit and the like). In any case, we test and debug with the default settings, so those are safe.

I am not sure what those settings do anymore; there are two possibilities as to their effect on Principia: whatever they do may be overwritten by Principia's opinion of where things are; they might violate Principia's assumptions on the behaviour of KSP. Principia makes fairly few assumptions, so it is probably (1) rather than (2), but to be safe you may want to just keep these settings to their default values. It does make the release process a little bit more annoying; we do indeed plan on dropping 1.2.2 support when RO etc. move on to a newer version, which cannot happen too soon (cc @NathanKell :-p).

For the new moon (lunation number 225), the new release (Coxeter) is out. This release: uses SSE2 intrinsics for improved performance; addresses numerical stability issues in the Jool system reported by @Eriksonn; introduces an API for @Jim DiGriz's guidance algorithms; introduces support for KSP 1.4.1, thanks to @awang. See the change log for more details. We support three versions of KSP: downloads are available for 1.4.1, 1.3.1, and 1.2.2. Make sure you download the right one (if you don't, the game will crash on load).

I suspect that what is happening here is that your flight plan has two manoeuvres; the "show on navball" functionality always puts the upcoming or current manoeuvre on the navball, so that as soon as you reach the planned end of your first burn, guidance switches to tracking the (future) second one . This is obviously far from ideal user experience, but in the meantime, you can mitigate it by switching your SAS to "Stability Assist" (rather than "Maneuver") near the planned end of the burn. Eventually we should devise a way to do that automatically, but this gets tricky. As far as the general problem of guidance to a manoeuvre is concerned, we are working with @Jim DiGriz to provide utilities which will allow MechJeb's advanced guidance algorithms (PEG etc.) to know about Principia's flight plan, which will allow the manoeuvres to be automatically executed. Issue #1659 tracks this.

For the new moon (lunation number 224), the new release (Cohen) is out. The ephemerides are now computed using the Estrin method for polynomials expressed in the monomial basis instead of the Clenshaw method for polynomials expressed in the Чебышёв basis, improving the performance. See the change log for more details. Again, we support two versions of KSP: downloads are available for 1.3.1 and for 1.2.2. Make sure you download the right one (if you don't, the game will crash on load).

At that point it should no longer be necessary to force the flight plan to operate in stock-like instant-impulse mode, so that should also make it significantly easier to use.

The markers are always the Frenet frame, see the concepts page. Specifcally, they are the Frenet frame of the trajectory plotted in the plotting frame. In this case, the trajectory plotted in the target LVLH currently curves away from the planet (as you can see on the screenshot), so the normal vector is away from the planet. In the Kerbin-Centred Inertial frame, the trajectory would be an orbit around Kerbin, which curves towards Kerbin, and thus the normal vector would be towards the ground. Note that the Frenet frame that indicates the start of a planned manoeuvre in map view is that of the trajectory in the manoeuvre frame, not in the plotting frame: in this case your manoeuvre frame is KCKF, so the normal vector (blue line) points towards the ground. We are aware that the SAS gets confused; we haven't really had the time to investigate that.

Summarizing some discussion on IRC, the issue is that @Jim DiGriz needs the trajectory after the manoeuvre, which Principia doesn't expose; forcing Principia to act like stock (instant impulses) and going through the stock manoeuvre node API works, but is unsatisfactory. We have an issue (#1659) to track providing an API to allow a PEG implementation to guide towards the planned trajectory; this will take us some time, but at least it's a well-defined and clearly-scoped feature request.

For the new moon (lunation number 223), the new release (Clifford) is out. A bug in the implementation of DoublePrecision that caused a test to fail on Macintosh, as reported by @awang and @Jim DiGriz, was fixed. Solar system designers can now pick an integrator more suited to their solar system, as requested by @GregoxMun whose surprisingly stable Alternis Kerbol Rekerjiggered does not fare well with Principia's default integration parameters, which were chosen (in Cartan) to work for stock KSP and the real solar system. See the change log for more details. Again, we support two versions of KSP: downloads are available for 1.3.1 and for 1.2.2. Make sure you download the right one (if you don't, the game will crash on load). Thanks to @awang for contributions (clang warning cleanups) during this lunation.

I've been meaning to reply to this for a long time, but never got around to it; apologies for the delay. The flight plan does not currently support staging events, so the results of the plan will be somewhat inaccurate. There is no prediction frame. There is a plotting frame, which is the reference frame in which you are drawing the trajectories, and a manoeuvre frame for each manoeuvre, which is the reference frame used to define what "tangent" means when you burn tangent. They need not be the same; indeed, when planning an escape burn from Earth, the manoeuvre should be tangent in ECI (i.e. along the path of your orbit around the Earth), but you probably want to look at the trajectory in a frame where your target is fixed (probably Venus-centred, Sun-aligned). The warning should be seen more as a reminder that when burning "forward" isn't going to burn forward along the trajectory that is drawn, but along the trajectory in another reference frame.