HTML automatically generated with rman
Table of Contents

Name

runbody1, nbody1 - (frontend to) Aarseth N-body code

Synopsis


runbody1 [parameter=value]
nbody1   < nbody1.in

Description

runbody1 is a NEMO frontend to Aarseth’s NBODY1 (fortran) program, running the code in a run directory where all files are stored.

The new version 2.x interface tries to mimic to run NBODY1 in virial units with a default input and output. In previous versions the defaults were more geared towards running the classic interface where data were scaled and times were measured in crossing times, making comparisons with other codes in NEMO much harder. This however means it is now more work to make NBODY1 run in classic mode. Parameters names and meaning have not changed, except for the introduction of kz(15), to work in code (virial) units.

Parameters

The following parameters are recognized in any order if the keyword is also given:
in=
input file (optional, see nbody= to generate your own input data on the fly). If input data are given, you must also set KZ(4) =2 (see below). WARNING: The input snapshot will be mass-weight centered before the integration started by NBODY1. Default: not used.
outdir=
Output run directory. This directory should not exist, although can be overriden with NEMO’s standard error= system keyword. No default.
nbody=
** Total particle number. The maximum value (NMAX) is compiled into the NBODY1 program. Note that even if input files are supplied, this parameter is needed. No default.
nfix=
Output frequency of data save (KZ(3) ) or binaries (KZ(6) ). [Default: 1]
nrand=
Random number sequence skip. [Default: 0]
nrun=
Run identification index. Not really used for anything, just a relic from nameless Aarseth-type files. The outdir now has this function. [Default: 1]
eta=
** Time-step parameter for force polynomial. [Default: 0.02]
deltat=
Output time interval in units of the crossing time (M**2.5/(2E)**1.5). [Default: 0.25]
tcrit=
Termination time in units of the crossing time. [Default: 5]
qe=
Energy tolerance (restart if DE/E > 5*QE & KZ(2) > 1) [Default: 2e-5]
eps=
Potential softening parameter [Default: 0.01]
kz=
** Non-zero options for alternative paths (see below) [Default: 1,2,1,2,0,0,0,0,0,1,1,0,0,0,1] 
   1  COMMON save on unit 1 if TCOMP > CPU or if TIME > TCRIT. [1]
   2  COMMON save on unit 2 at output (=1); restart if DE/E > 5*QE (=2).
[2]
   3  Basic data written to unit 3 at output time (frequency NFIX). [1]
   4  Initial conditions on unit 4 (=1: output; =2: input). [2]
   5  Initial conditions (=0: uniform & isotropic; =1: Plummer). [0]
   6  Output of significant binaries. [0]
   7  Output of movie frames on unit 7. [0]
   8  Generation of two subsystems (merger experiment). [0]
   9  Individual bodies printed at output time (MIN(5**KZ9,N)). [0]
  10  No scaling of initial conditions. [1]
  11  Modification of ETA by tolerance QE. [1]
  12  Initial parameters for binary orbit. [0]
  13  Escaper removal (R > 2*RTIDE; RTIDE = 10*RSCALE). [0]
  14  Adjustment of coordinates & velocities to c.m. condition. [0]
  15  Use code units for tcrit/deltat [1]
alphas=
** Power-law index for initial mass function (routine DATA) [Default: 2.3]
body1=
Maximum particle mass before scaling [Default: 5.0]
bodyn=
Minimum particle mass before scaling [Default: 1.0]
q=
** Virial ratio (q=0.5 for virial equilibrium) [Default: 0]
vxrot=
XY-velocity scaling factor (> 0 for solid-body rotation) [Default: 0]
vzrot=
Z-velocity scaling factor (not used if VXROT = [Default: 0]
rbar=
Virial radius in pc (for scaling to physical [Default: 1]
zmbar=
Mean mass in solar units [Default: 1]
xcm=
** Displacement for subsystem (routine SCALE; KZ(8) )
ecc=
Eccentricity of relative motion for subsystem (ECC =< 1)
kstart=
** Run mode: 1=new >1 restart, with increasing options of resetting variables. Only new runs are currently supported.
tcomp=
not supposed to be used, but counts max computing time alotted.
KZ#=
Special indexed keyword to override kz=, for example KZ4=1.
exe=
Name of the (fortran) executable to run. [Default: nbody1]

Bugs

Scaling can cause output to become out of bounds.

Coding the the input-order logic in the frontend program can be hazardous to your health. It will depend on how the NBODY1 main program is structured.

Input

Order of input lines in "nbody1.in" for a new run (KSTART=1) 
          variables                   condition             where
  ----------------------------    -------------------      ---------
  KSTART TCOMP                                            MAIN
  Nbody NFIX NRAND NRUN                                   INPUT
  ETA DELTAT TCRIT QE EPS                                 INPUT
  KZ(1..15)                                               INPUT
      ALPHAS BODY1 BODYN          KZ(4).NE.2              DATA
      SEMI ECC                    KZ(12).NE.0             DATA
  Q VXROT VZROT RBAR ZMBAR                                SCALE
      NFRAME DELTAF               KZ(7).GT.0              SCALE
      XCM ECC                     KZ(8).GT.0              SUBSYS

Caveats

The input snapshot is (mass-weighted) centered before integration is started. Not clear why kz(14) still gives some different answers.

By decreasing TCRIT, you observe the integrations at finer details, thus re-syncing all particles again. This will have an effect on orbits

Examples

If you want to use runnbody1 as a NEMO tool with snapshots in and out, here is an example with a 128-body plummer sphere: 
   mkplummer p128 128
   runbody1 p128 run1 deltat=0.1 tcrit=10
This will create a run1/OUT3.snap. Code units are now used, not crossing time units.

If however you want to use the more original NBODY1 flavored run, pay attention to the kz= vector as the default will not suffice anymore. 

   runbody1 outdir=run2 nbody=128 deltat=0.1 tcrit=10 kz=1,2,1,1,1
Note that requesting tcript=10 you will see the final snapshot written at time=28.2843 because the crossing time is about 2.828 and tcrit is measured in terms of crossing times, as opposed to code times for the default run with kz(15)=1.

Benchmark

The command 
     make bench
will run a standard 1280 body plummer sphere benchark to T=10.

Caveats

nbody1 still uses the old-style individual time-steps with force polynomials, not the improved hermite integrater that is embedded in later versions of the NBODYx series. However, Sverre has made versions available with a hermite integrator, see for example the micky-mouse version nbody04h described in nbody0(1NEMO) .

See Also

nbody0(1NEMO) , runbody2(1NEMO) , runbody4(1NEMO) , runbody6(1NEMO) , snapshot(5NEMO) , u3tos(1NEMO) , stou4(1NEMO)

Files


$NEMO/src/nbody/evolve/aarseth/nbody1    nbody code
$NEMO/src/nbody/evolve/aarseth/tools    various tools code
$outdir/fort.1                           restart dump (compile time dep. size)
$outdir/fort.2                             restart dump (compile time dep. size)
$outdir/fort.4                             restart dump (compile time dep. size)
(see stou4(1NEMO) and u4tos(1NEMO))
$outdir/fort.7                             formatted frame files (option KZ(7))
$outdir/OUT3                            particle dump (see u3tos(1NEMO))

Author

Peter Teuben

Update History


4-mar-98    V1.1 documented, and changed out= to outdir=, n= to nbody= PJT
17-mar-04    V1.1a fixed bug when in= was specified
17-mar-06    V1.2 using fullname for in=
7-feb-2019    V2.0 better defaults for snapshot input    PJT
14-feb-2019    V2.1 default run now computes nbody= and converts to snapshot    PJT

Table of Contents