Overview

Input

When running a simulation Phoenix obtains input data from 3 sources.

1. Data entered into the application directly, and saved in the project file,
2. Files in the Gridded_Weather directory, and
3. Files in the Data directory.

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", 30 x 30 cells wide. This tiling can be easily done in ArcGIS using a specially developed "Toolbox". The base input data is usually at 20 or 30m resolution, but when it is read into PHOENIX it is averaged into larger cells to speed computations. Typically the grid cell size for PHOENIX computation is 100 or 200m, but could range from 50 to 500m depending on the nature of the terrain and the level of detail required.

Output

In addition to the source data for running the PHOENIX model, it is also necessary to have a visual reference layer such as a satellite image or topographic map on which to set up the simulation area and to overlay the results of the simulation.  More on this below.

This document describes the data files that are obtained from the Gridded_Weather and Data directories. 

The actual location of these directories is specified in the project file, and usually defaults to subdirectories of C:\Phoenix

Sub directories :-

The Data Directory

The Data directory normally contains input layers that have been created by hand.

General Requirements

1. 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, we suggest using "VicGrid 94" which is a Lambert Conformal Conic Projection with a GDA 94 reference Datum.
   Across Australia, we suggest "Geoscience Australia Lambert 94" projection which is a Lambert Conformal Conic Projection with a GDA 94 reference Datum.
   
   
2. The only data layer that MUST be provided is the Fuel Layer.
   However, other layers make the simulation much more realistic. If there is no data file location specified, then the input value will be zero.
   
   
3. As all data layers must be in the same coordinate system only one projection file is required.  The default name of this file is data.prj and is best located in the root of the Data directory.
   The format of the projection file conforms to the requirements of ESRI ArcGIS 9.
   
   
4. Layers can be provided as zip files, to decrease the size of data that has to be copied around.

Possible Input Layers

The actual layers that Phoenix will use in a simulation are configured in the Project window, on the Data tab. The list below is the complete set of possible layers:

Mandatory

• Fuel Layer - developed from a vegetation layer

Optional

• Digital Elevation Model (DEM) - from which to calculate slope, aspect and elevation
• Fire History Layer, with an optional Supplementary Fire History Layer - from which to calculate the current level of fuels across the landscape
• Road Proximity Layer - from which to determine the level of assistance given to suppression
• Disruption Layer - from which to determine the effect of linear features such as roads, rivers, railway lines and fire breaks, on fire behaviour and spread
• Assets Layer - assists in assessing asset impact during the fire simulation.  Assets include Housing, Infrastructure, Plantation and Rainforest
• Wind Modifiers Layer - assists in making changes to local wind speed and direction
• Curing Layer
• Drought Factor Layer

Example :-

Other files in the Data directory

TBD - pull more out of both PHOENIX_data_preparation_20080413.pdf and Phoenix User Manual

Gridded Weather

The Gridded_Weather directory is expected to contain gridded forecast weather data in the form of NetCDF files normally obtained from the Bureau of Meteorology.  This data is produced twice a day by the BOM. A downloading process has to be put in place to get this data, but it is restricted to registered users. PHOENIX will also run on a single stream of weather data 

TBD - Info about the weather downloader required.

The Tools dropdown menu provides the options to

• Download Gridded Weather - get the latest gridded weather from the Bureau of Meteorology ftp server (only available to registered users)
• Shut Down Phoenix Workers - a facility to run separate simulations, in a parallel process, on a cluster of computers or on different processors for multi-core processors such as Quad-cores. This is a function set up for large simulations.
• Unpack Phoenix Datafile - unpack the zipped input data tiles to compile a single ASCII file
• Edit Fuel Types
• Edit Suppression Rates
• Push data to nodes - such as write the simulation inputs and outputs to the ignition points

TBD - populate this section with a description of how to use the weather downloader

Refer to the manual for how to use weather entered directly into the UI/project file

Other directories

Application

This is where you'll find Phoenix.exe which you can use to run the application.

Outputs

This will ultimately contain the range of files produced from the simulations.

Projects

This will store the .xml files containing the settings for each simulation created.

PHOENIX – Data Preparation

Datum and Coordinate System

All data needs to be prepared in a consistent projection that has a scale in metres. You cannot use a geographic coordinate system using measurement in degrees. For consistency across Australia, we recommend using the GDA_1994_Geoscience_Australia_Lambert projection.

GIS Software Requirements

GIS software is an ongoing problem. We have decided to write PHOENIX to use ESRI ArcGIS 9.2, sp4. You need a licence to operate ArcGIS 9.2 ArcView (or similar Arc product such as ArcEditor, ArcInfo). It is our intention to keep the PHOENIX software compatible with the most recent version of ESRI ArcGIS. 

