Reading AREPO data (experimental)
The AREPO/IllustrisTNG gas workflow below — physical getvar(:rho/:T/:metallicity), PDFs/profiles, and point / SPH-kernel / Voronoi maps on real snapshots — runs end-to-end in 16_multi_OtherCodes.ipynb, rendered as Other Simulation Codes — Worked Examples.
AREPO is a moving-mesh code: gas lives in the cells of a Voronoi tessellation that moves with the flow. It writes the GADGET HDF5 snapshot layout (shared with IllustrisTNG, which is AREPO), so Mera reads it through the same frontend as GADGET — but it is auto-detected as AREPO (from the Config group AREPO writes) and reported as Code: AREPO, and its gas-cell physics is read in physical units. Everything downstream (getvar, projection, pdf, profile, …) then runs unchanged.
Gas (PartType0) loads into a Mera PartDataType — a point-with-volume per Voronoi cell (the snapshot stores the mesh-generating points and per-cell scalars, not the cell faces). DM/stars/BH load as particles. Cosmological a/h is applied automatically. 3-D Cartesian.
Usage
getinfo / getparticles auto-detect the code from the HDF5 Header:
using Mera
info = getinfo(59, "/data/TNG/halo_59") # prints "Code: AREPO" + redshift/H0/Ω for a cosmological run
gas = getparticles(info; families=[0]) # PartType0 gas → :x,:y,:z,:vx,:vy,:vz,:mass,:id,:family + cell fields
msum(gas, :Msol); getvar(gas, :T, :K) # the usual particle analysis, unchanged:family is the particle type (0 gas, 1 DM, 4 stars, 5 BH); families= restricts the load. Use getparticles_gadget directly for the families= option on huge snapshots.
Gas-cell physics
For PartType0, the cell fields present in the file are read as columns and a per-cell volume is derived; getvar adds the thermodynamic quantities. All returned in physical units.
| AREPO/TNG dataset | Mera symbol | notes |
|---|---|---|
Coordinates, Velocities | :x,:y,:z, :vx,:vy,:vz | comoving→physical a/h (and √a on velocity) applied |
Masses | :mass | cell mass |
Density | :rho | × h²/a³ to physical |
| (derived) | :volume | = mass/ρ — the Voronoi cell volume |
InternalEnergy | :u | specific internal energy |
ElectronAbundance | :ne | sets the mean molecular weight μ |
GFM_Metallicity | :metallicity | metal mass fraction |
StarFormationRate | :sfr | M⊙/yr |
MagneticField | :bx, :by, :bz | MHD field; comoving→physical a⁻² and cgs→Gauss baked in — getvar(:bx, :muG) / :Gauss / :nG |
Potential | :gpot | gravitational potential (peculiar, a⁻¹); present on all particle types |
NeutralHydrogenAbundance | :nh | neutral-hydrogen fraction (dimensionless) |
Star particles carry GFM_StellarFormationTime as a scale factor, not an age. age_from_aform converts it: age_from_aform(info, aform; unit=:Gyr). It returns NaN for the negative aform values that mark wind particles in IllustrisTNG, so they drop out of statistics instead of becoming spurious ages. (The RAMSES equivalent, starting from a :birth time, is stellar_age.)
| Machnumber | :mach | cell Mach number (dimensionless) | | (derived) | :T, :p, :cs | T = (γ-1)·u·μ·m_H/k_B; μ from :ne (neutral-primordial fallback if absent) |
getvar(gas, :rho, :g_cm3) # physical density
getvar(gas, :T, :K) # temperature [K] — matches the official TNG formula
# (bare `getvar(gas, :T)` is code units, as for :p/:cs)
getvar(gas, :metallicity) # metal mass fraction
getvar(gas, :bmag, :muG) # |B| [μG]; also :pmag (:Ba), :beta, :v_alfven (:km_s), :mach_alfven/fast/slow
pdf(gas, :rho); profile(gas, :r_sphere, :T) # PDFs / radial profiles on the gasThe temperature reproduces IllustrisTNG's documented conversion (density to machine precision, temperature to sub-percent), so the values match what TNG itself reports.
Cosmological runs
A run is treated as cosmological when Ω_Λ > 0; then Time is the scale factor a and the comoving→physical factors are applied automatically (positions ∝ a/h, density ∝ h²/a³, mass ∝ 1/h, velocities × √a). H₀, Ω_m, Ω_Λ come from the Header, so iscosmological, redshift and the cosmology utilities work. A non-cosmological AREPO run (Ω_Λ = 0, e.g. an idealised cluster) is left in code units with a = 1.
Maps — projecting a moving mesh
A Voronoi cell is neither a grid cell nor an SPH particle, so projection offers three depositions (weighting=):
:mass(default) — deposit each cell at its point; fast, mass-conserving, but speckly.:sph— smear each cell over an M4 kernel sized from its volume (h = (3V/4π)^⅓); smooth and mass-conserving — the standard moving-mesh rendering, as in yt.:voronoi— sample each line of sight through the nearest cell (KD-tree, capped at the cell radius): sharp, genuinely cell-respecting. Intensive maps (:T, metallicity) are exact; surface density is approximate (use:sph/:massfor conserving column mass).
projection(gas, :sd, :Msol_pc2) # surface density (mass-conserving)
projection(gas, :T, weighting=:sph) # smooth temperature
projection(gas, :T, weighting=:voronoi) # sharp, cell-respecting temperatureA fully Voronoi-exact renderer (re-tessellate + analytic polyhedron–pixel integration, as in AREPO's ArepoVTK) would be more faithful still, but is rarely needed.
An IllustrisTNG halo cutout (±400 ckpc around one galaxy) is centrally concentrated, so its maps do not fill the frame — that is physical, not a bug. A full simulation volume (e.g. an AREPO cluster-merger box, or a cosmological box) fills the frame.
How it maps onto Mera's structs
Gas is a PartDataType carrying an explicit :volume column — not a HydroDataType. A Voronoi cell has an independent per-cell volume and arbitrary shape, so it cannot be placed on Mera's power-of-two AMR octree (where the volume is a function of level alone and the cells tile to boxlen³). Keeping gas as points-with-volume is honest: stored columns pass through getvar directly, mass is read (not derived), and the particle analysis works unchanged. The reader is the GADGET frontend (getinfo_gadget/getparticles_gadget) with the gas-field and a/h handling described above.
Reference readers
This frontend agrees with the origin tools for AREPO/TNG data:
- illustris_python — the official TNG loader; the field layout, unit conventions and temperature formula are matched against it.
- yt — reads AREPO as SPH-like (smoothing length from cell volume), the same approach as Mera's
weighting=:sph. - ArepoVTK — AREPO's own Voronoi ray-tracer (the exact, re-tessellating renderer).
See also
- Multi-code support — the code-blind architecture and the sibling readers.
- Reading GADGET data — the shared HDF5 frontend (GADGET/GIZMO/SWIFT).
- Other Simulation Codes — Worked Examples — the executed notebook.