eggrobin

Yes, this is what issue #1868 is about, @pleroy was a bit confused.

2019-01-06  For the new moon (lunation number 235, partial eclipse), the new release (Εὔδοξος) is out. We have added an enhanced selenopotential in RSS, complete to degree and order 30; this means that the moon now has mascons, making some low lunar orbits unstable. Note that you will only get the new selenopotential when making a new save. As a concrete example, consider this screenshot of a lunar orbit, whose periapsis decreases by 3400 m over the course of 18 orbits because of the irregularities of the Moon's gravitational field (another dozen orbits later, the spacecraft collides with the Moon, between craters Spencer Jones and Spencer Jones W). Saves are now encoded in base64 instead of hexadecimal, making them smaller and faster to load. We have rerun the TRAPPIST-1 optimization, this time with a small enough integration time step allowing us to accurately model the dynamics of the system. Thanks to @AloE for spotting the incorrectly-timed transits. The resulting system has residuals similar to those reported by Grimm et al., with χ² = 358.79 vs. χ² = 342.29 in the paper. See the change log for more details. We support two sets of versions of KSP: downloads are available for 1.4.x & 1.5.1, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load).

Another serious issue was found with the Erdős release (#2021, adding a manœuvre to a flight plan would cause a crash, effectively rendering flight planning unusable), so we have hotfixed it again; if you downloaded Erdős prior to this post, please download it anew (the version string in the Principia UI should say 3e2334a95bcfc6869b5464ecda5ae48b5412dba0, not 773e6fbad7f9fb59790de49fde48650d9451a278 or f772b71b057b64f978bbabdc95ebea2095f27018). We apologize for the inconvenience.

The NaN PotatoRoids have been addressed, Erdős is back. If you downloaded it before the above note was posted, you should redownload it to avoid running into crashes when NaN PotatoRoids appear in the gravitational field of an extended body (the version string in the Principia UI should say 773e6fbad7f9fb59790de49fde48650d9451a278, not f772b71b057b64f978bbabdc95ebea2095f27018).

Note: Erdős is not quite available yet as we are scrambling to address a last-minute issue involving NaN PotatoRoids.

2018-12-07 For the new moon (lunation number 234), the new release (Erdős) is out. Support for realistic geopotential modeling at arbitrary degrees is finally available, with a 10th-degree model of the Earth geopotential in RealSolarSystem; more advanced modelling for other bodies (Moon, Mars, etc.) will be added in future versions. #1955, a performance issue on macOS (continuation of #1908), was resolved by using a different synchronization library. The issue reported by @AloE above (#1999) has been temporarily addressed by using the same integrator configuration that was used for the optimization. We will redo the optimization with a more appropriate configuration in a future version, as this issue likely indicates that the integrator had not quite converged. see the change log for more details. We support two sets of versions of KSP: downloads are available for 1.4.X & 1.5.1, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load).

2018-11-07 For the new moon (lunation number 233), the new release (Ἐρατοσθένης) is out. Support for KSP 1.5.1 has been added. We working on extending geopotential models beyonds oblateness (mascons etc.), but that is not yet ready; see the change log for more details.  We support two sets of versions of KSP: downloads are available for 1.4.x & 1.5.1, and for 1.3.1. Make sure you download the right one (if you don't, the game will crash on load).

Well, α and δ are relative to the celestial equator, not the ecliptic; the ecliptic is rarely used in modern astronomy, see Capitaine and Soffel (2015), On the definition and use of the ecliptic in modern astronomy, arXiv:1501.05534 [astro-ph.EP]. You should probably follow the usual astronomical convention (right ascension and declination of pole), to make it easy to supply tilt for real-world bodies. Regarding your general vessel rotation woes, it seems that below the inverse rotation threshold, you are doing exactly what we do (tilt the universe around the main body). Since you don't actually own the physics of everything, it means you must chase down the various bits of the universe to tilt them (which seems to be the bug at hand), whereas our approach (we own the orbit of everything, whether it is packed or not, as soon as it leaves the ground) makes it easier to just tilt the whole universe at once. Both variants however will run into the issue of the vessels themselves being rotated, even if their orbits are fine (Principia issue #1639), so to answer @Phineas Freak, this mod should have the same issue, just at the inverse rotation threshold instead of the SOI boundary. @Phineas Freak: note that we do plan to do something about #1639 eventually; it is a bit tricky, but with the Principia approach of keeping an authoritative record of the position of everything, it should be feasible, see At the moment we are working on extended geopotential models (mascons, etc.) however.

The standard astronomical convention is to use the right ascension and declination of pole (α0 and δ0 in figure 1 of https://astropedia.astrogeology.usgs.gov/download/Docs/WGCCRE/WGCCRE2015reprint.pdf). They probably don't map directly to the numbers you use: (90° - α0, 90° - δ0, W) are ZXZ Euler angles, i.e., the rotation of 90° - α0 is about the celestial north Z, the rotation of 90° - δ0 is about the rotated X axis (lying on the celestial equator, 90° - α0 from the origin of right ascension), and the reference system used is right-handed (with Z being celestial north). From a cursory reading of your code, you seem to be applying those rotations around X and Z in left-handed, Y-up reference systems instead (it's not clear to me which one is applied first when starting from the celestial frame), so that the transformation between (TILTX, TILTZ) and (α0, δ0) would be nontrivial.

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.