Why Model Galaxies?
Every galaxy is a record of its own history. The way its gas rotates, how fast the outer edges spin relative to the centre, how the disk warps and tilts, encodes the distribution of matter within it, including the dark matter we cannot see directly. Measure the rotation of enough galaxies and you begin to reconstruct how galaxies form, grow, interact, and how the universe assembled the structure we live inside today.
Followed far enough, the question of how galaxies evolve becomes the same question as how we came to be here: how gas collapsed into disks, how disks formed stars, how stars forged the elements that make up planets and people. A rotation curve measured from the faint 21-centimetre glow of hydrogen gas is one small, precise data point in that very large story.
The challenge has always been scale. Modelling one galaxy's kinematics well is hard. Modelling tens of thousands of them, consistently and with rigorous uncertainties, has been beyond reach, not because the science is unknown, but because the compute is enormous. That is the gap this work closes.
First Run
We ported the computational core of the 3KIDNAS bootstrap stage from its original Fortran into JavaScript so it runs natively, sandboxed, inside the Distributive Compute Protocol (DCP). Then we ran it: 1,000 bootstrap realizations of a single galaxy's kinematic fit, distributed across a DCP worker pool. The run completed and produced physically meaningful results: well-behaved distributions for every fitted parameter, the overwhelming majority of realizations converging to sensible, consistent values (a small minority of bootstrap resamples are intrinsically hard to fit, in native Fortran as much as in JS, and are excluded from the aggregate statistics rather than silently averaged in). The port is faithful; the science survives the translation to JavaScript.
The Survey: WALLABY
The Widefield ASKAP L-band Legacy All-sky Blind surveY (WALLABY) is a flagship science project of the Australian SKA Pathfinder (ASKAP) telescope. It is mapping the neutral atomic hydrogen (HI) content of the nearby universe out to a redshift of about z ≈ 0.1, and is expected to detect the gas in roughly 210,000 galaxies.
Detecting a galaxy is not the same as being able to model it. A kinematic model, a rotation curve and a gas density profile, requires a galaxy that is spatially resolved: bright and large enough on the sky that its disk is sampled by several independent telescope beams. Most detections are too small or faint to clear that bar. Based on the survey's own pilot results, the modellable fraction sits in the range of roughly 8% to 18% of detections.
That places the kinematically modellable population on the order of 17,000 to 38,000 galaxies, what the WALLABY team describes as several thousand and more, the largest homogeneous set of HI kinematic models ever assembled. Each one a rotation curve. Each one a data point in the story of cosmic structure.
Each of the six fitted geometry parameters is bootstrapped independently: the pipeline re-samples the galaxy's data, re-fits the tilted-ring model, and repeats. The grid below is a corner plot of that ensemble — every panel below the diagonal is a scatter of one parameter pair across all realizations, and the diagonal shows each parameter's own distribution as a histogram. Where two parameters are correlated, the scatter tilts into a diagonal streak rather than a round cloud; that shape is exactly what a single "± error" on each parameter separately would hide. The rotation curve and surface-density panels on the right show the same idea applied to the radial profiles, one faint curve per realization, tracing out the model's uncertainty at every radius. The plot animates in to make the effect tangible: watch the cloud fill in and the error bars tighten as more bootstrap realizations are added.
The Pipeline: 3KIDNAS
3KIDNAS, the 3D Kinematic Data aNalysis Algorithm for Surveys (pronounced "echidnas"), is an automated kinematic-modelling pipeline developed by WALLABY's technical working group under the leadership of Kristine Spekkens and Nathan Deg. It fits rotating-disk models to HI data cubes and, critically, produces statistically meaningful uncertainties on every parameter it measures.
Those uncertainties are where the cost lives. To know not just a galaxy's rotation speed but how confident we are in it, 3KIDNAS uses bootstrapping: it re-samples the galaxy's data many times, re-fits the model to each re-sampled version, and studies the spread of results. More re-samples means a better-mapped parameter space and tighter error bars. A robust run uses on the order of 1,000 bootstrap realizations per galaxy, and each realization is a complete, independent model fit.
That independence is the key. A thousand bootstrap fits do not depend on one another. They can run at the same time, on different machines, anywhere. This is exactly the workload distributed computing was made for.
What runs where
This port covers the parallel uncertainty stage only, not the full pipeline. The initial galaxy fit is still performed upstream by the original Fortran 3KIDNAS, modified to dump its post-fit state to two JSON files (the fit configuration, observed cube, beam, and best-fit tilted-ring parameters; and the best-fit model cube). Both are shipped to every worker as static arguments, so each sandbox has full context without fetching anything. Each worker then generates one bootstrap realization and runs a complete tilted-ring fit on it.
The Scale: A Staggering Amount of Compute
Here the numbers become vivid. Take the modellable population, 17,000 to 38,000 galaxies. Give each a proper uncertainty estimate, ~1,000 bootstrap realizations. And recognize that a single realization is not cheap: depending on the size and resolution of the galaxy, one fit takes anywhere from several minutes to an hour (our first run measured about 8 minutes on a modestly-sized galaxy; larger, better-resolved systems run longer).
That is on the order of tens of millions of independent model fits and millions of compute-hours. Run serially, it would take centuries. Provisioned on commercial cloud at on-demand rates, it would cost a fortune no research budget is built to absorb. But it is also, structurally, the most parallelizable workload imaginable, millions of small, independent, self-contained jobs. Exactly what DCP exists to run.
DCP Architecture
This workload is a natural fit for DCP's distributed model. Bootstrap realizations are embarrassingly parallel: each slice is independent, stateless, and returns a compact result (best-fit parameters and a goodness-of-fit value). No inter-worker communication is required; aggregation happens only at the job dispatcher.
Reusing the science, not reimplementing it
The original 3KIDNAS pipeline is a stack, not a single program: Python drives the run and calls a compiled Fortran binary for the tilted-ring fit and geometry estimation, which itself shells out to two more native C tools for the heavy numerical work, SoFiA-2 (source finding) and a linked FFTW3 + cfitsio (FFT-based beam convolution and FITS I/O). Hand-porting that C math to JavaScript would be slow to write and easy to get subtly wrong, so we didn't: the same C source compiles, unmodified, to WebAssembly via Emscripten and loads as ordinary modules inside the DCP worker sandbox, sofia2wasm, fftw3wasm-v3, cfitsio4wasm. Only the orchestration around them, tilted-ring model generation, parameter handling, and the Nelder-Mead optimizer itself, was reimplemented in JavaScript, with every floating-point operation wrapped to reproduce Fortran's REAL*4 (float32) rounding exactly rather than silently running in JS's native float64.
Numerical equivalence was checked at both levels before any distributed run was trusted: the wasm FFT build was validated bit-exact against a real compiled libfftw3.a reference binary, and the full bootstrap pipeline's output was cross-checked against native Fortran on the same galaxy (Step 03 below).
Why CPU, not GPU?
The core computation is a two-pass Nelder-Mead (downhill simplex) optimization, an iterative, sequential search with data dependencies between steps. Like most simplex minimizers it maps poorly onto SIMD GPU parallelism. CPU workers are the correct resource, with parallelism expressed at the realization level, one galaxy's thousand fits fanned across a thousand cores, rather than within a single fit.
The Distributive difference
Distributive's compute doesn't come from a hyperscaler's data centre. It comes from machines that already exist and already sit idle, computers at universities, schools, and research institutions, powered on and available. For a workload like WALLABY's, that means the enormous compute bill is not spent on cloud capex and margin; it flows instead to the institutions doing the science, funding hardware refresh and generating value from equipment they already own. A workload that would be prohibitively expensive on commercial cloud becomes tractable, and does so in a way that recirculates the spending into the research community itself.
Collaborators
This project is conducted with the WALLABY kinematic-modelling team and the CanDIAPL consortium. 3KIDNAS is under active development and pre-publication; results here are shared with the pipeline team's awareness.
Contribute compute. Help map the sky.
The first run proved the port. Scaling it to tens of thousands of galaxies will take a great deal of compute, and every DCP worker that joins the network contributes directly to modelling real galaxies from the WALLABY survey. Workers receive model inputs and run fits; no proprietary data leaves any institution.