C++ N-body Problem

The Distribution of Molecular Speeds

Speed of Velocity of Particle

Obtained Maxwells speed distribution. Well it looks like it anyway. The choppy lines are variations in the discrete sampling buckets. Sampled the simulation over time and found that given any initial distribution over time converged to the Maxwell speed distribution. This was visually confirmed by looking at the shape of the graph.

Speed : r=0.02, numParticles=200, vmax=5.0, 81 histogram divisions, vmax=5.0. Sampling every 100 timesteps. Box dimensions 10 by 10. The graphs are left to right, up to down. The snapshots were taken though arbitrary time points. The initial distribution had random particle speeds up to vmax.

Speed : vmax=2.0. A different initial condition with all particles had the same initial speed.

Changing the box size to 4 by 2 still results in similar graph.

Speed along the x-axis

What appears to be a normal distribution evolved as the time steps increased.

This was observed in the other axes too. It appeared independent of box dimensions.

By changing the box size reducing the space increased the number of collisions in time and accelerated the system towards the steady states.

Code History

I borrowed heavily from Geoff Leeches particle collision code. Converting the brute force from C to C++. Also using the original code as a benchmark. If what I wrote performed badly it was rewritten.

The code was kept similar in parts to benchmark the speed differences between C and C++ and where different to see how the differences performed.

Wrote 2D collision with brute force and uniform grid in C++
Histogram and Sampler objects written
Support for different initial conditions by architecture where you can define a distribution to be slotted in.
Rewrote using poor mans collision test and gained much better performance. Removed STL vector for it performed significantly worse than the ordinary C style array. Geoff suggested STL interfering with cache. As a consequence I removed STL vectors and gained a performance boost.

Added colored balls to make it more visually interesting and for debugging purposes the first and last are red and green. Blue is every 10th not including the first. Able to follow a particles journey an verify what an individual particle is doing.
Learned to use gprof frequently for looking at where time was spent in the code, particularly with in line functions. Gained about 18% improvement in the brute force method over the C version with the C++ version. Mild success attributed to in lined functions.
With the brute force in C++ code, I experimented with in line functions by timing a task with functions in lined and without. Dramatic differences were noticed with nested in line calls performing worse the more nested the in lining was. Sometimes many times worse!
Sometimes member functions performed significantly worse than cutting and pasting the code at the point of evaluation, even just calling other functions. I suspect the compiler is the problem because almost the same code should be generated but this is not the case.
Conclusion: C++ as fast as C in theory and if in lining faster. The inner maximum loaded code is in lined will produce the results.
In lining code needs to be profiled as a minor source change can have a dramatic effect, usually in a negative sense if unaware.

Major achievement: the C++ uniform grid was about 9.4 times faster than the C uniform grid implementation. Primarily by preallocating the memory and never reallocating it.
Wrote non-linear solver to solve a minimization problem for curve fitting. It was interpolation for a particular type of polynomial. The approximations were not good enough and I fitted the curve by hand.
Verified kinetic energy by putting in code to sum and display the sum of the velocities in the console.
Added configurable parameters so that the code would not have to be recompiled. The command line class does this and added -h for help to display available options. The client enters the options at the command line. eg
$ ./main numParticles=300 samplerstate=1 uniform=true -h
Lennard-Jones Potential added as option with the brute force method. eg. LJ=true Parameterized the sampler so can configure it at the command line too.

Investigating Algorithm Complexity

Decoupled graphics from computation. Timed one incrementation varying the number of particles for the two methods. I expected polynomial time. This was shown by plotting log(number of particles ) vs log( time taken), which produces a straight lines for both methods.

When log X vs log Y graphs produce a straight line the relationship is a geometric curve of the following form.

$y (x) = a x^{b}$
$a$ and $b$ are constants.

Brute Force

Number of Particles vs Time(s) for 1 time step

log(Number of Particles) vs log(Time(s)) for 1 time step

Uniform Grid

A straight line relationship is observed from the graph. Then the uniform grid is performing with O(n) complexity.

Number of Particles vs Time(s) for 1 time step

log(Number of Particles) vs log(Time(s)) for 1 time step

So I then needed statistical software to minimize the following curve and solve for a and b.

