Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Arepo Arepo
  • Project information
    • Project information
    • Activity
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Model experiments
  • Analytics
    • Analytics
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Commits
Collapse sidebar
  • Volker Springel
  • ArepoArepo
  • Wiki
  • Userguide
  • diagnosticfiles

diagnosticfiles · Changes

Page history
Update diagnosticfiles authored Aug 28, 2019 by Rainer Weinberger's avatar Rainer Weinberger
Hide whitespace changes
Inline Side-by-side
userguide/diagnosticfiles.md
View page @ 12b6a60a
......@@ -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)
......
Clone repository
  • Home
  • userguide
    • Getting started
    • config options
    • development
    • diagnosticfiles
    • migration
    • parameterfile
    • simtypes
    • snapshotformat