Input data to the model must be prepared in a GIS such as ESRI's ArcGIS or MapInfo. This base data is then converted into a format read by PHOENIX which is an ASCII grid broken into data tiles. Tiling can be achieved manually, but is better achieved using ancillary support tools provided as part of PHOENIX, installed as part of the ArcGIS Toolbox.

In some cases an Input to the model is produced by taking several data files provided to PHOENIX (as configuration or spatial data sets) and performing some pre-processing. The relationship between inputs and file names used by PHOENIX as described in Appendix 2. For detailed instructions on preparing data for PHOENIX (including descriptions of preparing individual input layers), please refer to the PHOENIX Input Data Guide.

Generally, PHOENIX input data has the following requirements:

All data layers must be in the same coordinate system, and this must be a map grid projection (grid reference in metres) not a geographic one (latitude and longitude in degrees). In Victoria, using 'VicGrid 94' is recommended, which is a Lambert Conformal Conic Projection with a GDA 94 reference Datum. Across Australia, using 'Geoscience Australia Lambert 94' projection is recommended, which is also a Lambert Conformal Conic Projection with a GDA 94 reference Datum.
The only data layer that must be provided is fuel types. However, other layers are required for realistic simulations. If there is no fuel types file location specified, then the input value defaults to zero (no fuel, or bare area).
As all data layers must be in the same coordinate system only one GIS spatial projection file is required.
Layers are broken into 'tiles' and packaged as zip files, to decrease the size and number of files that have to be copied and transported. The zipped files are unzipped on the first run of a simulation session.

4.1 Fuel types

4.1.1 Purpose

Fuel types is a mandatory input layer required by PHOENIX to generate fine fuel levels for each fuel stratum (surface, elevated and bark – see Hines et al. 2010 for details).

4.1.2 Basis

Fuel type is built upon spatial vegetation type data.

In Victoria, 900 or so vegetation types (EVCs) were manually assigned to one of about 40 fuel types by Kevin Tolhurst on the basis of his knowledge and experience. This was initially done to enable a proof-of-concept run of the PHOENIX simulation. However, this initial classification is largely still being used. In some areas, there have been efforts to improve/correct this classification. In NSW, a significant effort was made to map the fuel types and their accumulation rates after fire, as part of a separate research program. South Australia, Western Australia, Tasmania and Queensland have undertaken similar processes to what has occurred in Victoria.

4.1.3 Assumptions and limitations

Vegetation type is used because it is assumed that vegetation type is the most likely layer to be kept up-to-date by government agencies. The mapping must cover the whole area. Areas with no fuel type mapped will be assumed to not carry fire.

Fuel types with no elevated or bark fuel are assumed to be grasslands.

4.1.4 User interactions

Due to varying vegetation classification standards in different jurisdictions, vegetation types must be converted/aggregated to fuel types by the user. The user prepares the input layer by assigning each vegetation type to a user-defined fuel type for use in PHOENIX. The maximum fine fuel levels for each fuel stratum (surface, elevated and bark) and the rate of reaccumulation in each stratum after burning must be specified for each fuel type defined.

4.1.5 Description

Management agencies commonly spatially classify landscapes into distinct vegetation types suitable for use in modelling (Sun et al. 1998). It is acknowledged that there are several vegetation type classifications and a range of mapping detail and quality within some states and between states. Therefore, in the creation of the PHOENIX fuel layer, each vegetation type must be classified into a fuel type and assigned an integer code ('FuelCode') by the user. An example of a fuel type classification is shown in Table 3. The fuel mapping must cover the whole area being simulated. Areas with no fuel type mapped will be assumed to carry no fuel (e.g. a water body) and therefore will not carry fire.
A lookup table of fine fuel parameters must then be defined and conform to the PHOENIX convention. This lookup table is typically called 'Fueltype.xml' and joins to the fuel type layer via the FuelCode. Section 5.7: Fuel Accumulation has more information.

