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

7. Asset Impact

7.1 Purpose

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.

7.2 Inputs

• Asset layer;
• Fuel type;
• Fire history;
• Spotting/embers;
• Terrain (DEM); and
• Weather.

7.3 Basis

Damage to assets is determined with the use of loss functions where outputs from the fire behaviour model (e.g. ember density, flame height and maximum intensity) are used as predictors. Impact is based on the interaction of the fire characteristics and the vulnerability of the asset to fire, such as fire intensity or ember density.

7.4 Assumptions and limitations

Impacts can be calculated for up to 99 asset types and evaluated against up to 99 loss functions.

7.5 User interactions

None, other than preparing the asset and values layer (see Section 4.5: Assets and Values).

7.6 Description

Characterising fires by asset impact can be useful for prioritising fires in a tactical scenario or strategically for quantifying the effectiveness of a specific treatment. Asset impact can be a more meaningful measure than traditional characteristics like fire area, average intensity, perimeter length, etc.
Against each cell of the input asset layer (e.g. 30 m grid) the user assigns an asset type, asset priority, an impact type and asset value in metres squared. This is described below.

7.6.1 Asset type

One asset type is assigned per cell. The user can define up to 99 asset types and each is assigned an Asset ID. An example is provided in Table 7. Where more than one asset type occurs in an input data cell, a priority for asset types has to be defined so that the asset with the highest priority is stored in the input data raster file.

Only one asset ID can be stored per input data cell (e.g. 25 m or 30 m), but several asset IDs may be combined into a PHOENIX Fire Grid cell (e.g. 180 x 180 m).

Table 7. PHOENIX Asset ID (from Tolhurst et al. 2017)

7.6.2 Impact type and loss functions

Asset impacts are computed post-fire by applying the asset-specific impact functions. Asset impacts are recognised as the probability of loss weighted by asset density. Asset impacts can be tallied or used to produce impact maps (Tolhurst et al. 2013).

For each asset type, an impact type must be assigned. Some indicative functions have been developed to indicate impacts on the following asset types: housing, infrastructure, plantations, catchments and rainforest (see Table 7). Currently, only five impact types have been defined (Table 8) and can only be edited through the modification of the base PHOENIX code. Users can define additional impact types and functions (up to 99 impact types). It is expected that these will be derived through empirical relationships. The impact type can be defined as a mathematical function (loss function), as with house loss. Alternatively, it can be defined as some fire characteristic threshold criteria such as an asset being exposed to a fire greater than a specified level of intensity (Table 8).

Table 8. PHOENIX asset impact type

1 - EXP(0.2894 - 0.000487 * FlameXS - 0.02003 * EmberDensity - 0.0000157 * Convection) / (1 + EXP(0.2894 - 0.000487 * FlameXS - 0.02003 * EmberDensity - 0.0000157 * Convection))

Where FlameXS is defined as FlameHeight * FlameDepth / 2

7.6.3 Asset value

The user prepares the data layer through geospatial analysis of source layers to derive density values for each cell.

Assets values are expressed as units per square metre; point assets such as houses must be converted by the user to their equivalent density in metres squared. Area-based assets such as catchments are given an asset value of 1, indicating a 1 to 1 relationship with burnt area i.e. 1 unit/m2.

Asset values are limited to a maximum of 4 digits and 4 decimal places giving an effective range of .0001 to 9999. Care needs to be taken to ensure suitable units are selected for assets to accommodate this limited range.

7.6.4 Asset code description

Because each of the input data layers into PHOENIX are in ASCII format, only one value is possible from the input layer resolution cell (e.g. 30 x 30 m). To enable multiple pieces of information to be stored in a single integer value, a coding system is used (Figure 36). In Table 9, the integer value of 230312340 can be decoded as Asset ID 23, Impact Type 3, Asset Value of 1,234. The PHOENIX Integer Scientific Notation helps to interpret the 'asset value'. For example, when the scientific notation has a value of zero (0) as in this case, then the value is taken as is, i.e. 1,234, whereas for Asset ID 11 the Asset Value is 0.001234 because the scientific notation has a value of minus three (-3) which means x 10^-3.

Figure 36. Asset code formulation.

Table 9. Worked examples of the PHOENIX asset code