Cell2Fire: A Cell Based Forest Fire Growth Model

Cell2Fire is a new cell-based forest and wildland landscape fire growth simulator that is open-source and exploits parallelism to support the modelling of fire growth cross large spatial and temporal scales in a timely manner. The fire environment is characterized by partitioning the landscape into a large number of cells each of which has specified fuel, weather, fuel moisture and topography attributes. Fire spread within each cell is assumed to be elliptical and governed by spread rates predicted by a fire spread model such as the Canadian Forest Fire Behavior Prediction (FBP) System. The simulator includes powerful statistical and graphical output and spatial analysis features to facilitate the display and analysis of projected fire growth. We validated Cell2Fire by using it to predict the growth of real and realistic hypothetical fires, comparing our fire growth predictions with those produced by the state-of-the-art Prometheus fire growth simulator. Cell2Fire is structured to facilitate its use for predicting the growth of individual fires or embedding it in landscape management simulation models. It can be used to produce probabilistic fire scar predictions by allowing for uncertainty concerning the basic spread rate predictions and uncertain weather scenarios that might drive their growth.


Introduction
The effects of global warming on temperature, precipitation levels, soil moisture and other forest and wildland fire regime drivers have increased and are expected to continue to increase both the number of and area burned by wildfires around the globe (Westerling, 2016). Wildfires  That has also resulted in increases in expenditures by forest and wildland fire management agencies (see, e.g., Stocks and Martell, 2016). Despite concerted efforts, wildfire growth remains a complex and very difficult to model process.
Two of the most important characteristics of a wildfire are its rate of spread (ROS) and intensity which are influenced by fuel type, fuel moisture, wind velocity, and slope.
The Canadian Forest Fire Behavior Prediction (FBP) System includes empirical fire spread rate models that can be used to predict the rate of spread and the intensity of wildfires based on weather, fuel moisture, time of year and topographical variables for specified fuel types; e.g., for individual grid cells that contain homogeneous fuel types (Forestry-Canada, 1992).
However, the FBP System alone cannot be used to predict how a fire will grow across a heterogeneous landscape/grid over time. Spatial fire growth models like Prometheus, a deterministic fire growth simulator, are designed to use FBP spread rates to do so (Tymstra et al., 2010). Prometheus is a vector-based fire growth simulation model that is based on an adaptation of Huygens' principle of wave propagation, i.e., the propagation of the fire front is modelled in a fashion similar to a wave, shifting and moving forward continuously in time and space. It uses spatially explicit fire environment input data concerning topography (slope, aspect and elevation) and FBP fuel types along with a weather stream and fire danger rating codes and indices, FARSITE Finney (2005) is another widely used fire growth simulator. It is based on the U.S. Forest Service's BEHAVE fire behavior prediction system and is also a vector-based Huygens' type model. A review of twenty-three simulators that can be used to predict forest fire growth can be found in Papadopoulos and Pavlidou (2011).
The two models found to best simulate historical fires were FARSITE in the United States and Prometheus in Canada.
Recent years have witnessed growing interest in the development of detailed cellbased deterministic/stochastic fire simulators and some of the modelling assumptions that have been adopted include, for example the use of memoryless distributions (Markovian processes) to model the fire spread dynamics (Boychuk et al., 2009), homogeneous forests (cells' characteristics are identical), reductions in the number of adjacent cells to which a fire can spread (e.g., from 8 to 6 or 4), no spotting, and no stochasticity is included.
Our goal was to include many realistic aspects of fire behaviour in Cell2Firean open-source (https://github.com/cell2fire/Cell2Fire) cell-based fire growth simulator, with a view to achieving high computational performance via parallelism when simulating large-scale fire instances to provide valuable insight to inform both fire and forest management. We therefore use both real and realistic hypothetical fire instances to validate our simulator and assess its computational performance.
FireSmart (Hirsch et al., 2001) forest and fuel management calls for landscape management and fire growth simulation models that have well-structured interfaces that facilitate the exchange of data between them to inform the iterative re-planning that takes place when strategic plans are modified in response to what fires materialize and what areas actually burn over long planning horizons. Acuna et al. (2010) demonstrated the importance of integrating fire management with strategic forest management planning models to develop and evaluate FireSmart forest management plans. Although stand-alone fire growth models can be used to evaluate specified forest and fuel management plans, the fire growth simulators described above were designed to simulate fire growth and cannot readily be incorporated strategic planning frameworks that can be used to develop good or optimal strategic FireSmart landscape management plans.
Cell2Fire is designed specifically for use in a fuel-management framework with the intent of mitigating the detrimental impact of large fires efficiently. Cell2Fire can therefore be used as a pure simulation tool to model the growth of specific fires over a short time frame and/or embedded in a landscape management framework to evaluate fuel-management strategies or linked with optimization software to develop "optimal" fuel management strategies over long planning horizons.
The primary objective of our research was to develop an efficient and realistic fire growth simulator that enables simulation of the dynamics of fire growth across a grid representation of a real or hypothetical forest using cell attributes such as fuel type, elevation and weather, given an ignition point or initial fire perimeter, to inform FireSmart forest management. Our ultimate goal is to develop a tractable methodology that can be used to generate realistic spatial fire scar scenarios that can be used to support fuel management and harvesting planning.
The paper is organized as follows: In section 2, the two main fire growth simulation paradigms are described and a review of state-of-the-art simulators is included. Section 3 describes the Cell2Fire simulator structure, the main simulation steps, the fire growth dynamics model and the computational implementation. The results of a case study based on a real forest landscape in Canada and several test instances that were used to validate the simulator output and compare its computational performance with state-of-the-art simulators are discussed in section 4. Finally, section 5 contains our conclusions and thoughts concerning future research needs.

Description of fire growth dynamics
The two methods that have most often been used to simulate fire spread rates and fire growth across heterogeneous landscapes are the wave propagation approach and the cellular automata approach. We therefore begin by providing a brief overview of those two approaches.

Wave-propagation model: Huygens
Huygens considered every point on a wavefront of light as a source of individual wavelets and described the new wavefront as the surface tangential to the circumferences of the secondary waves. The use of Huygens' principle to simulate fire growth is based on the assumption that the shape of a fire can be represented by a polygon, a plane figure composed of a sequence of straight-line segments forming a closed path, whose vertices are a tangential envelope of the elliptical "firelets". Huygens' principle was first applied to the simulation of fire spread by Sanderlin and Sunderson (1975). Anderson et al. (1982) later developed a simple elliptical model based on Huygens' principle of wave propagation to simulate the spread of grass fires. Richards (1990) then extended the Anderson et al (1982) model by deriving a set of partial differential equations to model the growth of fires across a heterogeneous landscape.
Both the FARSITE (Finney, 2004) and Prometheus models use Richards (1990) partial differential equations to propagate each vertex on a fire's perimeter. However, the models differ in the fire danger rating system components and fuel models used to model fire spread rates. FARSITE uses the US National Fire Danger Rating System and fire behavior prediction fuel models developed by Rothermel (1972) and extended by Anderson (1982) and Scott and Burgan (2005), whereas Prometheus uses the Canadian Forest Fire Danger Rating System.

Cell-based fire growth models
Cellular automata models that employ a raster-grid of square or hexagonal cells, are widely used to model wildfire spread. Fuel and terrain conditions are usually assumed to be homogeneous within each cell in order to simplify basic fire spread rate calculations. The fire propagates through the grid-cells basis, typically from a cell's center to the center of an adjacent cell. Each ignited cell behaves as an ignition source that is independent of any adjacent burning cells. To spread the fire from one cell to another, a search mechanism such as an adjacency or spread template is required. Kourtz and O'Regan (1971) developed the first computer simulation model to spatially simulate the growth of a small fire. Their model was based on a heterogeneous and discontinuous fuel-type grid but did not account for the effects of terrain and wind. This deterministic model predicted how long it would take a fire to burn through one square area or cell within a fuel grid when the location of the fire, the starting time, and the grid resolution were known. Travel times were calculated using fixed rates of spread (based on the fuel type and the spread index for the day) and fixed spread directions from the burning cell. Later, O'Regan et al. (1973) developed a method for using directional rates of spread to predict fire growth. They also rewrote the original model for use on what was then a large computer to simulate fires of up to 15,000 ha. in size. O'Regan et al. (1976) calculated average directional rates of spread using the equation: where a and b are major axes, the quotient c/a is the eccentricity e and φ is the focal angle. Kourtz et al. (1977) then further modified this model to accommodate variation hourly wind conditions. Todd (1999) adapted the Kourtz et al. (1977)  Recently, a fire growth simulator (Arca et al., 2019) was released with the goal of assisting civil protection and fire management agencies. In order to provide short term forecasts of how the fire will grow, they based their simulator on models of wind field progression. The fire growth model uses the level set technique (see Ghisu et al. (2015) and the Rothermel (1972) fire behavior model.) The goal of our paper, in contrast, is to not to support large fire management operations but rather to inform strategic harvest planning and fuel management. We are interested in producing final fire scars that are reasonable. To do that, we need to have a reasonable evolution of the fire, but approximations with respect to minute-by-minute status are acceptable in the interest of computational efficiency because many scars may need to be generated to explore methods for strategic timber harvest scheduling and forest management planning or to validate the use of simpler methods for creating fire scar scenarios such as, e.g., Kuhlmann et al. (2014).

Canadian Fuel Behavior Prediction System: FBP
The Canadian FBP System is a set of empirical models that can be used to predict fire spread rate, fuel consumption and fire intensity in homogeneous fuel types as functions of fuel type, fuel moisture and current weather expressed in terms of the Canadian Forest Fire Weather Index System (FWI) codes and indices (Forestry-Canada, 1992).
It includes fuel models that are used to classify forest types into 17 fuel types that collectively represent most of the major forest cover types in Canada.  3 Cell2Fire growth simulator

Description
Cell2Fire is an open-source cell-based fire growth simulator developed in Python and C++ for use on laptop or desktop computers as well as on High-Performance Computer (HPC) systems. It allows a user to simulate fire growth across a grid that represents a real forest landscape using fire environment variables such as the fuel type, elevation (topographic/terrain components) of each cell, fire ignition points and weather.
A forest landscape is mapped into a rectangular region comprised of n rows and m columns partitioned into a series of identical area square cells to produce a grid where the cell size depends on the desired spatial resolution that will of course, be influenced by the spatial scale for which cell attribute data is available. Each cell represents a specific portion of the landscape and has two information layers that pertain to its topographic and fuel characteristics. Those layers define the characteristics of each independent cell, allowing the simulator to treat them as individual objects that can interact with other cells on the forest landscape to model fire growth.
Algorithmically, Cell2Fire simulates the growth of fire by tracking the state of all cells as the model progresses through discrete equally-spaced time steps. The status of the fire and all the cells on the landscape are updated at the end of every time step and smaller time steps lead to better fire growth precision.
A cell can be in one of five states: "Available", "Burning" , "Burned", "Harvested", or "Non-Fuel" where the label "Available" indicates that the cell contains a flammable fuel type; "Burning" represents that the cell contains an active fire; "Burned" indicates that the fire has passed through the cell; "Non-Fuel" is a non-flammable fuel type such as rivers, lakes, or rocky. The state "Harvest" is provided so that the simulator can be embedded in a strategic harvest planning system. The harvest planning module would be responsible for labeling the cells that are harvested and provide the appropriate post-harvest fuel type.
Once an ignition point has been specified, the fire is ignited. During each time step the fire may spread along the axes emanating from the centre of each burning cell to its neighboring cells. The predicted FBP system Head Rate of Spread (HROS), Flank Rate of Spread (FROS) and Back Rate of Spread (BROS) are used to model elliptical fire growth within each cell with the focus of the ellipse at or near the center of the cell (see this process described in more detail in 3.7). The geometry of the ellipse is then used to predict the fire spread rates along the axes emanating from the centre of each cell.
A signal/message is then initiated to any adjacent cells whose center is reached by the fire. In the present implementation, it is assumed that each cell has at most 8 adjacent cells (see Figure 2) because the grid is assumed to be rectangular. These are the only neighbors considered because the simulation time step is assumed to be small enough to ensure that the fire can not spread beyond adjacent cells in one time step.
For the examples we tested using a 100m by 100m cell size, simulation time steps below one minute resulted in almost no change in final fire scar compared to one minute. Shorter simulation time steps result in longer run times for the simulation.
Note that there is also an approximation because the fire enters a cell a from its neighbor and the neighbor's cell characteristics are used to model fire spread within that cell until the fire reaches the center of the destination cell. At that point,the characteristics of the destination cell take over.
When the fire spreads from the edge of a cell and reaches its center, the cell receives a message. When the cell receives a message it calculates what its ROS based on its characteristics and the current weather and if that ROS is greater than a user-specified parameter (which was zero in the experiments reported here), its state is labeled as "Burning". At this point, the main Rate of Spread values are calculated by the FBP System module and fire progress begins to be calculated along with its available axes.
Predicted ROS values for each axis are based on the assumption that fire spreads in the shape of an ellipse in each cell and the geometry of the ellipse and its orientation are used to predict spread rates along the axes emanating from the cell as described later in Section 3.7.
The fire's progress is updated at each fire time period by examining the state of all "Burning" cells. Once no adjacent cells are available or a burn-out criterion (See assumption (A5) in 3.2) has been satisfied the cell changes its status to "Burned" and is omitted from the simulation in further steps.
This process is repeated until a fire ending event state is reached, i.e., the total number of fire burning periods or hours have passed or there are no more cells available to burn.
Three different sources of uncertainty can be included in our model to account for the most important perturbations that can significantly affect the fire growth dynamics: (1) ignition point(s) selected via a user-defined spatial probability distribution or else simply with equal probability for each cell, (2) a perturbation level the stochastic aspects of the basic FBP predicted Rates of Spread via its coefficient of variation, accounting for its inherent approximation error, allowing the user to obtain different fire scars taking into account uncertainty in the fire spread rates, and (3) a set of usergenerated weather stream files (fire weather scenarios that can occur with specified probabilities can be provided to Cell2Fire, performing a series of simulations with different weather scenarios thereby allowing the user to study the behavior of the fire under different weather conditions for a specified forest/instance.  (1) Raw data is pre-processed into Cell2Fire's format, (2) Cell2Fire calls an independent fire spread model (e.g., FBP), performing the simulations including harvesting plans provided by the user (if needed), and (3) finally, outputs are generated and returned to the user.

Modelling assumptions
Based on the previous description description of our model we can summarize the main simplifying assumptions upon which Cell2Fire is based as follows: (A1) The growth of the fire depends on the "Rate of Spread (ROS )" of the fire from a burning cell towards its neighboring cells. We assume that a cell is ignited when the fire reaches its center and conditions for burning are met (see A5). Each cell has at most 8 neighbors.
(A2) The Rates of Spread along the 4 principal orthogonal axis (which are functions of the weather, fuel moisture conditions and characteristics of each cell) are calculated using the Canadian FBP System. Note that a the main axis of the ellipse that burns in each cell is aligned in the direction that the wind is blowing (the HROS direction) for that time step and the BROS is aligned in the opposite direction. The FROS is perpendicular to the wind direction (the two flanks). Note that other fire spread models could be used in lieu of the Canadian FBP system, a point we discuss in our Conclusions section.
(A3) Each cell that burns serves as a new source of fire. Fire spread occurs at the cellular level and cell size depends on the spatial resolution and corresponding data availability.
(A4) The effect of fire suppression action is not modelled. It is beyond the scope of this paper and will be addressed in a future research project.
(A5) There are two sets of conditions for modeling the termination of fire growth (a fire ending event) in Cell2Fire: the cellular level and general fire evolution conditions.
At a cellular level, each cell becomes unavailable (burned) for future fire dynamics if (i) the ROS along the main available axes is less than some empirical threshold δ > 0, (ii) the cell does not have any adjacent cells that are available to burn, (iii) the residual fuel available in a cell is not sufficient to support fire spread (implicit in the FBP system), or (iv) a user-defined head fire intensity (HFI) threshold is provided and the HFI is below that threshold.
Regarding the general fire dynamic, the total duration of the simulated wildfire event is determined by (1) maximum number of hours of burning per day -a season-dependent constant Parisien et al. (2005), or drawn from a probability distribution -and (2) the total fuel remaining in the forest (available cells).

Cells
Cells that contain the information concerning the structure of the forest as well as the past and current state of the simulation are the main processing units in Cell2Fire.
The main fields that define the state of a cell i ∈ N are the following: i) Fuel type: following the classification criteria of the FBP System (Forestry-Canada, 1992), each cell is assigned a specific fuel type (e.g., conifer, grass, nonfuel) represented by an FBP code. This will be used for selecting the specific fire spread models and coefficients defined by the FBP System in order to predict the rate of rate of spread (ROS) in that cell.
ii) Slope: the slope % in terms of the vertical rise over the horizontal run and adjacent cells, and the upslope direction (radians) have a significant impact on the predicted ROS.
iii) Elevation: altitude in meters of the current cell with respect to the sea level. iv) Location: latitude and longitude coordinates are provided with the instance.
v) Status: cells are classified into five different states during the simulation time steps. Cells that have not been harvested/burned and represent valid fuel types are labeled as "Available" cells. Cells that are actively burning are classified as "Burning" cells, updating the fire progress along each of its 8 axes every timestep. When a burned-out condition (see Section 3.2) is reached, burning cells are turned into "Burned" cells, meaning that they can no longer contribute to the propagation of the fire across the forest and can be omitted in further simulation steps. Finally, a cell can be labeled as "Harvested" or "Non-Fuel" and therefore, not available for the fire spread.
In addition, each cell contains a series of secondary parameters that allow Cell2Fire to track the evolution of the fire within the forest and change the state of the current simulation run. The Fire dynamics group includes the fire ignition date and time of each cell, the fire's progress along each axis, and the effective ROS(t, θ) values (per period and axis angle). The average age of trees inside the cell, approximate volume of wood/products available, ID label, perimeter, area, adjacent cells list, and distance to adjacent cells centers can be found in the Demographic category.
Due to this independent structure, cells can be treated as individual units allowing an efficient parallel computing approach for each iteration. We can therefore update their status and generate the relevant fire messages to model the fire dynamics of each burning cell in parallel using independent threads and update the global status of the forest at the end of each fire time period and thereby obtain significant improvements in execution times (from hours in serial mode to minutes in parallel mode) when dealing with large fires that have many simultaneously active cells.