Fine fuel hazard levels are converted to an equivalent fine fuel load (t/ha). While coarser fuels are consumed during a fire, the combustion of fine fuels is the process that predominantly determines spread rates. Fuels are considered as three separate strata; surface (which includes near-surface fuels), elevated fuel and bark, in accordance with forest fuel measurement standards in Southern Australia (McCarthy et al. 1999; Hines et al. 2010). Fuel classes that have no elevated or bark fuels are considered by PHOENIX as grasslands and are processed using functions derived from the CSIRO grassland fire spread model (Cheney et al. 1998).

Table 3. PHOENIX fuel types currently recognised in southern Australia.

Veg Type	Code	FuelCode	Description	Fuel Characteristics
Forest	F01	15	Rainforest	dense vegetation with little dead material, epiphytes, vines, ferns, rarely dry
	F02	32	Wet Forest with rainforest understory	wet sclerophyll forest with a mesic understorey
	F03	13	Riparian Forest shrub	dense vegetation but with a small proportion of dead material
	F04	11	Wet Forest shrub & wiregrass	high biomass forest, but with little dead suspended material unless wiregrass present
	F05	12	Damp Forest shrub	dense understorey and potentially high bark hazard (karri)
	F06	40	Semi-mesic Sclerophyll forest	forest with semi-mesic shrubs and flammable grasses, sedge understorey
	F07	33	Swamp Forest	dense Melaleuca forest with little understorey
	F08	6	Forest with shrub	potentially high bark hazard, shrubs moderate flammability (mixed jarrah/karri)
	F09	7	Forest herb-rich	potentially high bark hazard, little elevated fuel
	F10	45	Dry Forest shrubs	dry forest with continuous understorey, (southern jarrah)
	F11	8	Dry Open Forest shrub/herbs	dry forest with open understorey (northern jarrah)
Grass/sedges	G01	16	High Elevation Grassland	dense sward of tussock grasses or herbs, high cover
	G02	4	Moist Sedgeland / Grassland	dense sward, potentially high dead component, button grass
	G03	29	Ephemeral grass/sedge/herbs	dense grass and sedges with potentially high levels of dead suspended material
	G04	20	Temperate Grassland / Sedgeland	grasses and sedges widespread, but varying in biomass
	G05	44	Hummock grassland	hummock grassland, discontinuous surface fuels
Herbs	H01	30	Moorland / Feldmarks	low flammability cushion plants
	H02	36	Alpine herbland	dense, upright, low flammability herbs
	H03	34	Wet herbland	freshwater herbs on mud flats
	H03	37	Wet herbland	low herbs in seasonally inundated lakebeds or wetlands
Mallee	M01	27	Mallee chenopod	low flammability except after exceptional rain bringing grasses
	M02	42	Mallee grass	mallee woodland with predominantly grass understorey
	M03	25	Mallee shrub/heath	continuous shrub layer but amount of dead material depending on species present
	M04	26	Mallee spinifex	discontinuous fuels, very flammable under windy conditions
Bare	NIL	0	Water, sand, no vegetation	fuel absent
Plantations	P01	98	Softwood Plantation	dense canopy with continuous surface fuels
	P02	99	Hardwood Plantation	uniform canopy with continuous surface fuels
Shrubs	S01	17	High Elevation Shrubland/Heath	dense cover of shrubs with surface fuel largely under plants
	S02	14	Riparian shrubland	dense vegetation with little dead material
	S03	35	Wet Scrub	flammable shrubland with high level of dead elevated fuels
	S04	1	Moist Shrubland	dense shrubland, salt affected
	S05	31	Dry Closed Shrubland	tea-tree or paperbark thickets, little understorey
	S06	21	Broombush / Shrubland / Tea-tree	dense shrubland, but with relatively low level of dead material
	S07	10	Sparse shrubland	sparse shrubby vegetation with discontinuous surface fuels
	S08	3	Low flammable Shrubs	low flammability except after exceptional rain bringing grasses
	S09	38	Mangroves / Aquatic Herbs	trees, shrubs and herbs in permanent water, unburnable
Heaths	S10	23	Wet Heath	dense heath possibly with dense sedgy undergrowth
	S11	24	Dry Heath	dense heath with significant amounts of dead material
