SIFRA is a System for Infrastructure Facility Resilience Analysis. The detailed documentation is at this link.
It comprises a method and software tools that provide a framework for simulating the fragility of infrastructure facilities to natural hazards, based on assessment of the fragilities and configuration of components that comprise the facility. Currently the system is designed to work with earthquake hazards only. However, in the development of the methodology and classes, there is a strong emphasis on making the hazard attribution process and infrastructure models flexible to allow for expansion to other hazards and new infrastructure sectors.
SIFRA was developed in Geoscience Australia (GA) in support of the agency’s vision to contribute to enhancing the resilience of communities in Australia and its region.
Some key features of this tool:
Open Source: Written in Python, and there is no dependency on proprietary tools. It should run on OS X, Windows, and Linux platforms.
Flexible Infrastructure Model: The data model is based on graph theory. All infrastructure systems are represented as networks. This allows an user to develop arbitrarily complex custom facility models - for a Facility or a network – for impact simulation.
Extensible Component Library: User can define new instances of
component_type(the building blocks of a facility) and link it to existing or custom fragility algorithms.
Component Criticality: Scenario Analysis tools allow users to identify the cost of restoration for chosen scenarios, expected restoration times, and which component upgrades can most benefit the system.
Restoration Prognosis: Users can experiment with different levels of hazards and post-disaster resource allocation to gauge restoration times for facility operations.
It is good practice to set up a virtual environment for working with developing code. This gives us the tools to manage the package dependencies and requirements in a transparent manner, and impact of dependency changes on software behaviour.
The system is currently being designed as microservices implemented in docker containers. If you have docker installed on your system it is probably easiest to use the containers as described below.
Building the run environment using Docker
Docker configuration is now the preferred way to deploy and develop the application.
To run tests use unittest. Move into sifra folder:
$ cd sifra $ python -m unittest discover tests
If you are using docker as described above, you can do this within the sifra container.
Restructure of Python code. While the simulation has been integrated with the json serialisation/deserialisation logic, the redundant classes should be removed and the capacity to create, edit and delete a scenario needs to be developed.
The handling of types within the web API is inconsistent; in some cases it works with instances, in others dicts and in others, JSON docs. This inconsistency goes beyond just the web API and makes everything harder to get. One of the main reasons for this is the late addtion of 'attributes'. These are meant to provide metadata about instances and I did not have a clear feel for whether they should be part of the instance or just associated with it. I went for the latter, which I think is the right choice, but did not have the time to make the API consistent throughout.
Consider whether a framework like Redux would be useful.
Perhaps get rid of ng\_select. I started with this before realising how easy simple HTML selects would be to work with and before reading about reactive forms (I’m not sure how/if one could use ng\_select with them). One benefit of ng\_select may be handling large lists and one may want to do some testing before removing it.