Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bizarre trajectories in frames tied to Pol #1741

Closed
pleroy opened this issue Mar 3, 2018 · 2 comments · Fixed by #1746
Closed

Bizarre trajectories in frames tied to Pol #1741

pleroy opened this issue Mar 3, 2018 · 2 comments · Fixed by #1746
Labels

Comments

@pleroy
Copy link
Member

pleroy commented Mar 3, 2018

Reported by Eriksonn on the forum:

There is a rather embarrassing bug in Cohen (and, we suspect, Clifford and Christoffel) where trajectories drawn in a reference frame involving both Pol and Jool (either Pol-Centred-Jool-Aligned or Jool-Pol-Barycentric) appears horribly wiggly:

screenshot2

Interestingly enough, this is already fixed by #1734. More interestingly, we don't have a real understanding of what's happening here other than "something is ill-conditioned". Clearly the backward difference computation is part of the problem, but there may be deeper issues.

@pleroy pleroy added the bug label Mar 3, 2018
@pleroy
Copy link
Member Author

pleroy commented Mar 6, 2018

Update:

It appears that the state of the symmetric linear multistep integrator gets somehow damaged by close encounters between Bop and Pol. @eggrobin wrote a test (#1744) that demonstrates that the local error grows by steps each time a close encounter occurs. Around day 409 of year 4, for instance, the two bodies get within a few thousand kilometres of each other and the local error grows from 1 to 500 metres per day.

In Cohen, where the velocities were computed using a backward difference method, the position errors resulted in amplified velocity errors, thus the picture above. After #1734 the velocities only use one position difference together with the accelerations, and the errors are much less visible (but still present).

We are still trying to understand better how the integrator gets damaged, but this is clearly tied to the system being on the edge of instability. We are also trying to understand its Ляпунов exponent and the backward error.

A possible fix will be to stop using a symmetric linear multistep integrator for the KSP system, and go for a symplectic Runge-Kutta-Nyström integrator. The errors will be larger but not subject to catastrophic growth. For the real solar system, the symmetric linear multistep integrator works just fine because that system doesn't have close encounters (good news everyone!).

Sorry, something went wrong.

@pleroy
Copy link
Member Author

pleroy commented Mar 7, 2018

Conclusion:

As explained in the previous note, the integrator gets damaged by close encounters between Bop and Pol.

Here is a graph of the acceleration of Pol in the 𝑧 direction around the encounter. The same thing happens to the 𝑥 and 𝑦 coordinates, but there the acceleration is dominated by the Sun and Jool, so we would have to look at the jerk to see something.
Time runs horizontally, with one point every 10 minutes; acceleration runs vertically. The orange points are the actual accelerations, the blue points the second derivative of the computed trajectory:
pol1
Until the encounter the orange and blue points are indistinguishable. But when the kick happens the integrator doesn't have enough time resolution to track the change of acceleration (the time step of 10 minutes is too long). This introduces spurious oscillations in the state of the integrator, which explain the wiggly trajectories.

After that, the integrator continues to properly track the system, but the spurious oscillations persist:

pol2
Each time a close encounter happens, the oscillations will become bigger. It seems that using a time step of 2 minutes is sufficient to properly resolve the kick, but that would make the integration 5 times slower. We are better off using a different integrator, less sensitive to these kinds of events.

@pleroy pleroy added this to the Coxeter milestone Mar 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant