You need to keep an eye on the speed and accuracy of a Grav-Sim simulation.

Grav-Sim provides 3 different simulators:

SimulatorSpeedAccuracyMachine PrecisionSuitable For
FastSimFast< 7 decimal digitsfloatGlobular Clusters
GravSimMedium< 15 decimal digitsdoubleOpen Clusters
FineSimSlow< 30 decimal digitsdd_realPlanetary Systems

Pick the wrong one and FastSim will have the planet eventually wandering away from the star in a 2-body model, or FineSim will take a very long time simulating a 100,000-body model.


Grav-Sim offers a choice of time-step type:

TypeOverall SpeedSimulation Time

* - the default
** - Shared and Individual time-steps are also known as Variable for this reason
*** - Shared time-steps are included only for completeness; they offer no benefit compared to Individual and take longer to compute

Constant time-steps are the simplest, but suffer from inaccuracy when bodies come close together and need shorter time-steps.

Shared time-steps provide this adaptive behaviour, whilst still keeping all bodies on the same time-steps at the same times.

Individual time-steps provide fully adaptive behaviour and do not restrict bodies to having the same time-steps at the same times.

Unless predictability of simulation time is important to you, Individual time-steps are recommended.


The Grav-Sim 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:

IntegratorOrder*Available With
Chin-Chen (or Optimised)4YesYesYes
Runge-Kutta-4 (or 4n)4YesYesYes
Runge-Kutta-2n (or 2n_fsal)2YesYesYes

* - the order of error reduction with increasing number of steps
** - the default (less prone to numerical rounding errors compared to Hermite-8)
*** - 1st-order integrators are impractical, they're included only for completeness
**** - Multi-Step was available in early releases of Grav-Sim but is no longer maintained


Grav-Sim provides a variety of ways to organise the gravity calculations, depending on whether speed or accuracy is the priority:

AcceleratorOrder*AccuracySpeedInteractorSpace Divider
Barnes-HutO(n log(n))ApproximateMediumDirectOctree
StadelO(n log(n))ApproximateMediumDirectKDTree
Ridler**O(n log(n))ApproximateMediumDirectHilbert
DehnenO(n)V. ApproximateFastPairwiseOctree
Dehnen-Stadel***O(n)V. ApproximateFastPairwiseKDTree
Dehnen-Ridler***O(n)V. ApproximateFastPairwiseHilbert

* - the order of simulation time with increasing number of bodies
** - a variant on a Barnes-Hut tree which uses a Hilbert space-filling-curve and a 1D bottom-up tree instead of a 3D top-down Octree
*** - experimental


Grav-Sim 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 time-steps 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:

LevelApproximate Steps Per Orbit

* - 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 higher-order integrators (e.g. Hermite-8) 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 lower-order integrators (e.g. Leap-Frog).


Grav-Sim provides some simple statistics as part of its logging:

Simulated TimeParameter 
Kinetic EnergyCalculated
Potential EnergyCalculated
Total EnergyKE + PEWatch for errors
Total MassConstant 
Centre of MassConstantWatch for errors
Drift VelocityConstantWatch for errors
Maximum DistanceCalculated from originWatch for ejections
Half-Mass DistanceCalculatedWatch for core collapse
Root-Mean-Square DistanceCalculated 
Maximum SpeedCalculatedWatch for ejections
Half-Mass SpeedCalculatedWatch for core cooling
Root-Mean-Square SpeedCalculated 
Crossing TimeRMS Distance / RMS SpeedUseful as simulation time
Minimum Collision TimeCalculatedScale for Constant time-steps
Root-Mean-Square Collision TimeCalculatedWatch for errors
Closest Approach So FarCalculatedWatch 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 non-physical results.


The high accuracy of the Brute-Force accelerator benefits from shorter time-steps but takes longer to compute.

You can see the effect of using shorter time-steps in the following orbit plots from the 2-body model. The simulations were performed with GravSim using the Leap-Frog integrator and Constant time-steps. 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.

Leap-Frog Constant 500 Steps Per Orbit

500 Steps Per Orbit

Leap-Frog Constant 707 Steps Per Orbit

707 Steps Per Orbit

Leap-Frog Constant 1000 Steps Per Orbit

1000 Steps Per Orbit

Parallel Processing

Grav-Sim has been written to take advantage of the capabilities of modern multi-core CPUs. It uses OpenMP to divide up the work amongst the available processors, leading to improved performance compared to serial execution. The following specific (time-consuming) parts of the code support parallel processing:

  • All Integrators
  • Brute-Force Accelerator
  • Direct Interactor

Up to 92% scaling efficiency can be achieved on a dual-core CPU for Brute-Force with Shared or Constant time-steps.

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 command-line switch: -cpu serial or: -cpu parallel.