Development of a Bushfire Evacuation Support Tool Using Workspace

1 downloads 279 Views 872KB Size Report
... of the highest-risk towns (such as Anglesea, Lorne, Aireys Inlet and Wye River) in ... support bushfire evacuations
Development of a bushfire evacuation support tool using Workspace Leorey Marquez 1*, Vincent Lemiale 1, Rajesh Subramanian 1, Joel Robertson 2, Tim Gazzard3 and Peter Ashton 4 1

Natural Hazards Initiative, CSIRO Data61, Clayton, Victoria, Australia RMIT University, Melbourne, Victoria, Australia 3 Department of Environment, Land, Water and Planning, Colac, Victoria, Australia 4 SurfCoast Shire, Torquay, Victoria, Australia * Corresponding Author: [email protected] 2

Abstract: Bushfires are a serious and growing threat to Victorian communities. At present, more than 433,500 Victorians live in 146,750 dwellings in areas impacted by bushfires in the past 50 years. The bushfire risk is increasing due to growing populations in high-risk, rural-urban interface areas and a trend to hotter, drier summers with more extreme fire-weather days. The seriousness of the current situation has brought about the Great Ocean Road Decision Support System (DSS) Pilot project that will develop a software tool to support emergency management organisations assess evacuation and risk mitigation options in the Barwon-Otways region, one of the highest-risk areas in the country. The software tool integrates a bushfire hazard model, an evacuation traffic model and a behavioural response model using Workspace, CSIRO’s own workflow-based development framework. The Workspace GUI provides a catalogue of pre-built Workspace operations featuring basic and enhanced capabilities in flow control, visualisation, modularisation, database access, scripting and parallel execution in order to implement rapid application development. Preliminary results will be presented that indicate a reasonably robust and responsive tool capable of meeting most of the initial performance requirements. With additional workshops to exchange expertise between stakeholders and surveys to obtain new data, the model capabilities are being expanded to deal with new use-cases and behavioural issues. Keywords:

disaster and crisis management, decision support systems, simulation

Introduction Bushfires are a serious and growing threat to Victorian communities. At present, more than 433,500 Victorians live in 146,750 dwellings in areas impacted by bushfires in the past 50 years. The bushfire risk is increasing due to growing populations in high-risk, rural-urban interface areas and a trend to hotter, drier summers with more extreme fire-weather days. In response to this challenge, Data61, in partnership with Victorian state and local government agencies, is conducting a pilot study aimed at developing a software tool to assist emergency management organisations assess evacuation and risk mitigation options. This tool will enable users to explore how different mitigation strategies may impact community evacuations, how infrastructure and resource investments can be expected to improve evacuation, and how new developments or increases in population impact evacuation planning. This paper describes the design and development of a bushfire evacuation support tool using Workspace, Data61’s scientific workflow framework. Workspace provides enhanced capabilities in visualisation, modularisation, database access, scripting and parallel execution in order to seamlessly integrate workflows and processes from multiple disciplines into a single, rapid, graphical development platform. With Workspace, evacuation modellers can create reusable plug-ins, libraries, custom user interfaces and complete applications that can run on the Linux, Windows and Mac operating systems. This paper will also present and discuss preliminary results from the application of the tool prototype in a case study. Bushfire risk factors The SurfCoast Shire remains as one of the most visited areas of Australia featuring historic towns, popular festivals and events, and scenic attractions such as the Great Ocean Road. The Shire contains highly-populated centres along a coastline bounded by thick, natural forests and vegetation on one side, and the waters of the Bass Strait and Southern Ocean on the other, as shown in Figure 1. The demographics and geographic characteristics

