A-Evac: The Evacuation Simulator for Stochastic Environment

We introduce an open-source software for fire risk assessment named Aamks. This article focuses on a component of Aamks—an evacuation simulator named a-evac. A-evac models evacuation of humans in the fire environment produced by a zone fire model simulator. In the article, we discuss the probabilistic evacuation approach, automatic planning of exit routes, the interactions amongst the moving evacuees and the impact of smoke on humans. The results consist of risk values based on fractional effective dose and are presented in the form of various probability distributions and evacuation animations. The intended scope of Aamks is buildings, e.g., offices, malls, factories rather than stadiums or streets. We present the need for such software based on the current state of research and existing engineering tools in the probabilistic risk assessment domain. Then we describe a-evac and its details: geometry, path-finding, local movement, interaction with fire, and visualization. Given the above scope, the article contributes to the domain of probabilistic risk assessment by proposing: (a) stochastic approach to evacuation, (b) velocity-based model for evacuation, (c) evacuation software that interacts with fire conditions and zone fire models.

There are scientific methods and models of the fire and the emergency scene, there are computer implementations, but the complexity of the domain impedes the more widespread use of these tools.
Currently, the most typical approach for assessing the safety of the building is a precise choosing of the input parameters for a small number of lengthy, detailed simulations.This procedure is managed by a practitioner, based on his experience.However, based on heuristics and biases [31,22] we have concerns that human judgement surpasses statistical calculations.The alternative is to let computer randomly choose the parameters and run thousands of simulations.The resulting collection allows us, after further processing, to judge on the safety of the building.

Aamks, the multisimulations platform
We created Aamks -the platform for running simulations of fires and then running the evacuation simulations, but thousands of them for a single project.This is the Monte-Carlo approach.We use CFAST, which is a rough, but a fast fire simulator.This allows us to explore the space of possible scenarios and assess the probability of them.The second component of risk -consequencesis taken from an evacuation simulator capable to model evacuation in the fire environment.We use a-evac as the evacuation simulator which we have built from scratch.The multisimulation is a handy name for what we are doing.Aamks tries to assess the risk of failure of humans evacuation from a building under fire.We applied methodology proposed in [16,8,1] -stochastic simulations based on the Simple Monte-Carlo approach [7].Our primary goal was to develop an easy to use engineering tool rather than a scientific tool, which resulted in: AutoCAD plugin for creating geometries, web based interface, predefined setups of materials and distributions of various aspects of buildings features, etc.The workflow is as follows: The user draws a building layout or exports an existing one.Next, the user defines a few parameters including the type of the building, the safety systems in the building, etc.Finally, they launch a defined number of stochastic simulations.As a result they obtain the distributions of the safety parameters, namely: available safe egress time (ASET), required safe egress time (RSET), fractional effective dose (FED), hot layer height and temperature and F-N curves as well as the event tree and risk matrix.
Fortran is a popular language for coding simulations of physical systems.CFAST and FDS+Evac are coded in fortran.Since we don't create a fire simulator we code Aamks in python which is more comfortable due to extremely rich collection of libraries.We decided that borrowing Evac from FDS and integrating it with Aamks would be harder for us than to code our own evacuation simulator, hence a-evac was born.There's also a higher chance of attracting new python developers than fortran developers for our project.
Aamks consists of the following modules: a-geom, geometry processing: AutoCAD plugin, importing geometry, extracting topology of the building, navigating in the building, etc. a-evac, directing evacuees across the building and altering their states a-fire, CFAST and FDS binaries and processing of their outputs a-gui, web application for user's input and for the results visualisation a-montecarlo, stochastic producer of thousands of input files for CFAST and a-evac a-results, post-processing the results and creating the content for reports, a-manager, managing computations on the grid/cluster of computers a-installer 3 A-evac, the evacuation simulator In the following subsections we describe the internals of a-evac, sometimes with the necessary Aamks context.

