Ffire: a wave app forest fire

simulator
H2O wildfire challenge
Miguel Batista; miguelcbatista@gmail.com; team Ffire; Feb 2022
Structure

1. Introduction
2. App walkthrough
3. Simulation structure
4. Main assumptions/criticism
5. More ideas
Introduction

Wildfire simulation is traditionally a very difficult problem to solve; this is in part because of the complex
systems that determine the fire dynamics, such as wind and fire interactions, and partly because of lack of
data for extreme conditions which are hard to recreate in a lab.

This application wants to approach simulations as a learning opportunity, making clear assumptions and
starting from simple ideas: a terrain that contains a forest, which when catches fire, creates a wildfire
that interacts with wind and other geographical factors.

As complexity grows and entire wildfires are simulated, understandability starts to deteriorates; still,
with a clean frontend and real-time components, the behavior of wildfires can be explored and compared
against our simulations.
App walkthrough
App walkthrough
The simulation button allows the user to restart the
simulation (once complete) and resets the upload routine.

Downloads a template file to be edited/adjuster by the user

Downloads a file with wildfire data. The user needs to pick one of
these, and the app will automatically generate bounding boxes,
wildfire contours, and starting points.

Upload the parameter file from your local file system.

App walkthrough Please note there is an offset: 21 is row 23 in
the csv file.

This file can be easily changed (together with the contour data) from WFIGS to
include whatever wildfire in the US since these events are recorded.☺This sample is
from Nov 2021.
App walkthrough Loading a valid json file will allow the
simulation to begin. Three new pages will
appear in the app.
App walkthrough Live updates in wave app

3-d stream of
Evolution of
the landscape
forest state
dynamics

Log from app and

simulation engine
 Simulation structure
The diagram reads from top to bottom:

● Our wave app files receive user input that determines the scope of
the simulation. This is essentially a choice of which wildfire to be
simulated, which comes from WFIGS datasets.
● A simulation is started and a fire is created. This triggers the creation
of two objects: a forest and wind. Fire determines the potential of
each tree catching fire.
● Wind is created with a direction and speed; it is assumed to be
constant everywhere. This influences the area of action of a fire and
is one the mechanisms of fire propagation.
 Simulation structure

● A forest is created on top of a terrain. It is essentially a collection of

trees, projected on the geometry of the terrain. The attributes of a
forest are determined by input parameters.
● A tree has a state, and the size and fuel amount is determined
randomly. Tree positions are determined by projecting a (lat, lon) pair
in a terrain object (using interpolation).
● A terrain is a collection of 3-d points (cartesian and coordinate
systems). The precision can be adjusted, and determines the amount
of calls to an elevation API.
 Simulation
constraints

Simulation structure
When choosing a wildfire, it’s important to consider the areas. Because we’re
simulating a large amount of trees, the memory footprint is not negligible.

A combination of the following parameters is needed in order to simulate large

wildfires.

● forest_density: this determines the amount of trees in the simulation. For

large areas, it’s needed, at the expense of becoming closer to a
representation of an ensemble of trees, instead of an individual tree.
● safe_radius: For a large area, less trees need to be created, so the
interaction distance needs to increase: increasing safe_radius is needed.
 Simulation
constraints

Simulation structure
The transition of states in trees can be adjusted, as it’s defined based on the
amount of fuel left in a tree.

These transition regions (burning tree -> ember and ember -> ash) were
defined to speed up the simulation, as nothing really interesting is
implemented for embers and ash (like flying embers in the wind direction
which cause new fire fronts).
 Wind
failure

Simulation structure
A bug related with the direction of the wind went unfixed in the final
submission.

Without time to correct it and test it, the interaction of wind and fire is not
correct. The issue resides in weather.py in fire projection method of the
wind class.
 Fire
dynamics

Simulation structure
The fire potential of a tree is determined by three factors:

● Height difference between their burning trees: this attempts to

model fire behavior observed for instance in elevations.
● Proximity between trees: if more trees are burning close to a tree,
it’s burning potential increase.
● The aspect of the position of a tree: if a tree is located in a southern
face, it’s likely to be dryer.

The combination of these 3 factors determines one component of wildfire

propagation. The importance attributed to each was (roughly) manually
estimated, but favors proximity, then height, then aspect.
 Fire
dynamics

Simulation structure
The propagation of a wildfire is also determined by the interaction effects
from wind and fire.

The extension of flames (or conduction of heat) in the direction of the wind
is determined by the wind speed. A simple geometry was calculated and
the trees that are contained in that polygon will be tested for burning
potential.

In addition to the wind, there is one additional distance parameter that

determines the shape of this polygon. It can be interpreted as ‘danger
distance’ (even though it’s named safe_radius☺). The larger, the more trees
will burn.
 Forest
constraints

Simulation structure
The propagation of a wildfire, such as it was designed initially, involved the
comparison of all trees with each other.

A heuristic that reduced computation involved creating cells in our terrain,

and determining that trees that belonged to a neighbourhood of 2 cells in
every direction would have some propensity to burn.

The dimension of these cells was determined by a safe_radius. With wind

and fire interactions, it doesn’t seem like a good approach anymore.
 Terrain
constraints

Simulation structure
Some issues that may arise from the API. There is a monthly limit of 15 k
calls.

The app allows for bundled calls, this is, retrieve the elevation of
several(tbd) coordinates at once. This was not implemented, mostly
because it was the 3rd API that was tried out over the course of the
experiment – free APIs tend to die quickly.

num_points is the parameter that determines how many calls we make. In

more detail: we make num_points² calls to the API per simulation. Have this
in mind.☺

See the criticism section to understand pros/cons of high num_points.

Main assumptions and criticism of
the app
Assumptions & criticism
● Fire fighting is not considered in any of the historical wildfires that were studied.
This is not realistic and may justify divergences between perimeters in
simulations and real wildfires.
● The terrain is uniformly generated: rocks, roads, bodies of water, ... are not
considered in the terrain generation, and we assume that a dense pine forest is
present throughout the landscape.
● The terrain geometry is only as accurate as the elevation data used to estimate
surfaces. Small peculiarities (<30 m for US territory and <150 for most of the
world) are not taken into account and therefore the impact in the propagation of
the fire is ignored.
Assumptions & criticism
● The wind is considered to be uniform in direction and intensity across the entire
landscape. This is not realistic, as terrain alters both of these attributes of the
wind.
● Interaction effects between major parameters in the simulation are not
modelled.
● The effect of burning trees in its neighbours is considered to be linear.
● It’s assumed that the WFIGS files arrive in the same format: any change in file
data and metadata will not be properly handled and will likely kill the execution
of the simulation.
● The elevation API & linear interpolation are not working perfectly. For some
values of ‘num_points’, the terrains are generated with aberrations. Lower values
seem more stable, but come with the cost of less detail.
More ideas

● Simulate wind behavior in Windninja. File format conversion was the problem here: conversion between coordinate systems
was not easy without using heavy libs, which would inject too much complexity to the app.
● A robust metric to evaluate the similarity of recorded contours and simulated wildfires, and report it in the app would be helpful
to compare different simulations.
● An optimization/inference routine to optimize what conditions were most likely to cause the wildfires.
● Additional detail to terrains: extracting bodies of water or roads from open street maps’ API would create more realistic
simulations.
● Improved shapes for fire and wind interactions, and implementation of interactions effects between most of the other effects.
● Performance improvements to the simulation engine (which enables most of the points above). The code was created with pure
python, and a lot of vectorization and much better algorithms could have been implemented. Experiments with Go showed that
comparable interactions with 10s of millions of trees could be carried out much quicker and with a very small memory footprint.