The trajectories linked to below are displayed using the JavaView Lite applet. Rotate geometry by moving the mouse inside viewer window, pressing and holding the left mouse button, and dragging. Press right mouse button to select major interaction mode from popup menu, or use keyboard keys to temporarily switch between different modes:

o | Rotate surface (this Orbit mode is the default mode) |

s | Scale surface, drag in vertical direction |

t | Translate surface in viewing plane |

r | Reset camera and display, object returns to default position |

Real space, magnetized, 4 particles

Real space, magnetized, 8 particles

Real space, unmagnetized, 8 particles

Real space, unmagnetized, 30 particles

Download Powerpoint slideshow with additional figures

The trajectories are generated by integrating the 1/r^2 Coulomb force for a set of *N* electrons and single-charged ions with the actual electron-deuteron mass ratio.
The magnetic force due to a uniform and constant background magnetic field is also included, but inter-particle magnetic forces are ignored since particle speeds are much less than the speed of light.

The simulations are carried out at a value of ln(Lambda) much less than typical values in today's fusion experiments (8-17 or so).
To understand why this unrealism is necessary, consider that
we want to simulate a time on the order of a collision time (the point of the simulation is to visualize a small number of collisions.)
Since the simulation timestep is fixed by the need to resolve the electron gyromotion, the product (collision time) * gyrofrequency cannot be too large
if the simulation is to run in a reasonably short time.
Up to constants of order unity,

(collision time) * (gyrofrequency) = Lambda * (Debye length) / (gyroradius)

Since the Debye length is not too far from the electron gyroradius in fusion plasmas, I choose to keep the ratio (Debye length) / (gyroradius) realistic, which means that the simulation takes longer to run as Lambda increases.
We can still have ln(Lambda) >> 1, just not quite as >> 1 as in a realistic fusion plasma.
The simulation time gets impractically long for Lambda larger than about exp(6.0). Since (up to constants) Lambda = T^(3/2) / n^(1/2), this means that the simulations operate at unrealistically low temperatures or unrealistically high densities.
Put another way, in a realistic fusion plasma there would be many more gyro-orbits between collisions than in the figures shown here.

Periodic boundary conditions are used, i.e., each particle pair is counted once in tallying up the total force, but each inter-particle separation vector is adjusted by multiples of the unit cell vectors to minimize the magnitude of this separation distance. The trajectories are 'unwrapped' for display here: one of the unit cell vectors is added or subtracted from the particles' positions as needed to make the trajectory continuous. The electron gyroradius is comparable to the simulation box size. The box shown in the interactive pages is a bounding box for the unwrapped trajectories, much larger than the simulation volume.

The integration is performed using a 4-th order Runge-Kutta algorithm with adaptive step size, closely following the example in *Numerical Methods in C*.
The simulation is written in C++ and executed on a single processor.
Since the problem is solved in such a brute-force manner, the runs shown here take roughly 40 hours on a Pentium 4 PC running linux.
Computation could certainly be greatly expedited by using clever algorithms (e.g. fast multipole methods) and parallelizing.

*Matt Landreman, May 2008*