Table of Contents
nbody2 - direct summation N-body integrator with Ahmad-Cohen scheme
in=snap_in out=snap_out [keyword=value ...]
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.
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.
- 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
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].
energy tolerance allowed per output time deltat. (restart if de/e>5*qe and
option 2(kz)>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:
- 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].
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
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.
control the amount of standard ascii output of (all/a
) bodies: stepsize, positions and velocities, regular and irregular
forces and rs.
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
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: nmax.inc 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
The total is hence 560.NMAX bytes.
Aarseth, Peter Teuben (NEMO adaptations)
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
Table of Contents