Why nuke simulators show different numbers (and how to compare them)

nongyi531415 — Fri, 02 Oct 2026 14:37:02 +0000

After I posted a short video of a simulated 15 kiloton airburst, a viewer commented that they had checked another calculator and got different numbers. That is a fair point, and the answer is not that one tool is broken. Blast simulators make different modelling choices, and those choices move the rings a lot.

I build Kaboomly, a free nuke map that runs in the browser, so here are the four choices that matter most.

1. Airburst or surface burst

The same weapon behaves very differently depending on where it goes off. An airburst spreads the blast wave over a wider area, so the light-damage rings get bigger. A surface burst gives smaller blast rings but pulls soil into the fireball and creates local fallout. Some tools default to one, some to the other.

2. Burst height

Even among airbursts, height matters. There is a height that maximizes the area of a given overpressure, and it is different for every pressure level. Kaboomly does not optimize this. It takes one documented historical example, Hiroshima at about 1,670 ft for roughly 12.5 kt, and scales it with the cube root of the yield. A tool that picks a different height will show different rings for the same yield.

3. Which threshold a ring represents

A ring labelled "heavy damage" might be drawn at 5 psi in one tool and at 10 or 20 psi in another. Thermal rings can mean first, second or third-degree burns, and the distance changes a lot between them. Always check the legend before comparing two maps.

4. Scaling law and source data

Most public calculators, including NUKEMAP and Kaboomly, trace back to The Effects of Nuclear Weapons by Glasstone and Dolan (1977). Blast distances scale with the cube root of yield, so ten times the yield gives only about 2.15 times the distance. The fireball has its own scaling, about W^0.4. Tools that use rounded rules of thumb instead of the published curves will drift, especially at very small or very large yields.

An example

For a 15 kt airburst Kaboomly shows the 5 psi ring at about 1.6 km (1.0 mi) and the 1 psi ring at about 4.5 km (2.8 mi). If another tool uses a surface burst or a different height, its numbers for the same yield can be noticeably smaller or larger, and both can be correct for their own assumptions.

What I did about it

On Kaboomly every result shows the burst type and the thresholds, and there is a page explaining how the numbers are calculated with references. The site never shows casualty estimates, only the rings and the number of residents living inside an area.

If you compare simulators, compare like with like: same yield, same burst type, same threshold. The differences mostly disappear.

Splitting a large image across multiple printed pages without alignment marks

nongyi531415 — Fri, 18 Sep 2026 00:46:00 +0000

I recently added tiled printing to a small static tool I run (ArtGrid) — the kind of "print a big image across several A4 sheets and tape them together" feature you've probably seen in poster-printing tools. The naive version is easy: slice the enlarged image into a grid of page-sized rectangles, export each as a PDF page. The annoying version is making the pieces line back up on paper, where a fraction of a millimeter of printer scaling error compounds across every seam.

Most tools solve this with alignment marks — corner crosses or registration dots you have to trim to and match by eye. I skipped that entirely by changing where the cuts land.

The trick: cut on lines that are already there

My tool overlays a grid on the reference image — rows and columns of equal square cells, used for the classic grid-method drawing technique. Once you're enlarging that grid to poster size, you already have a full set of straight lines running across the whole surface. If every page boundary is forced to land exactly on one of those grid lines, the seam is the line. There's nothing to trim, because the join is a continuation of a mark you were going to draw anyway.

The constraint this puts on the math: instead of dividing by fixed page dimensions, you divide by however many whole cells fit on a page, and let the last row/column of pages be a partial page if it doesn't divide evenly.

function tileGeometry(geometry: GridGeometry): TileResult {
  const area = tileArea(geometry.paper); // printable area minus margins
  const { drawingCell, columns, rows } = geometry;

  if (drawingCell > area.w || drawingCell > area.h) {
    return { ok: false, error: `cell ${drawingCell}mm exceeds printable area` };
  }

  const colsPerPage = Math.floor(area.w / drawingCell);
  const rowsPerPage = Math.floor(area.h / drawingCell);
  const pagesX = Math.ceil(columns / colsPerPage);
  const pagesY = Math.ceil(rows / rowsPerPage);

  return { ok: true, value: { colsPerPage, rowsPerPage, pagesX, pagesY,
    pageCount: pagesX * pagesY } };
}

Each page then covers a [colStart, colEnd) × [rowStart, rowEnd) slice of cells, and the pixel crop for that page is just that slice's bounding box in the source image, scaled the same way the whole grid was scaled. Cutting on floor(printable_area / cell_size) rather than on the raw page dimension is the entire trick — it's a one-line change from "divide by page size" that removes a whole category of physical-alignment UX.

Why this only works if the cells are square

This only holds together because every cell is guaranteed to be the same width and height. If rows and columns are sized independently — which most grid tools do, because it lets you fill the page edge-to-edge — a "cell" isn't a fixed unit you can tile against, and you're back to needing marks. Forcing square cells (deriving whichever axis you didn't set, rather than letting both float to fill the sheet) was originally a decision about drawing accuracy — a square cell's diagonal is a clean 45°, useful for judging angles by eye — but it turned out to be the same property that makes tiling trivial later. One geometric constraint paid for two unrelated features.

Testing the seams

The part I actually didn't trust until I checked it: does the printable rectangle reconstructed from all the tiles equal the original enlarged rectangle, to the millimeter? I wrote this as a standalone assertion rather than trusting the math by inspection:

const topRowWidth = pages.filter(p => p.rowStart === 0)
  .reduce((sum, p) => sum + p.tileRectMm.w, 0);
console.assert(Math.abs(topRowWidth - drawingRect.w) < 0.01);

— summed the top row's page widths, summed the left column's page heights, compared both against the target enlargement size. It matched to a hundredth of a millimeter, which is the point where you stop worrying about floating point and start worrying about your actual printer's calibration instead (which is why there's still a 50mm ruler printed on the first page — measure it, and if your printer scaled the page, you'll catch it before taping together nine sheets).

If you want to see the live version: griddrawing.org/print-large-image-multiple-pages. It's a static site, runs entirely client-side, source reference stays in the browser tab.

DEV Community: nongyi531415