Meraxes Bottleneck Review &
Next-Generation Tree Input Optimization

The project at a glance

• Two largely independent tracks, guided by profiling done first.
• Track A — GPU rejuvenation: audit, repair, and re-validate the legacy CUDA reionization module so it runs on today's machines and codebase.
• Track B — Tree input: cut merger-tree read time with a compact representation, and add native support for HBT merger trees.
• Planned deliverables: a validated GPU module · an optimised tree-I/O pipeline · an HBT tree reader — everything developed proposed upstream, with documentation and handover.
• 10 weeks of development effort.

Why: where the time goes

• Cheaper model evaluations open the door to Bayesian parameter inference and faster turnaround for the student projects.
• First step is measurement: confirm exactly where the time goes before optimising.

GPU rejuvenation

• The CUDA module (ADACS 2017) accelerates the reionization bubble-finding — the most expensive per-snapshot computation.
• Untouched since 2022; it no longer builds against the current code, compilers and libraries — a full audit and repair is budgeted.
• Then: integrate with today's codebase and validate scientific equivalence against the CPU path on Gadi and OzSTAR.
• Success: compiles, runs, agrees with the CPU results on an agreed test suite, speed-up measured and documented — plus handover so the team can maintain it.

Tree input: compact representation + HBT

• Profile first: confirm the read is data-volume-bound and fix the measurement baseline.
• Design and implement a compact/compressed tree format — packed properties, dense indices, dropping unused data — with conversion of existing suites.
• Target: ≥3× faster tree reads (profiling-led; flagged best-effort in the assessment).
• Add an HBT tree reader beside the existing VELOCIraptor and gbpTrees readers, validated end-to-end on Chris's tree products.

The shape of the ten weeks

Indicative sequence — overheads are spread through the project in practice, and the GPU and tree tracks are independent, so work can interleave. Profiling gates the tree-format design.

Science configurations & validation

• Which physics configurations must the GPU path support — recombinations? UV background feedback? minihalos / spin temperature?
• Which simulation and run configuration is the benchmark — the one behind the 40-minute number?
• What does "scientifically identical" mean quantitatively — which observables, what tolerances?
• Is lossy compression of tree data ever acceptable, and for which halo properties?
• What's the priority order across GPU, tree compression, and HBT?

Data, systems & ways of working

• HBT trees: which HBT variant, sample products + format documentation, and how the forest metadata is generated.
• Systems: Gadi & OzSTAR project codes, storage, GPU queues and CUDA versions.
• Workflow: how code changes are reviewed and merged into the main Meraxes repository (smutch/meraxes).
• People: meeting schedule, and how we coordinate with the student projects and their deadlines.

Next steps

• Weeks 1–2 (one week of profiling plus setup overheads): access and environments on both machines · reproduce a reference run · profile the tree read and the reionization compute · circulate the baseline report.
• In parallel: the GPU audit — it does not depend on the profiling results; only the tree-format design does.
• Progress tracked openly in a shared task-level plan; regular check-ins at the cadence we agree today.

Thank you!