Closed eggrobin closed 5 years ago
Perhaps it would be easiest to change the definition of
BodyCentredNonRotatingDynamicFrame
so that it uses the same z axis asBodySurfaceDynamicFrame
, making the y axis the node Q rather than making the x axis the point B from figure 1 of the 2009 report of the IAU WGCCRE.
This sounds mostly useful, except for the Sun; the inclination of the Earth's orbit with respect to the Sun's equator is about 7°, and most other planetary orbits would be similarly inclined.
Perhaps we should use the invariable plane of the solar system for the sun?
The Sun's equator would be a useful reference plane in a system with a highly oblate star, but hopefully in such a system the invariable plane would match the stellar equator better (consider, for instance, the low inclinations of the large moons of Jupiter).
except for the Sun
Unfortunately, a similar problem applies to any body with meaningful obliquity, and there is no clear solution when the body is oblate or can be landed on. For instance, considering orbits around the Earth:
Perhaps the solution is to offer two different body-centred reference frames:
We could make the x axis point to the ascending node of the orbit with respect to the equator of the orbiting body; this puts the x axis at the equinox, close to ♈︎
for the case of Earth (coinciding at J2000).
Relevant to the "show the inclination" part of this feature request: https://www.reddit.com/r/KerbalSpaceProgram/comments/9jug8y/mods_that_help_out_with_principia/.
Further thoughts: showing nodes with respect to the invariable plane or with respect to the ecliptic in the heliocentric or geocentric frames respectively does not seem all that critical: for a heliocentric orbit, one can care about its deviation from the plane of the orbit of a planet, e.g. for a transfer, or for an Earth-trailing orbit (Spitzer, Kepler, STEREO-B, etc.), but we have more appropriate reference frames for that (body-centred fixing the direction of the Sun).
We still do not want to show nodes with respect to the equator of the Sun, but we would want to do so for a very oblate star, and we want to show nodes with respect to the equator of Jupiter, so that showing nodes only in reference frames centred on a body with a landable surface is not the answer.
Perhaps we should display the nodes:
we should display the nodes […] within some appropriate range if the body has a nonzero 𝐽2 but has no ground
Using the inner_threshold
of the Geopotential::HarmonicDamping
for degree 2 with a tolerance of 2-24 (note that the tolerance used here should not vary with the one in the numerics blueprint, since we should not start caring more about the equator of the sun even if we simulate the solar system more accurately), we get the following values for the solar system bodies that have no ground:
Threshold | |
---|---|
☉ | 2 268 473 408,26164103 m = 3,3 ℛ☉N = 0,039 𝑎☿ |
♃ | 61 485 396 603,2066574 m = 860 ℛ𝑒JN = 1,2 𝑟Hill ♃ = 33 𝑎Callisto |
♄ | 54 629 082 549,7388153 m = 938 𝑅♄ = 0,89 𝑟Hill ♄ = 15 𝑎Iapetus = 4,2 𝑎Phoebe |
♅ | 10 743 852 957,8324566 m = 423 𝑅♅ = 0,16 𝑟Hill ♅ = 18 𝑎Oberon |
⯉ | 10 447 898 379,5284729 m = 424 𝑅⯉ = 0,091 𝑟Hill ⯉ = 29 𝑎Triton = 1,9 𝑎Nereid |
The values seem large enough for the gas giants (in particular, they encompass the major satellites), and small enough as to not be a concern for the Sun (even the Parker Solar probe does not come close enough).
For comparison, here are corresponding thresholds for some telluric planets:
Threshold | |
---|---|
♀ | 90 093 373,0178448409 m = 15 𝑅♀ = 0,090 𝑟Hill ♀ |
🜨 | 1 488 865 844,35271454 m = 233 ℛ𝑒EN = 1,0 𝑟Hill 🜨 = 3,9 𝑎☾ |
♂ | 1 065 713 084,68501496 m = 314 𝑅♂ = 1,1 𝑟Hill ♂ = 25 𝑎Deimos |
These have a surface, so the thresholds would not actually be used.
unconditionally if the central body has a surface on which it is possible to land
This is a bad criterion: as adding a technically-landable surface beneath a thousand kilometres of atmosphere should not change the way we display orbits.
A possibility would be to take the maximum of
inner_threshold
of the Geopotential::HarmonicDamping
for degree 2 with a tolerance of 2-24This means that we show the nodes for synchronous orbits (for these and lower orbits, the surface may matter), and when 𝐽2 is relevant.
The table becomes
𝐽2 threshold | supersynchronous threshold | |
---|---|---|
☉ | 2 268 473 km = 3,3 ℛ☉N = 0,039 𝑎☿ | 40 136 621 km = 58 ℛ☉N = 0,69 𝑎☿ |
☿ | 36 329 km = 15 𝑅☿ = 0,21 𝑟Hill ☿ | 385 555 km = 158 𝑅☿ = 2,2 𝑟Hill ☿ |
♀ | 90 093 km = 15 𝑅♀ = 0,090 𝑟Hill ♀ | 2 439 122 km = 403 𝑅♀ = 2,4 𝑟Hill ♀ |
🜨 | 1 488 866 km = 233 ℛ𝑒EN = 1,0 𝑟Hill 🜨 = 3,9 𝑎☾ | 66 931 km = 10 ℛ𝑒EN |
♂ | 1 065 713 km = 314 𝑅♂ = 1,1 𝑟Hill ♂ = 25 𝑎Deimos | 32 427 km = 9,6 𝑅♂ |
♃ | 61 485 397 km = 860 ℛ𝑒JN = 1,2 𝑟Hill ♃ = 33 𝑎Callisto | 253 998 km = 3,6 ℛ𝑒JN |
♄ | 54 629 083 km = 938 𝑅♄ = 0,89 𝑟Hill ♄ = 15 𝑎Iapetus = 4,2 𝑎Phoebe |
178 171 km = 3,1 𝑅♄ |
♅ | 10 743 853 km = 423 𝑅♅ = 0,16 𝑟Hill ♅ = 18 𝑎Oberon | 131 256 km = 5,2 𝑅♅ |
⯉ | 10 447 898 km = 424 𝑅⯉ = 0,091 𝑟Hill ⯉ = 29 𝑎Triton = 1,9 𝑎Nereid |
132 560 km = 5,4 𝑅⯉ |
While this leads to slightly absurd results for the slowly-rotating planets (Mercury and Venus), where a threshold based on the synchronous altitude is picked even though the synchronous altitude would be outside the Hill sphere, and thus synchronous orbits would be impossible, this is fine: the body-centred non-rotating frame is irrelevant outside the Hill sphere anyway.
The important thing is to avoid showing irrelevant nodes where the reference frame itself is relevant, which happens because the reference plane is not a dynamical property of the reference frame.
This came up during the design discussion in #1840.
This is not quite as simple as changing the conditions for prediction nodes and flight plan nodes, since the xy plane for the body-centred inertial frames is currently the global reference plane (Earth's equator in RSS, Kerbin's in stock) rather than the plane of the equator of the relevant body.
Perhaps it would be easiest to change the definition of
BodyCentredNonRotatingDynamicFrame
so that it uses the same z axis asBodySurfaceDynamicFrame
, making the y axis the node Q rather than making the x axis the point B from figure 1 of the 2009 report of the IAU WGCCRE.Note that Q≠
♈︎
for Earth, since α₀=0; this motivates making the y axis the node Q, rather than the x axis, so that the x axis points towards♈︎
for Earth (in other words,BodyCentredNonRotatingDynamicFrame
for Earth would be the same asBarycentric
in RSS).Addendum: it seems GitHub ignores VS-15 on U+2648 ARIES unless it is within a code block.