Classic Computer Magazine Archive CREATIVE COMPUTING VOL. 9, NO. 12 / DECEMBER 1983 / PAGE 278

An Applesoft simulation: gravity. Chris Williams.

An Applesoft Simulation


Back in the 60's, a rash of grade B science fiction movies dealt with space flight. In these movies there were certain scenes that the writers apparently felt were required. I suspect you can remember them as well as I can.

First, there was the dramatic blastoff scene that was actually a bit boring. Then there was a brief zero-g demo that gave the special effects people a chance to show off. And then there was my favorite, the meteor storm/repair damage scene.

In this scene a meteor storm would damage something on the hull and someone would have to suit up and go outside to fix it. Naturally, he would manage to leave his lifetime undone and then would kneel down and break the contact of his magnetic soles with the hull. Off he would go. The stage was now set for some exotic rescue techniques ranging from oxygen cylinder propulsion to lassoing. Exciting stuff.

But I have often wondered about that. Suppose, air permitting, he just took a nap. The ships in those movies were massive. His initial radical velocity was low, as he certainly didn't push off. Would gravity reel him in within a reasonable time period?

The Applesoft program I present here can answer that question. It allows you to place two theoretical objects in space and watch their mutural gravitational attraction take effect. You can define the mass of each object, its initial distance from the other, and an initial veolocity. Then you turn them loose and watch them pull themselves together to impact. Their final statistics (velocities, distances traveled, and time) are displayed.

The program is written in Applesoft Basic and runs reasonably fast depending on your choice of delta time. The algorithm uses Newton's gravity equation F=MmG/R2 and his force equation F=ma. Both are implenented in a loop that continually updates each along with velocities and distances.

Prompts for the initial condition inputs are sufficiently detailed to prevent errors. Units, which are metric, are kept consistent throughout the program.

The program is an excellent example of iteration in that, unlike many programs, this one has several interdependent variables all of which are updated in the loop. Most iterative routines update only one variable. The program also illustrates the conventional method of performing integration on a computer.

While I am on that subject let me mention a few things about delta time (DT). DT is the period of pseudo-time that each iteration represents. If you could select an infinitely small DT, the program would yield perfect (for an 8-bit machine) accuracy.

But if you select a tiny DT, the program will take forever to run. So you must compromise execution time with accuracy. I think you will find that accuracy doesn't really suffer too much as you increase DT, because the error is not linear. If you are concerned, try several different DTs for the same problem and graph your results. You will discover that time-to-impact begins to look asymptotic with surprisingly large DTs.

Finally, the program should not be difficult to modify. The iterative print statement could display other variables. The masses themselves could be made variable (simulating fuel burning in a rocket). Or you could get fancy and add a Lorentz transformation to my relativistic subroutine, which currently does nothing but exit when the velocity of an object exceeds .lc. This could prove interesting with very large masses like stars and planets.

Table: Listing.