| 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
