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

2. Development Philosophy of PHOENIX

The development of PHOENIX RapidFire was driven by the need to have a way to realistically characterise bushfires across the landscape so as to be able to assess the relative bushfire risks to a wide range of values and assets in the landscape under a range of possible fire management regimes.

Initially, a review in the late-1990's was undertaken of the elements contributing to bushfire risk and the current state of knowledge. This was documented in 2000 (Shields 2000; Shields and Tolhurst 2003). With the establishment of the Bushfire Cooperative Research Centre (CRC) in 2004, funding was made available to continue with Bushfire Risk Assessment research. The first stage of this work was to define the Fire Management Business Model (Tolhurst et al. 2006). The fire management business model (or mitigation model) showed how 54 factors (or elements) of bushfire risk management (Figure 3) interacted to reduce bushfire risk for a given level of resources allocated to each element.

Having established a bushfire management business model, it was then necessary to be able to characterise and quantify the effect of different bushfire management strategies on reducing the level of bushfire risk (Figure 4). It was seen that the best way to characterise fires across the landscape was to use a fire simulator as this would be spatially and temporally explicit and would also be objective and repeatable. Two international fire simulators were considered, but thought to be too difficult to adapt to Australian conditions. These were the Canadian-developed PROMETHEUS simulator (Tymstra et al. 2010) and the USA-developed FARSITE simulator (Finney 2004). Three Australian fire simulators were also considered: SIROFire (Coleman and Sullivan 1996), CAFÉ (Bradstock et al. 1998) and FIRESCAPE (Cary and Banks 1999; Cary et al. 2009), but CAFÉ and FIRESCAPE simulators were designed for looking at the relative fire frequency in the landscape rather than more detailed bushfire characterization and risk analysis, and SIROFire did not capture the dynamics of high-intensity bushfires very well. As there seemed to be no suitable bushfire simulator readily available, it was decided, in 2005, to develop a new one which became known as PHOENIX RapidFire (Tolhurst et al. 2008).

The initial development of PHOENIX was primarily as a fire characterisation simulator and once that was adequately established, additional functionality was added to assist in assessing the relative level of bushfire risk. This revised simulator was renamed: PHOENIX RapidFire (Figure 5).

A number of guiding philosophies helped guide the decision-making process in the development of PHOENIX RapidFire. An understanding of these philosophies will assist others in understanding the structure and logic of PHOENIX RapidFire and what makes it unique. These philosophies will be outlined here.

2.1 Philosophy 1 – Each fire simulation must be realistic

Based on the experience of how some existing bushfire models had worked, it was decided that it was important for each fire that was simulated to be as realistic as possible. Some previous models worked on the basis that, providing there were enough simulations made, the 'general pattern' of fire in the landscape, after thousands of fires, was sufficient to draw conclusions about changes to the various inputs to the models. The philosophy with PHOENIX RapidFire differed from this because it was required that each fire should be as realistic as possible if the potential impact at any point in space or time was to be credible.

2.2 Philosophy 2 – High-intensity fires burn the largest areas and do the most damage so concentrate on them.

The initial focus of the fire simulation development was on high-intensity fires burning under severe weather conditions. This was because the potential for bushfires to cause damage was greatest during major fire events. It was initially thought that lower intensity fires would be dealt with later.

2.3 Philosophy 3 – Empirically-based verification

Because of the desire to see spatially and temporally realistic fire simulations, real fire observations were used to develop, calibrate and test the models. A range of bushfire case-studies were used to calibrate and verify the simulations. The Black Saturday Fires in Victoria in 2009 were documented in detail for the Victorian Bushfires Royal Commission and so provide one source of fires for simulation calibration and development. Fire in other States under a wider range of conditions were useful for simulator verification (e.g. Cook et al. 2009; Jacobs 2017).

Other components of the simulator were also based on field observations, such as the convection and plume model. The modelled height of the plume was compared with the plume height measured with weather radar (Chong et al. 2012b). Similarly, the modelled 'convective strength' was verified by correlation analysis, using observed areas of tree-fall and simulated estimates of convective strength (Chong et al. 2012b).