Fire propagation dynamics
As described above, the fire growth model is simple but powerful: every time a cell is ignited by an adjacent cell it acts as a new source of potential ignition for neighboring cells in the forest, updating the progress of the fire for each available axis (center-tocenter directions).
Following an object-oriented programming paradigm in Python and C++, a series of classes for the most relevant components of the problem were developed: Forest, Cells, Weather, Ignitions, FBP System methods and Input/Output formatting. Then, the main program instantiates the different objects and applies the pertinent methods required to simulate fire growth. Once the fire instance data has been read and the forest has been initialized inside the simulator engine, the main simulation steps are as follows: i) Relevant fire parameters are calculated by performing calls to the FBP System module to determine the Rate of Spread (ROS) for each available fire spread axis of the burning cell: based on fuel characteristics, topography, and weather different ROS(t, θ) are obtained where t is the current fire time period and θ is the angle with respect to the center of the adjacent cells (0 • = East, increasing counter-clockwise) based on the procedure described in Section 3.7. Following a discrete time simulation approach, the internal simulator clock advances one unit of time -a user-input precision parameter -and the fire's progress is updated for each axis.
ii) Fire spread between cells is modeled by using a sending/receiving message approach (which enables parallelization) based on the computed ROS along each axis. If the fire reaches the center of a cell during the simulated time step, a message is sent. Checking environmental and cells characteristics, a the cell begins burning (or not). This is the core of the simulator and thus, the critical performance bottleneck that comes into play when simulating fire spread across large lanscapes. However, we designed it to maximizing the parallel performance of the code, obtaining a large percentage of naturally parallelizable code, representing around 80% of its structure.
iii) The previous steps are repeated until some specified ending criterion is satisfied: e.g., the maximum number of weather periods, the maximum simulation time, and/or some fire ending event condition. Statistics regarding the status of the forest as well as plots and other outputs of the fire scar evolution are produced.  We use the following notation to describe the main steps of the simulation Algorithm 1: -N denotes the set of cells in the forest and i ∈ N represents cell i ∈ N .
-Adj (i) denotes the set of available cells that re adjacent to cell i (at most 8).
-BurningCells is the set of actively burning cells in the simulation process.
i → t j indicates that cell i "sends a message" to cell j at time t

