

Gravity simulation on a desktop computer 
You need to keep an eye on the speed and accuracy of a GravSim simulation.
GravSim provides 3 different simulators:
Simulator  Speed  Accuracy  Machine Precision  Suitable For 

FastSim  Fast  < 7 decimal digits  float  Globular Clusters 
GravSim  Medium  < 15 decimal digits  double  Open Clusters 
FineSim  Slow  < 30 decimal digits  dd_real  Planetary Systems 
Pick the wrong one and FastSim will have the planet eventually wandering away from the star in a 2body model, or FineSim will take a very long time simulating a 100,000body model.
GravSim offers a choice of timestep type:
Type  Overall Speed  Simulation Time  

Individual*  Fast  Variable**  
Shared***  Medium  Variable**  
Constant  Slow  Predictable  
*  the default 
Constant timesteps are the simplest, but suffer from inaccuracy when bodies come close together and need shorter timesteps.
Shared timesteps provide this adaptive behaviour, whilst still keeping all bodies on the same timesteps at the same times.
Individual timesteps provide fully adaptive behaviour and do not restrict bodies to having the same timesteps at the same times.
Unless predictability of simulation time is important to you, Individual timesteps are recommended.
The GravSim simulators use numerical integration techniques to work out where the bodies will be a short time in the future. The calculation is based on where they are now, how fast they’re moving and how strong the pull of gravity is due to the other bodies in the system. The process is then repeated based on the new positions, speed and gravity, moving forward in time step by step.
A choice of integration methods is available:
Integrator  Order*  Available With  

FastSim  GravSim  FineSim  
Hermite8  8  No  Yes  Yes 
Hermite6  6  Yes**  Yes**  Yes** 
Hermite  4  Yes  Yes  Yes 
ChinChen (or Optimised)  4  Yes  Yes  Yes 
RungeKutta4 (or 4n)  4  Yes  Yes  Yes 
RungeKutta3  3  Yes  Yes  Yes 
LeapFrog  2  Yes  Yes  Yes 
RungeKutta2n (or 2n_fsal)  2  Yes  Yes  Yes 
ProtoHermite  2  Yes  Yes  Yes 
ForwardPlus***  1  Yes  Yes  Yes 
ForwardEuler***  1  Yes  Yes  Yes 
MultiStep****  2  No  No  No 
*  the order of error reduction with increasing number of steps 
GravSim provides a variety of ways to organise the gravity calculations, depending on whether speed or accuracy is the priority:
Accelerator  Order*  Accuracy  Speed  Interactor  Space Divider 

BruteForce  O(n^{2})  Exact  Slow  N/A  N/A 
BarnesHut  O(n log(n))  Approximate  Medium  Direct  Octree 
Stadel  O(n log(n))  Approximate  Medium  Direct  KDTree 
Ridler**  O(n log(n))  Approximate  Medium  Direct  Hilbert 
Dehnen  O(n)  V. Approximate  Fast  Pairwise  Octree 
DehnenStadel***  O(n)  V. Approximate  Fast  Pairwise  KDTree 
DehnenRidler***  O(n)  V. Approximate  Fast  Pairwise  Hilbert 
*  the order of simulation time with increasing number of bodies 
GravSim automatically judges the number of steps to use depending on the integrator and the model (and also the local conditions in the model if Variable timesteps are used).
Level 1 uses the fewest number of steps to produce a reliable result. You can increase the number of steps by going to level 2, 3 etc. Each successive level uses a factor of sqrt(2) times more than the previous one:
Level  Approximate Steps Per Orbit  

Hermite8  Hermite6  Hermite  LeapFrog  
1*  148  193  250  500 
2  209  273  354  707 
3  296  386  500  1000 
4  418  546  707  1414 
5  592  772  1000  2000 
6  836  1092  1414  2828 
*  the default, all integrators have been tuned to achieve a similar level of accuracy at level 1 
There is little point in using anything other than level 1 with FastSim because calculations are only accurate to 7 decimal places anyway.
The higherorder integrators (e.g. Hermite8) need fewer steps to achieve a given level of accuracy, at the cost of more computation time per step. However, from level 2 upwards they improve in accuracy at a higher rate compared to the lowerorder integrators (e.g. LeapFrog).
GravSim provides some simple statistics as part of its logging:
Statistic  Definition  Comments 

Simulated Time  Parameter  
Kinetic Energy  Calculated  
Potential Energy  Calculated  
Total Energy  KE + PE  Watch for errors 
Total Mass  Constant  
Centre of Mass  Constant  Watch for errors 
Drift Velocity  Constant  Watch for errors 
Maximum Distance  Calculated from origin  Watch for ejections 
HalfMass Distance  Calculated  Watch for core collapse 
RootMeanSquare Distance  Calculated  
Maximum Speed  Calculated  Watch for ejections 
HalfMass Speed  Calculated  Watch for core cooling 
RootMeanSquare Speed  Calculated  
Crossing Time  RMS Distance / RMS Speed  Useful as simulation time 
Minimum Collision Time  Calculated  Scale for Constant timesteps 
RootMeanSquare Collision Time  Calculated  Watch for errors 
Closest Approach So Far  Calculated  Watch for near misses 
All stats are produced both at the beginning and the end of a run so you can make a comparison.
The time and energy stats are also reported during a run, at a defined number of log points.
The Total Energy stat in particular is a sensitive measure of accumulated errors leading to nonphysical results.
The high accuracy of the BruteForce accelerator benefits from shorter timesteps but takes longer to compute.
You can see the effect of using shorter timesteps in the following orbit plots from the 2body model. The simulations were performed with GravSim using the LeapFrog integrator and Constant timesteps. Each simulation ran for a duration of 200 orbits, with every 20th orbit drawn on the graph.
The orbits should be perfect ellipses, each one overlapping the last. The deviation gives an indication of the overall accuracy.
500 Steps Per Orbit 
707 Steps Per Orbit 
1000 Steps Per Orbit 
GravSim has been written to take advantage of the capabilities of modern multicore CPUs. It uses OpenMP to divide up the work amongst the available processors, leading to improved performance compared to serial execution. The following specific (timeconsuming) parts of the code support parallel processing:
Up to 92% scaling efficiency can be achieved on a dualcore CPU for BruteForce with Shared or Constant timesteps.
The Pairwise interactor is a clear candidate for future parallisation. The Octree, KDTree and Hilbert tree codes could also be parellelised during tree construction.
The execution mode can be controlled at run time with the commandline switch: cpu serial or: cpu parallel.