Geometry of the environment
The Aamks workflow starts with a 3D geometry where fires and evacuations will be simulated.We need to represent the building, which contains one or more floors.Each floor can consist of compartments and openings in them, named respectively COMPAS and VENTS in CFAST.Our considerations are narrowed to rectangular geometries.There are two basic ways for representing architecture geometries: a) cuboids can define the insides of the rooms (typea-geometry) or b) cuboids can define the walls / obstacles (type-b-geometry).CFAST uses the type-a-geometry.We create CFAST geometries from the input files of the following format (there are more entities than presented here): All the entities in the example belong to the same FLOOR 1.The triplets are (x 0 , y 0 , z 0 ) and (x 1 , y 1 , z 1 ) encoding the beginning and the end of each entity in 3D space.In practice we obtain these input files from AutoCAD, thanks to our plugin which extracts data from AutoCAD drawing.There's also an Inkscape svg importer -useful, but without some features.Adding basic support for another graphics tools is not much work.
In later sections we will introduce problems of guiding evacuees throughout the building.Those modules require the type-b-geometry.We convert from a type-a-geometry to a type-b-geometry by duplicating the geometry, translating the geometry and applying some logical operations.Figure 2 shows the idea.
Fig. 2 The conversion from type-a-geometry to type-b-geometry There are three aspects of movement when it comes to evacuation modeling [9]: (a) path-finding -for the rough route out of the building, (b) local movement -evacuees interactions with other evacuees, with obstacles and with environment, and (c) locomotion -for "internal" movement of the agent (e.g.body sway).A-evac models only (a) and (b).

Path-finding (roadmap)
The simulated evacuees need to be guided out of the building.The type-bgeometry provides the input for path-finding.Each of the cuboids in typeb-geometry -representing obstacles -is defined by the coordinates.These coordinates represent corners of the shapes.Since we model each of the floors of a building separately, we flatten 3D geometry into 2D and represent obstacles as rectangles.Therefore type-b-geometry in path-finding module is represented as set of 4-tuple coordinates (x 0 , y 0 ), (x 1 , y 1 ), (x 2 , y 2 ), (x 3 , y 3 ) .
The set of 4-tuple elements is then flatten to the set of coordinatesbag-of-coordinates.Due to the fact that majority of the obstacles share the coordinates, we remove duplicates from the set (for the sake of performance).Then, this bag-of-coordinates is the input for triangulation.We apply Delaunay triangulation [10], that represents space as a set of triangles.Figure 3 depicts the idea of triangulation.The triangles are used as navigation meshes for the agents.The navigation meshes define which areas of an environment are traversable by agents.
After triangulation of bag-of-coordinates, some of the triangles are located inside the obstacles -those (by definition) are not traversable so we remove them.What is left is a traversable-friendly space.
We create then the graph of spatial transitions for the agents, based on the adjacency of triangles obtained from the triangulation.Spatial transition means that an agent can move from one triangle to another.
An agent on an edge of a triangle can always reach the other two edges.For triangles which share edges it allows an agent to travel from one triangle to another.
The pairs of all neighbouring edges are collected.We use python networkx module [4] which creates a graph made of the above pairs.For further processing we add agents positions to the graph, by pairing them with the neighbouring edges.
The graph represents all possible routes from any node to any other node in the graph.We can query the graph for the route from the current agent's position to the closest exit.It means that agent will walk through the consecutive nodes and will finally reach the exit door.We instruct networkx that we need the shortest distances in our routes (default is the least hops on the graph) and we obtain a set of edges the agent should traverse in order to reach the exit.Figure 4 depicts the set of edges returned by the graph for an example query.
Fig. 4 The roadmap defined by the graph for an example query.The red line crosses centers of edges that an agent needs to travel to reach the exit.
The set of edges returned by the graph cannot be used directly for pathfinding.Neither the vertices of the edges nor the centers of them, do define the optimal path that would be naturally chosen by evacuees during real evacuation.Therefore an extra algorithm should be used to smooth the path.For this purpose we apply funnel algorithm defined in [6].The funnel is a simple algorithm finding straight lines along the edges.
The input for the funnel consists of a set of ordered edges (named portals) from the agent origin to the destination.The funnel always consist of 3 entities: the origin (apex) and the two vectors from apex to vertices on edges -the left leg and the right leg.
The apex is first set to the origin of the agent and the legs are set to the vertices of the first edge.We advance the left and right legs to the consecutive edges in the set and observe the angle between the legs.When the angle gets smaller we accept the new vertex for the leg.Otherwise the leg stays at the given vertex.After some iteration one of the legs should cross the other leg defining the new position of the apex.The apex is moved and we restart the procedure.
As a result the path is smoothened and defined only by the points where the changes in velocity vector are needed.Moreover, we used an improved version of the funnel algorithm that allows for defining points keeping a distance from the corners reflecting the size of the evacuee.This allows for modeling the impaired evacuees on wheeled chairs or beds in the hospitals.Figure 6 depicts the smoothened path by funnel algorithm.
Fig. 6 The roadmap from starting point to exit smoothened by funnel algorithm.