Main Inputs
As is the case with other state-of-the-art fire growth simulators, the Cell2Fire model requires a number of inputs including a minimum set of data layers that define an instance/forest to start the simulations. The relevant inputs needed to simulate the growth of a fire are as follows: Algorithm 1 Cell2Fire Pseudo-code 1: procedure Sim(F orestData, F T ypes, Ignitions, W eather, T M ax, Options) 2: Step 0: Initialize Cell2Fire

13:
Repeat, until F P eriod < T M ax 14: Step 3: Results and Outputs generation 15: Generate Grids, Statistics, Output plots 16: end procedure i) Forest raster data: ASCII grid forest files that specify the number of cells in the forest, their geographical coordinates and information concerning each cell including as its fuel type, elevation, slope (% and azimuth), degree of curing. Files can be in either .csv or .asc format. If topographic data is not fully available, default input dummy values for parameters such as elevation or slope can be provided by the user (null by default).
ii) Fuel type dictionary: Fuel type codes and descriptions that match the Canadian FBP System fuel types (Table 1) are included inside a .csv file. Future implementations will allow the use of a custom dictionary file that includes fuel types not currently included in the set of Canadian FBP fuel types.
iii) Ignition points: An optional file that that specifies the cell(s) in which fires are to be ignited during the simulation, paired with their corresponding ignition time periods.   Besides the main input files, a set of options and user-provided parameters for exploiting all the flexibility of the simulation engine including tuning options (see Section 3.7) are available as secondary inputs when running Cell2Fire.