of the Shire has made it one of the areas with the highest risk of bushfires in the country. To minimise risk for the SurfCoast Shire, Victorian emergency planning authorities note that: 1. Anglesea is one of Victoria’s most at-risk towns. According to the 2016 census (ABS, 2017), the town has a resident population of around 2600 people. However, visitor and transit numbers surge during the summer season, with peaks occurring around Christmas, New Year’s Eve and Easter. In February 1983, the Ash Wednesday fires ravaged the area destroying houses and infrastructure, and causing three deaths. Bushfires that reach Anglesea may extend some 70 km to the north and 40 km to the west. Victorian Department of Planning simulations show that an effective backburning and fuel management strategy is critical in reducing the number of properties impacted by bushfires (DELWP, 2015). 2. Lorne is a seaside town on the Great Ocean Road, nestled in the forested foothills of the Otway Ranges. According to the 2016 census (ABS 2017), Lorne has a resident population of around 1200. The town’s population surges during the summer months when it hosts a number of popular events. The annual fourday Falls Music Festival held around New Year’s Eve attracts over 14,000 ticket holders (Fowles, 2016) while the 1.2 km Pier to Pub Swim held in January attracts over 25,000 spectators (Hall, 2017). In 2015, the Falls Festival event was relocated to Mt. Duneed Estate following Christmas Day bushfires along the Great Ocean Road. The festival then returned to Lorne the following year. The main risk to Lorne comes from bushfires that sweep in from the north and double back along the coast from the southwest. To reduce the fire hazard, the fuel management strategy for Lorne includes planned burning and mulched fuel breaks at the interface of the bushland and the town (DELWP, 2015). 3. The Great Ocean Road (GOR) is a 243 km stretch of road along the south-eastern coast of Australia, connecting the Victorian cities of Torquay and Allansford on both ends. The road is essential infrastructure for the tourism industry, providing access to the most popular attractions of the SurfCoast and the Shipwreck Coast including the Twelve Apostles, Loch Ard Gorge, the Grotto, and the London Arch. Consequently, the road carries its heaviest traffic at the height of the bushfire season. Much of the road runs through forest, creating risks for people who travel through the area. The Great Ocean Road is also the only main road connecting several of the highest-risk towns (such as Anglesea, Lorne, Aireys Inlet and Wye River) in Victoria. Fuel management activities enhanced by comprehensive traffic management plans for the area reduce the risk of bushfires and other emergencies to road users (DELWP, 2015).

Figure 1. Map showing natural features of the SurfCoast Shire. (Source: Google Earth, 2018) The gravity of the bushfire risk has brought about the Great Ocean Road Decision Making Support System (DSS) Pilot project that will develop a software tool to support emergency management organisations assess evacuation and risk mitigation options. This partnership, managed by Emergency Management Victoria (EMV), includes

2

CSIRO’s Data61, DELWP, the Surfcoast Shire, the Department of Premier and Cabinet (DPC), Victoria Police, VicRoads, Country Fire Authority, and other emergency support agencies. The results of this capability will hopefully inform future policy and strategies on preparation and risk mitigation activities for emergencies in the entire state (Fairnie, 2017). DSS end users The scope of this pilot project includes the development and evaluation of a DSS prototype with the capability to support bushfire evacuations and risk mitigation in the Barwon Otway Risk Landscape. The objective of the project includes the completion of a case study evaluating the application of the technology in one or more representative bushfire evacuation scenarios. One of the outcomes of the project could be an understanding of key evacuation bottlenecks in the region. Additionally it is expected that this prototyping exercise will lead to EMV and other project stakeholders being able to stress test various extreme weather scenarios from an evacuation planning perspective. (Fairnie, 2017) Potential end users of the evacuation DSS include (Fairnie, 2017): 1. 2. 3. 4. 5.

Incident Emergency Management Team (IEMT) including the Incident Controller, Victoria Police representative, VicRoads representative etc. Fire Behaviour Analysts (FBAN) Risk Analysts Data Analysts Strategic Planners, including members of the Regional Emergency Management Executive and Planning Committee (REMPC)