Woodland	W01	18	High Elevation Woodland shrub	wooded area with shrubby understorey
	W02	19	High Elevation Woodland grass	wooded area with continuous grass tussocks
	W03	97	Orchard / Vineyard	orchard or vineyard
	W04	2	Moist Woodland	low trees, shrubby, sedgy understorey, bark hazard
	W05	22	Woodland bracken/shrubby	wooded area with varying understorey, but not heathy
	W06	9	Woodland Grass/Herb-rich	surface fuels dominated by grass and herbs
	W07	5	Woodland Heath	flammable shrubs and high bark hazard
	W08	41	Gum Woodland heath/shrub	gum woodland with moderate bark hazard, heath/shrub understorey
	W09	43	Gum Woodland grass/herbs	gum woodland with moderate bark hazard, herbaceous understorey
	W10	39	Savanna grasslands	tall flammable grasses in an open woodland
	W11	28	Woodland Callitris/Belah	low flammability except after exceptional rain bringing grasses

4.2 Wind reduction factors

4.2.1 Purpose

Bureau of Meteorology 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.2.2 Basis

Wind reduction factors are specified by the user for each defined fuel type in the Fueltype.xml file (See Section 5.7: Fuel Accumulation).

4.2.3 Assumptions and limitations

It is assumed that the wind at 1.5 m is the 'mid-flame height' wind speed which is clearly untrue for very low-intensity fires and very high-intensity fires. It also assumes that the wind reduction factor is a constant, but it is known to vary from day to night and with the magnitude of the wind speed in the open.

4.2.4 User interactions

Wind reduction factors can only be changed by the user by redefining the fuel type characteristics in the Fueltype.xml file.

4.2.5 Description

Wind reduction factors are assigned to each fuel type in the fueltype.xml file. Values for the wind reduction factors are not well studied and so many will have to be estimated by an experienced fire behaviour scientist. Some guidance on the values of wind reduction factors can be gained from the Western Australian 'Red Book' (Sneeuwjagt and Peet 1998 p.30). The wind reduction factor is used to estimate the mid-flame height wind speed within the vegetation based on the observed or forecast wind speed measured at 10 m in the open. In 18 m high open eucalypt forest, McArthur assumed that the wind reduction factor at 1.5 m above the ground was a factor of 3. In Jarrah forest in Western Australia, Project Vesta found that the wind reduction factor at 5 m above the ground was also a factor of 3. In grassland, there is no wind reduction factor assumed so the value is set to 1. In grassy woodland in northern Australia, Cheney et al. (1998) found the wind reduction factor to be a factor of 2. Since flame height varies from low-intensity surface fires to high-intensity crown fires, the reality is that the wind reduction factor is not constant even for a single fuel type, but a single typical value is used. Work by Kangmin Moon (2016) developed a model of estimating the wind reduction factor in different fuel types at different heights which would enable the use of a dynamic wind reduction factor, but this has not yet been incorporated into PHOENIX.

The cell wind reduction factor is also used to estimate an approximate leaf area index (LAI) used to calculate shading based on Beer's law (Silberstein, Sivapalan et al. 2003). Refer to Section 5.6: Solar Radiation Model for further information on how shading is used.

4.3 Fire history

4.3.1 Purpose

Fuel types are used in conjunction with the fire history layer to generate fuel levels at the time of the simulation. Based on the time of ignition specified by the user, fuel levels are calculated through the combination of fuel type and the time since the last fire using fuel accumulation curves defined in the fuel type conversion file.

4.3.2 Basis

This layer is based upon fire history provided by the user.

4.3.3 Assumptions and limitations

In the case of overlapping fire histories, PHOENIX only uses the most recent fire occurrence.

4.3.4 User interactions

PHOENIX uses the fuel accumulation model (see Section 5.7: Fuel Accumulation) to calculate fine fuel hazard classes which are then converted to an equivalent fuel load (t/ha) for surface, elevated and bark fuels. The accumulation curves are part of the fuel type conversion file.