Main Outputs
Once a simulation run has been completed, the following outputs are available: i) Burn-Grids: Files in which 1s indicate burned cells and 0s indicate those that are available to burn. Useful for statistical comparisons with other simulators as well as to generate burn probability maps.
ii) Plots: Initial forest state, fire scar evolution, and message sending/receiving can be visualized by a series of plots ( Figure 5) generated after the simulation run has been completed.

Rate of Spread from cell to cell
We use the approach proposed by the Canadian FBP System Tymstra et al. (2010) where an elliptical distribution scheme is applied. This method does not require the ignition point or the point of propagation to coincide with either of the two foci of the ellipse, although the authors indicate that "small differences between the point of ignition and the focus of the ellipse do not change the results", i.e., the elliptical propagation shape/size.
Let a, b, and e be the semi-major, semi-minor, and eccentricity of the ellipse, respectively.
-The FBP system predicts the HROS, the BROS and the length to breadth ratio (LB) which is 2a/2b or a/b.
-During the first time interval t, the fire will spread from its ignition point to the center of the ellipse and then from the center of the ellipse to the farthest edge of it.
-At time t, we have: to expand the ellipse generated by the propagation of fire at time t on the two main axes.
-Noting that LB = a b we have F ROS = HROS + BROS 2LB . Therefore, the eccen-tricity is: Using these equations and the procedure described in Tymstra et al. (2010), we can estimate the Rate of Spread from the center of a cell to the center of any adjacent cell as in equation (1). Figure 6: Elliptical Rate of Spread distribution scheme using the ellipses defined by the Canadian FBP System. At any time t, the backfire will be BROS × t behind the point of ignition and the head fire will be HROS × t ahead of the point of ignition of the fire, expanding the ellipse. Then, if the fire emitted by cell i reaches the center of an adjacent cell j at time t(j), a new ellipse is generated at time t > t(j), calculating the corresponding rate of spreads, and so on.

