Fire potential and Monte Carlo burn probability

ELMFIRE Mode 2

ELMFIRE has a convenient ‘Mode 2’, which is a fire potential calculation mode.

For every burnable landscape cell, mode 2 asks:

Suppose this cell were burning as the head of a fire under this fuel, terrain, moisture, wind speed, and wind direction. What would its potential spread rate and flame length be?

At each cell, the important calculation chain is approximately:

1. Read the local surface fuel model and fuel moistures
2. Calculate the no-wind no-slope surface fire behavior using the Rothermel model
3. Calculate local wind and slope effects
4. Vector wind and slope when they are not aligned to determine the direction and magnitude of maximum spread
5. Calculate head-fire spread rate in that direction
6. Evaluate crown fire initiation and spread using the canopy inputs, unless crown fire is disabled in the ELMFIRE input namelists
7. Convert the resulting fireline intensity to flame length
8. Write that cell’s potential head-fire spread rate and flame length

Flame length is a fire behavior or fire intensity indicator, not a direct burn severity metric. Flame length describes active combustion behavior at the time of burning, and fireline intensity describes the rate of heat release per unit length of the fire front.

Monte Carlo burn probability analysis

ELMFIRE also has a convenient way to run several thousands of random ignitions on a landscape and use that to calculate the number of times burned of each raster cell. Number of times burned can be used to calculate the burn probability of a given cell, with given weather and fuel moisture inputs.

Getting things running on my computer

It was a struggle to get parallel processing to work on my Windows machine. I had run the Mode 2 tutorial using one core and it took around 2 hours on the tutorial dataset, so I knew I wanted to try to run both Mode 2 and Monte Carlo analysis on multiple cores (I have 8), because my landscape was 698 x 675 cells at 60m resolution.

I used ChatGPT to help me figure out how to get ELMFIRE running with parallel processing. My original ELMFIRE Docker container showed /dev/shm = 64M. That was likely inadequate because in SETUP_SHARED_MEMORY_1, ELMFIRE calculates:

WX_SIZE = WX_NCOLS * WX_NROWS *WX_NBANDS * 4

For the weather rasters, WX_NCOLS = 698, WX_NROWS = 675, WX_NBANDS = 23. So each shared-memory window is 698 * 675 * 23 * 4 = 43,345,800 bytes ≈ 41.3 MiB.

ChatGPT calculated that the fuel moisture rasters alone would require approximately 331 MiB of memory, and the default 64 MiB for a Docker container was much to small.

I created a new container using:

--shm-size=2g

With 2 GiB /dev/shm, ELMFIRE could execute using multiple cores!

Next I had to figure out that I had to set:

CALCULATE_TIMES_BURNED = .TRUE.
DUMP_BINARY_OUTPUTS    = .TRUE.

With those settings, a parallel run of 8 members executed with no errors, and ELMFIRE also successfully wrote the crown_fire_area.tif, surface_fire_area.tif, and times_burned.tif files!