Source Data Preparation

1. Fuel (Vegetation)

The Fuel layer is used in conjunction with the fire history layer to create the fuel attributes used in PHOENIX. It has been assumed that the vegetation layer is the layer most likely to be kept up-to-date and more readily available than a purpose built fuel type layer. However, it is also acknowledged that there are several vegetation type classifications and a range of mapping detail and quality within some states and between states. Therefore, the approach taken in PHOENIX has been to convert various vegetation classifications into a standard set of fuel types, e.g. there are about 700 vegetation types mapped in Victoria and these are classified into about 40 different fuel types.

The user needs to assign a fuel type to every vegetation type in the area of interest. To enable this, a code for each vegetation type is needed, e.g. 97 – Semi-arid Woodland. This code is used in a lookup table and joined to a fuel-type code. This fuel type code must then be added to the attribute table for the vegetation map in a GIS. The setting up of the conversion process is beyond the scope of these notes, but
it can be done by “Joining” the lookup table to the vegetation attribute table in the GIS.

An example of a list of vegetation codes and their matching fuel type code.  Several vegetation types may be in the same fuel type.

The fuel mapping must cover the whole area. Areas with no fuel type mapped will be assumed to carry no fuel and therefore will not carry fire (e.g. a water body).

The fuel type layer (and all other input data layers for PHOENIX) needs to be converted to an ASCII grid (.asc) format. The cell size units must be in metres (m), and the cell size must be in whole numbers. A cell size of 30 m is recommended for vegetation. The ASCII file must be called: “fuel.asc”.

Once the “fuel.asc” file has been prepared, it is processed in PHOENIX to compress the data, divided into tiles, and stored in a folder called: “fuel”. This process will be explained in more detail.

Fuel data preparation process - Manual Method

It is necessary for the user to prepare a comprehensive vegetation data layer for the area to be used. Each vegetation type must be identified with a unique code. Below
shows an example of an attribute table associated with a vegetation layer (shapefile).  “VEG_ID” is the unique code that will be used to assign each vegetation type to a fuel
type. Once the vegetation layer has been attributed with the fuel type codes, it can be used to create the ASCII grid layer. The name given to this fuel type field is not critical. Producing an ASCII grid is a two step process with the intermediate process being the production of a raster layer with the ESRI grid format.

Step 1 - create a unique integer code for each fuel type (ArcMap)

Two tools are available to convert the shapefile to an ESRI GRID (raster), “Feature to Grid” (below) and “Polygon to Grid”. Specify the output file as “vegetation (no extension)” and the output cell size as 30m.

Step 2. Convert the shapefile to an ESRI GRID file. (ARCMap)

Once the ESRI GRID (raster) file has been created, it must be converted to an ASCII grid format. To do this, use the Conversion Tool – From Raster to ASCII tool. The output ASCII file must be called “fuel.asc”.

Step 3. Convert the ESRI GRID file to an ASCII grid file. (ARCMap)

This ASCII grid file must now be compressed and broken into tiles using a facility in PHOENIX. The fuel, or any other layer, can be converted on its own, or all together, the choice will be yours.
Start by opening PHOENIX. Then select the “Phoenix GIS Data Converter” from the “Data” dropdown menu.

Navigate your way to the folder containing the vegetation ASCII grid file and select it. “Start” the compression and tiling process. The data files will be output to a folder within the one you selected with the ASCII grid file. This folder will be called “fuel” and if it does not already exist, it will be created.

Step 4. Convert the ASCII grid file into a compressed set of ASCII tile files.

The “Date Converter” tool in PHOENIX converts the ASCII grid data into the format needed to run PHOENIX simulations. Note: in this case only the fuel data is being processed, but other layers could be processed at the same time if desired.

This fuel data will be used in conjunction with the fire history layer to convert them into a current fuel levels when a fire grid is created in PHOENIX. The process of doing this will be explained later.

The fuel layer is now ready for use.

Fuel data preparation process - ArcGIS Toolbox Method

The data preparation process can be simplified by using a set of customised tools developed to be used in ArcGIS 9.2 to produce the data files required as input to PHOENIX.

In order to use these tools, first they must be installed on your GIS program.

Installation

Pre-Check

The toolbox and scripts are stored in a folder in the PHOENIX root directory called Scripts. This will typically be C:\Phoenix\Scripts

It is important to check that these files are in the Scripts folder:

• DEM.py
• Disruption.py
  
