... obsolete stuff below ...
The applet above is a gravitational simulator of orbits in space. The executable is in orb.jar and the code is in orbcode.jar. (If you prefer, the code is in Point.java, Eye.java, BVector.java, BMatrix.java, BInterpolate.java, Moon.java, Simulate.java, and Orbit.java.) The mouse lets it stop and start (by clicking without dragging), roll left or up (by clicking near the center and dragging), clockwise and zoom (by clicking far from the center and dragging). Moon colors, sizes, masses, positions, and velocities are applet parameters. Total momentum and and the center of gravity are automatically normalized to (0,0,0). Trajectories are plotted with a symmetric multistep method.
Here's a page that puts the applet through its paces, and another of neat orbits.
Parameters for the applet are:
Moons of weight 0 have an optimization that they're ignored when calculating the forces on all other objects. That means 1 sun with 1000 massless satellites takes O(n) to simulate instead of O(n2). It allows massless objects around binary stars or in globular clusters, too.
Here's an overview of the orbital applet.
Newton's Law of Gravity lets you deduce accelerations from positions and masses of moons (Simulate.accel()). The accelerations, positions, and velocities (Moon.velocity()) let you approximate the positions after a small time increment from the current time (Moon.step()). It's convenient to take several steps per display (Simulate.move()).
Applet parameters are interpreted by Orbit.java. Positions are three dimensional points (Point.java). The view is determined by a camera (Eye.java) that converts 3d model points into 3d points centered on the camera, then Eye.mapx, Eye.mapy convert those to the 2d points on the screen. Moon.java describes a moon and has routines for single-moon calculations. Simulate.java, specifically Simulate.move(), manages taking all the steps between display points.
I use an explicit symmetric multistep method for finding the next positions (Moon.step()). This has several odd consequences:
Since the multistep method needs Moon.degree previous positions, Simulate.getGoing() uses a different method to find the first few positions. First it uses the Verlet leapfrog method to make Moon.POINTS steps 2-32th the final size. Next it fills Moon.history steps using the multistep method. Then it takes every other position, doubles the stepsize, and generates Moon.history more positions. This is repeated 32 times, bringing the time increment up to the intended size.
Total energy is supposed to be conserved. Any gain or loss of energy corresponds to errors in the integration (Simulate.FindEnergy()). Total energy is kinetic+potential. Potential energy is -mass/||distance||. That is always larger than kinetic (mass*velocity2/2) unless some objects have escape velocity. Although Simulate.FindEnergy() could use the distances between moons calculated in Simulate.accel(), accel() is called much more often, so it turned out to be faster to have accel() simple and FindEnergy() as a separate routine.
The routine Moon.dejitter() removes the jitter from a moon's path. It uses BInterpolate.java to build the interpolating polynomial, which in turn uses BMatrix and BVector to do the necessary linear algebra. Dejittering is done by finding the interpolating polynomial for the accelerations, integrating twice, and rederiving the positions. Velocity is found using two points known to have the same jitter error.
Itzu, or Crabs In Space
Why there are no perpetual
motion machines
Cryptographic Protocols
Table of Contents