 The magazine of the Melbourne PC User Group The three-body problem Ken Holmes |
Back in the eighties, Scientific American ran regular articles,
called "Computer Recreations", which dealt with the many interesting programs being devised on those (fairly)
new-fangled computer things. They were largely responsible for my adoption of programming as a hobby in my
retirement. At last, there was a willing slave to do vast numbers of repetitive calculations with the results
displayed graphically to give a quick insight to complex situations. The three-body problem seemed an ideal
application since my main interest was in graphics and, specifically, true 3D viewing to use all that wasted
space in front of and behind the screen.
Mathematicians have long since reduced the orbits of two bodies on their own in space to fairly simple
equations and their motions can be confidently predicted for evermore, that is, unless a third body happens
along. The only way to deal with this is by taking small time steps and calculating the gravitational effect
of each one on its fellows. Gravity is continuous and complete accuracy would require infinitely small time
steps; a compromise has to be made. If results are plotted in two dimensions, horrible tangles result, as may
be seen in the figures here.
True 3D stereo makes the developing orbits fascinating to watch and I first experienced this by using the
red/green goggles trick. Each eye gets its own perspective and it works--each orbit is perceived in 3D, but
in white--you may have any other colour as long as it is white. Then the mirror trick was drawn to my
attention. A vertical mirror, 300 to 400 mm wide, faces left, with its edge along the vertical centreline of
the screen. The right eye perspective is drawn on the right screen, the left eye view is flipped onto the
left screen so that its reflection is on the right and is true for the object there. But wait, each body's
orbit can be in a different colour and it is much easier to follow the developing orbits.
The first (1988) QuickBasic program on my XT ran like a dog (three-legged)--many cuppas while patterns
emerged--but became acceptable with the advent of the 486. Revisiting it now to translate to C++ has given me
a jolt as there were lots of superfluous calculations going on. Avoiding these and streamlining the logic
gave a substantial boost in speed, which could be traded for a reduction of the time steps to give a bonus of
much better accuracy.
This is of particular importance in close encounters where larger steps cause skidding out on the bend and a
different departure direction and velocity from that in real life. A basic time step is adopted between
actual plotting of positions on screen; at each plot, a check is made for the minimum separation between any
two stars and, based on the inverse square of this, is decided how many sub-intervals will be used for
calculations during the next time step. This can range from eight to 2000 or more so that, during close
encounters between any two stars, these can be more accurately calculated.
Playing with the program reveals a lot about the behaviour of stars. Binaries will form where two bodies'
relative velocities are less than escape velocity and some have expressed the opinion that half of the stars
are binaries in the hundred billion galaxies with a hundred billion stars each--or thereabouts. But they are
markedly exclusive of interlopers; any body approaching from a large distance will "fall" in and sweep by at
more than escape velocity, and its hyperbolic path will send it off in a different direction with much the
same speed as it came.
If it passes close to one of the binaries, it will be whipped to a higher speed, if going in roughly the same
direction, but will be slowed down if going in roughly the opposite direction. In the latter case, it may
even be captured by one of the binaries; if it orbits closely enough, it may stay with it, but larger orbits
will eventually encounter the other binary. Then the interloper may orbit with it, or be ejected at high
speed, or anything. Be assured, any scenario you care to imagine has happened out there--billions of times.
If the interloper is large, it may even race off in a new marriage with one of the binaries, sending the
other off to try its luck elsewhere.
To get patterns to stay on the screen long enough to be interesting, it is necessary to contrive masses,
positions and velocity components carefully. A binary pair is essential and others should be placed nearby
with zero relative speed. Then trial and adjustment can give the sort of pattern desired.
The total linear momentum needs to be near zero in two dimensions (across screen and vertically) to avoid
drifting off; even then, ejection of one at high speed will make the rest recoil in the opposite direction
and you may lose the lot. It is an advantage with stereo viewing to have movement into or out of the screen
to separate different episodes in the development.
The program STERSTAR.EXE (64 KB) and the figures here give some idea of the
sequences it contains, nine with three stars and nine with four stars. The program can cope with more stars
but speed is inversely proportional to the square of the number of stars and any increased interest does not
compensate for the more sluggish performance.
The printed picture is a poor substitute for seeing the development of orbits on screen, with optional white
or black background, optional goggle or mirror viewing and optional playing speeds. It is more interesting to
watch patterns developing slowly and the accuracy is also better, so it is necessary to offer a wide range of
speeds to satisfy machines from 386s to Pentium 400s.
|
|
Figure 1 shows a binary pair, green and red, of slightly different mass,
started in circular orbits with smaller, magenta and blue, stars placed above the orbital plane. These drop
in and select a partner each, establishing their own inclined orbital planes. However, as their parents move
in their own orbits, the satellites' paths become a mixture of spiral and cycloidal elements. The satellites
have enough mass to cause undulations in the orbits of the binaries and ruin the neat circular pattern. If
the satellites had been dropped in from much further out, they would have interfered with each other, swapped
parents and eventually been ejected.
|
|
Figure 2 is a bit messier but more typical of real-life patterns. The green
and magenta binaries are in elliptical orbits about their common focus and moving steadily further beyond the
screen. The advent of the pesky red and blue satellites causes upset in their happy lives. Blue moves in wide
orbits around the pair without seriously disrupting them but red keeps returning for close encounters, with
either binary, which seriously modify the shape and bodily movement of their orbits. Both satellites are
hurled off the screen but keep returning. This is true chaos since minor changes in the initial placements
will give markedly different outcomes. Incidentally, there is an artificial form of chaos due to the
calculation inaccuracies resulting from the adoption of finite time steps; if we vary the time step, to offer
different program speeds, the pattern becomes different, particularly after each close encounter.
I realise that this type of program will not be a novelty for many of our older members, but offer them for
younger members who may not have seen them, particularly for those learning programming, or contemplating
doing so, and looking for ideas to try out.
Reprinted from the December 1998 issue of PC Update, the
magazine of Melbourne PC User Group, Australia
