5 ms·

> Even simpler, though, because only one of the masses needs to have a location. The other one is effectively at a fixed direction and distance, far enough away

> Even simpler, though, because only one of the masses needs to have a location. The other one is effectively at a fixed direction and distance, far enough away that you can ignore relative motion. This still sounds like precisely what I described. Euler's three-body problem is two fixed point masses, so there's no relative motion by construction, and the restricted three-body problem in a rotating/pulsating reference frame has mathematical transformations applied so the two bodies are "effectively fixed" relative to each other in that reference frame (while preserving effects due to rotations, such as centripetal/centrifugal forces). The question in such a case becomes whether such a thing is substantially better than a regular n-body integrator. Euler's three-body problem may lose some useful n-body effects such as Lagrange points, which partially defeats the purpose of moving away from Keplerian orbits, and the restricted three-body problem arguably isn't simplified enough compared to full-blown n-body integration to be worth it. > I'll rephrase. The gravitational vector on the craft won't be shifting very fast, so you can get away with a quite big timestep. Ah, that makes more sense. IIRC Principia has an adaptive timestep, so it already does that, though that's with full n-body calculations. Swapping between the approximation and proper n-body depending on position relative to other bodies seems like a rather complex scheme, though, and I'm not sure whether that'd be the best approach.

Dylan16807 6y ago
> This still sounds like precisely what I described. Euler's three-body problem is two fixed point masses, so there's no relative motion by construction, and the restricted three-body problem in a rotating/pulsating reference frame has mathematical transformations applied so the two bodies are "effectively fixed" relative to each other in that reference frame (while preserving effects due to rotations, such as centripetal/centrifugal forces). You still have to care about the where the particle is relative to both masses. The whole point of the calculation is figuring out which way the particle goes, and the simplification I'm suggesting removes a lot of that math. Instead of two masses providing a continuously varying force in both direction and magnitude, you have one mass providing a continuously varying force plus a static offset. This removes multiple degrees of freedom from the problem. > Swapping between the approximation and proper n-body depending on position relative to other bodies seems like a rather complex scheme, though, and I'm not sure whether that'd be the best approach. I wasn't suggesting swapping between the methods. If you're in the middle of nowhere, then while the Keplerian portion of the model will be a smaller factor, it won't harm anything.
- aw1621107 6y ago
  > Instead of two masses providing a continuously varying force in both direction and magnitude, you have one mass providing a continuously varying force plus a static offset. Ah, so the force vector is constant/infrequently updated, not the position of the second body. My apologies for the misunderstanding. I'm honestly a bit curious what an that would look like. For example, what would an orbit around the Earth-Moon L1 look like? What would an Earth -> Moon low-energy transfer look like? I feel like depending on the system you might need to update the "fixed" force vector relatively frequently to get anywhere close to approximating n-body results, which basically sounds like regular integration. I suppose at some point the question becomes how much fidelity are you willing to sacrifice in the name of decreasing CPU usage. > I wasn't suggesting swapping between the methods. My mistake again. Sorry about that. > If you're in the middle of nowhere, then while the Keplerian portion of the model will be a smaller factor, it won't harm anything. Wouldn't that arguably be where the most significant errors would be, as that's where the relatively unphysical constant force vector would have the most significant influence?
  - Dylan16807 6y ago
    > Ah, so the force vector is constant/infrequently updated, not the position of the second body. My apologies for the misunderstandin That's fine, glad we got it cleared up. > I'm honestly a bit curious what an that would look like. For example, what would an orbit around the Earth-Moon L1 look like? What would an Earth -> Moon low-energy transfer look like? > I feel like depending on the system you might need to update the "fixed" force vector relatively frequently to get anywhere close to approximating n-body results, which basically sounds like regular integration. For a basic example-numbers implementation, replacing an n-body simulation that updates every 10 seconds, I was imagining that you might update the force vector 1/100th as often, every 1000 seconds. That's plenty fast to accurately handle a multi-day orbit around a lagrange point or a low energy transfer. The paths the craft take should look completely normal. If you then combine a normal single-influence orbit with that force vector, you could summarize 1000 seconds of orbit into one moderately complex equation. So instead of doing a moderately complex calculation every 10 seconds, you'd do two of them every 1000 seconds, an estimated 50x CPU savings. If you're not very close to anything, there's no benefit over just running an n-body calculation every 1000 seconds. But the hard-to-handle case is orbits that are low enough to need rapid updates, but high enough that it's noticeably wrong to use an ellipse. And it's easy to end up with a lot of things in those orbits. > Wouldn't that arguably be where the most significant errors would be, as that's where the relatively unphysical constant force vector would have the most significant influence? Treating the forces as constant over a stretch of time, when they actually are almost constant, shouldn't have all that much error, unless I'm missing something glaring. As you get further and further away from the most influential mass, this system gets closer and closer to simply being an n-body simulation with a timestep of how often you update the force vector.

