Table of Contents

The density can be writtin in the slot normally
used for Potentials (the default), or if **write_at_phi=f** be written to a
tag named *Density*.

**in**=*in-file*- Input data will
be read from
*in-file*in snapshot format. **out**=*out-file*- Output data are written
to
*out-file*in snapshot format. **neib**=*value*- Number of neighbors used to determine the local density. The default of 6 is the recommended value by Casertano & Hut (1985) [default: 6].
**rneib**=*value*- Initial radius to search the neighbors.
*Hackdens*adaptively change this search radius during the calculation. Therefore it is definitely required that particles in the snapshot are arranged so that the neighboring particles have similar local density. (See NOTES) [default: 0.1]. **write_at_phi**=*t|f*- Logical if the density data is written in the "Potential" slot of the snapshot file. If false, the density will be written with tag "Density". [default: f]
**rsize**=*value*- Intial size of the root box. Box will automatically expanded to keep all particles in it [defaults:4.0]
**rmin**=*value*- If given, the coordinates of the lower left corner of the initial box. If not given, the center of the root box will lie at the origin. [defaults:none]
**options**=*option-string*- Output control options, specified as a comma-separated
list of keywords. Currently recognized keywords are:
**mass**,**phase**: output mass, phase space data with major data outputs [defaults:mass,phase]. **fcells**=*value*- Ratio of cells to bodies, used when allocating cells [defaults:0.9].
**nudge**=*size*- nudge overlapping particles with this positional dispersion [0]
**verbose=t|f**- Logical if print out the number of particles processed during the calculation [defaults:f].
**density=t|f**- write density, or alternatively distance to Kth particle. Default: t
**ndim=2|3**- 3D or 2D computation [Default: 3]
**direct=t|f**- slower N-squared direct density computation. Default: f
**norm=0|1**- Mode of
normalization. Earlier (2.x and before) versions would scale equal mass systems
by nbody, the current default is norm=1 which normalizes by nbody, so densities
from the slower snapdens(1NEMO)
agree with
**hackdens**. Default: 1

Ideally, it is best if particles are sorted by the local density itself. Since the local density is not available, the second choice is to sort particles with some quantity that has strong correlation with the local density. For example, if the potential is available, sort particles by potential.

In many cases the system is roughly spherically symmetric. That means the density has strong correlation with the distance from the center of the cluster. Then sorting particles by the distance from the center will improve the speed significantly.

snapcenter nbody.dat nbody.centered

snapsort nbody.centered nbody.sorted

hackdens nbody.sorted nbody.density

One can also weight the particles by its potential to some power. For this we create a Plummer sphere, without centering, and compute the center in two ways:

mkplummer - 100 zerocm=f | snapsort - - rank=r > p.dat

snapcenter p.dat . report=t

hackdens p.dat - | snapcenter - . weight=dens report=t

hackforce p.dat - | snapcenter - . weight="-phi*phi*phi" report=t

hackforce p.dat - | snapcenter - . weight="phi*phi*phi*phi" report=t

Note that in this case the Plummer sphere should have the correct mathematical
center, and not *centered*. This snippet of code is expanded in a script $NEMO/scripts/csh/centering.sh,
in which these different methods can also be applied to different models,
as expanded in the following table.

nbody=100 models: Plummer
King1 King3 King5 DeVauc

-------------------------------------------------------------

snapcenter on m: 0.102 0.029* 0.030* 0.033 0.299

snapcenter on dens: 0.060 0.039 0.036 0.030 0.030*

snapcenter on phi: 0.053

snapcenter on phi^2: 0.050*

snapcenter on phi^3: 0.052 0.032 0.030 0.026* 0.035

snapcenter on phi^4: 0.054 0.034 0.032 0.027 0.031

snapcenterp: 0.080

snapmnmx on min phi: 0.122

snapmnmx on m 50% phi: 0.058

snapmnmx on m 33% phi: 0.063 0.053

snapmnmx on m 25% phi: 0.067

rockstart on m: 0.082:

A (*) denotes the best method for that model.

Although for a Plummer sphere the best method is more than twice as good than the worst method, this does not apply to other models.

*density(1falcON)*
is considerable faster,
about twice with their K=32 default.

mkplummer - 100000 |\ snapscale - -
mscale=10 |\

snapsort - - |\

density - - give=mxvr |\

snapshell - ’10**[-4:4:0.1]’ dens |\

tabmath - - ’log(%1),log(%4)’ all |\

tabplot - 1 2 -4 4 -14 2 line=1,1 point=2,0.1

vs.

mkplummer - 100000 |\ snapscale - - mscale=10 |\

snapsort - - |\

hackdens - - |\

snapshell - ’10**[-4:4:0.1]’ dens |\

tabmath - - ’log(%1),log(%4)’ all |\

tabplot - 1 2 -4 4 -14 2 line=1,1 point=2,0.1

The density in
*snapdens(1NEMO)*
and *density(1falcON)*
are in the correct units, but in
*hackdens(1NEMO)*
seem to be off by **nbody** for equal mass particles. For example,
a Plummer sphere in virial (nbody) units should have a central density

(32/(3.pi^2))^2 ~ 1.168

https://ui.adsabs.harvard.edu/abs/1985ApJ...298...80C/ - Casertano & Hut (1985)

Presorted snapshot: 5 minutes on Sun-3/60, particles are presorted by the distance from the center of mass of the system.

Random snapshot: 60 minutes Sun-3/60

2-Dec-88V1.0:CreatedJun 6-jul-89doc updated?Jun 23-oct-90doc updatedPeter 18-jul-92printf -> dprintf to make it pipablePeter 24-may-02fixed running out of bits for large-NPJT 11-aug-2022added example hackforce vs. hackdensPJT 21-sep-2023added direct=PJT 11-oct-2023V3.0 added norm=1 as a new defaultPJT 12-oct-2023V3.0 proper mass/nbody scalingPJT