The user can upload a supplementary fire history layer to PHOENIX to capture recent fire events or to explore the effect of hypothetical fires in the landscape.

4.3.5 Description

Fuel types are used in conjunction with a user-provided fire history layer to create fuel layer information used in PHOENIX simulations and stored in the Fire Grid. The time since the most recent fire is used to estimate fuel levels using negative exponential accumulation curves (discussed in Section 5.7: Fuel Accumulation). As data is retained for only the most recent fires (see Figure 9), where historic fires are being simulated, the fire history layer must be adjusted to be representative of the appropriate conditions.

Figure 9. Diagram of how PHOENIX treats overlapping fire history. On the left, two fires have been mapped, one in 1972 and the other in 1985. On the right, a new fire in 2008 has overlapped these earlier fires and has replaced their fire history in the overlapping areas.

ESRI Shapefiles can be used to supplement the baseline fire history layer for particular simulation runs. This provision is made to account for fires that have occurred since the baseline fire history was processed or to enable hypothetical prescribed burning scenarios to be quickly evaluated. The supplementary fire history is added to any existing fire history layer and processed in the same manner as the fire history stored in the Fire Grid.

4.4 Topography

4.4.1 Purpose

A digital elevation model (DEM) is required by PHOENIX to support various models, such as slope correction, wind field models and map reprojection.

4.4.2 Basis

An ASCII grid DEM provided by the user with values represented as heights above sea level.

4.4.3 Assumptions and limitations

That the DEM is accurate.

4.4.4 User interactions

Preparation and provision of input data.

4.4.5 Description

From the DEM, elevation, slope and aspect are determined using bilinear interpolation with neighbouring cell values during a simulation. Bilinear interpolation is a common texture mapping technique.

4.5 Assets and values

4.5.1 Purpose

The user can provide data about asset locations, type, value and vulnerability in order to support the Asset Impact PHOENIX model (see Chapter 7: Asset Impact).

4.5.2 Basis

The asset and values layer can be built by the user using one or more spatial datasets that represent assets and values (such as houses, infrastructure, catchments, plantations or biodiversity values).

4.5.3 Assumptions and limitations

A limitation of using an ASCII grid for primary input data is that only one asset can be recorded against an input data cell (e.g. 30 x 30 m), although this might correspond to 30 or more asset types for each Fire Grid cell (e.g. 180 x 180m). All spatial data must be converted to density per square metre for consistency in using different Fire Grid cell sizes. Impacts can be calculated for up to 99 asset types and evaluated against up to 99 loss functions. Asset values are limited to a maximum of 4 digits and 4 decimal places giving an effective range of 0.0001 to 9999.

4.5.4 User interactions

The user prepares an asset data code in an ASCII grid. The asset code includes the asset type, and impact type, an asset priority and an asset value for that cell in units per square metre.

4.5.5 Description

Users can draw on a range of spatial data layers in order to build a composite asset and values input layer. Examples include state and federal government data for property addresses, critical infrastructure or biodiversity values. For example, Tolhurst et al. (2017), in Appendix C, contains a review of potentially suitable data layers in Victoria, and Appendix A described the process of creating the composite asset layer in detail (using point, line and polygon data sources).

Against each cell of the input asset layer (e.g. 30 m raster) the user assigns an asset type, asset priority, an impact type and asset value per square metre, to build an asset code. Assets are sampled by the Fire Grid for use in the PHOENIX asset impact model. Chapter 7: Asset Impacts, has more information.

4.6 Road proximity

4.6.1 Purpose

Roads play an integral role in fire suppression, providing access and acting as anchors for suppression, backburning and burning out (Arienti et al. 2006). PHOENIX uses the road proximity layer to assess how much, if any, roads will assist in suppression efforts.

4.6.2 Basis

Road proximity is gridded data created from a road GIS layer provided by the user.

4.6.3 Assumptions and limitations

It is recommended that maximum values are truncated at 1,000 m as beyond this distance roads are assumed to have minimal influence. It is recommended that proximity is calculated to the nearest 50 m.

4.6.4 User interactions