Local movement
Local movement focuses on the interaction with (a) other agents (b) static obstacles (walls) and (c) environmental conditions.A-evac handles (a) and (b) via RVO21 which is an implementation of the Optimal Reciprocal Collision Avoidance (ORCA) algorithm proposed in [3,32].Later in this section we describe how we are picking the local targets which is an aspect of (b).(c) is basically altering agent's state such as speed.
RVO2 aims at avoiding the velocity obstacle [11].The velocity obstacle is the set of all velocities of an agent that will result in a collision with another agent or an obstacle.Otherwise, the velocity is collision-avoiding.RVO2 aims at asserting that none of the agents collides with other agents within time τ .
The overall approach is as follows: each of the agents is aware of other agents parameters: their position, velocity and radius (agent's observable universe).Besides, the agents have their private parameters: maximum speed and a preferred velocity which they can auto-adjust granted there is no other agent or an obstacle colliding.With each loop iteration, each agent responses to what he finds in his surroundings, i.e. his own and other agents radiuses, positions and velocities.The agent updates his velocity if it is the velocity obstacle with another agent.For each pair of colliding agents the set of collision-avoiding velocities is calculated.RVO2 finds the smallest change required to avert collision within time τ and that is how an agent gets his new velocity.The agent alters up to half of his velocity while the other colliding agent is required to take care of his half.Figure 8 a-b depicts the idea of velocity collision avoidance.
The algorithm remains the same for avoiding static obstacles.However, the value of τ is smaller with respect to obstacles as agents should be more 'brave' to move towards an obstacle if this is necessary to avoid other agents.
It turned out problematic how to pick the local target from the roadmap.Local targets need to be updated (usually advanced, but not always) near points defined by funnel algorithm during path-fining phase -the disks on Figure 7, after they become visible to the agent.However, the disks can be crowded and agents can be driven away from the correct courses by other agents.We carefully inspected all possible states that agents can find themselves in.In order to have a clearer insight and control over the agents inside the disks we use the Finite State Machine2 instead of just plain algorithm block in our code.The state of the agent is defined by 4 binary features: (a) is agent inside the disk?(b) are where agent is walking to and what agent is looking at the same target?(c) can agent see what he is looking at (or are there obstacles in-between)?(d) has agent reached the final node?
Within each iteration of the main loop we check the states of the agents.The states can be changed by agents themselves -e.g.agent has crossed the border of the disk, or by our commands -e.g.agent is ordered to walk to another target.Consider these circumstances: the agent has managed to see his next target and now he walks towards this next target -he is in state S1.But now he loses the eye contact with this new target and finds himself in state S2.The program logic reacts to such a state by transiting to the state S3: start looking at the previous target and walk towards this previous target.Based on what happens next we can order the transition to another state or just wait for the agent to change the state himself.By careful examination of all possible circumstances we can make sure that our states and their transitions can handle all possible scenarios.
Agent is moving towards this target Agent is keeping an eye on this target On Figure 8c) we show how agents are passing through a HOLE.Due to our concept of the disks (where searching for new targets takes place) and due to the internals of RVO2 we gain the desired effect of agents not crossing the very center of the disk.Instead, the agents can walk in parallel and advance to another target which looks natural and doesn't create an unnecessary queue of agents eager to cross the very center of the HOLE.