Dylan16807 6y ago

> This still sounds like precisely what I described. Euler's three-body problem is two fixed point masses, so there's no relative motion by construction, and the restricted three-body problem in a rotating/pulsating reference frame has mathematical transformations applied so the two bodies are "effectively fixed" relative to each other in that reference frame (while preserving effects due to rotations, such as centripetal/centrifugal forces). You still have to care about the where the particle is relative to both masses. The whole point of the calculation is figuring out which way the particle goes, and the simplification I'm suggesting removes a lot of that math. Instead of two masses providing a continuously varying force in both direction and magnitude, you have one mass providing a continuously varying force plus a static offset. This removes multiple degrees of freedom from the problem. > Swapping between the approximation and proper n-body depending on position relative to other bodies seems like a rather complex scheme, though, and I'm not sure whether that'd be the best approach. I wasn't suggesting swapping between the methods. If you're in the middle of nowhere, then while the Keplerian portion of the model will be a smaller factor, it won't harm anything.

aw1621107 6y ago
> Instead of two masses providing a continuously varying force in both direction and magnitude, you have one mass providing a continuously varying force plus a static offset. Ah, so the force vector is constant/infrequently updated, not the position of the second body. My apologies for the misunderstanding. I'm honestly a bit curious what an that would look like. For example, what would an orbit around the Earth-Moon L1 look like? What would an Earth -> Moon low-energy transfer look like? I feel like depending on the system you might need to update the "fixed" force vector relatively frequently to get anywhere close to approximating n-body results, which basically sounds like regular integration. I suppose at some point the question becomes how much fidelity are you willing to sacrifice in the name of decreasing CPU usage. > I wasn't suggesting swapping between the methods. My mistake again. Sorry about that. > If you're in the middle of nowhere, then while the Keplerian portion of the model will be a smaller factor, it won't harm anything. Wouldn't that arguably be where the most significant errors would be, as that's where the relatively unphysical constant force vector would have the most significant influence?
- Dylan16807 6y ago
  > Ah, so the force vector is constant/infrequently updated, not the position of the second body. My apologies for the misunderstandin That's fine, glad we got it cleared up. > I'm honestly a bit curious what an that would look like. For example, what would an orbit around the Earth-Moon L1 look like? What would an Earth -> Moon low-energy transfer look like? > I feel like depending on the system you might need to update the "fixed" force vector relatively frequently to get anywhere close to approximating n-body results, which basically sounds like regular integration. For a basic example-numbers implementation, replacing an n-body simulation that updates every 10 seconds, I was imagining that you might update the force vector 1/100th as often, every 1000 seconds. That's plenty fast to accurately handle a multi-day orbit around a lagrange point or a low energy transfer. The paths the craft take should look completely normal. If you then combine a normal single-influence orbit with that force vector, you could summarize 1000 seconds of orbit into one moderately complex equation. So instead of doing a moderately complex calculation every 10 seconds, you'd do two of them every 1000 seconds, an estimated 50x CPU savings. If you're not very close to anything, there's no benefit over just running an n-body calculation every 1000 seconds. But the hard-to-handle case is orbits that are low enough to need rapid updates, but high enough that it's noticeably wrong to use an ellipse. And it's easy to end up with a lot of things in those orbits. > Wouldn't that arguably be where the most significant errors would be, as that's where the relatively unphysical constant force vector would have the most significant influence? Treating the forces as constant over a stretch of time, when they actually are almost constant, shouldn't have all that much error, unless I'm missing something glaring. As you get further and further away from the most influential mass, this system gets closer and closer to simply being an n-body simulation with a timestep of how often you update the force vector.