docs/source/user_guide/landscape_file.rst:64 warns that the link between the integer values in the fuel layer and the Index column in fuels.csv is "absolutely critical", and that an undefined index means the simulation "will likely fail or produce incorrect results". There is no command that checks this, and no error that lists which indices are missing.
What actually happens is worse: nothing happens
I generated a landscape where every cell carries fuel index 99 — fuels.csv defines 0–6 — then loaded it and ran:
--- loaded a landscape whose every cell is fuel index 99 ---
--- stepped 200 s ---
FireDomain[sw=(0,0,0);ne=(1000,1000,0);t=200]
FireFront[id=2;domain=0;t=0]
FireNode[...loc=(496.683,775.962,0);vel=(-0.0288452,0.999584,0)...]
No error, no warning, no diagnostic. Index 12345 behaves the same. The simulation produces confident-looking output on a landscape referencing fuels that do not exist.
A second observation I could not explain
Trying to quantify how wrong the results were, I built the same case with fuel indices 1, 2, 3 and 4 — all valid, with meaningfully different fuel depths (e = 0.24, 0.4, 0.4, 0.19) — and got identical spread in every case (front at y=584.0 m after 200 s), with Rothermel attached.
Either my minimal setup fails to wire the loaded fuel layer to the propagation model, or the fuel map is not reaching it. I could not tell which from outside, and that is the point: there is no way to ask ForeFire whether the fuel map you supplied is being used. If someone who knows the data path can say which it is, that answer belongs here — and if it is the second, it is a much more serious bug than a missing validator.
Suggested fix
A validation entry point — a script, or better a pyforefire function — that loads a .nc plus a fuels.csv and reports missing variables and wrong dimensions; every fuel index present in the raster but absent from the table, with cell counts; the reverse, indices defined but unused, which usually means a bad reclassification; and NaNs or out-of-range values in elevation and wind.
Pure Python, roughly half a day. Pairs naturally with #167, which produces these files.
Drafted by Claude Opus 5 from a codebase audit. Reviewed by a maintainer before filing.
EDIT: rewrote for human readability.
docs/source/user_guide/landscape_file.rst:64warns that the link between the integer values in thefuellayer and theIndexcolumn infuels.csvis "absolutely critical", and that an undefined index means the simulation "will likely fail or produce incorrect results". There is no command that checks this, and no error that lists which indices are missing.What actually happens is worse: nothing happens
I generated a landscape where every cell carries fuel index
99—fuels.csvdefines 0–6 — then loaded it and ran:No error, no warning, no diagnostic. Index
12345behaves the same. The simulation produces confident-looking output on a landscape referencing fuels that do not exist.A second observation I could not explain
Trying to quantify how wrong the results were, I built the same case with fuel indices 1, 2, 3 and 4 — all valid, with meaningfully different fuel depths (
e= 0.24, 0.4, 0.4, 0.19) — and got identical spread in every case (front at y=584.0 m after 200 s), withRothermelattached.Either my minimal setup fails to wire the loaded fuel layer to the propagation model, or the fuel map is not reaching it. I could not tell which from outside, and that is the point: there is no way to ask ForeFire whether the fuel map you supplied is being used. If someone who knows the data path can say which it is, that answer belongs here — and if it is the second, it is a much more serious bug than a missing validator.
Suggested fix
A validation entry point — a script, or better a
pyforefirefunction — that loads a.ncplus afuels.csvand reports missing variables and wrong dimensions; every fuel index present in the raster but absent from the table, with cell counts; the reverse, indices defined but unused, which usually means a bad reclassification; and NaNs or out-of-range values in elevation and wind.Pure Python, roughly half a day. Pairs naturally with #167, which produces these files.
Drafted by Claude Opus 5 from a codebase audit. Reviewed by a maintainer before filing.
EDIT: rewrote for human readability.