Reframe ensembles as burn probability

Proposal: build ensembles to produce a burn-probability map, not just "run N simulations". Wind forecasts are uncertain, and users (civil protection, insurers, land managers) need probabilities, not a single perimeter. Already listed in tools/TODO.md:10.

It also allows calibration. propagationSpeedAdjustmentFactor=0.6 and windReductionFactor=0.4 (tests/runff/params.ff) are tuned for Corsica. An ensemble lets us fit them against observed fires (tools/TODO.md:17).

This makes throughput more important than per-run speed, so threads matter more than MPI.

Prerequisites: #159 (leak per domain), #165 (log volume), #160 (exit(0) kills the run).

First step, no C++ changes: a Python driver that samples wind and the two factors, runs N simulations through pyforefire, and adds up the arrival-time rasters into one probability grid.

Drafted with Claude Opus 5, reviewed by a maintainer.

@HugoFara

Can this be fixed with python runners ? @HugoFara may be a good way, what do you think ?
A runner that can fork anytime will be great, the outstream may be rerouted in the context with accessors

Yes, the runners are a necessary step, I still need to bring a second PR there. Afterward, the Ensemble scaffolding should not be too hard, but I haven't tested it yet.

feat(python): run an ensemble and map its burn probability (forefireA…

feat(python): fork a running simulation with ForeFireRunner.fork() (f…

feat(python): run an ensemble and map its burn probability (forefireA…

Merge pull request #228 from HugoFara/feat/runner-fork

#228 is merged: run_ensemble and burn_probability, with members forked from a shared spin-up. What's left:

Calibration. Fit propagationSpeedAdjustmentFactor and windReductionFactor against observed fires. This needs observed perimeters and a score comparing a simulated map with an observed one. Blocked on case data (Automatic case generation from open European data #170, A landscape validation command #169).
Sampling. Build members from a weather forecast ensemble instead of a list written by hand. Most useful once Automatic case generation from open European data #170 supplies the weather.
Georeferenced output. Write the probability map as a GeoTIFF, or at least with the grid's corners, so it opens in a GIS. Small; can be done now.

Drafted with Claude Opus 5.5.

Can a single calibration of propagationSpeedAdjustmentFactor and windReductionFactor work outside Corsica? From three Californian fires, I think not: the bias changes sign from one fire to the next. What makes the ensemble useful is the case inputs.

I ran run_ensemble-style ensembles (200 members, each forked from a shared spin-up, about 1–4 min on 14 workers) on three fires. Each run uses:

the Farsite model with LANDFIRE 2016 fuels and 3DEP 30 m terrain;
hourly HRRR wind, temperature and humidity;
FEDS 12-hourly VIIRS perimeters to score against.

Members sample wind direction (±20°), speed (×lognormal 0.3), the midflame reduction (0.2–0.4), 1 h moisture (±1.5%) and the ignition point.

Fire	Size vs observed	Calibration (p ≥ 0.9 → burned)	What fixed it, or didn't
Mineral 2016 (29 km²)	3–6× too large	12%: no skill	Nothing in the model: probably suppression, the valley flank was held
Slinkard 2017 (39 km²)	right	99%; every bin near the diagonal	Gridded HRRR wind (7×7 cells, as time-varying layers) instead of one point: the fire then goes up the valley
Cranston 2018 (65 km²)	10× too slow at first	96% before containment	LANDFIRE maps unburned chaparral as GS2; as SH5 the ensemble is near-reliable until +27 h

Mineral 2016

Slikard 2017

Cranston 2018

Base:

Fuel switched (SH5)

Lessons for the remaining items:

Calibration. One global factor would have to make Mineral slower and Cranston faster. Per-case inputs matter more: fuels (Cranston), wind resolution (Slinkard), and suppression (Mineral, and every fire after containment). The model also keeps spreading after the real fire stopped. A "containment time" cut-off in scoring would separate model error from suppression.
Sampling. The ignition point is uncertain by kilometres in all three cases: the published points are road junctions, rounded, or in the middle of the burnt area. In Mineral it was the strongest driver of the fit. Members should sample it between the candidate points, the published point and the first FEDS perimeter.
Kernel. The cases turned up the bugs fixed in fix(core): interpolate time-varying data layers forwards, past 24 h too (#232) #235, fix(core): create the layers a model needs in its own domain, even when added late (#236) #237, fix(core): a front reaching the domain edge no longer floods the arrival map (#233) #240, fix(propagation): Farsite reads ForeFire's m/s wind and slope tangent, upslope only (#231) #242 and fix(core): a domain built without loadData takes its propagation model from the parameters #243. With those fixes, ForeFire's Farsite matches Finney's code to 1e-5 in a single cell. ForeFire's spread from a point is narrower than Farsite's ellipse, so the model shape does not explain the oversizing.

Possible next steps:

a scoring helper in pyforefire: Dice, Brier and reliability against a perimeter;
gridded wind from a forecast (data layers with a time axis);
the GeoTIFF output (item 3 of my previous comment).

Drafted with Claude Opus 5.5.

It is Beautifull,
So there are ensembles with the Farsite emulator.. crazy. Thanks a lot.

We originally did these ensembles by making many ff scripts,
see
https://inria.hal.science/hal-02447187
where it is possible to find some calibrated ensembles if you are interested

Thanks, I had a look at the paper, several similar ideas, good thing I am not reinventing the wheel.

I went with Farsite fires as it was a good stress test for Forefire, and they had good documentation to check on the values (Brier score and such). I will try with your paper, as I want to extend to some European fires.

feat(python): score an ensemble against an observed burnt area (#172) (…

Navigation Menu

Repository navigation