The science

Kessler@home runs very large Monte Carlo ensembles of the long-term evolution of the low Earth orbit (LEO) object population. This page explains what one simulation does, what is varied between simulations, and how many of them combine into a probability map.

Scenarios and realizations

A scenario is a complete set of assumptions held fixed: the starting population, the future launch traffic, how reliably operators dispose of their satellites, how often a small debris hit kills a satellite, how much debris is actively removed, how fast the upper atmosphere thins, and which physical models are used. A realization is one random draw of how events unfold under that scenario, a single simulated 200-year future.

What is random within a scenario: which pairs of objects collide, the fragment cloud each collision produces, which satellites fail to dispose of themselves, which close approaches are not avoided, which dead satellites and rocket bodies explode, when each launch happens and exactly where it goes, how long each satellite lasts, and which satellites are hit by small debris. Everything else is fixed by the scenario.

A BOINC workunit is one scenario plus one random seed, which is a whole number that starts the random-number generator. Your computer runs that future and returns a compact summary. The same seed always gives the same future, bit for bit, on any computer.

Each scenario gets 400 realizations in a first pass, enough to know its runaway probability with a standard error of at most 2.5 percentage points (about 5 percentage points either way at 95% confidence). Scenarios that come out near the boundary between stable and runaway, or where a rare outcome is the question, get a second pass of 2,000 or more. One scenario with all its realizations is one Monte Carlo simulation; the sweep of scenarios is the map.

What one realization computes

Orbit propagation. Objects in orbit do not attract each other measurably, so each one moves independently under Earth's gravity, with atmospheric drag that follows the solar cycle, and with the pull of the Sun and Moon for objects whose orbits reach high above LEO. About 36,000 objects 10 cm and larger are tracked individually in 5-day steps, from a starting population built from the public catalog as of October 2026.
Collisions. Each step, objects are placed at sampled positions and binned into 10 km cubes; a collision probability is computed for each pair sharing a cube, and dice are rolled. This is the cube method used by NASA's LEGEND, the UK's DAMAGE and MIT's MOCAT-MC. Dense constellation layers only a kilometer thick are too thin for a 10 km cube to resolve, so for them the collision rate is computed analytically from the objects' real radial spread (the Kessler 1981 rate). Working satellites with propulsion avoid 99% of collisions with objects that cannot maneuver, and two satellites with propulsion avoid each other 99.99% of the time; dead satellites and working satellites without propulsion avoid nothing.
Fragmentation. Collisions and explosions are broken up with the NASA Standard Breakup Model, which sets the number, size, speed and area-to-mass of the fragments from the masses and impact speed involved, and conserves mass: what the many small fragments do not carry stays in a few large pieces. Fragments 10 cm and larger join the tracked population; smaller ones join the small-debris field.
Small debris. Fragments between 1 and 10 cm are counted as a density per 50 km altitude shell rather than tracked one by one. They hit tracked objects at the rate the density implies. How often such a hit ends a satellite's mission, leaving it stranded, is one of the scenario variables (from never to always), because the real answer is not known.
Launches and behavior. Future launches follow one of three traffic files built from the launch record and the constellation filings: what is licensed or under construction, built at a realistic pace and replenished for the life of the run; every filed constellation built to its full filed size; or the 2024 to 2026 launches repeated. Launches outside the constellations continue at recent rates. Satellites live their design life, give or take a quarter, and then dispose of themselves with the scenario's reliability. Launches stop in 2076 for the runaway test. Operators never react to a worsening environment in any scenario, so a runaway result means "if nothing is done".
Runaway test. After launches stop, a 50 km altitude shell is in runaway if its fragment population keeps growing anyway, because collisions outpace drag. A run is stopped, and scored as a runaway at that year, once its tracked objects (those 10 cm and larger) pass 2 million; the 1 to 10 cm debris, which is counted per shell rather than tracked one by one, does not count toward that limit. Each realization answers yes or no per shell, with the year, and hundreds of realizations turn that into a probability.