Figure 2. End user interactions with the proposed DSS (Fairnie, 2017) Figure 2 illustrates the end user interactions with the proposed DSS. The users who are expected to manually interact with the DSS are the Fire Behaviour Analyst (FBAN), Risk Analyst and Data Analyst. The other groups will primarily be users of the DSS outputs (Fairnie, 2017). In addition to interacting with the DSS, the Fire Behaviour Analyst (FBAN), Risk Analyst and the Data Analyst will also perform model development and data preparation tasks for the DSS. In particular, the Data Analyst will be involved in organising and formatting the data that is then sent to the DSS as input. The FBAN/ Risk Analyst will also provide data from external models data which is then sent to the DSS as input. The FBAN/Risk Analyst can produce requirements that change rules and processes in the DSS after analysing the DSS Outputs.

Model components The initial design of the Evacuation DSS incorporated five primary components, as shown in Figure 3. The Hazards Model provides the estimation and forecasting capabilities associated with the hazards, natural or man-made, producing the emergency event. The Natural Hazards Initiative of Data61 has produced a number of validated hazard models for bushfires, floods, landslides, and storm surges as part of its Integrated Emergency Management Framework (Hilton et al., 2015). In the case of the Evacuation DSS, the bushfire hazard can be modelled using Data61’s own Spark model (Miller et al., 2015) or with Phoenix Rapidfire (Tolhurst et al., 2008) and Australis (Johnston et al., 2008), the last two were developed over the last ten years. The Hazards Model will provide estimates of the movement, extent and behaviour of the bushfires involved in the scenario, as well as associated elements such as smoke and ignition points, given a set of fuel, weather and topographic conditions. These estimates are then used to provide risk assessments for population centres, roads and evacuation areas.