Evacuation under fire and smoke
Each a-evac simulation is preceded with the simulation of the fire.We have only tested a-evac with CFAST [24,21].CFAST writes its output to csv files.
We need to query these CFAST results quite a bit, therefore we transform and store these results in a fast in-memory relational database3 .For each frame of time we are repeatedly asking the same questions: (a) given the agent's coordinates, which room is he in?(b) what are the current conditions in this room?
When it comes to (b), the environment effects on the agent can be: (b.1) limited visibility (eyes), (b.2) poisonous gases (nose) and (b.3) temperature in the room (body).Both (b.1) and (b.2) are read from the default (but configurable) height of 1.8 m.There are always two zones in CFAST, which are separated at a known height, so we need to read the conditions from the correct zone, based on where our 1.8 m belongs.
The value of visibility (OD -optical density) affects agent's speed.We use the relation proposed in [12] following the FDS+Evac [23]: where: K s is the extinction coefficient ([K s ] = m −1 ) calculated as OD/log 10 e according to [19,20], v n,min is the minimum speed of the agent A n and equals 0.1 • v pref n (agent's preferable velocity), and α, β are the coefficients defined in [12].
Setting the minimal value of speed means that the agent does not stop in thick smoke.They continue moving until the value of incapacitated Fractional Effective Dose (FED) is exceeded, which is fatal to the agent.FED is calculated from CFAST-provided amounts of the following species in the agent environment: carbon monoxide (CO), hydrogen cyanide (HCN), hydrogen chloride (HCl), carbon dioxide (CO 2 ) and oxygen (O 2 ) by the equation [26,23]: where HV CO2 is the hyperventilation induced by the concentration of CO 2 .Following are the formulas for the terms in the above equation.FEDs are given in ppm and time t in minutes.C stands for concentration of the species in %: Based on [17] In contrast to the model applied in Evac, CFAST does not allow for proactive correction of effect of nitrogen dioxide -C CN = C HCN − C N O2 .Therefore this effect is not included in the calculations.
Based on [28,17] F ED O2 = t 0 dt 60 • exp 8.13 − 0.54(20.9− C O2 (t)) ( 6) There are few quantitative data from controlled experiments concerning the sublethal effect of the smoke on people.In works [28,5,26,14,29] sublethal effect in a form of incapacitation (IC 50 ), escape ability (EC 50 ), lingering health problems and minor effects were reported.Incapacitation was inferred from lethality data, to be about one-third to one-half of those required for lethality.The mean value of the ratios of the IC 50 to the LC 50 was 0.50 and the standard deviation 0.21, respectively.In [14] a scale for effects based on FED was introduced.The three ranges were proposed: 1 FED indicating lethality, 0.3 FED indicating incapacitation and 0.01 FED indicating no significant sublethal effects should occur.We propose based on this data a scale for sublethal effects of smoke for evacuees as presented in Table 1.
F ED total affects the agent's movement in the smoke.For F ED total > 0.3, the smoke inhalation leads to sublethal effects [5] -the agent is not able to find safety from the fire and just stays where he is.For F ED total > 1 we model lethal effects.We later use these effects in the final risk assessment.
Table 1 summarizes the FED effects on human health, what is our original proposition for evaluation of sublethal effect of smoke.These ranges are incorporeted in Aamks.It is based on the following works: [28,5,26,14,29]

Probabilistic evacuation modeling
This section presents the internals of our probabilistic evacuation model, which we find distinct across the available, similar software.Table 2 presents the distributions of the input parameters used in Aamks.Each of the thousands of simulations in a single project is initialized with some random input setup according to these distributions.Aamks has a library of the default parameters values for important building categories (schools, offices, malls etc.).The Aamks users should find it convenient to have all the distributions in a library, but they may choose to alter these values, which is possible.
Most of the data in table 2 come from the standards and from other models, mostly FDS/Evac.Following are some comments on table 2.
Aamks puts much attention to the pre-evacuation time [9], which models how people lag before evacuating after the alarm has sounded.Positions 7. and 8. are separated, because the behaviour of humans in the room of fire origin is distinct.We compile two regulations C/VM2 Verification Method: Framework for Fire Safety Design [30] and British Standard PD 7974-6:2004 [2] in order to get the most realistic, probability-based pre-evacuation in the room of fire origin and in the rest of the rooms.
The Horizontal/Vertical speed (unimpeded, walking speed of an agent) is based on [18,13,25,15].Speed in the smoke is modeled by formula 1.The randomness of the simulations comes from the random number generator's seed.We save the seed for each simulation so that we can repeat the very same simulation, which is useful for debugging and visualisation.
We register all the random input setups and the corresponding results in the database.We are expecting to research at some point the relationships in these data with data mining or sensitivity analysis.
The final result of Aamks is the compilation of multiple simulations as a set of distributions i.e.F-N curves.The F-N curves were created as in [12].Figure 9 depicts the exemplary results.Fig. 9 The results of evacuation modeling as F-N curves.

Visualization
In Aamks we use a 2D visualization for supervising the potential user's faults in his CAD work (e.g.rooms with no doors (Figure 10)), for the final results, and for our internal developing needs.We use a web based technology which allows for displaying both static images and the animations of evacuees.We also have a web based 3D visualization made with WebGL Threejs.This subsystem displays realistic animations of humans during their evacuation under fire and smoke.(Figure 11).Below we evaluate the quality of a-evac as described in [9,27] as well as it's computer performance.

