Release notes and migration

Version 2.0 status

gevolution 2.0 is an alpha/developer-preview GPU port. The user interface is largely inherited from version 1.3, but the execution model and several features differ.

Migration matrix

Area	Version 1.3	Version 2.0 GPU
Compute model	MPI-only, commonly one rank per CPU core	MPI + OpenMP + CUDA
Preferred rank layout	Many CPU ranks	One rank per GPU
Minimum process grid	2 x 2	2 x 2
One-GPU workstation	Not applicable	Four ranks sharing one GPU through MPS
Settings syntax	ASCII/CLASS-compatible	Nearly unchanged
Basic generator	Supported	Supported
Read from disk	Supported	Supported
prevolution	Optional legacy module	Removed
FalconIC	Optional legacy module	Removed
LTB / curvature generator	Available in v1.3	Not included in the GPU code
RELIC / second-order ICs	Available in suitable builds	Optional, not production-supported by default
Hibernation checkpoints	Supported	Checkpoint writes disabled
LATfield2 external I/O server	Optional	Not yet ported; compilation is blocked
Particle handler	Linked-list-oriented CPU implementation	Dense row-oriented GPU implementation
Mesh loops	Serial/MPI site loops	CUDA lattice_for_each callable structs
FFT	Distributed FFTW	Hybrid cuFFT/FFTW with CUDA-aware or host-staged MPI

Changed operational assumptions

• NVIDIA CUDA hardware is required.
• At least four MPI ranks are still required, because both process-grid dimensions must contain distinct neighbours.
• Production jobs should assign one rank per GPU and use OpenMP for host cores.
• Four ranks can share one workstation GPU through MPS.
• GPU memory, not only host memory, is a primary capacity limit.
• CUDA-aware MPI strongly affects FFT, halo-exchange, and light-cone communication performance, but host-staged fallbacks are supported.
• Output and non-CUDA-aware MPI staging use additional device and host memory.

Settings compatibility

Most v1.3 settings remain valid. Before reusing a settings file:

1. Remove hibernation schedules and wallclock limits.
2. Remove legacy IC generator selections.
3. Confirm optional compiler features are enabled.
4. Recalculate the process grid and verify Ngrid constraints.
5. Review output volume and GPU memory demand.
6. Run a reduced validation case before production.

Review the detailed compatibility table and the expanded settings reference. In particular, Omega_k and the LTB/non-flat workflow from v1.3 are not parsed by the current GPU path, and parser acceptance of hibernation metadata does not imply that checkpoint writing is supported.

Known limitations

• GPU checkpoint/hibernation writes are disabled.
• The LATfield2 external I/O server is not yet ported to the GPU backend.
• The release is CUDA/NVIDIA-specific.
• Second-order initial-condition workflows are not part of the default production-supported build.
• Some source retained from the CPU version does not represent supported GPU behaviour.
• Performance is often limited by distributed FFT communication and I/O rather than particle updates.

Planned documentation work

Future revisions should expand platform-specific installation recipes, validated memory-footprint models, end-to-end scientific validation suites, and specialised extension-development examples.