Creating a road proximity raster data layer from road polylines for the development of a 'road proximity' ASCII grid data layer for PHOENIX.

4.6.5 Description

PHOENIX incorporates the effect of roads on suppression rates by calculating the average distance (in metres) from the nearest road for each Fire Grid cell from a data input layer typically called 'Road_Prox' (see Section 6.4: Suppression Model for more information).

A road proximity input data layer is created by the user from a 'polyline' feature road layer. GIS software is used to create the Road_Prox input data layer at the typical data resolution (e.g. 25 or 30 m). This analysis records the proximity to the nearest road to the nearest 50 m for a maximum distance of 1,000 m. Please refer to the PHOENIX Input Data Guide for instructions.

4.7 Fuel disruption

4.7.1 Purpose

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.7.2 Basis

Created from vector linear data prepared by the user in a program such as ESRI ArcGIS.

4.7.3 Assumptions and limitations

It is assumed that there will be little or no fuel on these linear disruptions.

4.7.4 User interactions

The user must prepare linear GIS layers with a field called 'width' for each linear feature that describes the effective width of the fuel-free area along the length of the linear feature. This is then converted into a raster data grid (usually 30 m or 25 m resolution) using GIS software.

4.7.5 Description

There is likely to be a number of GIS layers needed to describe all the linear fuel disruptions in the landscape, however, each of these GIS layers must be prepared to contain a field called 'Width' which describes the effective width of the fuel-free area along the length of the linear feature (polyline).

The various layers are combined by the user to create a single ASCII fuel disruption file which represents the combined widths of various disruptive features occurring at each point. The resultant raster input data file is typically called 'Disruption.zip'.

The width of the disruption will be used in PHOENIX to determine the effect of the disruptions on the local fire intensity and will determine if the local fire intensity is sufficient to breach the disruption. This is discussed in Section 5.5: Road / River / Break Impact.

4.8 Weather

4.8.1 Purpose

PHOENIX requires weather data to support its fire spread models.

4.8.2 Basis

PHOENIX can incorporate spatially gridded weather data, in NetCDF format, as produced by the Bureau of Meteorology. Alternatively, the user can provide a stream of weather data for a particular point in the landscape and at known intervals of time.

4.8.3 Assumptions and limitations

Where weather data is provided as a stream of point data, the same weather conditions are assumed to apply for the entire fire. PHOENIX does not discriminate between forecast and observed data.

4.8.4 User interactions

The user can download gridded weather from the Bureau of Meteorology. A downloading tool has been developed to assist and automate this process. Alternatively, the user inputs a stream of weather data at specified time intervals. Grass curing can input into PHOENIX simulations as part of a point weather stream, gridded weather input or as a separate spatial data layer.

In the case of the passage of a cold front, additional entries may be added to the dataset immediately before and after the front's impact if a sudden change is wanted. Excluding this will result in a gradual shift in conditions from weather conditions input at the time step before the change and the time step after the change.

4.8.5 Description

To initialise PHOENIX to process fires on a particular day, the appropriate daily values for Drought Factor (Finkele et al. 2006) and grass curing (McArthur 1966) are required. The Drought Factor, an index of fine fuel availability developed specifically for the McArthur forest fire spread model, is derived from the number of days since rain and the Keetch-Byram drought index (Keetch and Byram 1968). When using PHOENIX to make future predictions, forecast rain may need to be considered to estimate Drought Factor.

PHOENIX provides a tool to download NetCDF data provided by BoM. NetCDF data is an open data standard used internationally to create and share data. Currently, only spatially gridded weather data compatible with the Australian Bureau of Meteorology's Gridded Forecast Editor (GFE) tool are supported.

The NetCDF files produced by the Bureau of Meteorology and used by PHOENIX are:

Surface Temperature (oC);
Surface (10m) Wind Speed (km/h);
Cloud Cover %;
Surface Relative Humidity (%);
Surface (10m) Wind Direction (deg.);
Drought Factor (0-10);
Grass Curing (0-100%); and
KBDI – Keetch-Byram Drought Index (0-200).

