ForeFire code is an API, a library and an interpreter with a ”pythonesque” syntax available under the GPL open source licence. Its purpose is to simulate the evolution of reactive fronts on a large domain at high resolution, ad is particularly applicable to rapid (subminute) simulation of large wildland fire. It is designed such as it can easily be run from the command line, coupled with other codes and extended with user defined propagation and surface emission (fluxes) models. Users of the code can therefore easily extend it to use it as a numerical testbed for new models. The code includes a solver that tracks the propagation of a fire front line. The fire front moves upon the earth surface according to several factors such as topography, fuel and wind. An analytical model is used to represent these effects on the propagation velocity of the front. The front is then tracked by approximating the fire front line with connected Lagrangian markers called nodes. Advection of these nodes according to the propagation velocity is carried through a constant-CFL asynchronous methodology that focus on zones of high velocity.
ForeFire code has been developed to bridge the gap between research and operational code, based on [Filippi et al.(2009)], [Filippi et al.(2011)] and [Balbi et al.(2009)]. It is now open source, designed for large scale fire simulation, can be easily extended with any new model formulations and can take typical landscape data as input. The code is composed of a simulation engine that may be integrated into other scientific environments ranging from SciPy/Numpy to Fortran numerical weather models [Filippi et al.(2013)]. Validation cannot be strictly achieved for such phenomenon, but simulation has been tested in various scenarios on Mediterranean landscape in [Filippi et al.(2014)] and [Santoni et al.(2011)]. This paper briefly presents first the numerical method that is used in the solver and in the last section the different components and uses cases of the simulation code. 1. the code can be run standalone or coupled with an atmospheric model, with similar and simple initialization procedures, 3. Velocity model(s) prescribing the propagation models may be added as well as flux(es) models for diagnostic. These specificities have been chosen at the design stage of the code with the simulation of large wildfire in mind and maximum flexibility in terms of physical parametrization. It implies a particular processing of the fire front propagation and numerical physical diagnoses that can be extrapolated from the front dynamics. 2.1
Though usually resolved by Eulerian methods in the literature such as the level-set method, this family of method (called front-capturing as the front is captured according to the values taken by a ’marker’ field) has proved to be computationally expansive as it simulates the spatial evolution of the state of the system in the whole domain [Maitre(2006)].
Front-tracking methods [Karimabadi et al.(2005)] on the contrary are designed to simulate only the spatial evolution of the interface and not a state evolution on the whole domain. The interface is described as a set of markers or vertices with coordinates that can evolve continuously in the domain (as opposed to fixed grids coordinates or particles in cell as [Coen and Schroeder(2013)]). By dealing only with the frontier, front-tracking methods need to discretize objects of smaller dimension than front-capturing methods. For example in wildland fire the discretization of the fire front is carried by approximating only the fire front line which is a 1D object, whereas front-capturing methods would have to approximate a 2D surface. Moreover the avection of each marker is relatively easy and computationally efficient way. The benefit in computational time is obvious but the counterpart is the need to handle topological changes with care. The objectives of the method used in ForeFire is to be as precise as possible to track the position of the fire front, deducing fuel loss, and requires to be less dependent on the input data resolution (wind, fuel), with less constraints on time-step. 2.1.1
Unlike conventional Lagrange methods for the advection of markers in a flow, Discrete Event Simulation (DES) advect its markers by solving the inverse problem, i.e. fixing a quantum distance rather than a time step. Instead of computing the spatial displacement while moving towards its new location in time t + dt the proposed algorithm computes the duration taken by a marker to move towards its next location.
This paradigm for solving advection results in a continuous discretization of time, i.e. ti(n) can take arbitrary values. This means that: 1. markers will not move at adjacent times, i.e. a record of which markers are to be advected according to their final time ti(n+1) has to be handled, 2. advection for markers with a large velocity is processed much more often than markers with slow motion. This feature is of great interest in strongly inhomogeneous flows such as wildland fires as it focuses the computation on the areas of high velocity, which usually corresponds to the areas of interest. Indeed the markers with low velocities will have large time-steps and thus will only be re-computed in a large amount of time, leaving space for the computation of high velocity markers. 3
ForeFire assumes that all the input data is contained in a single NetCDF file (fuel, wind, domain). Generating
this landscape file is part of companion scripts and may be done using either atmospheric models or simple raw
station data. One the data input is available, simulation in itself may be performed in various ways described
in this section. Specifically, this is possible because the software compiles in a shared library, that has optional
bindings to different programming languages and data formats to use as input/outputs (figure 1).
Interaction with the simulation is made with so-called commands, these can be either software calls (functions
available in Fortran/Python/C++/Java interfaces) or command calls from the interpreter (a binary file launched
from the command line) (figure 2).
Adding a velocity model such as Balbi
The philosophy of the tool presented here is typical of both scientific and operational software, with sources available, self compiling and expandable code but also having connections with data formats that allows to simulate real fire on existing data in a very limited time. Further work is focused on coupling with real-time data feed, enhance the python interface and add more interaction methods.
This research is supported the Agence Nationale de la Recherche, grant ANR-16-CE04-0006 FireCaster.