Spotting distance and patterns were based on observed spot fires during the Black Saturday fires in 2009 and other experimental work (Sardoy et al. 2008; Chong et al. 2012b, 2012a).

2.4 Philosophy 4 – The nature of the fire exposure at any point in space or time must be realistic

A corollary of the first point is that the nature of the bushfire exposure, in terms of radiation, convective heat, fire induced winds, ember density, fire intensity, and frequency of impact at any point in space or time across the bushfire landscape, must also be realistic if the potential impact on a range of values and assets is to be estimated.

2.5 Philosophy 5 – Estimates of value or asset losses should be based on real-world experience

In keeping with other philosophies, estimates of potential losses due to bushfires needed to be based on some known impacts. The best example of such an instance was the development of the 'House Loss' algorithm (Tolhurst and Chong 2011; Tolhurst et al. 2013; Tolhurst et al. 2017). House loss was found to be well correlated (about 80%) to the PHOENIX estimates of ember density, flame length and convective strength. All these factors have also been found to be the main causes of house loss in post-fire surveys (Blanchi and Leonard 2005; Blanchi et al. 2012).

2.6 Philosophy 6 – Computation of individual fires, up to 10,000 ha, anywhere in a State, should take less than one minute on a laptop computer

This philosophy is based on the desire for anyone to have access to the simulator regardless of where they are situated and regardless of whose computer operating environment they are working under. Therefore, the simulator should not need to be 'installed' and should even be able to be run from a USB drive if desired. The ease of computation and rapid simulation time is also desirable for operational use in decision support for real fire events, as well as for making simulations of thousands or millions of fire scenarios relatively cheaply and easily on multi-processor computing platforms for bushfire risk analysis and planning.

2.7 Philosophy 7 – The outputs from the simulation should be visually displayed

The complexity of bushfires means that tabular or other numeric forms of output will not be immediately accessible to the user without significant further processing, including the use of specialist software. For this reason, the outputs from PHOENIX have always included a Google Earth overlay file for rapid and easy 4-D display (x, y, z, t) with a motion replay facility. This makes the outputs easy to manipulate and investigate and also quick to identify any errors or anomalies. However, full and rich spatial and temporal data outputs are also given so that they can be post-processed using GIS or other software.

2.8 Philosophy 8 – One fire behaviour model

Bushfires are great integrators of fuel, weather, and topography. As a fire burns across the landscape, it effectively integrates fuels as it simultaneously burns in grassland, forest, heathland and plantation, so we should emulate this in the computer simulation environment rather than try to arbitrarily divide the landscape into 'fuel types'. Fuel Type classification is an artefact of forest management where vegetation is divided (classed) into vegetation types. Separate fire behaviour models for each fuel type is an artefact of manual or tabular fire behaviour calculations (e.g. Cruz et al. 2015). Whilst this might be useful for some broad management planning purposes, it is not always relevant to fire behaviour. For example, in Victoria, all the Mountain Ash forests (Eucalyptus regnans) are classified in one class, however, the fuels in this vegetation type vary widely across the landscape and this is reflected in very different fire behaviours for given weather and terrain conditions. The age of the forest can vary from young regrowth to old-growth with a partial rainforest understorey. The understorey may be a dense layer of treeferns, dense mesophytic shrubs or relatively dry sclerophyll shrubs and grasses. Each variation burns quite differently, but it is classed as just one of over 600 vegetation types in Victoria. Therefore the aim of developing the fire behaviour model in PHOENIX was to make it generic and only rely on fuel descriptions rather than vegetation types per se. To this end, fuel inputs to PHOENIX are based on the Overall Fuel Hazard Guide (Hines et al. 2010) which describes fuel within layers or strata viz. surface, near-surface, elevated, bark and potentially canopy. This fuel description method is not fully developed, but has worked sufficiently well to know that it is a better approach than using vegetation or fuel type mapping. PHOENIX dynamically incorporates different fuel strata as indicated by the model at any point in time or location.

Based on the knowledge of there being different spread mechanisms other than just radiative heat transfer, PHOENIX explicitly incorporates the contribution of short- and long-distance spotting to the rate of fire spread. This was clearly apparent in the 2009 Black Saturday fires in Victoria (Tolhurst 2009; Cruz et al. 2012), but also occurs in lower-intensity fires too. The spotting effect is driven by the strength of the local fire-induced convection, the amount of ember material, the strength of the winds and the ignitability of the fuels where the embers land (Chong et al. 2012b). PHOENIX is unique in how it captures this phenomenon.

