Infinite Force? Forty year old FORTRAN to the rescue!

I continue to be fascinated by the complexity that comes from the simple problem of three masses interacting through gravity. Last year I released the ThreeBody app to demonstrate some of this complexity – challenging users to place three bodies so they would stay together. For bodies at rest this is probably impossible (although I am not aware of a proof).  An early commenter asked exactly the right question: “Is the ejection of a body physical or an artifact of the simulation?”.

In the case of my app, in most cases it was an artifact of the simulation. I have been on a journey to remove this artifact and better demonstrate that it is STILL very hard to find solutions that stay together and this is now purely because of the physics and not the implementation.

The result is a significant reboot of ThreeBody, one that allows velocities to be added to the bodies and as a bonus has a gallery of very cool known stable three body solutions.

Close Encounters Have Near-Infinite Force

The force of gravity scales as 1/r^2. Start with two bodes at rest a fixed distance apart, attracted by gravity. As they get close, r (the distance between them), gets small and 1/r^2 becomes HUGE. In a game simulation applying a huge force for a short time step can result in an object moving a large distance, often far beyond the other object. In reality the pair would get the same very big force restraining them as they move past the closest approach. If you think about energy conservation and ignore the collision – it is impossible for the two bodies to fly apart. They can only get as far apart as they started (assuming they started at rest). If two bodies interacting do fly apart – it is an artifact of the simulation not coping well with the very large forces at close approach.

Simulation artifacts have been a well known issue in gravitational simulations since the beginning of computer astronomy experiments in the 1960s. There are ways to transform (“regularize”) the co-ordinates and the forces so that the infinities do not arise during close encounters. This is commonly done in scientific-grade simulations but in game physics is not typically demanded (since the collision usually results in some form of destruction).

Since my app was trying to model these close encounters, it needed a higher pedigree solution.

As usual, I started by buying more physics books and downloading papers. This convinced me that I did need to have a regularizing algorithm and also showed me that doing one from scratch would take some time. Since there is no substitute for running code, my next step was to look and see what researchers were using and if I could adapt it. There are some fantastic programs available (see references below) although many are instrumented for research, scaled for many masses and do not not need to be concerned about real-time performance. These programs are BIG and generally written in FORTRAN or C and I was hoping to continue to use C# within Unity.

I finally found the code TRIPLE from Aarseth and Zare developed in FORTRAN in 1974. It was about one thousand lines. After several attempts using tools to do Fortran to C to C# and experiments building the code as a C library and calling from Unity, I decided that the simplest approach was just to transcribe the code by hand. As an added bonus I would gain a much deeper insight into how the algorithm worked. The code then needed a bit of re-arranging to meet the real-time needs of evolution during a graphical application, and changes in reference frame (since the algorithm operates in the center of mass frame).

ThreeBody now uses the TRIPLE engine and the encounters continue to be very fascinating – even more than before. For masses with no initial velocity it is still difficult to find long lived solutions. The full version of ThreeBody allows the bodies to be given initial velocities allowing even more solutions to be explored. The full version also allows a choice of integration engine; you can go back to Leapfrog to see just how different the results are and monitor the change in total energy – which indicates the error in integration. There is also a higher pedigree non-regularized Hermite integrator for comparison to Leapfrog.

A large gallery of very cool three body solutions is now part of the app. Ranging from solutions found by Euler and Lagrange in the 1770s to those found as recently as 2013. These are hypnotically beautiful – even though not all of them a stable.

For those who want to delve further an annotated reference section is provided.

Resources and References

Three Body Solutions:

Broucke (1975) On Relative Periodic Solutions of the Planar Three Body Problem, Cel.Mech, 12, p439 SAO/NASA

Henon (1974) Families of periodic orbits in the three-body problem, Celestial Mechanics, vol. 10, Nov. 1974, p. 375-388. SAO/NASA

Suvakov (2013) Numerical Search for Periodic Solutions in the Vicinity of the Figure-Eight Orbit: Slaloming around Singularities on the Shape Sphere arxiv

Suvakov and Dmitrasinovic (2013) Three Classes of Newtonian Three-Body Planar Periodic Orbits arxiv

Regularization:

Aarseth, Zare (1972) A regularization of the three-body problem. Celestial Mechanics, vol. 10, Oct. 1974, p. 185-205. SAO/NASA

The discussion in The Basics of Regularization Theory by Celletti provides a very accessible introduction. More discussion can be found in Heggie & Hut, and Aarseth.

Books:

Aarseth (2009) Gravitational N-Body Problems, Cambridge Univ. Press. (Very comprehensive, detailed discussion of algorithms. My copy has an irritating mis-print in which a negative sign in a sub/superscript is printed as a heavy dot.)

Heggie, Hut (2003) The Gravitational Million-Body Problem, Cambridge Univ. Press. (A readable, wider ranging overview of N-body simulations and the behaviour of star clusters)

Roy (2004) Orbital Motion, CRC Press (Derives Euler and Lagrange three body solutions. One of the classic texts of orbital mechanics.)

Code:

The “defacto standard” code is from Aarseth. This is all in FORTRAN. The TRIPLE integrator used in ThreeBody is derived from the TRIPLE code here.

Starlab is another widely used collection of programs.  The Hermite integrator offered as an option in ThreeBody is a modified version of an integrator in Starlab.