• Fire_History.py
  
• Phoenix Data Optimiser.exe
  
• Phoenix.Grid.dll
  
• PhoenixTools.tbx
  
• Road_Proximity.py
  
• Fuel.py
  

The five files denoted with the .py extension are the Python scripts. These are written in Python 2.4 and should work with a standard ArcGIS 9.2 installation.

The .exe and .dll are the files required to perform data conversion from a shapefile or grid format to PHOENIX format. This will be run in the tool, but it is a standalone program that can be run separately on other ASCII files.

The .tbx file is the ArcGIS Toolbox that the user adds to the built-in toolboxes.

Adding the Toolbox to ArcGIS

In this section the user will add the toolbox to the ArcGIS tool list.

Step 1. Open ArcGIS to either the default environment or a previous project.
Step 2. Open the toolbox panel by clicking icon 1

Step 3. Right-click inside the panel so that the context menu opens up and select “Add Toolbox…” as shown below.

Step 4. Navigate to the Phoenix\Scripts directory and select PhoenixTools.

Do not double click as this opens the toolbox as a folder, but doesn’t add it. Once selected, click Open.

Step 5. Once added, click the + next to Phoenix Tools and then the Data Preparation tab and this should expand to reveal the five scripts.

2. Fire History

There are two main options for preparing the fire history data layer. The first is to produce a data layer showing the “Last Burnt” fire history where the most recent fire is shown where a previous fire history is replaced by a more recent fire (see below). The second option is where the extent of all known fires is kept, including overlapping fire areas and an effective Last Burnt fire history can be produced for a specified time in the past. This second option has much greater flexibility and is therefore preferred.

The fire history is used in PHOENIX during the fuel layer creation process. Based on the time specified in the simulation, fuel levels will be determined by the combination of fuel type and the time since the last fire.

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. There is only one layer of fire history.

At present, there is no distinction made between fires of different intensities on fuel accumulation rates. Users should be aware that intense fires that have resulted in structural changes to the vegetation may result in fuel accumulation rates different to those used in PHOENIX.

Fire History Data Preparation Process - Manual Method

As with the vegetation layer, the aim of this process is to produce an ASCII grid layer containing the fire history information to be used in the simulation. It is recommended that a grid cell resolution of 30m be used. The fire history attribute to be used in the ASCII grid layer is the fire start date MUST be expressed as an integer in the format “YYYYMMDD” (e.g. 19850421).  If the actual date is not known then
assume the date to be the 1st January for the season of the fire (e.g. 19850101).

a. Assuming You Have a Current “Last Burn” Layer

Using the GIS, make sure you have a field in the attribute table that contains a fire start date (Burn_Date) expressed as an integer in the format “YYYYMMDD”.

There are a number of ways of creating the Burn_Date. However, first of all, you must create the field in ArcCatalogue. Do this by opening the fire history shapefile and go to the “Fields” tab on the Feature Class Properties and add “Burn_Date” as a long-integer data type. This field MUST be called “Burn_Date”.

Having added the new field “Burn_Date”, you can now either write a Python script to create the data for this field from within ArcGIS, you can use the ArcGIS Field Calculator or you can open the attribute table in MS-Access and fill the fields there. It is always safer to create new fields from within the GIS environment rather than make them in Access, to make sure all the links are maintained.

In MS-Access, you can use the Update Query process to convert an existing date (or some other combination) into an integer Burn_Date. One example is shown below.

Within ArcGIS you can also create an integer Burn_Date using the Field Calculator, by opening the attribute table, selecting the Burn_Date field and right click to select the Field Calculator window. How you use this calculator will depend on the existing date information in the attribute table already. In the example below, it is just a matter of reformatting an existing date using the “Format( )” function. An alternative approach to achieve the same end is to use the “Data Management Tools”, toolbox and select the “Fields”, “Calculate Fields” option.

1. Create a Field in the fire history layer called Burn_Date with an integer date code. (ArcMap)
   The following steps are similar to those used in creating the vegetation data.
   
2. Convert the fire history layer into an ESRI GRID layer using the Burn_Date as the attribute for gridding. (ArcMap)
   
3. Convert the ESRI GRID file to an ASCII grid file. (ArcMap)
   
4. Convert the ASCII grid file into a compressed set of ASCII tile files.

b. Assuming You Have a Composite (overlapping) Fire History Layer

The first step is to create a Burn_Date field in the fire history layer as described above.

Step 1. Create a Field in the fire history layer called Burn_Date with an integer

In the case of a composite fire history layer, the full extent of all recorded fires is stored in the layer file indicating areas burnt more than once in the recorded history.

