This document details the enhancements requested and required for TCRM. It serves as a guide to the development team as to what elements need to be modified, created or upgraded to ensure Geoscience Australia delivers a quality product. Some of the enhancements are already underway, while others will require significant scientific and software development and may be several years from implementation. Each section gives a summary description of the issue, the requirements to be satisfied, any constraints that may need to be considered, and the current status of the enhancement. Sections may be added or removed over time as new enhancements are requested by users and others are implemented.

Currently TCRM generates an annual event set for a user-selected number of years. For each annual event set, the tracks and wind fields are stored in a single file (include example wind field image indicating existence of multiple events in a single file). Often, users will be interested in the idea of “what does a 1-in-100-year event look like for my location?” To enable users to interrogate individual events in this manner, each event needs to be stored as a separate entity. This capability will also allow users to analyse event losses and return period losses in sub-national regions (upon integration with the HazImp tool).

• Statistical module to calculate date (day-of-year) genesis statistics;
• Incorporate date information in track generation;
• Track generation model to sample environmental pressure from 3-dimensional long-term mean climatology (day-of-year, lon, lat);
• Each event to have unique identifier (e.g. serial number) that is recorded in the track file and wind field file;
• Hazard module to ingest individual wind field files (i.e. not annual maxima as at present);

To enable rapid selection of events, an event catalogue should be generated, which records key attributes of each event (including, but not limited to: genesis longitude/latitude, genesis date, event identifier, maximum intensity [wind speed and central pressure], total lifetime of event).

• Output wind fields files to be in netCDF format, CF-compliant (version 1.6).

In development in v2.0 branch.

Permit novice users to interact with the model through a graphical interface. Advanced users would use a command line interface (especially for parallel execution). An early prototype has been started (layout, limited functionality), but requires substantial work to become suitable for widespread use.

• Merging and upgrading of existing two configuration user interfaces to single interface;
• User selects advanced/basic configuration interface at run time;
• User Interface can optionally remain open during simulation execution;
• If user chooses to keep interface open during execution, two progress bars shown – one for overall progress and one for the executing module;
• Explore possibility of using map interface to define domains (e.g. see WRF Domain Wizard http://esrl.noaa.gov/gsd/wrfportal/DomainWizard.html). This remains a low-priority requirement;

The existing landfall decay model is based on US data, where topography is not a significant factor. In Australia, there are significantly different landscapes in the major landfalling areas – flat deserts, savannah lowlands and rainforest-covered mountain ranges. Because of these varying conditions, TCs weaken at different rates across the country. An updated landfall decay model will improve the performance of the model in simulating decaying TCs following landfall, where TC risks are realised. Because of the introduced reliance on datasets such as a DEM or land cover, it may be necessary to package low resolution but global datasets that can be used by TCRM.

• Landfall decay model is based on statistical relationship to land characteristics (e.g. elevation, slope, land cover);
• Model provides statistically verifiable improvements over existing model;
• Model tested in basin other than Australia;

• In absence of required data, TCRM defaults to existing landfall model;

• February 2014: Initial review of existing models started
• August 2014: Analysis of observations inconclusive on generic parameters for entire domain (spatially varying parameters for the model). Basic form of the model is acceptable, parameters modified to balance across Australian region.

Existing version of TCRM has been compiled into a single binary installer package to simplify installation of the model on Windows platforms. This was done to make installation easier for novice users (i.e. no need to install Python and associated packages.

• Upgrade of the Windows installer package for new code release;
• Must be tested on XP & Windows 7 platforms;

• February 2014: Under testing
• August 2014: Postponed due to lack of resources – installation instructions and requirements.txt file added to repository (for use with ‘pip’ to assist with installing dependencies).

The Hazard and Risk Infrastructure and Advice Section, Community Safety and Earth Monitoring Division, is developing a software tool to enable users to analyse the impacts of natural hazards, called HazImp. To enable TCRM to evaluate impacts in a seamless manner, the interface between the two systems needs to be designed and built.

• TCRM can import HazImp at run-time, as per user configuration;
• TCRM passes appropriately formatted information to HazImp;
• TCRM can receive appropriately formatted information back from HazImp;
• TCRM can store the information generated by HazImp, keyed by the event serial number to allow post-processing and analysis;

One of the most complex aspects of modelling TC behaviour is when they enter the mid-latitudes and begin transitioning from a (approximately) symmetrical tropical system to a baroclinic, asymmetrical subtropical weather system. This is a major consideration, as the west coast of Australia is often impacted by these transitioning storms, and maintaining stochastic storms as purely tropical will lead to over-estimation of hazard in these regions.

When a simulation is executed, the model should generate a database of events, tracks & hazard to map the event details to stations within the model domain. Easiest would be to use a sqlite database, as this is part of the standard library and can be created on the fly (see https://docs/python.org/2/library/sqlite3.html). This would allow easier generation of figures, and also allow for identifying an event that meets specified return period thresholds. The tables to be included are:

• tblStations: holds details of the stations within the model domain. This could feasibly be shipped with the code, rather than generated at simulation time. Fields: stnId, stnName, stnLon, stnLat, stnElevation, stnCountry, stnWMO
• tblEvents: holds details of the events generated. Fields: eventId, eventFile, eventTrackFile, eventMaxWind, eventMinPressure
• tblStationEvents: Holds details of the station-specific event outcomes. Fields: stnId, eventId, stnMaxWind, stnEastWind, stnNorthWind, stnMinPressure
• tblHazard: holds details of the hazard data at stations. Fields: stnId, returnPeriod, stnHazard, stnHazardUpper, stnHazardLower, stnLocation, stnScale, stnShape
• tblTracks: holds details of the relationship between stations and tracks (mainly details at closest point of approach). Fields: stnId, eventId, eventTrackFile, distClosest, prsClosest, dtClosest .

These structures are indicative only. This is being developed in the v2.0 branch.

Currently TCRM assumes the Earth’s surface is flat and featureless. However, landscape strongly influences wind speed – buildings, trees, water bodies and topography greatly reduce or enhance local wind speeds. To accurately represent the winds impacting buildings and infrastructure elements, these local effects must be incorporated. The current approach is to include these effects in an offline process, where the local effects are pre-calculated and stored as site-exposure multipliers.

• Site-exposure multiplier datasets available for ingestion: http://dapds00.nci.org.au/thredds/catalog/fj6/multipliers/catalog.html;
• Where data is not available, TCRM defaults to constant value;
• Multipliers are selected based on direction of wind at each grid point;
• Resolution of wind fields will be at resolution of multipliers;
• Wind field calculations will need to be transformed to projected coordinate system, or multipliers projected to a geographic coordinate system;