Table of contents

1. Introduction
2. Development philosophy of PHOENIX
3. The Fire Grid
4. Inputs
5. Fire Behaviour
6. Fire Perimeter Propagation
7. Asset Impact
8. 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:

• New users;

• Land and fire managers;

• Software technicians; and

• Others who wish to gain a greater understanding of the uses and components of PHOENIX.

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:

• How data is collected, represented and stored in PHOENIX using the 'Fire Grid' (Chapter 3);

• The inputs that are required or that are beneficial to support PHOENIX (Chapter 4);

• How each component model of PHOENIX works (Chapter 5: Fire Behaviour, 6: Fire Perimeter Propagation and 7: Assets); and

• The outputs that the user can generate from PHOENIX (Chapter 8).

Appendix 1 lists the various versions of PHOENIX and what each version added to software functionality.

Appendix 2 lists the actual files read by PHOENIX and their relationship to the inputs discussed in this document.

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.

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.

Table 1. Purpose of each component of PHOENIX