Computational details
We chose C++ for the parallel implementation because the objects we created in Python are naturally mapped to C++ objects, obtaining at least 15-20x average speedups depending on the forest characteristics. As previously discussed, our al- neighboring cells, this part is easily parallelizable. Each cell, in addition to updating its current status, can also "send a burning message" to an adjacent cell. In the receiving messages stage, we analyze the "burn messages" sent to non-burning cells and mark them as burned if the conditions are met. This part is also potentially parallelizable, but because the number of newly burned cells at a single time-step is dwarfed by the number of currently burning cells, we found that a speedup here is of lower priority.
Due to the easily parallelizable structure of our code, the most suitable approach for parallelizing its execution consists of a shared-memory approach using the well-known OpenMP API (Dagum and Menon, 1998). This is an advantage of Cell2Fire since the code will be also optimized for its execution in daily-use computers, without needing a multi-node architecture for exploiting its parallelism. Using it, we were able to obtain an average of 15%-20% extra performance for the parallel region.

Results and Discussion
In this section, we compare the predicted burn scars produced Cell2Fire and Prometheus for several instances created for this purpose as described in Section 4.2. We did not compare either simulator with the realized fire scars in our study because it is difficult to determine the extent to which the final shape of real fires that were fought was or was not influenced by suppression action. The simulator is fast and exhibits good parallel speed as described in the Appendix.