In Victoria and Tasmania, the resolution of the gridded weather forecast data is currently about 3 km, but in Queensland, NSW, WA, and South Australia, the NetCDF weather data has about a 6 km spatial resolution. All NetCDF data used currently has a one-hour temporal resolution.

Figure 10. Victorian gridded Temperature data for 11 am 7 February 2009.

Alternatively, a string of weather data can be specified. Values for the air temperature (oC), relative humidity (%), wind direction (deg), wind speed (km/h), drought factor (0-10), degree of grass curing (%) and cloud cover (%) for specified times must be provided as specified in Table 4. An example is provided in Table 5.

Table 4. Standard weather attributes

Attribute	Comments
Date/Time	Date and time of weather condition
Temperature	10 minute average in °C measured at 1.5 metres in a screen
Relative Humidity	10 minute average as a %, measured at 1.5 metres in a screen
Wind Direction	10 minute average in degrees, measured at 10 metres in the open
Wind Speed	10 minute average in km/h, measured at 10 metres in the open
Drought Factor	Fine fuel availability 0-10
Curing	Grass curing level as a % (0-100)
Cloud	Cloud cover as a % (0-100)

Table 5. An example of user-provided point stream weather inputs that are time-stamped

4.8.5.1 Upper-level winds

For simulations, PHOENIX either uses forecast wind data at 10 m above ground or otherwise converts this data to wind speeds at 1.5 m above ground (refer to Section 4.2: Wind Reduction Factors).

During its development, PHOENIX was modified to incorporate multi-level wind data, however, the forecast data had an uncorrected bias that resulted in incorrect ember transport modelling results. The lack of systematic, high resolution and comprehensive upper-wind observations makes bias correction and fire model testing impossible at the current time. It was therefore not possible to develop an improved ember transport model for PHOENIX using multi-level wind data (Chong et al. 2012a).

The option of including a single layer of upper-level wind was incorporated into PHOENIX for theoretical testing purposes. However, it is not available in the operational version of PHOENIX (Chong et al. 2012a).

For a discussion on the evaluation of upper-level winds on ember transport within PHOENIX, refer to the Incorporating Vertical Winds into PHOENIX RapidFire's Ember Dispersal Model (Chong et al. 2012a) Bushfire CRC and University of Melbourne technical report.

4.8.5.2 Interpolating weather data

Spot forecast, gridded forecast and automatic weather station data are often temporally quite coarse. If used in this raw form, weather data would result in instantaneous condition changes at the supplied date and time, which (apart from a frontal system) would not be realistic. To emulate real-world weather behaviour, weather conditions are linearly interpolated between entries.

Figure 11. Raw versus interpolated temperature values (in degrees Celsius).

A simple linear interpolation is used to derive continuous weather conditions for:

Temperature;
Relative humidity;
Wind speed; and
Wind direction.

BoM Gridded weather data is produced twice a day and provides forecasts for each hourly interval. However, for point stream data, time intervals can be specified down to 1-minute resolution. Specifying intervals shorter than an hour does not necessarily improve the accuracy of PHOENIX. In the Bushfire CRC and University of Melbourne Technical Paper Evaluation of weather data at different spatial and temporal scales on fire behaviour prediction using PHOENIX RapidFire 4.0 - Kilmore Case Study (Chong et al. 2012c), it was found that course level inputs performed better than very fine time-scale inputs and that 30 minute intervals were optimal (though more testing is needed, Chong et al. 2012c).

That being said, in the case of a frontal system, extra entries immediately before and after the front's impact may be necessary to accurately model changing conditions. The span of time between the 'before' and 'after' the passage of a cold front needs to reflect actually expected period of the transition.

4.8.5.3 Grass curing

Grass curing level is used in the grass rate of spread function. It can be inputted as part of a point weather stream, gridded weather input or as a separate spatial data layer. Providing curing as a separate spatial data layer allows for a higher resolution input, which can be important where curing levels are highly variable. If a separate curing data layer is provided, it will take precedence over values in weather inputs.

4.9 Suppression resources

4.9.1 Purpose

To provide the data necessary to run the PHOENIX suppression simulation model. Suppression details only need to be specified when a simulation of suppression is desired.

