HTML automatically generated with rman
Table of Contents


nbody2 - direct summation N-body integrator with Ahmad-Cohen scheme


runbody2 in=snap_in out=snap_out [keyword=value ...]


under development

nbody2 is a NEMO adaptation of version 2 of Aarseth’s N-body scheme in which close encounter are treated according to the Ahmad-Cohen scheme (ref: A.Ahmad and L. Cohen, J. Comp. Phys. 12, 389, 1973).

Each particle is followed with its own integration step - an essential feature when the dynamical times of different particles vary a lot. A complete description is given in: S.J. Aarseth, "Multiple Time Scales", ed. U.J. Brackhill & B.I. Cohen, pp377. Orlando: Academic Press. (1985).

For a proper choice of input parameters it is highly recommended to read an accompanying article NBODY2: Ahmad-Cohen-N-body Code by S. Aarseth. It is included in NEMO’s distribution package in the file $NEMO/doc/nbody2.tex, and can be printed using TEX


The following parameters are recognized in any order when the keyword is also given. Most of them have the same name as in Aarseth’s description, except where otherwise noted.
Input file in snapshot format. If no input file is given, a system will be generated for you, but it is expected that the nbody keyword (see below) is used in this case [default: empty].
Output file in snapshot format [no default].
Input file in local binary dump format. If output option kz(1) is choosen, this file will be overwritten. [default: not used].
Output file where last dump for restarts (option kz(2) is stored) [default: not used]
Number of bodies to create system with, in case no filename was given. Was called N in Aarseth’s original description. [default: 32]
Output frequency of binaries or data save (options 3 & 6) [default: 1].
Maximum number of neighbours (option 5 needs one more) [default: 10].
Time step parameter for irregular force calculation [default: 0.02].
Time step parameter for regular force calculation [default: 0.02].
Initial radius of neighbour spheres [default: 0.5].
Output time interval, expressed in units of the crossing time [default: 0.25].
Termination time, expressed in units of the crossing time [default: 2.0].
Relative energy tolerance allowed per output time deltat. (restart if de/e>5*qe and option 2(kz[1])>0) [default: 0.01]
Close encounter time step for neighbour retention (option 5) [default: 0.01].
Softening length for potential (was called cutoff in Aarseth’s original version) [default: 0.05].
kz=int array
Array of options, at most 20 in number. A non-zero number sets some activity, either output or control. A full description is given below [Default: 1::20].
Maximum CPU time allowed for the process. If the value is 0.0 or negative, the value is acutally ignored. Was called tcomp in Aarseth’s original program [default: 0.0].

Options Array

The options array kz, introduced as a keyword, requires some additonal explanation, it usually takes some time to understand the interaction between all other keywords and the kz.

Basic output occurs every deltat crossing times, but the frequency parameter nfix then still controls (together with certain options from the kz array) which other major items will be output at which frequency, such as a full body dump in the form of snapshots or restart dumps.

Basic output consists of 1) time, virial ratio (T/U) q, number of steps taken so far nstepn (6 numbers), radius of center of mass, relative energy error de, and the time in crossing times, tcr. Then 2) total angular momentum in z, az, average number of near neighbours nnbn, ???, virial radius and maximum ’rs’ density.

A full snapshot dump to out can be obtained at every nfix*deltat time-interval when kz(6) =1. nfix strangely enough also controls the standard ascii output of information on significant binaries.

kz(7) and kz(9) control the amount of standard ascii output of (all/a few(5) ) bodies: stepsize, positions and velocities, regular and irregular forces and rs.

kz(1) and kz(2) control if dumps are to be done on unit 1 or 2. Unit 1 is used only at the end of calculation, for a continuation or restart. Unit 2, when activated, stores all relevant information for (autoatic) restarts when energy conservation is not acceptable (see qe above).




If an input snapshot is given, it must ALWAYS start at T=0. The fortran code has too many assumptions that this is the case. Of course if the internal binary dump (restart) files are used, integrations can be continued from the end on, but not from a middle random snapshot without resetting the time.

/fIobsoleted?/fP: The code has a hardcoded maximum number of particles in the fortran code (nbody2.f), and C code (nbodyio.c), however both are transferred through their own header file: for the FORTRAN code and nmax.h for the C code. Whenever a new version is needed, use the makefile target ’nmax’, e.g. make nmax NMAX=256;make nbody2, to create new header files.


The FORTRAN code uses 4 large common blocks (named block1,block2,block3,and block4) which can also be communicated to the C code. These use 460.NMAX bytes. The C code allocated its space dynamically during runtime, and uses it’s regular 100.NMAX bytes units (assuming the standard <snapshot/body.h>).

The total is hence 560.NMAX bytes.


Sverre Aarseth, Peter Teuben (NEMO adaptations)



See Also

nbody0(1NEMO) , hackcode1(1NEMO) , quadcode(1NEMO) , newton0(1NEMO)


3-jul-89    V1.0: created + NEMO interfaces to fortran source    PJT
27-oct-89    -cosmetic-       PJT
mar-93        initial formal release         SJA
dec-93        released (u3 and u4 modified)                     SJA
16-mar-95    fixed a rand->rand2 common block name conflict    SJA
jun-97         adopted into NEMO (usr->src)
18-dec-99       1/2 bug fix in ALPHAS line in define.f  PJT/SJA/xxx
9-feb-2017    add kz(19) option

Table of Contents