Comparison Methodology
The comparison methodology we used consists of measuring the difference between fire scars generated by Prometheus and Cell2Fire simulations using three metrics. The simplest and most widely used full-reference quality metric is the mean squared error (MSE), which objectively quantifies the strength of the error signal. However, two distorted images with the same MSE may have very different types of errors, some of which are much more visible than others. Thus, as we are interested not only in the difference of the marks but also in structural information, we use a measure of similarity suggested in Zhou et al. (2004) and denoted by SSIM (structural similarity index). Finally, we also include the Frobenius norm of the difference between two scars X, Y , δ norm = ||X − Y ||.
First, we compare the evolution of Cell2Fire and Prometheus fire scars on a periodto-period basis (where a period represents one hour) in order to measure the differences in the fire propagation. We denote by P romGrid t a 0-1 Matrix at time t, which represents the fire scar obtained with Prometheus, where P romGrid t ij is equal to 1 if the cell (i, j) was burned and 0 otherwise. Analogously, we define the fire scar obtained by Cell2Fire as Cell2Grid t .
Below, µ X t , µ Y t , σ X t , σ Y t and σ X t Y t represents the means, standard deviations, and cross-covariance for scars X t and Y t respectively, and C 1 , C 2 , and C 3 , are internal parameters of the metric Zhou et al. (2004). The methodology is as follows: 1. Choose a ignition point for each instance and run Prometheus for T time periods.
2. Choose the same ignition point as above and then run Cell2Fire for T time periods from this point. Outputs: Cell2Grid t , t = 1, ..., T.
3. Set X t = P romGrid t and Y t = Cell2Grid t and calculate for all t: (a) Mean Squared Error: to measure average of the squares of the pixel differences of the fire scars, and (b) Structural similarity Measure: to measure the change in structural information between the fire scars obtained from the two simulators: Cell2Fire and Prometheus.
4. Measures analysis: MSE and SSIM evolution for all time t, δ norm for the final scar.

Instances
We used three sets of fire instances to compare the performance of Cell2Fire with Prometheus: (1) Sub-instances set, (2) British Columbia province real landscapes with simulated wildfires and (3) Case study: Dogrib fire landscape.