Step 2. Convert the fire history layer into an ESRI GRID layer

It is necessary this time to use the “Polygon to Raster” Tool. This tool has an option of specifying a “Priority” field. This can be used to specify the “Burn_Date” field so that the most recent (largest) date is used to create the raster layer and all underlying layers (fires) are ignored. In this way, only the most recent fires are recorded for each raster cell. 

The remaining two steps are the same as for previous instructions.

Step 3. Convert the ESRI GRID file to an ASCII grid file. (ArcMap)

Step 4. Convert the ASCII grid file into a compressed set of ASCII tile files. (PHOENIX)

The advantage of keeping this overlapping fire history data is that you can create
historic fire history layers for recreation of fire scenarios in the past. Where fires have
overlapped, the most recent fire has not removed the older fire information.

3. Road Proximity Layer

Road Proximity Data Preparation Process - Manual Method

The road proximity layer is used to determine if there is a road within 2000m of a specified point in the landscape, and if it is, how far away it is to the nearest 50m.  This information is used in PHOENIX to assess, how much, if any, roads will assist in providing access to fire suppression resources.

In order to develop this layer, first you must have a road layer. This will be a “Polyline” feature layer. Next you will use the Euclidean Distance tool in the Spatial Analyst toolbox to create the Road Proximity layer. The suggested output cell size is 50m and the suggested maximum distance is 1000m. The output file name has to be “Road_Prox”. This is a raster data set.

Step 1 (and 2). Create a road proximity layer called “Road_Prox”. (ArcMap)

The following steps are similar to those used in creating the vegetation and fire history datasets. Because the Road_Prox layer is already in ESRI GRID format, Step 2 has already been completed

Step 3. Convert the ESRI GRID file to an ASCII grid file. (ArcMap)

Step 4. Convert the ASCII grid file into a compressed set of ASCII tile files. (PHOENIX)

Road Proximity Data Preparation Process - GIS toolbox method

4. Fuel Disruptions Layer

The Fuel Disruption Layer defines the location and width of linear features such as roads, streams, firebreaks, and railway lines which are generally devoid of fuel and may act as barriers to the progress of a fire. 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 have a field in it called: “WIDTH” which described
the effective width of the fuel-free area along the length of the linear feature (polyline).

The width of the disruption will be used in PHOENIX to determine the extent of the disruptions on the local fire intensity and will determine if the local fire intensity is sufficient to breach the disruption.

Fuel Disruption Data Preparation Process - Manual Method

It is most likely that different disruptive types such as roads, railways and streams will have been mapped in different layers, therefore each layer will need to be prepared and then a combined disruptive layer with a common field “WIDTH” will need to be compiled by appending the files to a master disruptive layer file.

The following instructions assume that the disruptions will be compiled into a raster file, with 30m cells.

Step 1. Create a field in the first disruptive layer called “WIDTH”. (ArcCatalog)

Step 2. Populate the “WIDTH” field. 

Use an effective width (m) for each feature using either a lookup table joined to the attribute table of the layer or use the Field Calculator to create a width based on one or other of the attributes in the table.
(ArcMap). (Note: step 1 can be omitted if the name of the width field in the join layer is already “WIDTH”.) Join the widths of features to the GIS layer based on a classification of the features such as the AS2482 code.

Step 3. Create a single disruption layer

Merge all the disruptive layers into a single layer called “Disruption” using the Merge tool in ArcMap. All files must contain a common field called “WIDTH”.

Step 4. Create a new layer that has a buffer around each polyline.

The width of this buffer should equal the size of the raster grid to be used. Use 15m as a default for a 30m raster grid. (ArcMap)

Step 5. Convert the buffered disruptive layer into an ESRI grid. (ArcMap)

The above show converting the buffered fuel disruptions into an ESRI grid format using the Feature to Raster conversion tool. (see below for an alternative method).

Converting the buffered fuel disruptions into an ESRI grid format using the Polygon to Raster conversion tool. Note that this tool has more options than the feature to raster tool, i.e. the method of picking up polygon attributes (Cell_Centre) and the ability to discriminate which one of a number of overlapping features you will include in the final grid file (Priority Field).

Step 6. Convert the ESRI grid into an ASCII grid. (ArcMap)

Convert the ESRI grid into an ASCII grid using the Raster to ASCII conversion tool. The output file must be called “disruption.asc”.

Step 7. Convert the ASCII grid file into a compressed set of ASCII tile files. (PHOENIX)

5. Digital Elevation Model Layer

Digital Elevation Model Data Preparation Process - GIS toolbox method