Implementation and organisation¶

Since the code was written in C/C++, we used Object Orientation for the organisation of every aspect of the integrator.

Similarly, we focused in leaving one class per file, to help the understanding and organisation of the code.

The constants and structures global declaration are placed into a common header to avoid multiple definitions and for maintaining coherence.

Due to we provide a command line interface, we use the boost module called program_options which allow us to have an stable and robust base to create our options parsing and handling. This is included in the class OptionParser.

Every \(N-\) body code has the same general information, both particle information (r, v, a, dt, ...) and system properties (T, E, K, ...), which will be use always, for every different implementation, independently of the environment. This is the reason of storing all this information in a class called NbodySystem.

Additionally to the system information and features, it’s necessary to leave the functions in charge of calculating all the system properties, like core-radius, lagrange radii, crossing-time, among others, in a different class, that we called NbodyUtils.

To notify the user the inner process that the integration performing we created a separated class called Logger in charge of all the standard output procedures of the code.

The current version of our integrator is based on the Hermite 4th order integration scheme, which consist in a few well-determinated steps to perform the integration described in the class Hermite4. This class contains a few virtual methods, which are the main procedure, like prediction, correction, force interaction, among others. Th idea behind the virtual method is to allow inherit this class to implement the most heavy computationally methods with different techniques or parallelise, which is the case of Hermite4CPU, Hermite4MPI and Hermite4GPU, that implement this virtual methods using only OpenMP for a single node, only MPI for single node or cluster, and GPU for a single GPU-node, respectively.

A diagram to understand the distribution of this classes and files is displayed below.

The structure of the code allow us to use a different integrator scheme, for example the Hermite 6th order, in an easy way, since we just need to include the same classes includes by the current Hermite 4th order and then follow the structure of leaving the important methods as virtual for a future implementation for different environments.