... | ... | @@ -15,7 +15,7 @@ simulated, the latter provides information about the computational |
|
|
time spent in each part of the code, which can be influenced to some
|
|
|
degree by the values of the code parameters.
|
|
|
|
|
|
For ongoing simulations, these can be checked via::
|
|
|
For ongoing simulations, these can be checked via
|
|
|
|
|
|
tail -n 30 timebins.txt
|
|
|
tail -n 200 cpu.txt
|
... | ... | @@ -35,7 +35,7 @@ balance.txt |
|
|
Output of fractional cpu time used in each individual step, optimized to be
|
|
|
machine readable (while cpu.txt is more human readable).
|
|
|
|
|
|
Symbol key::
|
|
|
Symbol key:
|
|
|
|
|
|
total = '-' / '-'
|
|
|
treegrav = 'a' / ')'
|
... | ... | @@ -84,7 +84,7 @@ Symbol key:: |
|
|
restart = '(' / 'b'
|
|
|
misc = ')' / 'a'
|
|
|
|
|
|
example::
|
|
|
example:
|
|
|
|
|
|
Step= 13147 sec= 0.212 Nsync-grv= 5181 Nsync-hyd=
|
|
|
342 dhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhttwwwwwxxzBBBBBBBBBBBBBBB
|
... | ... | @@ -111,7 +111,7 @@ only the most time-consuming parts of the code. There is the option |
|
|
The different columns are:
|
|
|
name; wallclock time (in s) this step; percentage this step; wallclock time
|
|
|
(in s) cumulative; percentage up to this step. A typical block of cpu.txt looks
|
|
|
the following (here a gravity-only, tree-only run)::
|
|
|
the following (here a gravity-only, tree-only run):
|
|
|
|
|
|
Step 131, Time: 0.197266, CPUs: 1, MultiDomains: 8, HighestActiveTim
|
|
|
eBin: 20
|
... | ... | @@ -167,7 +167,7 @@ domain.txt |
|
|
The load-balancing (cpu work and memory) both in gravity and hydro calculation
|
|
|
are reported for each timebin individually. Reported every sync-point.
|
|
|
Ideally balanced runs have the value 1, the higher the value, the more
|
|
|
imbalanced the simulation.::
|
|
|
imbalanced the simulation.
|
|
|
|
|
|
DOMAIN BALANCE, Sync-Point 13314, Time: 0.997486
|
|
|
Timebins: Gravity Hydro cumulative grav-balance
|
... | ... | @@ -193,7 +193,7 @@ In specified intervals (in simulation time, specified by the parameter |
|
|
written into `energy.txt`. This file also contains the cumulative energy
|
|
|
that had to be injected into the system to ensure positivity in thermal energy.
|
|
|
All output in code units. Note: this only works with up to 6 particle types.
|
|
|
The columns are::
|
|
|
The columns are
|
|
|
|
|
|
1. simulation time/ scalefactor
|
|
|
2. total thermal energy
|
... | ... | @@ -226,7 +226,7 @@ The columns are:: |
|
|
29. total injected energy due to positivity enforcement of thermal e
|
|
|
nergy
|
|
|
|
|
|
Two example lines::
|
|
|
Two example lines
|
|
|
|
|
|
0.96967 3.29069e+06 0 4.27406e+07 3.29069e+06 0 1.65766e+06 0 0 3.93
|
|
|
02e+07 0 0 0 0 0 0 0 0 1.78097e+06 0 0 0 503.489 3047.89 0 0 65.5756
|
... | ... | @@ -239,7 +239,7 @@ info.txt |
|
|
========
|
|
|
|
|
|
Every sync-point, the time-bins, time, timestep and number of active particles
|
|
|
are written into this file, e.g.::
|
|
|
are written into this file, e.g.
|
|
|
|
|
|
Sync-Point 13327, TimeBin=16, Time: 0.999408, Redshift: 0.000592464,
|
|
|
Systemstep: 0.000147974, Dloga: 0.000148072, Nsync-grv: 17679,
|
... | ... | @@ -255,7 +255,7 @@ The reason for introducing this was to avoid memory fragmentation during |
|
|
runtime on some machines, but also to have detailed information about how much
|
|
|
memory Arepo actually needs and to terminate if this exceeds a pre-defined
|
|
|
threshold. ``memory.txt`` reports this internal memory usage, and how much memory
|
|
|
is actually needed by the simulation.::
|
|
|
is actually needed by the simulation.
|
|
|
|
|
|
MEMORY: Largest Allocation = 816.742 Mbyte | Largest Allocation W
|
|
|
ithout Generic = 132.938 Mbyte
|
... | ... | @@ -453,7 +453,7 @@ The individual columns are: |
|
|
* instantaneous star formation rate of all cells (Msun/yr),
|
|
|
* instantaneous star formation rate of active cells (Msun/yr),
|
|
|
* total mass in stars formed in this timestep (after sampling) (code units),
|
|
|
* cumulative stellar mass formed (code units).::
|
|
|
* cumulative stellar mass formed (code units).
|
|
|
|
|
|
4.373019e-01 9.714635e-03 1.100743e+02 1.405136e+02 2.2809
|
|
|
41e-02 2.752464e+01
|
... | ... | @@ -475,7 +475,7 @@ Each for each timestep, a linked list of particles on this particular |
|
|
integration step exists, and their statistics are reported in `timebins.txt`.
|
|
|
In this file, the number of gas cells and collisionless particles in each
|
|
|
timebin (i.e. integration timestep) is reported for each sync-point, as well
|
|
|
as the cpu time and fraction spent on each timebin. A typical bock looks like::
|
|
|
as the cpu time and fraction spent on each timebin. A typical bock looks like
|
|
|
|
|
|
Sync-Point 2658, Time: 0.307419, Redshift: 2.25289, Systemstep: 9.10
|
|
|
27e-05, Dloga: 0.000296144
|
... | ... | @@ -497,7 +497,7 @@ timings.txt |
|
|
|
|
|
The performance of the gravitational tree algorithm is reported in
|
|
|
`timings.txt` for each sync-point. An example of a single sync-point looks
|
|
|
the following::
|
|
|
the following:
|
|
|
|
|
|
Step(*): 372, t: 0.0455302, dt: 0.000215226, highest active timebin:
|
|
|
19 (lowest active: 19, highest occupied: 19)
|
... | ... | |