Anyway I thought that this is not too difficult to solve, so I will solve it myself. Big mistake. Well not for a learning perspective, it really is work acquiring a good stats program as its worth its weight in gold. (I am a theoretic mathematician so I am ever so slowly discovering numerical approaches, but almost every engineer I encounter has done no algebra!)

Wrote a non-linear equation solver, used it to get best solution over a grid region. Plotted the curve with GnuPlot and not happy with the approximation : curve not bound to points so while accurate was not the correct shape.

Improvised and fitted a curve through trial and error which took all of 60 seconds, and fitted a much better curve. I found the brute force method to be approximately quadratic in order because a quadratic fitted through its data points.

Brute Force Curve Fitted

Prediction of Simulation Time with Brute Force

	1e3 particles	1e4 particles	1e5 particles	1e6 particles
1e3 timesteps	5.7*10^1 s	5.7*10^3 s	5.7*10^5 s	5.7*10^7 s
1e4 timesteps	5.7*10^2 s	5.7*10^4 s	5.7*10^6 s	5.7*10^8 s
1e5 timesteps	5.7*10^3 s	5.7*10^5 s	5.7*10^7 s	5.7*10^9 s
1e6 timesteps	5.7*10^4 s	5.7*10^6 s	5.7*10^8 s	5.7*10^10 s

Lennard-Jones Potential

I have not got very far with this one. Lets discuss the equation. The majority of the time for simulations the simulation explodes (the kinetic energy goes to infinity). This is attributed to when two particles get too close they are shot away from each other at high speeds.

Since the force is so great when two particles are near (a power of 13 repulsion) they shoot away. Now the new particles have much greater speed and are much more likely to collide with other particles head on - generating even more kinetic energy. This continues and the system breaks down.

Its clear that low velocities are needed so this situation does not arise, and particles can not get close to other particles centers because of the energy released. Hence the slow velocity so the particle can be repelled.

Onto of this is the inherent nature of hard sphere collision systems to produce particles with high velocities. Only one of these particles is needed to send the system into anarchy.

So for a stable system hard sphere collisions can not occur. From the graph of Lennard-Jones Potential its clear that a minimum energy state occurs where attraction and repulsion are equal. But what does it mean here where the equation is applied to every other particle.

I tried to get a lattice thinking that would be the minimum state. The equation even hints that this is the case. By taking the derivative and solving for zero we get the following expression.

$r = 2^{\frac{1}{6}} σ$

In a lattice I imagine the forces balancing each other and the particles being about this distance away from each others centers. However I could not come up with the numbers and I don't know how to relate this to how many particles should be in a given area.

The much more obtainable situation was where the particles went about but stayed away from each others centers (no hard sphere collision). Even for this I had to use very low speeds (compared to hard sphere collision case).

Because of the systems inherent instability I created a distribution where the spheres are spaced apart - to avoid the dramatic situation of particles speeding away from each other at the start and breaking the system.


$ ./main numParticles=15 x1=0.5 y1=0.5 vmax=0.005 LJ=true LJpsi=.000005 LJsigma=.01510 radius=.01 h=.1 samplerstate=1 histhigh=0.015


$ ./main numParticles=15 x1=0.5 y1=0.5 vmax=0.005 LJ=true LJpsi=.000005 LJsigma=.01510 radius=.01 h=.1 samplerstate=2 histhigh=0.015

It appears that the same distributions for the hard sphere collisions are being produced by the Lennard-Jones potential. ie normal for speed along axes, maxwell distribution for speed of velocity.

TODO

zpr option removed, reimplement it.
Document code with Doxygen style comments.

N-Body Problem

Intro

System

Source

Files

Doxygen

The Distribution of Molecular Speeds

Speed of Velocity of Particle

Speed along the x-axis

Code History

Investigating Algorithm Complexity

Brute Force

Number of Particles vs Time(s) for 1 time step

log(Number of Particles) vs log(Time(s)) for 1 time step

Uniform Grid

Number of Particles vs Time(s) for 1 time step

log(Number of Particles) vs log(Time(s)) for 1 time step

Brute Force Curve Fitted

Prediction of Simulation Time with Brute Force

Lennard-Jones Potential

TODO