Output and post-processing

gevolution writes background diagnostics, spectra, field snapshots, particle snapshots, and light-cone data. Output can dominate runtime and storage, so schedule only datasets needed for the analysis.

For exact defaults, output specifiers, schedule behaviour, and light-cone geometry rules, see Output and light-cone settings.

Output overview

Output	Format	Notes
Background	ASCII	One record per integration cycle
Power spectra	ASCII	Dimensionless spectra with \(k\) in h/Mpc
Field snapshots	HDF5	Code units; parallel HDF5 recommended
Particle snapshots	Gadget-2 binary	Standard or multi-file output
Particle light cones	Gadget-2 binary	Written per light-cone segment
Pixelised metric light cones	Custom binary maps	HEALPix sampling; convert with lcmap

Background and settings

<generic file base>_background.dat records cycle, conformal time, scale factor, expansion information, and homogeneous metric/source quantities. <generic file base>_settings_used.ini records parameters consumed by gevolution.

Field snapshots

HDF5 snapshots can contain metric fields, stress-energy fields, momentum, particle density, and derived Newtonian quantities. They use code units.

Use downgrade factor to reduce field resolution where appropriate. The factor must divide each rank's local domain.

Particle snapshots

Gadget2 writes conventional Gadget-2 binary snapshots. multi-Gadget2 allows distributed files and is generally the faster, more scalable choice for large runs. In the current GPU writer, CDM/baryon outputs use one file per MPI rank while non-CDM outputs use one file per rank in process-grid dimension m. Use tracer factor to reduce particle output volume.

Power spectra

Power-spectrum outputs are computed at requested redshifts. With EXACT_OUTPUT_REDSHIFTS, power spectra can be interpolated and Gadget-2 particle positions shifted to the requested redshift; field snapshots remain tied to integration steps.

Light cones

Particle light cones store particles crossing the selected null hypersurface. Metric light cones sample \(\phi\), \(\chi\), \(B_i\), and \(h_{ij}\) on HEALPix shells when HAVE_HEALPIX is enabled.

Numbered light-cone geometries must be contiguous from lightcone 0; parsing stops at the first missing or invalid numbered vertex. Unnumbered settings provide defaults for numbered geometries.

Particle light-cone Gadget2 positions use the same Gadget length units as ordinary Gadget-2 snapshots. The unit is controlled at compile time by GADGET_LENGTH_CONVERSION; use the same definition when building readers and post-processing tools.

The lcmap utility converts or reduces the custom metric-map format to HEALPix/FITS products. lccat supports particle light-cone catalogue post-processing.

GPU staging and I/O

Particle and pixel data reside on the GPU during compute-intensive work. Output staging buffers are prepared on device memory and transferred in bulk to host memory for file output. When CUDA-aware MPI is unavailable or disabled, particle light-cone ID routing, balanced particle sends, and HEALPix communication also use host-staged fallbacks. This reduces fine-grained transfers but means output consumes both GPU memory and temporary host memory.

Planning storage and performance

• Estimate particle bytes, field components, number of redshifts, and light-cone coverage before submission.
• If scheduling more than the default 32 output entries, increase and validate MAX_OUTPUTS, PARAM_MAX_LINESIZE, and PARAM_MAX_LENGTH together.
• Prefer multi-Gadget2 for large particle snapshots.
• Use parallel HDF5 where available.
• Reduce snapshot cadence and use spectra for frequent diagnostics.
• Use tracer and downgrade factors deliberately; both are lossy.
• Benchmark the intended output schedule, not only compute-only runs.
• Ensure the output directory exists and the parallel filesystem has adequate quota and free space.

Advanced builds can tune PCLBUFFER, PIXBUFFER, HEALPIX_SHELL_CHUNK, and PARTICLE_LC_BALANCED_IO. These options trade staging memory, communication, and write balance; benchmark them on the target filesystem.