4.9.2 Basis

The user is required to enter specific resources available during the course of the fire. Resource availability is characterised by the resource type, quantity, the time available at the fire perimeter, and in the case of aircraft, their turnaround time between drops.

4.9.3 Assumptions and limitations

Construction rate limiting factors have been identified for each of the suppression methods (McCarthy et al. 2003) including fire intensity, terrain, fuel density and turnaround time. In contrast to limiting factors, some elements, such as road proximity, augment construction rates.

4.9.4 User interactions

The user provides the suppression agent types, quantities, start time and turnaround times (if applicable). The user also provides data on the effect of limiting or augmenting factors on construction rates.

Suppression types and productivity rates can also be added or altered in the 'Suppression.xml', but this is an advanced user function and should not be undertaken without careful consideration and knowledge.

4.9.5 Description

Suppression operations are defined by the activities of individual suppression agents (Hu and Sun 2007). The model allows for construction rates to be defined for specific suppression methods. Suppression methods currently supported are:

Hand Trail / Slip-ons (light tanker- 400 litre);
D4 Dozer;
D6+ Dozer;
Tanker (4000 litre);
Fixed Wing Bombers (Single Engine Air Tanker - 2500 litres);
Medium Helicopter (1400 litres);
Large helicopter (Erickson Air Crane) (5600 litres);
Road Grader; and
Mallee Roller/Clearing Chain.

Other types of suppression methods can be included if the user adds them to the suppression definition file 'Suppression.xml'. This is an advanced user task.

For a discussion on how suppression resource inputs are used in simulations see Section 6.4: Suppression Model.

4.9.5.1 Construction rate limiting factors

Construction rate limiting factors have been identified for each of the suppression methods (McCarthy et al. 2003) including fire intensity, terrain, fuel density and in the case of aircraft, turnaround time. The effect of each factor on the suppression method's construction rate is expressed as a series of tabular data points. A sufficient number of points are required to accurately capture the relationship. A simple linear interpolation is then performed to calculate the exact construction rate given a limiting factor value.

This data point-based method for expressing relationships has been chosen over inbuilt functions because of its transparency and ease of modification.

Figure 12. The effect of slope and intensity on fireline construction and holding rates of large tankers (4,000 litres).

The effect of each limiting factor is multiplicative. To calculate the resultant construction rate, the proportion of the maximum construction rate is calculated for each limiting factor then multiplied together. The resulting proportion is then multiplied by the maximum construction rate to calculate the resultant rate.

For example, a suppression type with a maximum construction rate of 2000 m/h with two limiting factors that result in a proportion of the maximum of 0.7 and 0.6 respectively, results in an 840 m/h construction rate.

Resultant Rate = 0.7 x 0.6 x 2000 = 840 m/h

4.9.5.2 Construction rate augmentation based on road proximity

In contrast to limiting factors, road proximity augments construction rates. The distance from the Fire Grid cell centroid to the closest road is calculated and stored against each cell in the Fire Grid (see Section 4.6: Road Proximity).

PHOENIX incorporates an inbuilt basic road proximity modifier for land-based suppression methods that increases the previously calculated suppression rate based on the proximity of the fire to a road. The effect of road proximity is expressed as an increase in the maximum construction rate. The relationship between road proximity and construction rate increase varies between suppression methods.

Figure 13. Increase in construction rate by large tankers (4000 litres) based on road proximity.

To calculate the modified construction rate, the percentage increase is calculated for the suppression type then applied to the previously calculated value.

For example, based on the graph in Figure 13, a road proximity of 200 m would result in a construction rate increase of 1714 m/h. Given an unrestricted maximum construction rate of 2000 m/h this would result in a 185.7% increase in the previously calculated construction rate.

Percentage Increase = (2000 + 1714) / 2000 = 185.7%

Given a limiting factor affected construction rate of 840 m/h the road proximity effect would augment the construction rate by 185.7% to 1559 m/h.

New Rate = 840 * 1.857

TRG Chapter 4: Inputs

Table of contents