Verification of a-evac
Verification and validation deals with how close the results of the simulations to the reality are.We took care to be compliant with the general development recommendations [9] by: (1) obeying good programming practices, (2) verifying intermediate simulation outputs, (3) comparing simulation outputs against the analytical results, and (4) creating debugging animations.
The are three types of errors that can be generated by our software: a) error in deterministic modeling of single scenario, b) error of Monte Carlo approximation, c) statistical error -disturbance.
For the first type of error we applied the methods proposed in [27].The proposed tests are organized in five core components: (1) pre-evacuation time, (2) movement and navigation, (3) exit usage, (4) route availability, and (5) flow conditions/constraints.For each category there are detailed tests for the geometry, the scenario and the expected results.The results are in table 3. RVO2, the core library of a-evac which drives the local movement, was also evaluated in [33].The conclusions are that RVO2 is of the quality comparable with the lattice gas and social force models.The social force model is commonly used in a number of evacuation software.
The above is the evaluation of a single, deterministic simulation.However, the final result is the compilation of the whole collection of such single simulations -this is how we get the big picture of the safety of the inquired building.The picture is meant to present risk.Probability of risk is calculated as a share of simulations resulted in fatalities, in the total number of simulations.
The accuracy of this evaluation depends on the method applied -stochastic simulations.The error is proportional to the square root of number simulations.Namely for the discrete Bernoulli probability distributions used for example for evaluation of probability of scenario with fatalities, the error is calculated as follows: where: pn is the probability of fatalities obtained as a number of simulations resulted in fatalities to the total number of simulations, n is the number of simulations.
We are aware of the third type of error which may be generated by the application.The input for Aamks is a set of various probability distributions what may occasionally generate unreal scenario.For example an evacuee who moves very slowly on corridors and very fast on stairs.In most cases these errors are related to the other parts of Aamks i.e. probabilistic fire modeling.
However, fire environment impacts the evacuation.This error can be evaluated by comparison of data generated by Aamks with real statistics.So far we do not have idea how to tackle this problem efficiently.We consider to evaluate this error by launching simulations for the building stock and check whether we reconstruct historical data.This method is very laborious and not justified at that moment, because our application still lacks some models i.e. fire service intervention -what has significant impact on fire.

Performance of the Model
The main loop of Aamks processes all agents in the time iteration.Table 4 summarizes how costly the specific calculations for a single agent within a single time iteration are.The tests were performed on computer with Intel Core i5-2500K CPU at 3.30 GHz with 8 GB of RAM.The total time of a single step of the simulation for one agent is 2 × 10 −4 s and it grows linearly with the number of agents.The speed and FED calculations are most costly, because they both make database queries against the fire conditions in the compartment.The time step for a-evac iteration is 0.05 s.There is no significant change in fire conditions within this time frame.Therefore for performance optimization we update speed and FED every 20-th step of the simulation.

Discussion
Vertical evacuation is troublesome and not implemented.There is RVO2 3D, but it is for aviation where agents can pass above each other -clearly not for our needs.Besides, we think things look actually better in 2D.We like the idea that vertical evacuation can be still considered 2D, just rotated, and we plan to move in this direction.
A-evac does not model the social or group behaviours.However, it is difficult to evaluate, how much the lack of such functionalities impacts the resulting probability distributions.
In the workflow we run a CFAST simulation first.Then a-evac simulation runs on top of CFAST results.This sequential procedure has it's drawbacks, e.g.we don't know how long the CFAST simulation should last to produce enough data for a-evac, so we run "too much" CFAST for safety.Also, evacuees cannot trigger any events such as opening the door, etc.We considered a closer a-evac-CFAST integration.
There seems to be lot's of space for improvement in Aamks.We work with the practitioners and know the reality of fire engineering.We know the limitations of our current implementations and most of them can be addressed -there are models and approaches that we can implement and the major obstacle are the limits of our team resources.Therefore we invite everyone interested to join our project at http://github.com/aamks.

Conclusion
Aamks is actively developed since 2016 and we are truly engaged in making it better.The software, though not really ready for end-users has already served as a support for commercial projects and fire engineers and scientists regard Aamsk as having potential.The stochastic based workflow of Aamks is not a new concept.There are opinions in the community that this approach is how fire engineering should be done.Since no wide-used implementation has been created so far, this is an additional motivation that drives our project.

Fig. 1
Fig. 1 The concept of a HOLE: a) the room in reality, b) the room representation in CFAST: two rectangles for separated calculations, but open to each other via HOLE.

Fig. 5
Fig. 5 The idea of funnel algorithm.a) starting point, b) advancing legs.

Fig. 7
Fig.7The roadmap and local movement

Fig. 8
Fig.8RVO2 at its work of resolving collisions: (a) agents on direct collision courses and (b) their calculated collision-avoiding courses, (c) three agents crossing a HOLE in parallel.

Table 1
FED effects on human health in Aamks.

Table 2
Parameters of the distributions for the exemplary scenario.

Table 3
The results of Aamks tests

Table 4
The costs of a single loop iteration per agent