Info |
---|
Table of contents
- Introduction
- Development philosophy of PHOENIX
- The Fire Grid
- Inputs
- Fire Behaviour
- Fire Perimeter Propagation
- Asset Impact
- Outputs
1. Introduction
1.1 Purpose of this document
This document provides a technical overview of PHOENIX RapidFire 4.1 (often abbreviated to 'PHOENIX' in this document) for the benefit of:
...
This document provides the information necessary to allow PHOENIX to be compared to other similar systems. It contains technical detail and references technical detail contained in other documents where appropriate. It is part of a series of key documents about PHOENIX including:
Be aware that in addition to the above, various government agencies have produced guidelines for PHOENIX that are specific to support their individual operating environments. Also, there are various technical papers that have been prepared by the University of Melbourne and the Bushfire CRC that this document draws upon, and which are referred to throughout.
1.2 Navigating this document
This document starts by introducing the PHOENIX RapidFire fire simulation software, what it is, why it was developed and how it works (Chapter 1). It goes on to discuss the development of and development philosophy behind PHOENIX (Chapter 2) and then describes in detail:
...
Appendix 3 provides a discussion on the simulation process, from ignition, through to build-up, spotting and fire spread.
1.3 What is PHOENIX
PHOENIX is a bushfire characterisation model that integrates fuel, terrain, weather conditions and suppression to simulate a fire's development and progression in the landscape. It is used by land and fire managers to support fire management and land-use planning and to support decision making during bushfires.
PHOENIX is a mechanistic continuous, dynamic, empirically-based model that simulates fire characteristics such as fire spread, flame height, intensity, size and ember density and stores the results in a database (using spatially gridded data), and can also simulate some the effects of suppression efforts and the impact of fire on various values and assets.
At a minimum, PHOENIX requires fuel data as an input. However, there are several inputs, including terrain, weather, suppression, fire history and assets that are required for realistic simulations. These inputs must be prepared correctly in a spatial format.
PHOENIX produces a range of outputs including fire spread, intensity, flame height, ember density, burn frequency and asset impact. The outputs of a simulation can be viewed in GIS, Google Earth, as images and in spatially gridded data provided in ASCII, XML, CSV and Shapefile file formats.
1.4 How PHOENIX works
PHOENIX is a standalone executable program designed for operation under Microsoft Windows, but can also be easily converted to Mono to run on UNIX and LINUX operating systems. It has a graphical user interface (GUI), but can also be controlled via command line to allow integration with other software systems. It is standalone software that does not need to be installed and therefore can be run directly from a device such as a USB storage device. It is also designed to support running across more than one computer (where one computer is the master) or processor, for more complex simulations requiring more processing power.
In order to gain an overview of how the simulation process in PHOENIX works, an overview is offered below based on Figure 1. A more detailed explanation is offered in Appendix 3: The Simulation Process.
Figure 1.Simulation process used in PHOENIX RapidFire
To trigger a simulation the user specifies an ignition time and location. This is used to access the underlying input layers such as fuel, terrain and weather, in order to start the fire behaviour calculations.
Each new fire (including spot fires) has an initial build-up phase. The rate of build-up is based on the conceptual model described by Cheney (1981) modified so that the proportion of the available fine fuel and the wind speed affecting the build-up rate of spread is related to the proportion of the build-up.
Each point on the perimeter is dealt with individually using Huygen's spread principle (Andersen et al. 1982). Flame height is used to determine which fuel strata are incorporated in the fire behaviour. For non-grassland fuel types, flame height and maximum spotting distance for each point are based on a modified McArthur model (McArthur 1967), fire intensity and spread rates are based on a unique dynamic fire spread algorithm developed for PHOENIX and a modified CSIRO grassland model (Cheney et al. 1998) for fuel types that have no elevated fuel component.
The convection model in PHOENIX assumes that convection columns will form over the hottest areas of a fire. It uses this information, in conjunction with (terrain modified) wind speed and direction to determine potential ember impact patterns.
The convective strength and amount of bark fuel of each heat centre are used to determine the quantity of embers launched and the expected travel time for the embers once aloft. PHOENIX calculates the probability of embers igniting a spot fire. Once the probability of ignition is high enough, a spot fire is initiated. Any spot fires are run as independent fires and start by going through a build-up phase.
Perimeter expansion is modelled in discrete time steps. At the end of each time step, the fire perimeter is checked for any 'tangles' or coalescence with another fire such as a spot fire. As a perimeter grows additional vertices are added to the perimeter if required to keep the distance between each perimeter point less than the size of the Fire Grid defined for the simulation.
The computational sequence is now repeated for the new time step with fuels, weather and terrain conditions reassessed to find current conditions.
1.5 An overview of the components of PHOENIX
Figure 2 provides a diagrammatic overview of each of the components of PHOENIX. Broadly speaking, components are divided into:
Fire Grid. PHOENIX represents and stores data against a spatial grid called the Fire Grid. The Fire Grid is initially populated with inputs, and then outputs after the simulation.
Inputs. The user provides inputs as spatial or temporal data to support PHOENIX.
Models. PHOENIX accesses input data stored in the Fire Grid or other underlying data in order to run various calculations to support the simulated fire spread and asset impacts.
Outputs. PHOENIX produces a range of outputs including fire perimeters and fire characteristics stored against the Fire Grid. Input values are also provided in the Fire Grid.
This document is structured based on Figure 2, and the numbers against each component of the figure correspond to section numbers within this document. The figure is repeated at the start of each chapter and section, as a visual aid to orientate the reader.
Table 1 offers a brief description of the purpose of each component. Later chapters describe these components in detailed.
Figure 2. Overview of the PHOENIX components including inputs, data representation, models and outputs. The numbers against each element refer to chapters or sections within this document.
Table 1. Purpose of each component of PHOENIX
Chapter / Section | Chapter Name | Component Name | Purpose |
---|---|---|---|
3 | FIRE GRID | The Fire Grid is central to PHOENIX in that it is used to manage and represent data. It is used for inputs, to feed data to the models and to store outputs. | |
4 | INPUTS | Inputs are the underlying spatial or temporal data layers provided by the user that power PHOENIX. | |
4.1 | Fuel Types | Fuel type is a mandatory input layer required by PHOENIX to generate fine fuel levels for each fuel stratum. | |
4.2 | Wind Reduction Factors | Forecast wind data is provided at 10 m above ground. PHOENIX takes this data and converts it to wind speeds at 1.5 m above ground for use by various PHOENIX models. | |
4.3 | Fire History | Fuel types are used in conjunction with the fire history layer to generate fuel levels at the time of the simulation. | |
4.4 | Topography | A digital elevation model (DEM) is required by PHOENIX to support various models, such as slope correction, wind field models and map reprojection. | |
4.5 | Asset and Values | The user can provide data about asset types, value and vulnerability in order to support the Asset Impact PHOENIX model. | |
4.6 | Road Proximity | PHOENIX uses the road proximity layer to assess how much, if any, roads will assist in suppression efforts. | |
4.7 | Fuel Disruptions | The Fuel Disruption Layer defines the location and width of linear features such as roads, streams, firebreaks and railway lines that are generally devoid of fuel and may act as barriers to the progress of a fire. | |
4.8 | Weather | PHOENIX requires weather data to support various fire spread models. | |
4.9 | Suppression Resources | To provide the data necessary to run the PHOENIX suppression simulation model. | |
5 | FIRE BEHAVIOUR | The various models that drive underlying fire behaviour, including fire behaviour models, slope correction, convection, ember generation, fuel moisture and breaks in fuel. | |
5.1 | Behaviour Models | Fire behaviour models form the basis of simulations of fire spread and other fire characteristics within PHOENIX. | |
5.2 | Spotting / Embers | Simulates ember generation, lofting, transport and distribution. | |
5.3 | Slope Correction | Slope is derived by PHOENIX from the digital elevation model and is used to modify the outcomes of fire behaviour models. | |
5.4 | Wind Field Models | PHOENIX can incorporate a wind modification layer that represents the deviation in wind speed and direction caused by local topography, to modify the outcomes of fire behaviour models. | |
5.5 | Road / River / Break Impact | Linear fuel elements with no fuel such as roads and streams can be highly disruptive to fire spread, with their effect far exceeding the area they represent. PHOENIX implements a process that attempts to capture this effect. | |
5.6 | Solar Radiation Model | PHOENIX incorporates a solar radiation model to determine the amount of solar radiation at each cell of the Fire Grid. Solar radiation is required as an input into the fuel moisture and suppression models. | |
5.7 | Fuel Accumulation | Fuel levels are considered in a dynamic manner, using the time since the last fire to moderate total fuel levels for each stratum. These are then used in fire behaviour calculations. | |
5.8 | Fuel Moisture | Fine fuel moisture is an important component for fire behaviour calculations. PHOENIX incorporates a fine fuel moisture model. | |
5.9 | Convection / Heat Centres | The outputs of the convection model are used in conjunction with wind speed and direction to support simulation of ember lofting and distribution. | |
6 | FIRE PERIMETER PROPAGATION | Includes models that deal with the spread of the fire perimeter. This includes perimeter expansion, spot fire generation and how fire spread is ameliorated through suppression efforts. | |
6.1 | Point Spread Modelling | This model simulates the movement of the active fire perimeter. | |
6.2 | Self-Extinction | A self-extinction process is incorporated into PHOENIX, in which parts of the perimeter are predicted to extinguish if heat output is less than a threshold value. | |
6.3 | Reprojection on Map | During the perimeter modelling process, a surface-to-plan conversion of point spread is carried out to accurately capture the fire perimeter in three-dimensional space. | |
6.4 | Suppression Model | The suppression model modulates fire spread based on suppression resources provided by the user. | |
6.5 | Spot Fires | Starts new fires outside of the fire perimeter where burning embers land in suitably flammable fuels. | |
7 | ASSET IMPACT | PHOENIX provides for the intersection of fire attributes with maps of assets to allow estimates of fire damage. Characterising fires by asset impact provides an additional means of comparing fire management options. | |
8 | OUTPUTS | PHOENIX produces a wide range of outputs. Vector perimeter isochrones are a standard output, produced both as ESRI Shapefiles and Google Earth KMZ files. In addition, a wide range of gridded cell values about fire characteristics can be outputted in various formats. |