Figure 3. Components of the evacuation decision support tool Using the risk assessments provided by the Hazards Model, one or more evacuation policies are activated to mobilise resources, assist the sick and elderly, and get the impacted population out of danger. The Traffic Model performs a simulation of the movement of people and vehicles along a changing transport network following the specifications of the selected evacuation policy. The simulation module is based on MATSim (Multi-Agent Transport SIMulation), which represents the street and road network as a queuing network. MATSim is an activity-based, extendable, multi-agent simulation framework implemented in Java. It is open-source and can be downloaded from the Internet (http://www.matsim.org). The framework is designed for large-scale scenarios, meaning that all models’ features are stripped down to efficiently handle the targeted functionality (Horni et al, 2016). The Traffic Model produces detailed logs identifying the location and activities of persons and vehicles at given times to produce counts and measures of time and distances for evacuation trips. The Behavioural Model is tasked with producing vehicle movement along the road network that approximates the behaviour of a population responding to the various evacuation information, conditions, constraints and directives. The estimates of the proportion of the population providing a given response and behaviour are incorporated in the Traffic Model as updates to the expected activities, schedules, route choice and destination choices during the simulation run. The Behavioural model used in the initial version of the Evacuation DSS simply adopts the regular MATSim agent behaviour where agents follow specified plans as directed, agents select routes according to the “shortest-path” algorithm chosen, and agents improve their decisions using knowledge gained from numerous iterations of the simulation. A more adaptive Behavioural Model is desired, for the next version, where agents can react independently to unplanned events (such as road closures or accidents), perform dynamic routing, and perhaps in some cases, exhibit some semblance of irrationality or impulsiveness. Several studies have identified a number of frameworks for behavioural modelling including those represented by multi-nominal logit models (Koot et al, 2012) and BDI (Belief-Desire-Intention) (Adam and Gaudou, 2017; Adam et al., 2015; Bulumulla et al., 2017; Singh et al., 2016). The BDI approach has been selected for application in the next version of the Evacuation DSS with guidance from behaviour experts and a questionnaire survey expected to provide crucial information in its design and implementation. The Analysis module performs the aggregations, calculations and queries on the scenario input and simulation output to produce tables, statistics and measures for evaluating the performance of the selected evacuation policy.

4

Similarly, the Visualisation module provides the graphs, charts, thematic maps, and animations that illustrate the significance of the computed statistics and measures. Workflows The Evacuation DSS is currently being implemented using Workspace, CSIRO’s own application development framework (Workspace, 2014). Workspace is a powerful workflow-based framework, with two user categories in mind. (Cleary et al, 2015):  

Users who want to create and share scientific workflows in one coherent, easy to use environment where much of the “heavy lifting” has already been developed and proven over a number of years. Developers who want to make their software available as standalone products, plugins or components that can be freely or commercially distributed or mixed with capabilities from collaborators.

Workspace is a cross-platform application development framework, built on the QT toolkit, that allows individual operations to be connected and managed in a workflow environment (CSIRO, 2017). Workflows represent a network of operations that carry out whatever set of tasks the user wants. Operations are connected together in a workflow to achieve an output. Tasks can be performed in sequence or in parallel. Each task can be of arbitrary complexity and is represented by an operation symbol, as shown in Figure 4. The symbol shows that each task can take a number of inputs from one or more previous tasks, and produce a number of outputs that may be used as inputs to a succeeding task.

Figure 4. Structure of a generic Workspace operation Workspace provides a graphical environment through which users can connect up various operations into a coherent workflow, execute it and interact with it while it is running (Cleary et al, 2015). The Workspace GUI, and an example workflow that runs the MATSim simulation, is shown in Figure 5. The operations and connections in a workflow are graphically constructed in the “Root” panel by dragging operations from the catalogue in the upper left panel. A broad range of pre-built operations are provided in the catalogue, particularly for visualisation, web services and data analysis, as well as fundamental building blocks such as file input-output, flow control (equivalent to if-then-else, loops, etc.), string handling, and database support. Researchers can easily develop new capabilities or expose existing libraries through C, C++, Python or JavaScript via inbuilt facilities - or “callout” to other software packages such as R. (Cleary et al, 2015). For example, to facilitate the embedding of MATSim in the Evacuation DSS, an “EvacuationModelling” plug-in library has been added to Workspace that includes operations to create the MATSim link network, create the traffic plan XML, and output MATSim results to a database. In addition, a “Geospatial” plug-in library has also been added to read shapefiles, display maps, and convert maps into images. Thus, the Workspace framework makes it convenient for users to mix and match existing and new capabilities within an easy to use drag and drop environment (Cleary et al, 2015). In Workspace, workflows run in “continuous mode”, where data can be visualised immediately while executing and operations are only re-run when out of date. Figure 5 shows the operations used to perform the “Run MATSim” workflow which completes two tasks for the Evacuation DSS – (1) collect the inputs to MATSim and run the MATSim simulation, and (2) extract the XML files from the archived MATSim output files. The operations in green on the left side of the Root panel denote parameters being passed to the workflow from external objects, the operations in blue denote processing activities, while the operations in red denote closure activities that trigger the re-running of dependencies downstream. The direction of the arrows denote the direction of dependencies between operations.

This set of 18 operations is “updated” each time a MATSim simulation is performed. First, the locations of the 7Zip utility, the Java executable, the MATSim JAR file, the simulation output directory and the MATSim configuration file are provided as input to the workflow. As the Unzip operation cannot overwrite existing XML files, the simulation output directory is cleared of previous XML files before the MATSim simulation is performed. At the same time, the Unzip executable is then setup to work with the output directory. The Unzip operations are only performed after the MATSim simulation that produce the output archive files has completed. The clean-up operation labelled “Close MATSim” ensures that the "Run MATSim" is executed before "Unzip Network XML" since the latter depends upon the former. The “Close workflow” operation terminates the workflow and updates any dependency on this workflow.

Figure 5. The workflow that runs the MATSim simulation and extracts the XML output from the archives. Note that Figure 5 shows a highlighted “Run MATSim” operation which also exposes the input and output “hooks” of the “Run MATSim” operation, the slots where the other operations connect with the highlighted operation. The operation editor panel, shown on the lower left side, allows the values and settings of the input and output slots to be entered and examined manually. Mark 1 An initial version of the Evacuation DSS (Mark 1) has been implemented with an initial set of features designed to meet the basic requirements for an evacuation simulation. The initial version includes the following features:     

A facility to load and save files, parameter and configuration settings in an XML formatted input file. A facility to create and edit MATSim configuration files A facility for viewing and analysing fire boundaries, spot times, and fire cells. A facility for viewing logged messages produced by Workspace. Facilities for creating the MATSim network XML and plan XML files from associated shapefiles or CSV files 6

  

A facility to run a MATSim simulation and store its output in a specified directory Facilities for analysing the MATSim output and storing these as well as any number analysis tables into a database. Facilities for visualising analysis data in terms of maps and charts.

The next version of the Evacuation DSS (Mark 2) is expected to add the following capabilities:    

A fully integrated behavioural module implementing a BDI extension to the MATSim framework, providing agents more “intelligence” with respect to route choice and evacuation behaviour. An interactive facility for creating evacuation plans using messaging and timing options for specified population subsectors. A reporting facility that creates customised reports automatically based on the components of the evacuation scenario and the results of the analyses. A reference facility that contains the user manual, a quickstart guide, frequently asked questions and other documentation.

Figure 6. Evacuation tab to view simulation in the Evacuation DSS Figure 6 displays a screen capture of the Evacuation DSS playing an animation of the evacuation simulation and fire spread. A thematic map containing the road network, fire movement and geography is used as backdrop for the simulation of evacuation using coloured circles to represent the movement of vehicles towards designated destinations. Circles coloured red indicate vehicles moving at very slow speed indicating serious link congestion whereas blue indicates vehicles travelling at higher speeds. The slider at the bottom of the window allows the animation to be played or reversed at any desired speed. Case Study A preliminary case study was conducted to investigate the impact of selected evacuation strategies on the performance of the evacuation plan, as well as to demonstrate the viability of the Evacuation DSS. The case study considered the evacuation of around 13,600 vehicles (residents and visitors) from the Anglesea area towards one

of four evacuation destinations in response to a simulated bushfire emergency. The case study aims to compare two destination selection strategies with two departure time selection strategies. The two destination selection strategies consist of: 1.

2.

Random available – the evacuation destination of the agents are selected randomly from the four choices, subject to the capacity constraints of the destination. If the selected destination is full, the process is repeated until a destination with available capacity is found. Closest available – the evacuation destination of the agents are selected as the closest from the four choices, subject to the capacity constraints of the destination. If the selected destination is full, the process is repeated until the next closest destination with available capacity is found.

The two departure time strategies consist of: 1. 2.

Identical departure – All agents are directed to leave at the same time (e.g. 1:00pm) Staggered departure –Agents are directed to leave at a time determined by their destination (e.g. 1:00pm for destination 1, 1:30pm for destination 2, 2:00pm for destination 3, etc…)

The combination of strategies produced the following four scenario and corresponding evacuation plans: 1. 2. 3. 4.

Scenario A – Agents are directed to travel from their origin to a randomly chosen (and available) target destination and to leave at the same time (e.g. 1:00pm). Scenario B – Agents are directed to travel from their origin to the closest available target destination and to leave at the same time (e.g. 1:00pm). Scenario C – Agents are directed to travel from their origin to a randomly chosen (and available) target destination and to leave at staggered times. Scenario D – Agents are directed to travel from their origin to the closest available target destination and to leave at staggered times.

MATSim is then configured to perform the traffic simulation where each evacuation plans is applied to the same road network. Statistics on the trip length and arrival rate by time for each scenario were obtained from the corresponding output event files and tabulated as shown in Table 1. Table 1. Comparison of four evacuation plans with respect to trip length and arrival rates by time Scenario / Plan destination policy

A random available

B closest available

C random available

D closest available

departure policy

identical

identical

staggered

staggered

No of vehicles evacuated Average Trip length (secs) Median Trip length (secs)

13616

13616

13616

13616

11170.2

10107.2

11548.3

8488.6

6600

6107.5

6745

5296

10873.2

10004.8

11166.4

8653.9

Max Trip length (secs)

39600

35798

39548

34134

Time at 25% arrivals (secs)

51300

49500

53100

52200

Time at 50% arrivals (secs)

62100

53100

63000

56700

Time at 75% arrivals (secs)

73800

63000

75600

69300

Time at 90% arrivals (secs)

83700

74700

84600

78300

StDev Trip length (secs)

The results show that trip lengths were shortest on average for agents in Scenario D with average lengths of 8488 secs or 2:20 hrs. The other three scenarios had trip length averages of 10107 secs (2:48) for Scenario B, 11170 secs (3:06) for Scenario A, and 11548 secs (3:12) for Scenario C. Scenario D had the lowest trip length statistics among the four scenarios followed by Scenario B. It appears that directing the agents to the nearest available target destination had a greater impact in decreasing trip times than using staggered departure times. 8

The bottom half of Table 1 shows the times at which 25%, 50%, 75% and 90% of the agents had arrived at their target destination for each scenario. Scenario B had the earliest arrival times for all levels, followed by Scenario D and then Scenarios A and C in a virtual tie. The complete charts of cumulative arrival rates by time for the four scenarios are shown in Figure 7. The charts again show that Scenario B produced the earliest arrival times, followed by Scenario D and then Scenarios A and C. To summarise, the agents from Scenario D exhibited the shortest aggregate trip times due to the selection of nearest available target destinations and staggered departure times. On the other hand, agents from Scenario B exhibited the earliest arrival times, inspite of having longer trip times than agents from Scenario D, because of near target destinations, as well as early departure times, sometimes 1.5 hours earlier than those of agents in Scenario D. Thus, the selection of near target destinations appears to provide a consistent positive impact on evacuation while the implementation of staggered departure times can have positive as well as negative impacts.

Comparison of Cumulative Arrival Rates by Time from Four Scenarios 100% 90% 80% 70% 60% A

50%

B 40%

C D

30% 20% 10%

11:30 PM

11:00 PM

10:30 PM

10:00 PM

9:30 PM

9:00 PM

8:30 PM

8:00 PM

7:30 PM

7:00 PM

6:30 PM

6:00 PM

5:30 PM

5:00 PM

4:30 PM

4:00 PM

3:30 PM

3:00 PM

2:30 PM

2:00 PM

1:30 PM

1:00 PM

0%

Figure 7.Comparison of the four scenarios with respect to cumulative arrival rates by time. Conclusion The collaborative nature of the Great Ocean Road Decision Making Support System (DSS) Pilot project makes Workspace an ideal application development platform for its implementation. The modular architecture of Workspace allows researchers from different organisations to develop, share and interchange components of the system and test new approaches to disaster modelling within a unified framework. Consequently, the DSS pilot project has adopted Workspace as the platform for the development of an agent-based simulation and modelling tool to support Victorian emergency personnel manage bushfire evacuation scenarios. The initial stage of development has produced a version (Mark 1) that exhibits the basic functionalities of an Evacuation DSS with modules that perform - (1) the modelling of natural hazard events such as storm surges, flash flooding and bushfires; (2) the embedding of third-party simulation software such as MATSim; and (3) the visualisation, analysis and mapping of the simulation results to answer the questions posed by stakeholders. Development work has commenced to produce the next version of the Evacuation DSS that will include a BDI implementation of the behavioural model as a MATSim extension, an interactive facility for creating evacuation plans, and an automatic facility for creating customised reports.

Results from the initial case studies indicate a reasonably robust and responsive DSS. With additional workshops and surveys planned to exchange expertise between stakeholders and obtain new data, the model capabilities are being expanded to deal with new use-cases and behavioural issues. References 1.

ABS (2017). "Anglesea (State Suburb)". 2016 Census QuickStats. Australian Bureau of Statistics (27 June 2017). Retrieved 16 November 2017.

2.

Adam, C., Beck, Dugdale, E., (2015) Modelling the Tactical Behaviour of the Australian Population in a Bushfire. ISCRAM-med2015: 53-64.

3.

Adam, C., Gaudou, B. (2017) Modelling Human Behaviours in Disasters from Interviews: Application to Melbourne Bushfires. J. Artificial Societies and Social Simulation, 20(3).

4.

Bulumulla, C, Padgham, L, Dhirendra, S and Chan, J 2017, 'The importance of modelling realistic human behaviour when planning evacuation schedules', in Proceedings of the16th Conference on Autonomous Agents and MultiAgent Systems (AAMAS 2017), Sao Paulo, Brazil, 8 - 12 May 2017, pp. 446-454.

5.

Cleary, P.W., Thomas, D., Bolger, M., Hetherton, L., Rucinski, C. and Watkins, D. (2015) Using Workspace to automate workflow processes for modelling and simulation in engineering, 21st International Congress on Modelling and Simulation, Gold Coast, Australia, 29 Nov to 4 Dec 2015. (www.mssanz.org.au/modsim2015, accessed November 2017).

6.

DELWP (2015) Strategic bushfire management plan Barwon Otway bushfire risk landscape: OVERVIEW, Victorian Government Department of Environment, Land, Water and Planning Melbourne, November 2015, (http://www.delwp.vic.gov.au/__data/assets/pdf_file/0007/318868/DELWP0018_SBMP_BO_A4_Summar y_WEB.pdf, accessed November 2017).

7.

Fairnie, C. (2017) Great Ocean Road Bushfire Evacuation Modelling: End User Business Requirements, Emergency Management Victoria, March 2018, pp. 5-7.

8.

Fowles, Shane (2016). “Falls Festival seeks approaval to increase capacity of Lorne event by an extra 1000 people”, Geelong Advertiser, October 6, 2016. (http://www.geelongadvertiser.com.au/entertainment/fallsfestival-seeks-approval-to-increase-capacity-of-lorne-event-by-an-extra-1000-people/newsstory/d8784cb6a2774258e1bf61d6078c0a24. Accessed December 2017).

9.

Hall, Bianca (2017) “Lorne Pier to Pub: 5000 take the plunge in worls’s boggest open water race”, The Age, January 7, 2017. (https://www.theage.com.au/national/victoria/lorne-pier-to-pub-5000-take-the-plunge-inworlds-biggest-open-water-race-20170107-gtni2u.html, Accessed December 2017).

10. Hilton, J., Miller, C., Bolger, M., Hetherton, L., and Prakash, M., (2015). An Integrated Workflow Architecture for Natural Hazards, Analytics and Decision Support, in: Environmental Software Systems. Infrastructures, Services and Applications, IFIP Advances in Information and Comm. Tech., 448, 333-342. 11. Horni, A, Nagel, K and Axhausen, KW(eds.) 2016 The Multi-Agent Transport Simulation MATSim. London: Ubiquity Press. DOI: http://dx.doi.org/10.5334/baw. 12. Johnston, P., Kelso, J., Milne, G.J. (2008): Efficient simulation of wildfire spread on an irregular grid. International Journal of Wildland Fire 17, 614–627. 13. Koot, J.M., M. Kowald and K.W. Axhausen (2012) Modelling behaviour during a large-scale evacuation: A latent class model to predict evacuation behaviour, paper presented at the 12th Swiss Transport Research Conference, Ascona, May 2012. 14. Miller, C., Hilton, J., Sullivan, A. and Prakash, M. (2015) “SPARK – A Bushfire Spread Prediction Tool, Environmental Software Systems”, Infrastructures, Services and Applications, IFIP Advances in Information and Communication Technology Volume 448, 2015, pp 262-271.

10

15. Singh, D, Padgham, L and Logan, B 2016, 'Integrating BDI Agents with Agent-Based Simulation Platforms', Autonomous Agents and Multi-Agent Systems, vol. 30, pp. 1050-1071. 16. Tolhurst, K., Shields, B., Chong, D. (2008) Phoenix: development and application of a bushfire risk management tool. The Australian Journal of Emergency Management 23, 47-54. 17. Workspace (2014), DOI: (http://dx.doi.org/10.4225/08/54D03170101B7, accessed November 2017).