What is varied

Eleven settings are swept, every combination of their options: the launch traffic model (what is licensed, what is filed, or the recent past repeated), the traffic volume, the layout of the planned 1,150 km constellation shells, disposal reliability (90% to 99.9%), the disposal rule (lower the orbit to 350 km, which leaves a few years in orbit for most satellites, or the 25-year rule), how often a small debris hit kills a satellite, the debris removal rate (none to 50 objects a year), the amount of small debris today, solar activity, whether old rocket bodies still explode, and how fast CO₂ thins the upper atmosphere. That is 302,400 scenarios and about 170 million realizations. Where an input is uncertain, its options are spread over the whole plausible range rather than placed where one run suggests the answer bends.

Why volunteer computing

Lidtke, Lewis and Armellin (2017) ran 25,000 realizations of a single scenario and found that about 60 runs pin down the average outcome. A probability needs more: with N runs its uncertainty is about the square root of p(1 − p)/N, so a runaway probability near one half needs hundreds of runs to be known to a few percentage points, and a rare outcome many more. Kessler@home applies hundreds of realizations per scenario, and thousands where it matters, across a sweep of eleven variables. A single realization takes from about ten minutes to a few hours of one processor core, and the sweep has about 170 million of them. No single research group has that much compute to spare; volunteers do.

How the model is checked

Before any work is sent out, the application is tested against things that can be checked. Its collision rate on the 2009 population reproduces the Inter-Agency Space Debris Coordination Committee comparison study within the published range of the agency models, and that benchmark is rerun after every change to the code. Its 1 to 10 cm debris field is compared with ESA's MASTER-8 model. Its fragment clouds are checked against six real breakups in the public catalog (Fengyun-1C, Cosmos 2251, Iridium 33, Cosmos 1408 and two exploded Briz-M upper stages), following how fast each cloud actually decayed. The same scenario has also been run through MIT's open MOCAT-MC model for comparison. See the Validation page for more information on how the validation was done.

Reproducibility

These simulations are chaotic: a change in the last bit of one floating-point number can change whether a collision happens, after which two runs diverge completely. BOINC checks results by running each workunit on two computers and comparing them, so the application is built to give the same result, bit for bit, on every computer. Every random draw is fixed by the seed, the time step, the object or pair of objects involved and the purpose of the draw (using Philox, a counter-based random-number generator), so no draw depends on the order in which objects are processed. Every mathematical function is correctly rounded (the CORE-MATH library), and the combined multiply-and-add step those functions rely on is always computed exactly, by the processor or in software. The results are identical on Linux, Windows and macOS, on x86-64 and ARM processors, and on graphics cards: the GPU versions work on many objects in parallel and are checked bit for bit against the CPU version. The application is built for processors on Linux (x86-64 and ARM64), Windows (x86-64) and macOS (Intel and Apple Silicon), and for NVIDIA graphics cards (CUDA) on Linux x86-64, Linux ARM64 and Windows and AMD graphics cards (HIP) on Linux x86-64 and Windows. A useful side effect is that any realization can be regenerated exactly from its scenario and seed, so only summaries need to be returned.

Data sources

Orbits come mostly from the public satellite catalog via CelesTrak, the rest from Jonathan McDowell's GCAT; whether a satellite is still working comes mostly from GCAT, with CelesTrak's operational status for some; masses, sizes, object types and the breakup history from GCAT; the average cross-section of most intact objects, and a few missing masses, from ESA's DISCOS database, as rounded derived values; the 1 to 10 cm debris field is reconstructed from the catalog's breakup history with the NASA breakup model and compared with ESA MASTER-8; future traffic from the launch record and the constellation filings; observed solar activity from the historical record of the Sun's radio flux at 10.7 cm wavelength (F10.7), the standard measure of how much the Sun heats the upper atmosphere. Orbital elements are de-identified before distribution so that no restricted catalog data is redistributed, and nothing from licensed models is redistributed at all.