egg changed the topic of #principia to: Logs: https://esper.irclog.whitequark.org/principia | <scott_manley> anyone that doubts the wisdom of retrograde bop needs to get the hell out | https://xkcd.com/323/ | <egg> calculating the influence of lamont on Pluto is a bit silly…
* raptop
pokes the bridge with a cat
<paculino>
It appears to be broken
<raptop>
blarg
_whitelogger has joined #principia
_whitelogger has joined #principia
queqiao- has quit [Remote host closed the connection]
<raptop>
But have they caused any accidental staging?
<queqiao->
⟨makoivis⟩ Oh yes
<queqiao->
⟨makoivis⟩ Oh so many times
<queqiao->
⟨makoivis⟩ It’s a test of abort capabilities, obviously
<queqiao->
⟨sichelgaita⟩ That's correct.
<queqiao->
To be honest we never investigated the usage FMM. However, as you know, O(N) looks better than Q(N^2) until you look at the multiplicative factor hidden in that big-O, and you realize that N is 20-30 in our case. The time spent in the quadratic loop is a handful of microseconds for each 10-minute step, so it's hard to believe that FMM would make a big difference.
<queqiao->
We investigated multistep methods (where Pluto would be integrated with a longer time step than Phobos) until we realized that keeping Pluto unmoving for several days would look weird in the game.
<paculino>
Would craft experience momentary high acceleration when Pluto made a big step, since it would not be the same as elsewhere?
<paculino>
(Craft at Pluto)
<queqiao->
⟨sichelgaita⟩ * O(N^2)
<raptop>
Does this mean that a craft could accidentally end up inside of Pluto?
<raptop>
(if the long steps were implemented)
<paculino>
How much longer would steps be?
<raptop>
several days it soduns like
<raptop>
*sounds
<queqiao->
⟨sichelgaita⟩ That was years ago, but from what I recall one issue with multistep methods is that the positions/velocities are incorrect until you have reached the point where all the steps synchronize. So if Phobos is integrated every 10 minutes and Pluto every 1280 minutes, you only get Phobos "right" every 1280 minutes. And in order to extrapolate the position of Pluto, you need to integrate 1280 minutes ahead of the present (to have an...
<queqiao->
... extra point). That's all very messy.
<queqiao->
Pluto is actually a terrible example because of the Pluto-Charon system, which need to be integrated at relatively high frequence. Uranus or Neptune would be better examples.
<raptop>
I'd assume that Triton would force Neptune into short steps for similar reasons
<raptop>
Sedna doesn't have any known moons...
<queqiao->
⟨egg⟩ Yeah, anything that has moons needs a short step for the inner system, so the classic Wisdom & Holman approach is useless if you need to model the moons. I had found a paper that dealt with that, https://www.aanda.org/articles/aa/pdf/2003/12/aa3133.pdf, but never looked seriously into it.
armed_troop has quit [Quit: Bye]
armed_troop has joined #principia
<queqiao->
⟨redtyro⟩ hi all, is there a setting somwhere to adjust the lead time in the "warp to maneuver" button in the flight plan? It seems to default to 60s before the burn, but I want to leave a bigger cushion than that to aim a the target and let my RCS settle, then rebase
<queqiao->
⟨redtyro⟩ I've been manually warping to about 3 minutes away
<queqiao->
⟨redtyro⟩ hi all, is there a setting somwhere to adjust the lead time in the "warp to maneuver" button in the flight plan? It seems to default to 60s before the burn, but I want to leave a bigger cushion than that to aim a the target and let my RCS settle, then rebase before the burn
<queqiao->
⟨redtyro⟩ I didn't see an option, but I figured I might be looking in the wrong place
<queqiao->
⟨mizokaya⟩ Mechjeb has a warp helper iirc with a manual time option, though I haven’t used it with principia, I imagine it works the same?
<queqiao->
⟨redtyro⟩ it uses RCS to aim at the node, then warps to 8 minutes ahead and aims again, then to smaller intervals re-aiming every time
<queqiao->
⟨redtyro⟩ extra impulses to change the burn calculations and wasting RCS
<queqiao->
⟨redtyro⟩ part of why I was warping to 3 minutes out and then aiming at the node and rebasing before hitting the MJ button to execute the node
<queqiao->
⟨mizokaya⟩ Warp helper shouldn’t touch orientation? It just lets you have finer control over when to warp to. This is different to the auto warp for manoeuvres mind you.
<queqiao->
⟨redtyro⟩ oh, that sounds like something I didn't knwo was in MJ
<queqiao->
⟨redtyro⟩ I've been using KER for years and MJ is new to me with Principia and RP-1
<queqiao->
⟨redtyro⟩ I'll poke around and find it
<queqiao->
⟨redtyro⟩ thanks!
<queqiao->
⟨mizokaya⟩ It’s around the same area in the menu as utilities and RCS Aid IIRC
<queqiao->
⟨redtyro⟩ found it, and it looks like exactly what I was trying to do - I can set it to warp to 3 minutes before a maneuver node. Thanks again!
<queqiao->
⟨sierra_hotel⟩ Huh, I was wondering about that, too. Just never looked into it more and dealt with the 60sec window.
<queqiao->
⟨egg⟩ We could probably have a setting in a config file somewhere like the colours…
<queqiao->
⟨redtyro⟩ honestly, I just tested the mechjeb solution and it worked perfectly
<queqiao->
⟨redtyro⟩ maybe just an additional sentence in the tutorial on the wiki that points to the MJ warp tool
<queqiao->
⟨lpg4999⟩ I've just always set a KAC quick maneuver alarm (which happens to use 3min, I think) to stop the principia warp early
<queqiao->
⟨lpg4999⟩ it's 2 button clicks on a window I always have open