PHOENIX RapidFire effectively uses two fire behaviour models in its current version; 'grass' and 'non-grass' models. This separation is made because there is no current way to incorporate fuel fineness into the model, but this could be done and a single, universal fire model would result. An additional modification that would enhance the universal fire model approach would be to incorporate a flame height wind speed input to the fire spread model rather than using a single wind reduction factor. The underpinning algorithm has been developed to enable this to happen, but the fuel description needs to include parameters for total vegetation height and plant density (Moon et al. 2013; Moon 2016).

2.9 Philosophy 9 – Mechanistic not Stochastic

An early decision was made that every time a PHOENIX simulation was run that it should always produce the same result if all the inputs remained the same – a mechanistic process. This is in contrast to using stochastic processes where variations in the simulation are produced due to the uncertainties of some of the processes in the modelling process, introduced as inputs varied randomly according to some pre-defined statistical distribution. The thinking here was that it was better to define the 'mean' conditions in the model and introduce any variations by deliberately varying the input values. This was considered a better option since the level of uncertainty in the input values would vary from one situation to another and the user knew the level of uncertainty being introduced and could control how uncertainty was dealt with. In the absence of applying a range of input values reflecting the range of uncertainty, PHOENIX would provide the 'best estimate' value.

Another rationale for using a mechanistic process was that to really capture the stochastic processes, hundreds of simulations might need to be run and then it is likely that some 'average' value would be derived which would be the same as using the 'mean' conditions in the first place, except having consumed a lot of computer and processing time to do it.

2.10 Philosophy 10 – Use all available data

PHOENIX was designed to make sure that it used all the available fuel, weather and terrain data. Spatial data was captured with a 'cell crawling' process which used all spatial data without 'jumping over' information. Temporal data, such as weather inputs, were used for every time step given with linear interpolation if finer time steps were needed.

Spatial data were aggregated and averaged into Fire Grid cells, but this was not found to cause any significant loss of accuracy, but it did improve computational efficiency. For example, the raw fuel data might have been captured at 25 m resolution, but then averaged into 200 m resolution Fire Grid data cells for simulation.

2.11 Philosophy 11 – Continuous fire spread

Although the input and output data is represented in a square grid, the Fire Grid, the perimeter of the fire at each time step is shown as a continuous line; there may be several fire perimeter time step lines per Fire Grid cells.

Huygen's wavelet propagation principle (Anderson et al. 1982) was used to describe the fire perimeter growth. With Huygen's propagation process, the perimeter of the fire is represented as a series of points joined by straight lines. The distance between the points is relatively small (less than 100 m) and so it gives the appearance of being continuous. The advantage of this approach is that the fire characteristics (e.g. flame height, intensity, size, time, etc.) are known for each point. Fire characteristic statistics for each Fire Grid cell are based on all the perimeter points that have passed through each Fire Grid cell. The fire characteristics of each perimeter point are also used in the dynamic suppression process in the simulation if it is being run.

2.12 Philosophy 12 – Modular software design

From the beginning of PHOENIX development, it was acknowledged that the understanding of bushfire science and computational science would change over time. The intention was to make PHOENIX as modular as possible so that elements of the simulation could be modified or swapped with better modules over time. The intention here was to 'future-proof' the simulator.

Unfortunately, with the limited resources available to the model development (less than one person full time), it was decided to just develop a model that worked and could be used by the end-users now. The logic was that if PHOENIX was to properly become operational, then time and effort would need to be spent on rewriting it and properly developing it for operational use. In this process, it was figured the coding could be made modular, but with the hindsight of what elements (modules) were needed in the simulator based on the original development and validation of PHOENIX.

2.13 Conclusions

The 12 philosophies of the development of PHOENIX RapidFire outlined here provide a very useful basis to understand how and why PHOENIX was developed the way it was. Many of these philosophies are quite fundamental to bushfire simulators for operational used regardless of what algorithms or computer systems are used.