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 to within about 2.5 points. 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 33,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 the agency models LEGEND, DAMAGE and MOCAT. 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 dead objects, and two working satellites avoid each other 99.99% of the time; dead satellites 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. 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 a traffic file built from the launch record and the constellation filings: each constellation shell is built up to its filed size at a stated pace and replenished for the life of the run; other traffic repeats the recent average. 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 whose object count passes 2 million is stopped and scored as a runaway at that year. 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 (immediate reentry 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 233,280 scenarios and about 130 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 showed that far more than the customary hundred runs are needed to capture the inherent variability of these models. Kessler@home applies hundreds of realizations per scenario, and thousands where it matters, across a sweep of eleven variables. A single realization takes from ten minutes to a few hours of one processor core; the sweep is on the order of ten thousand processor-years. 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. What each check found, including where the model is weak, is written up in the application document in the project repository.

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 be bitwise reproducible: one fixed random-number generator, every random draw in a fixed order, no fused or extended-precision arithmetic, and a single thread. 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 and operational status come from the public satellite catalog via CelesTrak; masses, sizes, object types and the breakup history from Jonathan McDowell's GCAT; a few missing masses and sizes 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 F10.7 record. Orbital elements are de-identified before distribution so that no restricted catalog data is redistributed, and nothing from licensed models is redistributed at all.