Sub-instances
We used portions of the Dogrib landscape data (see Section 4.2.3), we generate two sub-instances that we label Sub-1 and Sub-2 with a cell resolution of 100 × 100 meters.
The first one represents a sub-forest from the Dogrib landscape that is 20 × 20 cells Based on the results shown in Table 3 and Figure 7 we can see that Cell2Fire produced results that are similar with respect to the hourly fire growth and final fire scar to those produced by Prometheus. When testing the 6 critical hours of the Dogrib fire, the level of difference (MSE) is less than 5% for the first sub-instance and less than 6% for the sub-instance 2. For the full day simulation, a slight increment of the differences is registered, reaching average MSE levels values close to 6% and 7 % for Sub-2 and Dogrib instance respectively.
On the other hand, it is possible to observe how the structural similarity measurement has a decreasing pattern (see Table 3), a situation that is even more explicit when comparing the 22 hour fire weather stream. This indicates that the fire growth   The two fire growth models are consistent and correlated in that they produce very similar fire scars for the test instances as seen in Figure 7.

British Columbia wildfire set
The http://www.firegrowthmodel.ca/burnp3/software_e.php. We generated subsets of the large forests, simulated fires in Prometheus using 24 hours weather scenarios -using historical data from the zone -and then we compare the fire scars from Prometheus with the ones obtained with Cell2Fire.
The final fire scars and performance metrics -focusing in the affected area of the instance for easier visualization -obtained for the 10 simulated wildfires in both Prometheus (columns 1 and 3) and Cell2Fire (columns 2 and 4) can be seen in Figure   8. Results indicate the high similarity between the scars, obtaining good performance across the main three metrics (

Dogrib fire instance
The Dogrib fire (Tymstra et al., 2010)  accounted for ninety percent of the total area burned and resulted in high to very high burn severities. In Figure 9 we can see the Dogrib fire perimeter and burn severity as detected by Landsat. The comparison of the performance metrics after 22 hours of fire growth is shown in Figure 10 . Here, it can be seen that Cell2Fire has a very similar evolution with respect to the wave-front approach, obtaining good performance when compared with Prometheus, not exceeding a 20% difference in both measurements. An average of 87.91% of structural similarity and a global average of 91.82% of accuracy (1-M SE) are obtained during the 22 hours of active fire growth. A clear pattern can be seen in the graph where both performance metrics start very high and remain stable during the first 4 hours, then they show a significant negative slope between hours 4 to 11, and finally reach a steady state for the rest of the simulation. The explanation behind these results is clear: during the initial 4 hours of the fire, similar fire growth occurs due to weather conditions that are not extreme, resulting in diminished model differences (wave-front and cellular-automata), however, weather factors between hours 4 to 11 contain the most extreme conditions (strong wind speed, high temperature, low precipitation levels, etc.) magnifying the fire growth differences/approximations between both approaches in terms of the number of burning cells per hour (fire scar). After hour 11, differences between fire scars tend to be very stable due to the lack of new extreme weather episodes, but keeping the structural differences -mainly in terms of the current perimeter of the fire -in the fire scars obtained in the previous hours.  Detailed results are presented in Table 5 where both (1 − M SE) and SSIM values can be seen for the full 22 simulated hours. We conclude that Cell2Fire produces results that are similar to those produced by Prometheus, obtaining similar final fire scars as seen in Figure 11 where the simulated fires and the real satellite images are shown.

Conclusions
Cell2Fire provides numerous opportunities for researchers interested in incorporating fire growth in their models for strategic harvest planning and fuel management. We are currently using it in ongoing projects.
Because it is open-source and modular it lends itself to customization as needed. The simulator is fast and scales well in parallel computing environments so it is well-suited for use with large forests and large studies that may require many simulation runs.
Using the FBP fire spread model, we have compared the simulated fire scars with those produced by the state-of-the-art simulator, Prometheus. Other fire spread models can be employed instead, which extends the range of environments where Cell2Fire can be used and also allows for comparison of fire spread models when used in a growth simulator. In addition to supporting stochastic ignition and weather, the simulator also supports modeling of the uncertainty in the rate of spread.
By adding a highly parallelizable, open-source fire growth simulator to the tool set available, we hope to provide transparent support for ongoing research.

A.1 Methodology
The high complexity of the simulation scheme poses a challenge for measuring the performance of our implementation: each fire has a large number of parameters and specific characteristics that lead to different outcomes and thus, the potential for paral- updating itself, can also "send a burning message" to an adjacent cell. In the receiving messages stage, we analyze the "burn messages" sent to non-burning cells and mark them as burned if the conditions are met. This part is also potentially parallelizable, but because the number of newly burned cells at a single time-step is dwarfed by the number of currently burning cells, we found that a speedup here is of lower priority (≈ 10% of total execution time).

A.5 Parallelization: OpenMP work-sharing
Due to the easily parallelizable structure of our code, the most suitable approach for parallelizing its execution consists of a shared-memory approach using the well-known OpenMP API. This is an advantage since the code will be also optimized for its execution in normal desktop/laptop computers, without needing a multi-node architecture to exploit parallelism. We found that we could easily make the loop embarrassingly parallel if instead of adding to a single data structure, we add to a data structure local to the worker thread. Since we would iterate over the initial data structure to compute statistics, we found the additional complexity of "distributing" the data structure does not scale with grid size. In addition, different loop scheduling options were tested: dynamic, guided, auto, run-time, and static, as well as the chunk-sized block process.
Following a brute force optimization approach, we were able to obtain an average of 15%-20% extra performance for the parallel region (see the Appendix for more details).
One final improvement we made to our parallelism was analyzing the false-sharing effect. Because we had a vector < DS > to store our "distributed" data structures, where DS is the data structure of choice, we found there to be a bottleneck on the parallelism exploited in the problem. Upon further analysis, we found this to be falsesharing in the array of DS backing the vector. After adding padding between elements of the array -where optimal values were obtained following a binary search optimization approach -we achieved a significant additional speedup from our initial attempt.
A.6 Parallel section: % of total code In order to identify the potential benefits of a parallelization, we performed a detailed analysis of the execution times, breaking it into: (1) sending time ("parallel" region), (2) receiving time, (3)    It is important is to note the fact that some instances (lower tail) will experience a poor parallel performance. The reason behind this behavior is clear: certain combinations of fuel types and forests distributions lead to a significantly smaller set of simultaneous burning cells per simulation, and thus, the parallelization of (1) will not impact the overall execution times as much as we desire. Knowing this limitation, we proceed to analyze the solving times and accuracy of the simulations.

A.7 Running times & speedup analysis
Comparing the running times of our pure Python prototype and C++ implementations with the results obtained using Prometheus, we can see in Figure 13 how the optimized version clearly outperforms the pure Python prototype, reaching up to 15-20x speedups when dealing with large instances. Furthermore, Cell2Fire (C++) obtains significant shorter times than Prometheus (up to 30x speedups). This is very important since wave-based simulators are performing a series of approximations when generating the final fire scar that simplifies the calculations performed under our cell-based approach, indicating that our implementation is efficient.
It is interesting to note that Prometheus is not able to solve the three largest instances (80M, 90M, and 100M, due to an "out of memory" error). It is therefore not suitable for massive instances. Looking at Table 7 we can see that the detailed and average speedups obtained for the small instances with the optimized OpenMP version are very good, obtaining high-performance with a certain number of threads.
Performance is even better when dealing with the large instances, improving each average speedup up to an average of 16.48x when running 32 parallel threads.
As expected, even better speedups are obtained when the dealing with homogeneous forests as can be seen in the Table 8 where a summary for the large instances speedup averages is shown. From this, we can see a near optimal average speedup up to 16 threads, while reaching a great ≈ 20x with 32 threads.

A.8 Strong Scaling
After generating the speedup and strong-scaling efficiency plots for the experimental instances, we observe that the optimized implementation is able to obtain up to 15x and 20x speedups for the small and large instances respectively, as well as averages strong efficiency factors between 75% and 82%, depending on the size and structure of the forest. In Figures 14 (a) and (b) we present the results obtained for the average values obtained among 20 instances with 500,000 cells using the optimized OpenMP implementation. Similar -slightly better -results are obtained for larger instances.
Based on all our experiments, adding more threads leads to better execution times following a flat pattern w.r.t. the strong-scaling efficiency. Thus, our optimized implementation is able to obtain a great strong scaling performance, taking into account the high complexity of the instances and variability of the results depending on the forest's structure.

A.9 Weak Scaling
Due to the high dependency of the results on forest structure, we divided our analysis for heterogeneous and homogeneous forests. When the forests are heterogeneous, the comparison between instances of different sizes and number of threads looses its meaning since there is no guarantee that the problem will scale in complexity: increasing the problem size doesn't affect the computations time directly, it depends significantly on the composition of the forest, leading to different fire dynamics. Therefore, we expect an erratic pattern when dealing with heterogeneous forests in terms of weak-scaling efficiency.
In Figure 16 we can see the weak efficiency obtained for homogeneous instances. As expected, results for heterogeneous instances lack meaning since we are not comparing the same fire dynamics (and thus, the number of simultaneous burning cells, critical for the parallel performance). On the other hand, comparing homogeneous instances gives us correct results, since we compare the same fire dynamics reaching an average weak-scaling factor value equal to 81.6%. Again, similar and even better weak factors are obtained with larger (and homogeneous) instances, following the discussion above.
Therefore, our optimized parallel implementation is able to obtain high-performance values in both strong and weak scaling factors thanks to its naturally parallel design.