Aamks: the platform for assessing ﬁre safety of humans in buildings

. We introduce an open-source software for ﬁre risk assessment named Aamks. We provide a brief overview of the following aspects of the platform: the motivation for creating Aamks, the architecture of the platform, the user interface, the intended workﬂow for conducting ﬁre safety analyses, the probabilistic approach to ﬁre risk assessment, the geometry processing, the reasoning from the topology of the building (i.e. automatic planning of exit routes), the interactions amongst the moving evacuees, the impact of smoke on humans and ﬁnally the results and the visualization.


Introduction
In most countries nowadays the fire safety is based on the legal regulations [1]. There are strict regulations for the safety features of buildings of given categories, i.e. malls, schools, etc. Sometimes it is difficult to meet these regulatory criteria (e.g. the building may already be existing and be a subject to some new regulations after it's purpose has been changed). In such occasions there's a possibility to prove by computer simulations that the building is safe, even though it doesn't strictly comply to the regulations. Typically a fire safety expert creates the model of the building, then proposes say 3 or 5 likely scenarios and lets the Computational Fluid Dynamics (CFD) simulator perform detailed, but lengthy simulations -an order of a week for the complete project.
A single scenario is build of features of type: Where does the fire start? What are the fire parameters? How many people will there be in the building? Will particular windows and doors be open? Etc. The problem with the current approach used by practitioners is the arbitrariness of the scenarios picking.
Aamks addresses this problem exactly -it's the computer itself that proposes the scenarios. Aamks uses distributions for the above and many other features of a single scenario. At the cost of the precision of each simulation, Aamks runs hundreds or thousands of less accurate, but still meaningful simulations. The two key concepts that Aamks uses are a) the use of a zone fire model simulator (less accurate but fast) instead of the CFD simulator (accurate but slow) and b) the more thorough coverage of the possible scenarios space (than just 3 or 5) thanks to Monte Carlo sampling [2][3][4]. The complete Aamks analysis takes roughly the same amount of time as the alternative CFD solution popular today.
Aamks is not just about avoiding arbitrariness and covering the space of possibilities better. There is software in the field of fire safety, but it is mostly targeted towards very experienced users or scientists. In Aamks we try to provide a smooth workflow, make things easy for the users, be minimalistic in the interface and use modern technologies. Aamks is open source which except from being freely available allows others to join our team, enhance the software and inspect Aamks internals. In general Aamks architecture is based on multisimulation approach proposed by Adam Krasuski in [5] and also takes an advantages from the works of Simo Hostikka on Probabilistic Fire Simulator [6] and Two Model Monte Carlo approach [7].
We code Aamks in python and javascript which are modern and popular languages 1 due to rich collections of libraries. These languages increase the chances of attracting new developers to our project.

Architecture of Aamks
Internally Aamks is organised in the following modules: • Geometry processor What follows is the descriptions of these modules.

Geometry processor
The workflow needs to be started with a CAD model of the building. Currently Aamks allows for two methods: a) AutoCAD plugin or b) Apainter, our own editor.
AutoCAD plugin is a binary package that we distribute as part of Aamks. Once it is installed and configured it provides all CAD comfort for the users familiar with AutoCAD. For users who cannot afford to buy AutoCAD or for users who use an operating system where AutoCAD is not available we have Apainter editor. It is a javascript editor which requires Google Chrome or Chromium web browser and which is crafted exactly towards what Aamks requires. Apainter can be tried on our demo website 2 . The work basically takes place on a 2D plane, but a 3D view is provided for the verification that the model is correct.
Either of the above tools produces not only the geometry, but also encodes features like: this is a plain door, this is a door with an automatic closer etc. There's a dedicated json 3 file format to encode all these features. This file needs to be later imported and converted to an internal Aamks format which is needed for topology reasoning and other tasks.
A large topic here (a sub-module on it's own) is the problem of finding a path in the building from any given point to an exit (global navigation). At first Aamks solved this problem with graphs, but we are currently switching to a more advanced method based on navigation meshes [8].

Monte Carlo module
This is the stochastic producer of hundreds of simulation scenarios. Each scenario has a dozen of input parameters. Aamks has a library of distributions for each of these input parameters describing various aspects of the scene, for example: • There is a distribution of outside temperatures in Poland and Aamks draws a temperature for each single scenario. Based on the outside temperature Aamks further decides (based on another distribution) on the position of each window (open, half-open, close). This is important because ventilation has a huge impact on the development of the fire.
• There are parameters controlling the fire origin and it's development.
• Similarly, Monte Carlo module picks the number and the initial positions of evacuees in the building and further controls their behaviour -each evacuee gets their pre-evacuation time [9] and their preferred velocity.
It is worth to note, that this concept allows for great isolation of the problems which improves clarity: each of the distributions may at any point be improved (for example someone may come up with a better idea for how the outside temperature relates to opening windows). In other words it is the community that accepts the very internals of Aamks in a fully transparent process.
Also, Aamks' architecture allows for using new distributions for aspects that are currently constant, such as how much of the poisonous gases the evacuees really absorb while inhaling.

Fire simulator
Aamks uses the CFAST zone fire model [10]. This module is responsible for preparing the CFAST input file and for collecting CFAST results.
CFAST's task is to simulate the development of a fire and smoke in 10 seconds intervals. Even though CFAST is relatively fast, still it may take a couple of minutes to produce the data for the given interval. What Aamks does is it pauses the (less complex) evacuation simulation and waits until CFAST has produced the needed data. Then the evacuation simulation resumes and the resulting fire and smoke impact on the evacuees (poisonous gases and visibility) is taken under account.
Large part of this module is the mechanism for efficient queries of CFAST results. CFAST writes it's results to a file which is not at all suitable for massive queries. Therefore Aamks first partitions the geometry of the building into cells. Then Aamks parses each record of a CFAST file and each cell is filled with the necessary CFAST data. Finally, for the queries, an evacuee at position (x,y) can be efficiently mapped to a cell and receive the fire and smoke conditions for that cell.

Evacuator
This module is responsible for routing evacuees to safety. Except from the global navigation throughout the building, it needs to handle the collisions with other evacuees which is a totally separate issue. There are quite a few models of collision avoidance of both robots and humans. Not a single one clearly stands above the rest. Some models are too much optimised towards the efficient collisions avoidance (which doesn't need to be the case in real life crowded humans situations), some generate streams of crowds and some not, some allow for better handling of crossing streams of the crowds, some are better in counter flows of streams in narrow corridors, some are computationally instable, some have better and more readily available software implementations, etc. All this affected our choice for Aamks, which was the RVO2 model [11].
Except from the navigation and collisions aspects, the evacuees are a subject to smoke impact. Smoke restricts the visibility and affects the health and speed of the evacuees due to the poisonous gases inhalation measured as the Fractional Effective Dose (FED) [12].

User Interface module
Most of the processing, particularly the costly fire development simulations are run on a server with preferably attached cluster / grid computers. The administrator needs to install Aamks on the server and the user interacts with Aamks via a web browser, so it requires no configuration on the user's part, which is easy and comfortable. The user's interaction is brought down to providing the CAD model of the building (can be done right in the browser), setting a short list of meta parameters (e.g. the number of simulations), starting the simulations and later interpreting the results.

Results module
The results come in a form of animations displaying how the evacuees are moving and how poisonous gases affect their state. There are also collections of charts and tables summarizing various aspects of risk assessments, such as the F-N curves (Figure 1).

Grid manager
Obviously, there's quite a bit of computational power needed to run simulations, therefore Aamks is meant to be run in a cluster / grid environment. The computers running the simulations are called nodes or workers. The cluster / grid environment requires special management, such as waking up the workers, registering and unregistering the workers as our computing units, allocating the number of CPU cores on each worker, checking which workers are online, updating and verifying that each worker runs the same version of Aamks, etc. We created our own grid manager for all the above tasks and more.
Once the workers are all ready to run the calculations, there's a need for interchanging and storing of the input and output data of the simulations. The server needs to know which simulations there are to be calculated, the workers need to know how to get their data and how to send it back. We use Gearman job manager 4 , Apache web server 5 , and PostgreSQL database 6 for this.

Installer
This module provides the script for installing the needed server components, such as the web server environment, the job manager, the database server and multiple modules needed by python. Except from the installation the system also setups the necessary variables and the database schema. Aamks has only been tested under Linux operating system.

Discussion
Aamks has been actively developed since 2016 and is available from the github repository 7 . There's a lot of functionality already and we are working on smoothing things out and adding new functionality such as vertical evacuation. As we are developing the software we keep finding more robust solutions and we replace things like graphs with navigation meshes in global path planning. Aamks at this stage is a work in progress and we are not production ready just yet, even though Aamks has been used in real life projects already. Before Aamks is really used in production it needs to be tested, verified, documented etc. We have put Aamks through the NIST 1822 test suite [13] and Zhang and Seyfried [14] test. For now, we publish the current test results and videos 8 . Also, at the same website we compare Aamks against a commercial evacuation program Pathfinder 9 , but it is just a rough overview, because of the difficulty of setting the very same initial parameters for the two.