flamingo-lightcones

name	flamingo-lightcones
description	FLAMINGO past-lightcone products: virtual observers, particle lightcones, HEALPix shell maps, integrated_maps, and halo lightcones. Use when building mock surveys, stacking Compton-y or lensing maps, or cross-correlating with observations.

FLAMINGO lightcones

Source of truth: Lightcone outputs

During the run, SWIFT records particles (and derived maps) as they cross each virtual observer’s past lightcone. Products are not recoverable by post-processing snapshots alone.

Product families

Under each run directory (see flamingo-simulations layout):

Subdirectory	Content
particle_lightcones/	Particles at crossing with lightcone time/position
healpix_maps/	Full-sky HEALPix maps in redshift shells
integrated_maps/	Post-processed redshift-integrated HEALPix maps
halo_lightcone/	Haloes placed on the lightcone (minimal properties + indices to SOAP/HBT)

Portal subpages cover directory layout, file format, shell redshifts, and IO for each family.

Virtual observers

• 1 Gpc boxes: 2 observers (halfway from box centre to two opposite corners).
• 2.8 Gpc and larger: 8 observers (halfway from centre toward corners).

Exact comoving Mpc coordinates are tabulated on Observer positions.

Larger boxes extend single-observer reach; 1 Gpc runs need periodic replication to reach high redshift (correlated copies, not new realisations).

HEALPix shell maps

Maps are built in spherical redshift shells. Quantities include (among others): ComptonY (tSZ), DopplerB (kSZ), DarkMatterMass, gas/stellar/BH/neutrino maps, X-ray-related fields — each with documented units and whether SPH smoothing was applied. Full list: Map descriptions.

Shell redshift edges: Shell redshifts.

Shell maps vs integrated maps: at high z, shell width can exceed the box; periodic replication can correlate structure. Integrated products in integrated_maps/ apply a documented rotation scheme so integrated observables are mutually consistent; shell maps are not rotated the same way. Read Integrated lightcones before cross-correlating shell and integrated products.

Particle lightcones

Per particle type and observer: crossing position, velocity, mass, ID, expansion factor at crossing, plus type-specific fields (temperature, Compton-y weight, etc.). Use when an observable is not provided as a HEALPix map.

Halo lightcones

Per redshift shell HDF5 files; haloes traced with black holes, minimal properties plus indices into HBT-HERONS and SOAP for full properties. Portal documents format and the lightcone_io Python module for reading and sky cuts.

When to use which product

• Mock CMB secondaries / WL / X-ray maps: start with healpix_maps/ or integrated_maps/ as appropriate to the analysis.
• Cluster samples vs observations: halo lightcones + map cutouts.
• Custom observables: particle lightcones.
• Off-lightcone 3D work: flamingo-snapshots, not lightcones.

Full-sky tSZ: integrated Compton-(y) for (D_\ell^{yy})

For binned (D_\ell^{yy}) (and Cobaya tSZ likelihoods), use an integrated, rotation-corrected full-sky map at NSIDE=4096 — not per-shell ComptonY HDF5 alone.

Per-shell ComptonY under
.../healpix_maps/nside_4096/lightcone0_shells/shell_N/...
is useful for exploration but is not the map used for integrated (D_\ell^{yy}): shells need rotation and redshift integration; mismatched frames break halo–map work. See portal integrated lightcones.

Recommended: portal integrated_maps/yang26 (lensed, rotation-corrected)

Portal path (hdfstream, dataset data)	Typical local cache	Availability (verify on portal)
FLAMINGO/<run>/<run>/integrated_maps/yang26/lightcone0_shells/lensed_tSZ_rot_same_rot.hdf5	data/maps/{run_id}/tsz_lensed_rot_same_rot.fits	L2p8_m9, L1_m9

• Stream the full data vector once via hdfstream ((\sim 2\times 10^8) pixels, multi‑GB), then healpy.write_map locally (RING, NSIDE=4096).
• Do not sum per-shell ComptonY over the network unless you have verified rotation and integration against the release integrated product.
• Do not mix lensed (yang26) and un-lensed (ComptonY_rot_*.fits on RDS) products across runs — amplitudes differ by (\mathcal{O}(10\text{–}15%)).
• Runs without yang26 tSZ on the portal (e.g. L1_m8, L1_m10 at time of writing): skip tSZ power spectra / tSZ Cobaya for that run until the portal product exists — do not silently substitute another map family.

Reference implementation:
/scratch/scratch-lxu/flamingo_data_analysis/autoflamingo (code/download_tsz_map.py, docs/sim_matrix.yaml).

Legacy FITS on COSMA RDS (optional; verify per run)

Some hydro runs expose ComptonY_rot_0.fits on /rds/flamingo/ (integrated, un-lensed product). Example (HYDRO_FIDUCIAL / L2p8_m9):

/rds/flamingo/L2800N5040/HYDRO_FIDUCIAL/lightcone0_shells/ComptonY_rot_0.fits

Use only when the yang26 portal HDF5 is unavailable and you have confirmed this is the product your pipeline expects. Prefer portal yang26 for cross-run consistency.

Gotchas

• Read units from HDF5 attributes per map (Compton-y dimensionless, kSZ as Doppler b, masses in documented units).
• Each observer is a different sky; do not mix observers as independent cosmological realisations without checking portal guidance.
• IO helpers (lightcone_io, healpy) are documented on the portal — follow those pages rather than guessing map pixelization.
• tSZ power spectra: integrated NSIDE=4096 map from yang26 (preferred) or a single verified ComptonY_rot_*.fits — not per-shell ComptonY HDF5 alone.

Related skills

• flamingo-halo-catalogues — SOAP/HBT definitions referenced by halo lightcones
• flamingo-simulations — box size and observer count
• flamingo-power-spectra — matter P(k) complementary to map statistics