Series title, number and report code of publication

VTT Working Papers 119 VTT-WORK-119

Author(s)

Timo Korhonen & Simo Hostikka

Title

Fire Dynamics Simulator with Evacuation: FDS+Evac

Technical Reference and Users GuideAbstract

This document describes how to simulate human egress using the evacuation module, FDS+Evac, which is fully embedded in Fire Dynamics Simulator (FDS). This manual applies to the FDS+Evac version is 2.1.1, which is embedded in the current FDS version 5.3.0. The most up to date version of this manual can be obtained from the FDS+Evac home page at http://www.vtt.fi/fdsevac/. The FDS+Evac Technical Reference and Users Guide does not contain information on how to operate FDS nor Smokeview, the companion visualisation programme for FDS. Their full capabilities are described in their documentation, which can be obtained from the FDS-SMV home page http://fire.nist.gov/fds/.

PrefaceThis document describes how to simulate human egress using the evacuation module, FDS+Evac, developed at VTT Technical Research Centre of Finland, which is fully embedded in Fire Dynamics Simulator (FDS). This manual applies to the FDS+Evac version is 2.1.1, which is embedded in the current FDS version 5.3.0. The most up to date version of this manual can be obtained from the FDS+Evac web page at http://www.vtt.fi/ fdsevac/. The FDS+Evac Technical Reference and Users Guide does not contain information on how to operate FDS nor Smokeview, the companion visualisation programme for FDS. Their full capabilities are described in the Fire Dynamics Simulator (Version 5) Users Guide [2] and the Users Guide for Smokeview Version 5 [12]. Certain commercial entities, equipment, or materials may be identied in this document in order to describe an experimental procedure or concept adequately. Such identication is not intended to imply recommendation or endorsement by VTT Technical Research Centre of Finland, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.

DisclaimerVTT Technical Research Centre of Finland makes no warranty, expressed or implied, to users of FDS+Evac, and accepts no responsibility for its use. Users of FDS+Evac assume sole responsibility for determining the appropriateness of its use in any particular application; for any conclusions drawn from the results of its use; and for any actions taken or not taken as a result of analyses performed using these tools. Users are warned that FDS+Evac is intended for use only by those competent in the elds of re and evacuation simulation, and is intended only to supplement the informed judgement of the qualied user. The software package is a computer model that may or may not have predictive capability when applied to a specic set of factual circumstances. Lack of accurate predictions by the model could lead to erroneous conclusions with regard to life safety. All results should be evaluated by an informed user.

10 Sample Input Files 11 Conclusion Acknowledgements References

73 86 88 89

1. IntroductionThis document describes how to simulate human egress using the Fire Dynamics Simulator (FDS) [1, 2, 3, 4], and in particular, the evacuation module [5, 6, 7, 8, 9]. This combined re and evacuation simulation program is called FDS+Evac in this document. FDS+Evac allows simultaneous simulation of the re and evacuation processes. It can also be used to simulate only the human egress process without any re effects, e.g., a re drill. FDS+Evac treats each evacuee as a separate entity, or an agent, which has its own personal properties and escape strategies. The movement of the agents is simulated using two-dimensional planes representing the oors of buildings. The basic algorithm behind the egress movement solves an equation of motion for each agent in a continuous 2D space and time, i.e., FDS+Evac is doing some kind of an articial molecular dynamics for the agents. The forces acting on the agents consist of both physical forces, such as contact forces and gravity, and psychological forces exerted by the environment and other agents. The model behind the movement algorithm is the social force model introduced by Helbings group [13, 14, 15, 16]. A modication of the model to describe better the shape of the human body was introduced by Langston et al. [17]. This chapter contains some general information on FDS+Evac. In Chapter 2, the model documentation is summarised. Chapter 3 presents the theoretical model behind the agent movement algorithm and details on the implementation. Chapter 4 is dedicated to various verication tests of the programme and Chapter 5 deals with the sensitivity of the model to the model parameters. In Chapter 6, FDS+Evac is validated by comparing to other evacuation calculation methods and experimental results. Chapters 711 contain the users guide, where the inputs of FDS+Evac are explained. The user of FDS+Evac should read carefully every chapter of this manual before starting to use the programme. The knowledge on the theoretical method is needed in order to build up the model correctly. It also helps making the judgement on the applicability and reliability of the programme in the application in question. Because the evacuation calculation is implemented as a module of FDS, the reader is recommended to read rst the Users Guide of FDS and learn how to do re simulations. Even if the user wants to run the programme without re, she/he should be acquainted with the FDS in order to build up the simulation geometry and running the FDS simulations.

1. Introduction

1.1

Getting Started

The evacuation module is embedded inside the FDS. Thus, the running of FDS+Evac evacuation simulation is done similarly as an ordinary FDS re simulation. See the FDS Users Guide [2] for details. FDS+Evac results can be visualised using the Smokeview [12] programme. Also, the computer hardware requirements are similar with FDS. The FDS re calculation can be run parallel by using the MPI version of FDS, but the evacuation part is always calculated as a single thread. The evacuation module, FDS+Evac, is embedded in the FDS 5.3, which can be obtained from the URL http://fire.nist.gov/fds/ Download the latest version of FDS-Smokeview installation package and install it. Check if there exists more recent maintenance releases of the executables. The resulting FDS executables are also the executables of the evacuation calculation module. The source codes can also be obtained via the FDS-SMV web pages. The home page of FDS+Evac is http://www.vtt.fi/fdsevac/ This page contains the most recent version of this combined Technical Reference and Users Guide of FDS+Evac and some examples on the use of FDS+Evac. This web site is also used to store the validation and verication test cases including the input les. This (printed) manual refers to FDS 5.3.0 + Evac 2.1.1.

1.2

Features of Limited Functionality

All the intended features of FDS+Evac are not yet fully functional. For now, FDS+Evac is best suited for doing calculations in buildings, whose oors are mainly horizontal. Sports halls with spectator stands or concert halls can also be modelled if their geometry is not too complicated, but the user should note that simulations in inclined geometries have not yet been validated. It is also assumed that the different levels of the building are separated from each other, i.e., they are connected to each other by stairs, escalators, doors, and similar objects. Note, that FDS+Evac does not support the use of elevators during evacuation process. Wide stairs or inclines can also be used to connect different oors, but this is not as straightforward as to use the default staircase model. There are no merging ows allowed in the default staircase model, so FDS+Evac is not yet easy to use for tall buildings. The default staircase algorithm is still very simple and it should not be trusted too much if the stairs get crowded. At this point this is not a major problem, because there are no merging ows in the staircase model, i.e., the exit door restricts the ow to the staircase quite efciently. If merging ows in staircases are needed then the detailed geometry of the staircase should be modelled, but this is not usually very practical way of doing things. See the example case Stairs.fds on the FDS+Evac web pages.

1. Introduction

The evacuation calculation needs, in addition to the re calculation meshes, its own 2D evacuation meshes. If no re related data is needed in the evacuation calculation then there are no need for re meshes and FDS+Evac can be run in a re drill mode. Evacuation meshes should not be too ne, because then one might face problems with the evacuation ow elds, which are used to guide the agents towards the exits. This difculty can be addressed by an experience user, but an easier way is always to use evacuation meshes, which are not too ne. Usually mesh cell sizes 0.25 m or larger can be used without any problems. For example, if you have 1.2 m wide doors you could use 0.3 m, 0.6 m, or 1.2 m cell spacing depending on how detailed geometry is needed. Note, that Smokeview does not yet fully support the evacuation calculation, e.g., the positions of doors, stairs and other evacuation objects are not shown by Smokeview. Note also that the spaces, where agents are allowed to move, should be at least about 0.7 m wide, because FDS+Evac is not able to move agents in narrower exit paths correctly. The user should check the evacuation geometry by using the Smokeview programme and make sure that the holes in the evacuation geometry are not too narrow. The best way of seeing the evacuation geometry is to do a calculation without any re mesh denitions. Then the Smokeview shows just the evacuation geometry. It is a good practice to construct rst the FDS re calculation input le and do a short test run. After this one can add the evacuation meshes to the calculation and deactivate the re meshes, i.e., try to simulate (and see) just the evacuation part of the calculation. When the evacuation part of the input le seems to be working as it should then a full re + evacuation calculation could be done. Note that while the FDS re simulations can use time dependent geometry elements, such as obstacles and holes, which are created and removed by special control devices, the evacuation geometry does not support the time dependent geometries. For evacuation, the initial geometry is always used for the whole duration of the simulation, but the user can give time dependent information on the usability of the doors for the door selection algorithm. For now, the number of agents placed in the same main evacuation mesh is limited. The programme stops and writes out an error message if more than 10 000 agents are tried to place on the same evacuation mesh. Usually, one main evacuation mesh extends over a whole oor of the building. Several main evacuation meshes may coexist, e.g., the different oors of the building, and the total number of agents is not restricted by the programme. The available computer memory is the only factor limiting the total number of agents. However, the calculation is going to be very CPU expensive if there are more than a few thousands agents in the same evacuation mesh. The initial density of agents cannot be much larger than 4 persons per square metre. In cases of high human density, the simulation may require a couple of initialisation trials, because the initial positions of agents are generated randomly. If FDS+Evac cannot place agents on their initial positions, an error message ERROR: FDS improperly set up. is printed on the standard error channel and more information is printed on the diagnostic output le of the evacuation calculation. FDS+Evac enables coupled re and evacuation simulations. The smoke and gas concentrations from the re calculation affect the movement and decision making of the evacuating humans. In principle, the coupling could also be made to the other direction,

10

1. Introduction

i.e., humans could inuence the re calculation, e.g., by opening doors, but this feature is not yet implemented in FDS+Evac. Gas phase concentrations of O2 , CO2 , and CO are used to calculate Pursers Fractional Effective Dose (FED) index [24], indicating the human incapacitation. Smoke density is used both to slow down the walking speeds of the agents and to affect the exit selection algorithm of the agents. Smoke density can also be used to speed up the detection the re, but it should be kept in mind that human nose is a very delicate instrument and the levels of smoke concentration needed for a smoke sensing may be below the accuracy of the current FDS predictions. Note that the effects of radiation and gas temperature on agents are not yet implemented in the programme, so agents do not try to avoid a re if the user does not explicitly dene the evacuation geometry to take this in to account. The evacuation part of the FDS+Evac is stochastic, i.e., it uses random numbers to generate the initial positions and properties of the agents. In addition, there is a small random force on each agents equation of motion. Thus, same results are not obtained for a given input le if multiple simulations are done. For this reason, one should always do a dozen or so egress simulations to see the variation of the results. To speed up this process, several egress calculation can be done per one re simulation and the calculation of the evacuation ow elds used to guide agent movement need to be calculated only once to each given geometry. The present version of FDS+Evac does not use computer memory optimally and does not fully support parallel CPU calculations for the evacuation part. In later versions of the programme, the memory usage will be optimised. Currently, an efcient use of the computer memory requires that the evacuation meshes are made as small as possible and as few obstacles as possible are placed in the calculation. For now, if FDS+Evac calculation takes too much memory, the user must increase the amount of available memory. This may require switching from a 32 bit to a 64 bit operating system, because the evacuation meshes can not be distributed over many different processors/computers unlike the FDS re meshes using the MPI version of the FDS executable.

1.3

Most recent changes

Below is a short description of the changes made to the different versions of FDS+Evac. For a full change log, the reader is asked to consult the Readme.txt le, which is on the FDS+Evac web page.

1.3.1

Most recent changes, version 2.1.1 vs 2.1.0

The namelist objects EXIT, DOOR, and ENTR have their XB tted to the underlying grid just like the ordinary geometric objects in FDS re calculation meshes, e.g., OBST and VENT namelists. Note, that the EVAC, EVHO, and EVSS namelists are not (yet) tted to the grid.

Figure 1. How to make an exit or a door.

1.3.2

Most recent changes, version 2.1.0 vs 2.0.0

The version 2.0.0 demanded that a door should be dened such that it is slightly inside a wall, see Figure 1. One had to dene a small hole in the wall, where an exit (or a door) was placed. This is not anymore necessary in version 2.1.0. The outow vent and the exit door can be placed directly at the wall surface. In the earlier versions of FDS+Evac (2.0.0 and earlier) it was assumed that all obstacles in the computational geometry were at least one grid cell thick, i.e., THICKEN=.TRUE. was forced on the evacuation meshes. Now this is not anymore forced, so one can use thin obstacles for the evacuation geometry, but the user should keep in mind that one can not place a VENT on a zero thick obstacle. The keywords AVATAR_RGB and/or AVATAR_COLOR are used to give the colour of the agents shown in Smokeview on the EVAC and ENTR namelists instead of the QUANTITY keyword. Similar change is done for the namelists DOOR and EXIT, where the keywords RGB and/or COLOR are now used to give the colouring information instead of the COLOR_INDEX keyword.

1.4

Intended Use of FDS+Evac

FDS+Evac is primarily a research tool for studying evacuation processes in buildings. While it seems to produce similar egress ows as found in the literature (both experimental and other simulation tools) it is not yet fully validated. Thus, its use as an engineering tool needs further considerations. It is suggested that FDS+Evac is used together with some other (well) validated egress programme to study evacuation. If the two (or more) methods give similar results then the predictions of the computational modelling should be quite good. It is not the purpose of this document to give instructions on how to dene the egress scenarios for the design purposes. Fire regulators and designers should agree on the relevant scenarios and acceptance criteria before any design by the engineering methods.

12

2. Model DocumentationThis chapter provides a short description of the evacuation module of the Fire Dynamics Simulator (FDS). Detailed information about FDS can be found in its documentation [1, 2, 3, 4] and more detailed information about the evacuation algorithm and its features can be found in the next chapters. Smokeview, the companion programme of FDS, is used to visualise the results of FDS and FDS+Evac calculations and information on its properties and how to use it can be found on its documentation [12].

2.1

Name and Development Environment

The underlying re simulation programme, Fire Dynamics Simulator (FDS), is a computational uid dynamics (CFD) model of re-driven uid ow. FDS is written using Fortran 90 programming language. The companion programme Smokeview, written in C/OpenGL programming languages, is used for graphical presentation of the simulation results. The evacuation calculation module developed at VTT Technical Research Centre of Finland (VTT) is implemented as subroutines of FDS and these subroutines together with the FDS are called as FDS+Evac. Since the version 5 of FDS, the program development and maintenance has utilised a version control system (SVN). The source code is maintained at a public domain server.1 Changes in the version numbers correspond to major changes in the physical models or input parameters. For minor changes and bug xes, incremental versions are released, referenced according to fractions of the integer version numbers. In addition, day-to-day bug xes made in response to user feedback are referenced by a compilation date and a SVN revision number that are printed at the top of the diagnostic output le. The latest ofcial release version of FDS is obtainable on the web site http://fire.nist.gov/fds/. The latest documentation on the evacuation part of FDS+Evac can be found on the web page http://www.vtt.fi/fdsevac/.

2.2

Type of the Model

FDS+Evac is a combined agent-based egress calculation model and a Computational Fluid Dynamics (CFD) model of re-driven uid ow, where the re and egress parts1

The server is hosted by Google Code (http://code.google.com/p/fds-smv/)

13

2. Model Documentation

are interacting. FDS+Evac can also be used just to calculate the egress problem without any re-driven uid ow calculation, e.g., it can be used to simulate re drills. FDS+Evac models the egress of the agents using continuous space and time, but the building geometry is tted to the underlying rectilinear mesh. FDS+Evac uses simple rules and articial intelligence to model the exit selection processes of the evacuees.

2.3

Model Developers

The evacuation module of FDS was developed and its currently maintained by the VTT Technical Research Centre of Finland. A substantial contribution to the implementation of the evacuation calculation as a module of FDS was made by the Fire Research Division in the Building and Fire Research Laboratory (BFRL) at the National Institute of Standards and Technology (NIST). Additional contributors and co-workers are cited in the Acknowledgements.

2.4

Relevant Publications

Each version of FDS+Evac is documented by this publication the FDS+Evac Technical Reference and Users Guide. The Users Guide part of the publication explains the mechanics of using the computer programme. The Technical Reference Guide part provides the theory and the details of the algorithms, plus a description of the verication and validation studies and details about the many parameters of the evacuation model and their default values. This section contains also a throughout study of the effects of the model parameters on the calculated egress ows. Note that the most up to date verication and validation results are on the FDS+Evac web page. This manual is not updated as frequently as the web page and the web page will contain more example cases than this manual. The model behind the movement algorithm of FDS+Evac was introduced by Helbings group [13, 14, 15, 16]. The implementation of this algorithm inside the FDS program environment was introduced by Korhonen et al. [5]. Later the model was modied along the lines given in the paper by Langston et al. [17] to a three circle representation of humans by Korhonen et al. [6, 7, 8, 9].

2.5

Input Data Required to Run the Model

All of the input parameters required by the evacuation part of FDS+Evac to describe a particular scenario are conveyed via one text le, which is the same one that is used for FDS, created by the user. For the re-driven uid ow related parameters, see the FDS documentation [2]. The input le of FDS+Evac is such that it can be used with just minor modications (commenting out the evacuation meshes) to run an ordinary FDS calculation without evacuation calculation. Same is true for the other way also, i.e., by commenting out the re meshes one can make easily test runs to see that the construction of the evacuation calculation part is done correctly.

14

2. Model Documentation

A complete description of the input parameters required by the evacuation module of FDS can be found in the Users Guide part of this document.

2.6

Model Results

FDS+Evac computes the position, the velocity, and the dose of toxic gases of each agent inside the computational domain at each discrete time step. The movement of agents can be visualised using the Smokeview programme [12]. The number of agents gone through different parts of the evacuation scenario as well as the number of agents in different evacuation nodes are saved in simple, comma-delimited text le, that can be plotted using a spreadsheet programme. Some additional, quite detailed, information are written to the diagnostic evacuation text le including the initial positions and properties of the agents.

2.7

Uses and Limitations

Although FDS+Evac can address many egress scenarios, there are limitations in all of its algorithms. The most prominent limitations are listed below. Geometry: The efciency of FDS is due to the simplicity of its rectilinear numerical mesh. This can be a limitation in some situations, where certain geometric features do not conform to the rectangular mesh. The numerical meshes used by the agent movement algorithm of FDS+Evac are two-dimensional cut-offs of the FDS re meshes, thus the same limitations apply to the evacuation part of the code. The present version of the evacuation module can also treat inclines, like wide stairs and spectator stands, which are along the x or y direction of the underlying rectangular mesh. The grid cell size determines the nest details of the building geometry, which can be modelled by the programme, e.g., the widths of the doors are integral multiples of the grid cell sizes. Reduced Visibility: The smoke concentration calculated by the FDS is used to slow down the walking speeds of the agents using the results of the experiment by Frantzich and Nilsson [25], where larger smoke concentrations were used than in the experiments by Jin [26]. The scatter of the experimental results is wide and new experimental results would be more than welcome. Note also that in reality there are differences between individuals in this respect, but the present version of the programme uses average values for each agent. The default model for stairs does not include the option for agents to turn back when the smoke concentration becomes too high. Incapacitation: The incapacitation model is the FED concept introduced by Purser [24], but the large scatter between different humans is not taken into account in the current version of the programme. Whereas FDS is doing well for the smoke transport and the prediction of O2 levels, it does much worse on the prediction of the CO concentration. In the standard mixture fraction model of FDS, the amount of CO produced is mainly decided by the user inputs. Note also, that the effect of HCN is not modelled and that the toxic effects of CO2 are not modelled; only its hyperventilation factor is included. Exit Route Selection: The exit door selection algorithm is still a relatively simple one. It does not include any kind of social interactions, like herding behaviour. The user has more or less full control on the doors which different agents will be using. In some applications

15

2. Model Documentation

this can be listed as a benet of the model, but the requirements for users responsibility and expertise should be recognised. Detection and Reaction Times: The pre-movement time of the evacuating humans is decided by the user input by giving distributions for the detection and reaction times. In addition to the detection time given user input, the local smoke concentration can be used to trigger the detection of a re. Currently, the re detection by agents can not be connected to the control logic of FDS, e.g. the smoke/heat detectors in FDS re calculation can not be used to trigger the movement of the agents. Applications: There is no model for elevators in the current version of the FDS+Evac. Nor there is any specic objects relevant to maritime applications. Concert halls and sport facilities may be difcult to model due to the limitations dictated by the rectangular computational mesh. There is limitation on the number of humans per evacuation mesh (usually one mesh per one oor). In the present version one oor can contain at most 10 000 humans. The present version of FDS+Evac supports parallel calculation only for the re meshes, the evacuation meshes are always treated as a single thread. Thus, it is not possible to divide the evacuation calculation to different processors using the parallel version of FDS5. This sets the upper limit on the complexity of geometry, which can be modelled due to the available computer RAM memory. Changing to a 64 bit operating system and downloading the 64 bit versions of the FDS executables the memory problems may be avoided.

16

3. Theoretical Basis for the Evacuation Model

3.1 Introduction

FDS+Evac treats each escaping person as an individual agent, whose movement is treated by an equation of motion. This approach allows each agent to have its own personal properties and escape strategies. Agents experience contact forces and moments as well as psychological and motive forces and moments. The resulting equations of motions for the translational and rotational degrees of freedom are solved using the methods of dissipative particle dynamics. Thus, the model uses continuous time and space to track the trajectories of the agents. FDS+Evac allows the modelling of high crowd density situations and the interaction between evacuation simulations and re simulations. Some social interactions among the agents are introduced in the model. A reaction function model is used to select the exit routes. Humans are modelled as agents, which are moving in a 2D geometries representing the oors of buildings. The size of each agent is represented by three circles approximating the shape of the human body, see Figure 2, just like in the Simulex programme [19, 21, 22, 23], in the MASSEgress programme [20], and in the CrowdDMX model [17, 18]. The body dimensions and the unimpeded moving speeds of the default population types in FDS+Evac are shown in Table 1. The body diameters and walking speeds are by default drawn randomly for each generated agent from uniform distributions, whose widths are also given in the table. The body diameter and moving speed distributions are taken to be same as in the Simulex programme for the Male, Female, Child, and Elderly categories. The category Adult is just a simple superposition of the Male and Female categories. The existing re simulation environment of FDS is used to minimise the programming effort to write an egress programme. For visualisation, the existing Smokeview programme [12] developed at NIST is used. Additional benet of using FDS as the platform of an egress model is the direct and easy access to the re related properties, like gas temperatures, smoke and gas densities, and radiation levels at each point in the computational grid. These quantities can be used to model the behaviour of evacuating humans. The integration of the evacuation calculation in to the re calculation would easily allow the evacuation calculation to change the ow of the re calculation, e.g., by allowing the evacuees to open or close doors and windows, but this is not yet possible with the present version of the FDS+Evac programme.

17

3. Theoretical Basis for the Evacuation Model

Rt Rd RsFigure 2. The shape of the human body is approximated by a combination of three overlapping circles. Shown are also the denitions of the body size variables.

3.2

Agent Movement Model

The method of Helbings group is used as the starting point of the agent movement algorithm of FDS+Evac, where a so-called social force is introduced to keep reasonable distances to walls and other agents, see Figure 3. This model is shortly described below. For a longer description, see the papers by Helbings group [13, 14, 15, 16] and references therein. For the modication of the one-circle representation of an agent to a three-circle one, see the papers by Langston et al. [17] and Korhonen et al. [6, 7, 8, 9]. FDS+Evac uses the laws of mechanics to follow the trajectories of the agents during the calculation. Each agent follows its own equation of motion: mi d2 xi (t) = fi (t) + i (t) , dt2 (1)

where xi (t) is the position of the agent i at time t, fi (t) is the force exerted on the agent by the surroundings, mi is the mass, and the last term, i (t), is a small random uctuation force. The velocity of the agent, vi (t), is given by dxi /dt. FDS+Evac treats agents as combination of three circles moving on a two-dimensional plane [17]. These circles are approximating the elliptical shape of the human body, see Figure 2. The default body dimensions and the unimpeded walking speeds of different predened agent types of FDS+Evac are listed in Table 1. Note, that FDS+Evac uses stochastic properties for theTable 1. Unimpeded walking velocities and body dimensions in FDS+Evac. The offset of shoulder circles is given by ds = Rd Rs , for the denition of the other body size variables, Rd , Rt , Rs , see Figure 2. The body sizes and walking velocities of the agents are personalised by using them from uniform distributions, whose rages are also given.

where the rst sum describes agentagent interactions, the sum over w describes agent att wall interactions, and the terms in the last sum, fik , may be used for other agent environment interactions, like the reagent repulsion. The rst term on the right hand side describes the motive force on the evacuating agent. Each agent tries to walk with 0 0 its own specic walking speed, vi = |vi |, towards an exit or some other target, whose 0 . The relaxation time parameter i sets direction is given by the direction of the eld vi the strength of the motive force, which makes an agent to accelerate towards the preferred walking speed. The agentagent interaction force in Eq. 2 has three parts. For the social force term, soc fij , the anisotropic formula proposed by Helbing et al. [15] is usedsoc fij = Ai e(rij dij )/Bi i + (1 i )

1 + cos ij 2

nij ,

(3)

where rij is the distance between the centres of the circles describing the agents, dij is the sum of the radii of the circles, and the vector nij is the unit vector pointing from the agent j to i. For a three circle representation of agents, the circles used in Eq. 3 are those circles of the two agents, which are closest to each other. The angle ij is the angle between the direction of the motion of the agent i feeling the force and the direction to the agent j , which is exerting the repulsive force on the agent i. The parameters Ai and Bi describe the strength and spatial extent of the force, respectively. The parameter i controls the anisotropy of the social force. If i = 1, then the force is symmetric and if it is 0 < i < 1, the force is larger in front of an agent than behind. The psychological soc wallagent interaction, fij , is treated similarly, but values Aw , Bw , and w are used for the force constants. c The physical contact force between the agents, fij , is given byc n t tij , fij = kij (dij rij ) + cd vij nij + ij (dij rij )vij

(4)

19

3. Theoretical Basis for the Evacuation Model

soc

Rc f soc fc

Figure 4. Denitions of the radial vectors Rc and Rsoc .

t n where vij is the difference of the tangential velocities of the circles in contact, vij is the difference of their normal velocities, and vector tij is the unit tangential vector of the contacting circles. This force applies only when the circles are in contact, i.e., dij rij 0. The radial elastic force strength is given by the force constant kij and the strength of the frictional force by the force constant ij . Note, that Eq. 4 contains also a physical damping force with a damping parameter cd that was added by Langston et al. [17]. The original model by Helbing et al. did not have this force. This parameter reects the fact that the collision of two humans is not an elastic one. The physical wall c agent interaction, fiw , is treated similarly and same force constants are used. att The term fij can be used to describe attraction (or repulsion) between agents, like a herding behaviour or an adultchildren interaction. It could also be used to form pairs of agents, e.g., describing a re ghter pair entering the building. All of the force terms in Eq. 2 are relatively short ranged and they need a line-of-sight connection. Longer ranged 0 forces could be taken in to account by changing the preferred walking velocity eld vi of the agent. Equations 14 describe the translational degrees of freedom of the evacuating agents. The rotational degrees of freedom are treated similarly, i.e., each agent has its own rotational equation of motion:

Iiz

d2 i (t) z = Miz (t) + i (t) , dt2

(5)

z where i (t) is the angle of the agent i at time t, Iiz is the moment of inertia, i (t), is a z small random uctuation torque, and Mi (t) is the total torque exerted on the agent by its surroundings Miz = Mic + Misoc + Mi , (6)

where Mic , Misoc , and Mi are the torques of the contact, social, and motive forces, respectively. The torque of the contact forces is calculated as Mc i =j =i c Rc i fij ,

(7)

where Rc i is the radial vector, which points from the centre of the agent i to the point of contact, see Figure 4. In FDS+Evac, also the social forces exert torques on the agents and

20

3. Theoretical Basis for the Evacuation Model

these are given by the formula Msoc = i

j =i soc Rsoc , i fij

(8)

where only the circles, which are closest to each other, are considered. The vector Rsoc i points from the centre of the agent i to the ctitious contact point of the social force, see Figure 4. Analogous to the motive force, the rst term on the right hand side of Eq. 2, a motive torque is dened as Mi = Iiz 0 Iiz 0 0 ( ( t ) ) ( t ) = (t) , i i iz iz i (9)

where 0 is the maximum target angular velocity of a turning agent, (t) the current angular velocity, i (t) the current body angle, and 0 i is the target angle, i.e., where the 0 0 vector vi is pointing. The target angular speed, i , dened in Eq. 9 is larger when the body angle differs much from the desired movement direction. Langston et al. [17] used a different formula for the motive torque, which had a form of a spring force. During this work, it was noticed that a force like that will make agents to rotate around their axis like harmonic oscillators and, thus, some angular velocity dependent torque should be used. In FDS+Evac method, agents are guided to exit doors by the preferred walking direction 0 , and this eld is obtained using the ow solver of the FDS. This vector eld vector eld, vi is obtained as an approximate solution to a potential ow problem of a two-dimensional incompressible uid to the given boundary conditions, where all walls are inert and the chosen exit door acts as a fan, which extracts uid out of the domain. This method, or rather a trick, produces a nice directional eld for egress towards the chosen exit door, see Figure 5. A eld of this kind will always guide agents to the chosen exit door. This route will not be the shortest one, but usually it is quite close to it. This eld will guide more agents to the wider escape routes than on the narrower ones due to the fact that the eld is a solution to an incompressible ow. The analogy to an incompressible uid ow is not a bad starting point to nd the movement directions of large human crowds. For example, when humans are leaving a large sports or entertainment event, they usually just follow the egress ow to the outside of the building without much control on the process. The agent movement method presented in Eqs. 19 has many parameters. Some of these parameters are related to physical dimensions of humans, like mi and Iiz , but many parameters are related to the chosen model. Some of these parameters are chosen to be the same as found in the literature [14, 17] and some are estimated from test calculations. The parameters of the social force were chosen such that the specic ows through doors and corridors were appropriate. The parameters of the contact forces and the rotational degrees of freedom for the three circle representation of the agents were selected mainly by trial and error in order to obtain reasonably realistic looking movement. Monte Carlo simulations were done to see, which are the most important model parameters and further analysis was focused on those parameters. The rst choice for the social force parameters of the agentagent interaction was Ai = 2000 N, Bi = 0.04 m, and i = 0.5. For the agentwall interaction values

21

3. Theoretical Basis for the Evacuation Model

Figure 5. A 2D ow eld used to guide agents to the exit doors. In this case, only the left exit has an outow boundary condition, i.e., this ctitious agent ow eld is used to nd the left exit only. The main evacuation mesh should also have an outow boundary at the top exit.

Aw = 2000 N, Bw = 0.08 m, and w = 0.2 were used. It was noticed that these values are not good for congested situations if three circles are used to describe the human body. These parameters were modied such that the interaction strength parameter A was made 0 velocity dependent, A(vi ) = 2000 Max(0.5, vi /vi ) N. For the contact force parameters, values kij = 12 104 kg m-2 , ij = 4 104 kg s-1 m-1 , and cd = 500 kg s-1 are used both for the agentagent and for the agentwall interactions. Note that in Eq. 4 the effective elastic constant between two agents is calculated as kij = (ki kj )/(ki + kj ), where ki and ki are the elastic constants of the agents, i.e., if the agents have same elastic constants then ki = 2kij . The friction coefcient between two agents is simply assumed to be independent of the agents in contact, ij = i . The mass of a default male agent is mi = 80 kg and its moment of inertia was chosen to be Iiz = 4.0 kg m2 . For other agents, the mass and the moment of inertia are obtained by scaling. For the angular relaxation time parameter, z , a value of 0.2 s is used. The angular velocity parameter 0 has a value of 4 s-1 , i.e., two rounds per second. The random force in Eq. 1 is taken to be a truncated Gaussian with mean zero, standard deviation of i /mi = 0.1 m s-2 , and it is truncated at three times of the standard deviation. The random z torque in Eq. 5 is treated similarly and its standard deviation is i /Iiz = 0.1 s-2 . In principle, all the above parameters may be dependent on the person in question. But in FDS+Evac, only the body sizes, walking velocities, and the motive force parameter i are personalised by choosing them from random distributions. A uniform distribution ranging from 0.8 s to 1.2 s is used for i and the used uniform distributions for the body dimensions and for the unimpeded walking speeds are shown in Table 1.

3.3

Fire and Human Interaction

By using FDS as the platform of the evacuation calculation we have direct and easy access to all local re related properties, like gas temperature, smoke and gas densities, and

22

3. Theoretical Basis for the Evacuation Model

radiation levels. Fire inuences evacuation conditions; it may incapacitate humans and in extreme cases block major exit routes. On the other hand, humans may inuence the re by opening doors or actuating various re protection devices. For now, the effect of smoke on the movement speeds of agents and the toxic inuence of the smoke are implemented in movement algorithm of FDS+Evac. The exit selection algorithm of the agents uses smoke density to calculate the visibility of the exit doors and to categorise the doors to different preference groups. Smoke reduces the walking speed of humans due to the reduced visibility, its irritating and asphyxiant effects. Recently, Frantzich and Nilsson [25] made experiments on the effect of smoke concentration on the walking speeds of humans. They used larger smoke concentrations than Jin [26] and they tted the following formula to the experimental values 0 vi 0 0 ( + Ks ) , (10) vi (Ks ) = Max vi, , min where Ks is the extinction coefcient ([Ks ] = m-1 ) and the values of the coefcients and are 0.706 m s-1 and -0.057 m2 s-1 , respectively. The minimum walking speed of 0 0 an agent is vi, min = 0.1 vi , i.e., the agents are not stopping due to a thick smoke, they continue to move with a slow speed until they are incapacitated by the toxic effects of the re products. The standard deviations are reported to be = 0.069 m s-1 and = 0.015 m2 s-1 , but only the mean values are used in FDS+Evac, i.e., there is no variation between the agents. The toxic effects of gaseous re products are treated by using Pursers Fractional Effective Dose (FED) concept [24]. The present version of FDS+Evac uses only the concentrations of the narcotic gases CO, CO2 , and O2 to calculate the FED value FEDtot = FEDCO HVCO2 + FEDO2 (11)

Note, that the above equation does not contain the effect of HCN, which is also narcotic, and the effect of CO2 is only due to the hyperventilation, i.e., it is assumed that the concentration of CO2 is such low that it does not have narcotic effects. Carbon dioxide does not have toxic effects at concentrations of up to 5 per cent, but it stimulates breathing which increases the rate at which the other re products are taken up. The fraction of an incapacitating dose of CO is calculated as FEDCO = 4.607 107 (CCO )1.036 t , (12)

where t is time in seconds and CCO is the CO concentration (ppm). The fraction of an incapacitating dose of low O2 hypoxia is calculated as FEDO2 = t , 60 exp [8.13 0.54(20.9 CO2 )] (13)

where t is time in seconds and CO2 is the O2 concentration (volume per cent). The carbon dioxide induced hyperventilation factor is calculated as HVCO2 = exp(0.1930 CCO2 + 2.0004) , 7.1 (14)

23

3. Theoretical Basis for the Evacuation Model

where CCO2 is the CO2 concentration (percent). An agent is considered to be incapacitated when the FED value exceeds unity. An incapacitated agent is modelled as an agent, which does not experience any social forces 0 from the other agents and walls and whose target movement speed, vi , is set to zero. The size of an incapacitated agent is not changed, i.e., it remains on its feet. This is a very crude model and it needs to be modied in later versions of FDS+Evac.

3.4

Exit Selection

FDS+Evac uses game theoretic reaction functions and best response dynamics to model the exit route selection of evacuees [34, 27]. In the model, each evacuee observes the locations and actions of the other evacuees and selects the exit through which the evacuation is estimated to be the fastest. Thus, the exit selection is modelled as an optimisation problem, where each evacuee tries to select the exit that minimises the evacuation time. The estimated evacuation time consists of the estimated time of walking and the estimated time of queueing. The walking time is estimated by dividing the distance to the exit by the walking speed. The estimated time of queueing is a function of the actions and locations of the other evacuees. It is also assumed that people change their course of action only if there is an alternative that is clearly better than the current choice. This behaviour is taken into account by subtracting a parameter from the estimated evacuation time of the exit currently chosen. Note, that the present implementation of the exit selection algorithm of FDS+Evac does not include all aspects of the method ideally and there are some quite crude approximation made, see Sec. 3.6 for details. Apart from the locations of exits and the actions of other agents, there are also other factors that inuence the decision making process of an agent. These factors are the conditions related to the re, the familiarity of the agent with the exits and the visibility of the exits. The effect of these factors is taken into account by adding constraints to the evacuation time minimisation problem. According to the three factors mentioned, the exits are divided to seven groups so that each exits will belong to one group. The groups are given an order of preference. The familiarity of each exit for each agent can be determined by the user in the inputle of FDS+Evac. It is also possible to give a probability for the familiarity of an exit, and FDS+Evac will randomly set the familiarity of the exit. FDS+Evac determines the visibility of an exit to an agent by taking into account the blocking effect of smoke and obstacles. The possible blocking effect of other agents is not considered in the current version of the programme. The existence of disturbing conditions is estimated from the re-related data of FDS on the visible part of the route to the exit. By disturbing conditions we mean conditions, like temperature and smoke, that disturb an evacuee but are not lethal. If there are lethal conditions on an exit route, the exit has no preference. Here also some approximation are made, see Sec. 3.6 for details. The exit selection algorithm consists of the above described two phases. First the exits are divided to the preference groups according to Table 2. Then, an exit is selected from the most preferred nonempty preference group by minimising the estimated evacuation time.

24

3. Theoretical Basis for the Evacuation Model

According to socio-psychological literature [20, 28], the familiarity of exit routes is an essential factor inuencing decision making. This is because the unknown factors related to unknown routes are considered to increase the threat. As a result, evacuees prefer familiar exit routes even if there are faster unfamiliar routes available. For this reason, emergency exits are used rarely in evacuations and re drills.

3.5

Groups

According to socio-psychological literature, a crowd consists of small groups, like families, that tend to act together [20, 35]. This behaviour should be taken into account when building evacuation models. A method for modelling this grouping behaviour with the equations of Helbing was developed [34]. In the model, the actions of a group are divided into two stages: 1. In the gathering stage the group members walk towards each other to gather the group. 2. In the egress stage the group moves together along the selected exit route. These two stages are modelled by altering the preferred walking direction eld of Helbings equation of motion. In the gathering stage the pedestrians are trying to move towards the centre of the group. When the distances from the centre to each pedestrian are under a threshold value, the group is considered to be complete. When a group is complete, it starts to move towards an exit. This means that each group member is set to follow the same ow eld. While moving towards an exit, the group members also try to keep the group together. This is modelled by adjusting the walking speeds and by adding an additional force that points to the centre of the group. This force is called as the group force. The magnitude of the group force describes how eagerly the group members try to keep the group together. It can be given different values for different kinds of groups. ForTable 2. Preference order used in the exit selection algorithm. The last two rows have no preference. This is because the agents are unaware of the exits that are unfamiliar and invisible and, thus, can not select these exits. The last column shows the colours used in Smokeview to show the status of the agents.

Preference 1 2 3 4 5 6 No preference No preference

Visible yes no yes yes no yes no no

Familiar yes yes no yes yes no no no

Disturbing conditions no no no yes yes yes no yes

black yellow blue red green magenta cyan cyan

25

3. Theoretical Basis for the Evacuation Model

example, a group consisting of a mother and a child should have a larger group force than a group of work mates. The group-model is not yet available in FDS, but it will be added to later versions of the programme. The model has been programmed to a test-version and the results are promising, but quantitative effects of the model are yet to be analysed.

3.6

Numerical Method

The translational and rotational equations of motion are solved using a modied velocityVerlet algorithm, where the translational motive force part is solved using a self-consistent dissipative velocity-Verlet algorithm [30] and the other parts are solved using the standard velocity-Verlet algorithm, which can be found in any basic textbooks on molecular dynamics simulations. The time step used in the algorithm is adjusted during the simulations by the maximum forces exerted on agents. The minimum time step varies between 0.01 and 0.001 seconds, by default. The estimated evacuation time used in the exit door selection algorithm is approximated in the present version of FDS+Evac simply by dividing the distance to the door by the unimpeded walking velocity of the person. The distance to a door is calculated along a bee line both for the visible and non-visible doors. The distance should be calculated along the exit path and also an estimated queueing time at the door should be added to the estimated evacuation time, but this is not yet implemented in the model. Agents are updating their target exit doors on every second, on the average. The smoke density calculated by the FDS re simulation can be used to detect a re. By default, smoke density is not used for detection. User gives as inputs a detection time (distribution) and a reaction time (distribution) for the evacuating agents. If smoke is used to detect re then user should give the detection threshold concentration (mg/m3 ). An agent detects a re when the smoke concentration reaches its threshold value at the position of the agent or if the user given detection time has been reached. The smoke or toxic gas concentrations affect the exit door selection algorithm. By default, toxic gas concentrations are used (CO, CO2 , O2 ): a door is smoke free if the estimated value of FED less than 0.000001. A door is usable (and visible) as long as the estimated FED value is less than unity. If smoke concentration is used then the user gives the threshold visibility value for a door to be smoke free. A door is usable as long as visibility is larger than half the distance to the door, where local visibility = 3/extinction coefcient. If there is no line-of-sight to the door, then local concentrations at the position of the agent are used and the distance to the door is calculated along a bee line (this is a crude approximation but fast to compute).

26

4. Testing and Verication

4.1 Introduction

In the verication test cases the default parameter values of FDS+Evac for the different predened agent types were used unless otherwise stated. In many cases the simulation runs were also done using a value of 0.3 for the anisotropy parameter of the social force instead of the default value of 0.5. An archive of the verication tests of FDS+Evac are at the FDS+Evac web pages. This manual contains only a short summary of these test and it might not be up to date, so more interested reader should visit the web pages to get the most recent information. Note, that most of the results reported below are just based on one FDS+Evac simulation per each scenario. FDS+Evac is a stochastic modelling programme, i.e., it uses stochastic distributions to generate the initial positions of the agents and their properties. There are also small random forces and torques in the equations of motion. For the qualitative verication, however, it is enough just to run the model once for each scenario. Same is true for the numerical verication of some of the sub-models. Some of the qualitative verication cases of the agent movement algorithm are based on the IMO document Interim Guidelines for Evacuation Analyses for New and Existing Passenger Ships [29], where eleven different test cases are listed. These tests are referred below as IMO 1 etc. Note, that the IMO document species the test persons to be 3050 years old males dened in the IMO document [29]. This person group is similar to the default Male of FDS+Evac but the unimpeded walking velocities are generated from an uniform distribution between 0.971.62 m/s. If the test case in question is a IMO test case, then the reference to a Male person type is the default Male of FDS+Evac, but with different walking speed. The tests suggested by IMO do not include any quantitative verication, because IMO sees that At this stage of development there is insufcient reliable experimental data to allow a through quantitative verication of egress models. Until such data becomes available the rst three components of the verication process (component testing, functional verication, qualitative verication) are considered sufcient.

27

4. Testing and Verication

4.2

Component Testing

The movement algorithm of FDS+Evac was tested rst using some simple geometries to show that the agents do not walk through walls and that their speed is correct and they move towards the exit doors, which the user has specied in the input. These simulations were done in an evacuation trial mode, i.e., there was no smoke or re calculation present in the simulations. The effect of smoke on the moving speeds of the agents and the calculation of the FED were tested separately. An interested reader could download the input les of the test simulations from the FDS+Evac web pages and rerun the cases. This is especially true for some IMO verication cases, where the results can not be checked as numbers but one should see by own eyes that the programme is working as it should. 1. IMO 1: Maintaining set walking speed in corridor: One person with a walking speed of 1.0 m/s should walk a 40 m distance in 40 s. FDS+Evac passed the test. 2. IMO 2: Maintaining set walking speed up staircase: One person with a walking speed of 1.0 m/s should walk a 10 m distance in 10 s. FDS+Evac passed the test. Both existing models for staircases (&CORR and &EVSS namelists in the input) were used. 3. IMO 3: Maintaining set walking speed down staircase: One person with a walking speed of 1.0 m/s should walk a 10 m distance in 10 s. FDS+Evac passed the test. This test is actually the same as the test number IMO 2, because the staircase algorithm of FDS+Evac is the same for up and down, only the user input for the speed reduction factors species it the agent is going up or down the stairs. 4. IMO 4: Exit ow rate: 100 persons in a room with a 1.0 m exit, the ow rate should not exceed 1.33 p/s. FDS+Evac passed the test, if an Male with the parameter value i = 0.3 is used (1.21 p/s). If the default male (i = 0.5) is used then the ow is somewhat larger, 1.43 p/s. The default for this parameter is 0.5. See also the door ow test case in Sec. 6.3. It should be noted that larger specic ows through doors than 1.33 p/s/m are obtained if a wider door is used even for the case i = 0.3. 5. IMO 5: Response time: Verify that the humans start to walk according to a given uniform reaction time distribution. FDS+Evac passed the test. FDS+Evac prints out the main properties of the agents, including their response and detection times, unimpeded walking velocities, main body diameters, motive force time constants i , and the initial positions. 6. IMO 6: Rounding corners: Persons approaching a corner will successfully navigate around the corner without penetrating the boundaries. FDS+Evac passed the test. The social force model used for the movement of the agents does not allow the agents to go inside walls if the time step is small enough as it is in FDS+Evac for reasonable values of the model parameters.

28

4. Testing and Verication

1.0 FED, FDS+Evac Fractional Effective Dose 0.8 FED, Spreadsheet

0.6

0.4

0.2

0.0 0 30 60 Time (s) 90

Figure 6. A FED test.

7. IMO 7: Assignment of population demographics parameters: Distribute the walking speeds over a population of 50 people and show that the walking speeds are consistent with the distribution specied in the input. FDS+Evac passed the test, see the test number IMO 5 above. 8. FED calculation: To test the implementation of Fractional Effective Dose (FED) concept [24] a simple one room geometry with a re source and one agent in the middle of the room is used. The agent is xed at its initial position by putting the detection time large and setting random noise of the movement equations to zero. FDS point measurements of the gas densities are placed at the position of the agent. The FDS+Evac output for the value of the maximum FED among the agents is compared to a value computed using an external worksheet and the FDS point measurements for gas densities. The results of the comparison are shown in Figure 6. The results indicate that the FED calculation in FDS+Evac is implemented correctly. 9. Unimpeded walking speed vs smoke density: Smoke reduces the walking speed due to the reduced visibility. The prediction of this effect is tested in a long corridor geometry. The source code of FDS+Evac was modied a little bit for this test. The evacuation calculation did not use the smoke densities calculated by FDS but an articial smoke density history with stepwise behaviour was introduced: soot density was increased by an amount of 114.9 mg/m3 on every 10 seconds. The length of the simulation was 100 s and the unimpeded walking velocity for a smoke clear environment was set to 1.0 m/s. The result of this test is shown in Figure 7. In the gure, the line labelled as Theory is the experimental correlation given in Eq. 10. The velocities of the agents in FDS+Evac simulations were calculated using 8 s periods, like 22 s 30 s, because an agent needs a little bit time to adjust its speed (the inertia of mass) when the smoke density is changed. The results show that FDS+Evac accurately reproduces the anticipated reduction of walking speed.

29

4. Testing and Verication

Extinction coefficient (1/m) 4 6 8 10

0 1.2 1.0 Velocity (m/s) 0.8 0.6 0.4 0.2 0.0 0

12

Theory FDS+Evac

500

10003

1500

Soot density (mg/m )

Figure 7. A smoke vs speed test.

4.3

Functional Verication

For the functional verication required by IMO, a good technical documentation should be enough. The manual should set out in a comprehensible manner the complete range of model capabilities and inherent assumptions and give a guide to the correct use of the capabilities. It is left to the reader to decide if this manual together with the FDS+Evac web pages satises this criterion.

4.4

Qualitative Verication

The qualitative features of FDS+Evac were tested using some simple geometries to show that the agents behave like they are told in the input and that their movement is qualitatively correct. Most of these simulations were done in an evacuation trial mode, i.e., there was no smoke or re calculation present in the simulations. The effect of smoke and toxic gases on the decision making processes of the agents were tested separately. An interested reader could download the input les of the test simulations from the FDS+Evac web pages and rerun the cases. This is especially true for some cases, where the results can not be checked as numbers but one should see by own eyes that the program is working as it should. 1. IMO 8: Counterow two rooms connected via a corridor: Two 1010 m2 rooms are connected with a 10m long and 2 m wide corridor. Initially there are 100 persons in the room 1 and the room 2 has 0, 10, 50, 100 persons and both rooms move off simultaneously. The expected result is that the time the last person from the room 1 enters the room 2 increases as the number of persons in counterow increases. FDS+Evac results were 41 s and 305 s for the cases, where there were 0 and 10 persons in the room 2, respectively. The case, where there were 50 persons in the room 2, resulted a very slow movement towards the room 2 and the simulation was not run until the end. If there were 100 persons in the room 2 then there were

30

4. Testing and Verication

practically no movement in the corridor, i.e., a total jam was formed. This is due to the fact that the human density in the corridor is high and the default parameters describe agents that are competitive. 2. IMO 9: Exit ow crowd dissipation from a large public room: A 3020 m2 public room with four 1.0 m wide exits has 1000 persons. Calculate the time the last person leaves the room. Close two doors and repeat the calculation. The expected result is an approximate doubling of the time to empty the room. FDS+Evac passed the test. The total evacuation times calculated using the default person properties were 189 s and 361 s when all four doors were open and when two doors were closed, respectively. These times were 246 s and 455 s when the parameter value i is changed from the default, which is 0.5, to 0.3. Note that the ows through the 1.0 m doors were below 1.33 p/s when an Male with the parameter value i = 0.3 is used (1.08 and 1.13 p/s for the cases all doors open and two doors open, respectively). The default for this parameter is 0.5 and then ows through the doors are slightly larger. See also the door ow test case in Sec. 6.3. 3. IMO 10: Exit route allocation: Populate a cabin corridor section with 23 persons and allocate the main exit for 15 persons and the secondary exit for 8 persons. The expected result is that the allocated passengers move to the appropriate exits. FDS+Evac passed the test. Note that this geometry needed some more effort to model, see the FDS+Evac input le on the FDS+Evac web pages for more information. This is due to the fact that in order to model the test geometry rigorously the mesh cell sizes for the evacuation calculation meshes were 0.1 m in both the x and y directions. This is a little bit too ne mesh to construct the guiding oor ow elds for evacuation. This problem does not arise if one is modelling the cabinets to have closed doors and enters the agents in to the calculation at the cabin doors. 4. IMO 11: Staircase: A room populated with 150 persons is connected to a 2.0 m wide and 12 m long corridor which ends to a 2.0 m wide stairs going upwards. The expected result is that congestion appears at the exit from the room, which produces a steady ow in the corridor with the formation of congestion at the base of the stairs. FDS+Evac passed the test, if the user is giving reasonable input parameters for the denition of the staircase. Both models for staircases (the &CORR and &EVSS namelists in the input) were used. 5. Decision making model without smoke: The verication of the exit door selection algorithm of FDS+Evac was tested using the geometry shown in Figure 8. The gure on the left shows the target exit doors for the agents (blue: right bottom exit; green: top left exit) and in the gure on the right the colours of the agents mark the preference categories of the exit door selection algorithm (black: known visible door; yellow: known non visible door). This test case has no smoke and as a result, agents use only the known doors (top left and bottom right ones). The doors on the left and right walls are not used, because they are not dened as known doors

31

4. Testing and Verication

Figure 8. An exit door selection test without smoke. On the left, agents are coloured according to their exit doors. On the right, they are coloured according to their current preference categories.

in the input. Figure 8 veries that the door selection algorithm works as intended when there is no smoke. The agents rst choose the nearest visible known door, if such exists. If there are no visible doors, the agents choose the nearest non visible but known door; see the agents in the bottom left corner of the building. Note however, that in the present version of FDS+Evac, the distance to the non visible doors is calculated along a straight line through the internal walls. In later versions, the algorithm may be changed to calculate the distance along the streamlines used to guide the agents towards the doors. 6. Decision making model with smoke: The above test was modied by adding a re that produces smoke to the building. Figure 9 shows the visibility at the height of the human eyes at 10 s from the ignition. The door selections and preference categories at the same time are shown in Figure 10. Now the smokiness has changed the

Figure 9. The visibility at 10 s in the test case. Red and blue colours indicate good and very bad visibilities, respectively.

32

4. Testing and Verication

xFigure 10. An exit door selection test with smoke. On the left, agents are coloured according to their exit doors. On the right, they are coloured according to their current preference categories.

preferences. First choices are still the doors with no smoke. The input les for the exit selection tests are on the FDS+Evac web page an interested reader is able to rerun the simulations and use Smokeview to see that the door selection algorithm is functioning like intended.

4.5

Numerical Tests

The numerical accuracy of the model depends on the time step used to solve the equations of motion of the agents. The time step was chosen mainly by trial-and-error. There are some convergence checks made, see the paper by Korhonen et al. [9].

33

5. Model Sensitivity5.1 Introduction

This section concentrates on the effects of different input parameters on the FDS+Evac results. Especially the ows through doors, corridors and stairs are examined, because these are usually the main bottlenecks of an evacuation of a building. This section does not address the point if the chosen algorithms, numerical methods, etc. are appropriate for the evacuation simulation or not. Only the sensitivity of the chosen algorithms and numerical methods are examined and reported. The tests presented here are done in a re drill mode, i.e., the egress process is simulated without any re calculation.

5.2

Numerical Mesh Sensitivity

In principle, the movement algorithm of the agents described in Sec. 3 does not have any underlying computational mesh. The algorithm is continuous in time and space. But the implementation of the method in FDS+Evac introduces computational meshes. These meshes are used to dene the geometry of the calculation. The most obvious mesh sensitivity issue is that the resolution for the obstructions, like doors, stairs, etc., is the mesh resolution. The other, subtler effect, is the way how the mesh resolution changes the evacuation ow elds used to guide agents to the exit doors. In some cases, a ner grid does not always mean a better guiding eld for agents. If the evacuation mesh resolution is much less than the half of the body dimension then one may nd some difculties to obtain nice evacuation ow elds, see the IMO test case 10 in Sec. 4.4. The FDS re calculation mesh has effects on the evacuation calculation via the smoke, toxic gas, temperature, and radiation level calculation. These quantities are taken to have constant values in the evacuation mesh cells. How accurate are the predictions of FDS for the re products will, of course, depend on the FDS mesh resolution. See the FDS Technical Guide [1], and the verication and validation guides [3, 4] for the effects of the mesh resolution on the FDS re calculation. The evacuation calculation interpolates the re calculation results to the 2D evacuation meshes and the evacuation mesh resolution will have an effect on the spatial accuracy of this re related information, but usually grid sizes are equal or less than the dimensions of a human body and, thus, the accuracy of

Figure 11. Test geometries used to calculate the specic ows through doors and corridors.

the re information in the evacuation meshes is ne enough for the accuracy level of the evacuation calculation. There are many more factors affecting the calculation of the re agent interaction more than the spatial resolution of the evacuation and re meshes, e.g., the production of CO and other toxic gases depend largely on the user inputs.

5.3

Human Parameter Sensitivity

The agent movement algorithm of FDS+Evac has many parameters. Some of these are related to the physical description of humans, like the body size, the mass, the walking speed, and the moment of inertia. The others are the parameters of the chosen movement 0 , the parameters of the social force, Ai , Bi , i , and the parameters of model, i , iz , i the contact force, ki , i , cd . To test the relative importance of these parameters, Monte Carlo simulations were performed to nd the parameters, which have the greatest effect on specic ows. The calculations were done using Evac version 2.0.0, but the basic movement algorithm has not changed for version 2.1.1, so there is no need to recalculate these simulations. Two different geometries were used in the Monte Carlo simulations, see Figure 11. One of the geometries was used to study the ow through a narrow door and through a wide door and the other geometry was used to study ows in a corridor using densities 1.0 and 2.0 persons per square metre. There were 100 agents randomly located at the 5 5 m2 square in the door ow calculations. Corridor ow calculations had 96 or 192 agents inside the corridor depending on the density. Thousand egress simulation with different random initial properties were performed for each of these four different cases. The default Adult agent type of FDS+Evac was used in the calculations, but in total 0 0 eleven model parameters, Ai , Bi , i , vi , i , Aw , Bw , w , i , iz , and Iiz were varied 20 % about their means using uniform distributions. The monitored output quantity was the specic ow in all cases and the Spearmans rank correlation coefcients (RCC) were calculated for these four cases and they are shown in Figure 12. 0 It is seen from Figure 12 that the parameters Ai , Bi , i , vi , i , and Bw have the largest impact on the specic ows through doors and corridors. Thus, further simulations were

-0.2 0.0 0.2 0.4 0.6 Rank Correlation Coefficient

-0.15 -0.10 -0.05 0.00 0.05 Rank Correlation Coefficient

Figure 12. Rank correlation coefcients (RCC) for specic ows through doors and corridors. Widths 0.8 m and 2.0 m were used for doors and human densities 1.0 m-2 and 2.0 m-2 were used for corridors.

done to quantify these effects. Each of these six parameters were varied separately and 100 simulations were done for each discretely chosen value of the parameters. Two different door widths, 1.0 m and 2.0 m, were chosen to represent a narrow and a wide door. Corridor ow was calculated using a density of 2.0 persons per square metre, because it is known that around this density the specic ow has its maximum value. For the density 1. 0 persons per square metre the corridor ow is mainly specied by the used distribution for the unimpeded walking speeds, because at this density the agents can move relatively independently of each others in the corridor. The results of these, in total almost 20 000 simulations, are shown in Figure 13, where the markers represent the average of 100 simulations and standard deviations are shown as error bars. Note that in FDS+Evac the initial properties and positions of the agents are not deterministic, because agents are randomly positioned, the parameters Rd , v 0 , and i , are sampled from random distributions and there are small random forces in Eqs. 1 and 5. Increasing the values of Ai and Bi increases the social force which tries to keep agents apart from each other and, thus, the specic ow for door geometry will decrease. The corridor case has a constant agent density. Thus, these two parameters can not have an effect through the density. Larger social force, i.e., larger A and/or B , will make a forward walking person to reduce his/her speed in order not to step on someones heels, when the anisotropy parameter, i , is less than unity. Increasing the walking velocity will, of course, increase the specic ow. Decreasing i , i.e., increasing the motive force to go forward, increases specic ows quite rapidly for the door geometry. This effect is not as pronounced in the corridor case, because there is no free space in front of the agents to accelerate and also the agents are already moving with some velocity whereas they are almost standing and waiting their turn in front of the door. The anisotropy parameter of the social force, i , controls how eager agents are to push those who are in front of them. When i is large then agents are pushy. The effect of the wall force parameter Bw is to modify the effective width of doors and corridors, thus, increasing its value will make the effective width smaller and this will decrease specic ows slightly.

36

5. Model Sensitivity4.0 4.0 4.0

3.5

Door, 1.0 m Door, 2.0 m Corr, 2.0 m2

3.5

Door, 1.0 m Door, 2.0 m Corr, 2.0 m2

3.5

Door, 1.0 m Door, 2.0 m Corr, 2.0 m2

3.0

3.0

3.0

Flow (1/m/s)

Flow (1/m/s)

2.5

2.5

Flow (1/m/s) 0.06 0.08 B (m) 0.10 0.12

2.5

2.0

2.0

2.0

1.5

1.5

1.5

1.0

1.0

1.0

0.5 1000

1500

2000 A (N)

2500

3000

0.5 0.04

0.5 0.3 0.5 (-) 4.0

Door, 1.0 m Door, 2.0 m Corr, 2.0 m2

0.7

4.0

4.0

3.5

Door, 1.0 m Door, 2.0 m Corr, 2.0 m2

3.5

3.5

Door, 1.0 m Door, 2.0 m Corr, 2.0 m2

3.0

3.0

3.0

Flow (1/m/s)

Flow (1/m/s)

2.5

2.5

Flow (1/m/s)

2.5

2.0

2.0

2.0

1.5

1.5

1.5

1.0

1.0

1.0

0.5 0.7 0.9 1.1 1.3 v0 (s) 1.5 1.7

0.5 0.3 0.5 0.7

(s)

0.9

1.1

1.3

0.5 0.00

0.02

0.04 Bw (m)

0.06

0.08

Figure 13. Effects of different model parameters, Ai , Bi , i , v 0 , i , and Bw on the specic ows through doors and corridors. The corridor is 2.0 m wide, the agent density is 2.0 m-2 , and two different doors widths, 1.0 m and 2.0 m, are used.

5.4

Summary

One should be very careful when constructing the geometry, where agents are moving. One should use Smokeview to see the guiding ow elds for the agents before making a full evacuation simulation. To see the actual evacuation geometry and the ow elds, one should do just a plain evacuation calculation without any re meshes and see the results in Smokeview. One should especially check that there are no smaller than about 0.7 m wide holes in the evacuation geometry, because the agents need at least this wide exit paths. The effect of the parameters in the agent movement algorithm, Eqs. 19, are understood well and user should usually not use any other than the predened person types in FDS+Evac. The default predened person types use a value of 0.5 for the anisotropy parameter, i , of the social force. For some applications the resulting specic ows may be considered to be too large. If this is the case then the user should use 0.3 as the value of i .

37

6. Model Validation6.1 Introduction

Previous chapters are dealing on the fact that how the implementation of the model worked as a computer code. I.e. it was tested that the programme is functioning as planned and it was also considered how sensitive the model is to its input parameters. These tests give condence on how the model is working and how accurate the model equations are solved numerically. But these tests do not necessary tell how well the model is modelling the actual evacuation scenarios. For this reason, in this chapter the model predictions are tested against experimental data from evacuation experiments and trial evacuations. The model predictions are also compared to other evacuation models.

6.2

Comparisons with Test Data

This chapter lists three test cases, where the FDS+Evac predictions are compared to experimental data on human ows on horizontal paths and stairs. These calculations were done using Evac version 2.0.0, but the basic movement algorithm has not changed for version 2.1.1, so there is no need to recalculate these simulations. 1. Specic ows through corridors: In the research of pedestrian ows, the dependence of the specic human ow rate on the human density is called as fundamental diagram. It shows how the specic ow rst increases when the human density is increased, but then starts to decay as the density becomes high enough to hinder the walking. In this test case, the specic ow rates given by the FDS+Evac code are compared to experimental walking velocities on horizontal oors in corridor geometry. The geometry is shown in Figure 11. The corridor is modelled as a loop to avoid the effects of inow and outow boundary conditions. In Figure 14, the predicted ow rates are compared against some experimental results for pedestrian trafc ows taken from Daamens thesis [31]. Note that almost all of the experimental information is obtained by studying bidirectional pedestrian ows, the results for unidirectional ows might give different results. The FDS+Evac simulations were performed with two different parameter sets, labels 1 refer to the

Figure 14. The specic ows in corridors.

defaults of FDS+Evac and labels 2 refer to parameter sets, where i = 0.3 is used. 2. Staircase of an ofce building: The evacuation experiment at the large ofce building [11] was modelled using FDS+Evac. Since the experiment was strongly focused on just one staircase, only this staircase was modelled. Figure 15 shows the geometry of the studied staircase. The actual dimensions and door positions can be found in the experimental report [11]. The experimental entry times of humans to the stair landings were taken as inputs to the simulations. The standard adult person

Figure 15. A snapshot from a FDS+Evac simulation showing the geometry of the staircase.

Figure 16. Comparison of FDS+Evac (staircase model type 1) and experimental observations of a staircase ow. Values 0.3 (left) and 0.5 (right) for the anisotropy parameter of the social force are used. Different curves correspond to the different values of the staircase speed reduction parameter k .

type of FDS+Evac was used in the simulations. Two different values were used for the anisotropy parameter of the social force, i = 0.5 which is the default, and i = 0.3 which corresponds to more relaxed egress. The calculations for staircases were performed using both models for staircases available in FDS+Evac. Figure 16 shows a comparison of the experimental observations and the simulation results using the simple staircase model (type 1). This model is implemented using the CORR namelist, which is a crude model for stairs. In each gure, several simulated curves are shown corresponding to different values of the staircase speed reduction parameter. In Figure 16, the best results are obtained when the value for the speed reduction parameter is 0.5, i.e., the movement speeds of the agents are reduced to v = 0.5v0 at the stairs. The results using more sophisticated way of dening staircases (type 2) are compared to the observed values in Figure 17. In these simulations, the stairs are modelled as inclines (EVSS namelist), where agents move at reduced speed. Reducing the walking speed by a factor 0.7 gives a goodStairs, type 2, = 0.3 300 250 200 Count 150 100 50 0 60 120 180 240 Time (s) 300 360FDS, k=0.2 FDS, k=0.5 FDS, k=0.6 FDS, k=0.7 FDS, k=0.75 FDS, k=0.8 FDS, k=0.9 FDS, k=1.0 Exper

Figure 17. Comparison of FDS+Evac (staircase model type 2) and experimental observations of a staircase ow. Values 0.3 (left) and 0.5 (right) for the anisotropy parameter of the social force are used. Different curves correspond to the different values of the staircase speed reduction parameter k .

40

6. Model Validation

NORTH DOOR

MAIN EXIT B

MAIN EXIT A WEST DOOR

Figure 18. A snapshot from a FDS+Evac simulation shows the geometry of the FDS+Evac model for the second oor of the public library.

agreement with the observations. Whether the anisotropy parameter i is 0.3 or 0.5 does not have effect of any practical importance.

3. Public library: An observed evacuation experiment of a public library [11] was simulated to study the capability to predict the entire movement phase of the evacuation, consisting of movement inside the oor, queueing to the staircase and nally movement through a narrow staircase to the exit. The simulation geometry and the initial positions of the persons are shown in Figure 18. As the majority of persons in the building used the north exit door, the main results are for this door. Shown are also the results for the west door, where about 50% of the people originated from the rst oor. In the simulations, only the second oor of the building was simulated and people originating from the rst oor were placed into the second oor. The north door was the only door with observed crowding. The decision making processes were not modelled. Instead, the people were allocated for the north and west doors according to the ratio observed in the experiment. The simulations were performed using the standard agent type Adult. The premovement times were generated from symmetric triangular distribution with mean of 41 s and lower and upper limits of 11 s and 71 s, respectively. A comparison of the simulated and experimentally observed ows is shown in Figure 19. As can be seen, the predicted ow rates are in very good agreement with the experiments. For the west door, the results reect the goodness or badness of the assumed premovement time distribution because the ow rate through the door is so small. For the north door, the simulation is very relevant, because the ow rate is mainly determined by the geometry and the crowd dynamics during the queueing process.

41

6. Model Validation120 100 Number of Humans 80Exp. North FDS5+Evac North FDS5+Evac West

60 40 20 0 0

Exp. West

60

120 Time (s)

180

240

Figure 19. Comparison of FDS+Evac simulation results and observations at the north and west doors of the public library.

6.3

Comparisons with Other Evacuation Models

The FDS+Evac model is compared here to other evacuation models using four different geometries. The FDS+Evac results and corresponding input les are on the FDS+Evac web pages and some of these cases are also discussed in the summary report of the FDS+Evac development project [10]. These calculations were done using Evac version 2.1.0, but the basic movement algorithm has not changed for version 2.1.1, so there is no need to recalculate these simulations. 1. Sports hall: FDS+Evac simulations were compared to Simulex [19, 21, 22, 23] simulations in a sports hall shown in Figure 20. The hall was previously analysed by Paloposki et al. [32]. The sports hall is used to practice different kind of sports. There are no spectator stands in the hall and neither are there any social spaces like showers. People enter the hall through the main entrance (Door 1), which is 1.8 m

18 m

Door 4

74 m

Door 5

18 m 5m

20 m

72 m

25 m

Door 2 44.5 m3m

Door 1

Door 3

Figure 20. The geometry of the studied sports hall. The open grey area shows, where the agents are at the start of the simulations. The red rectangle shows the re location, which is close to door 3 and, thus, this door is not used.

400 300 200 100 0 0 60

120 180 240 300 360 420 480 Time (s)

Figure 21. The comparison of FDS+Evac to Simulex in a sport hall case. Results of ve different simulations are shown for each case.

wide. Doors 2 and 3 are 4.0 m wide two leaf doors and doors 4 and 5 are 0.9 m wide single leaf doors. It is assumed that a re starts close to door 3 (the shaded rectangle in Figure 20) so that this door cannot be used for egress. 235 persons use the closest door (Door 5), 130 persons use the main entrance (Door 1), 60 persons door 2, and 75 persons use door 4. Persons are initially located at the east end of the hall in an area of 2025 m2 (the open rectangle in Figure 20). Three different reaction time scenarios were considered, two having a normal distribution with a standard deviation of 15 s but different means (60 s and 180 s), and one having a log-normal distribution (median 75 s, standard deviation of the logarithm of reaction time was 0.7). Actually, the log-normal distribution was approximated by two uniform distributions, because the version of the Simulex, which was used, did not support log-normal distributions for the reaction time. The results of the simulations are shown in Figure 21. Since both FDS+Evac and Simulex are modelling human egress as a stochastic process, the presented results were collected from ve different runs per case. The FDS+Evac and Simulex results agree very well for the log-normal reaction time case, but for the other two cases the results differ somewhat. These differences arise due to the Door 5, which is only 1.0 m wide in the FDS+Evac simulations, but through which 235 persons escape. The ow through this door is larger in Simulex than in FDS+Evac. The ow through this door in the FDS+Evac simulations is 1.55 p/s for the cases, where normal distributions were used for the reaction times. If a value of 0.3 is used for the anisotropy parameter i the ow is reduced to 1.1 p/s. The other doors are not as crowded and there the capacities of the doors do not show up as much. 2. Open oor ofce: This test geometry was an open oor ofce, whose oor plan is shown in Figure 22. The oor has dimensions of 4040 m2 and there are initially 216 persons on this oor. The properties of these agents were assumed to be as the Ofce Staff category in the Simulex model and the reaction times of the agents were assumed to follow a normal distribution with mean of 90 s and standard deviation of 11 s. There are three stairs located at the central core of the building. The widths of the doors opening to the stairs are 1.2 m. In total seven different

43

6. Model Validation

Exit 2

Exit 3

Exit 1

Figure 22. The geometry of the open oor ofce test case.

egress scenarios were simulated, covering the cases where all stairs are in use, one stair is blocked and a case where two stairs are blocked. The results of FDS+Evac simulations are compared to results of Simulex simulations in Figure 23. Only when two exit doors were blocked, queues were formed at the door. For two or three operational doors the main form of the evacuation curves arise from the reaction time distribution. The FDS+Evac and Simulex results are quite similar. It should be mentioned, that in the FDS+Evac simulations, the initial (random) positions of agents do not change between different door scenarios (see Figure 22), whereas in Simulex runs the random initial positions are different in each calculation. This explains why the Simulex results have larger scatter in the cases where a certain number of doors are operational.

Figure 23. The comparison of FDS+Evac to Simulex in an open oor ofce case.

44

6. Model Validation12.8 m 7.2 m 20 m

21.4 m 7.2 m

50 m

7.2 m

10 m

60 m

Figure 24. A snapshot from (a) FDS+Evac, (b) Simulex calculation.

3. Assembly space: The second test case is a large ctitious assembly space having dimensions of 5060 m2 and 1000 people initially inside. There is only one 7.2 m wide corridor leading to the exit. The geometry is shown in Figure 24a. The FDS+Evac results (Evac) are compared to those of Simulex (Simulex) and buildingExodus [33] (Exodus) in Figure 25. Note, that the FDS+Evac simulations were also done using parameters describing more relaxed egress (labels Evac 2), where the value of the anisotropy parameter of the social force, i , had a value of 0.3 instead of the default 0.5. Considerable differences are shown between the results of FDS+Evac and the results of Simulex and buildingExodus programmes. These differences can be traced back to the motion of the agents in the corridor, see Figure 24. Simulex and buildingExodus are not using the whole width of the corridor efciently, when the simulations are done using the default values and standard input. (An advanced user of these codes might be able to get different results by using some additional features.) The results of FDS+Evac model look more realistic. In Figure 25 also shown are the results of the simulations for a case, where there is

Figure 25. The comparison of FDS+Evac to buildingExodus and Simulex in an assembly space.

no corridor at all, i.e., there is just one 7.2 m wide exit door located at the wall of the room. In this case, the agreement between the different evacuation programmes is much better. The calculated specic ows (1/p/m) are: Simulex 1.48, Exodus 1.95, FDS+Evac 2.15 (i = 0.5), and 1.73 (i = 0.3). 4. Specic ows through doors: The fourth test geometry is the same as used in Section 5.3 for human parameter sensitivity studies and it is shown on the left hand side in Figure 11. This geometry is commonly used in the literature to calculate the specic ows through doors. In the test, there are 100 agents randomly located at the 55 m2 square. In Figure 26, the results of FDS+Evac simulations for specic ows through doors are compared to simulation programmes Simulex and MASSEgress [20]. The results of the programmes MASSEgress and Simulex are extracted from Pans thesis [20]. The FDS+Evac simulations are performed with two different parameter sets, labels Male/Female/Adult refer to the corresponding default agent types of FDS+Evac and labels Male 2/Female 2/Adult2.5 2.0 Flow (1/m/s) 1.5 1.0 0.5 0.0 0.5 1.0 1.5 2.0 2.5 3.0 Door Width (m)MASSEgress FDS: Adult FDS: Male 2 FDS: Female 2 Simulex FDS: Male FDS: Female FDS: Adult 2

Number of Persons

Figure 26. The specic ows through doors.

46

6. Model Validation

2 refer to parameter sets, where i = 0.3 is used. It is seen that FDS+Evac is able to produce reasonable ows through doors. For some applications, the ows generated by the default parameter values may be considered too large, but it is quite straightforward to modify the parameters of FDS+Evac to reach specic ows that are more relevant to a more relaxed egress.

47

7. Running FDS+EvacRunning FDS+Evac is similar to running FDS, i.e., relatively simple. All of the parameters that describe a given re and egress scenario are typed into a text le that will be referred to as the fds or the input le. In this document, the data le will be designated as CHID.fds. In practice, the user should choose the input string CHID on the HEAD namelist group to be the same as in the le name so that all of the les associated with a given calculation will have a common prex. In Chapter 10, example input les will be presented. Several other example les exist at the FDS+Evac web site http://www.vtt.fi/fdsevac. It is suggested that a new user starts with an existing input le, runs it as is, and then makes the appropriate changes to the input le for the desired scenario. By running a sample case, the user will become familiar with the procedure, learn how to examine the results, and ensure that her/his computer is up to the task before embarking on learning how to create new input les. If the user wants to do a combined re and evacuation simulation, she/he should rst learn how to do re simulations using FDS. If the user is not experienced on doing FDS re simulations, it is suggested that the user uses FDS+Evac just to simulate re drills, i.e., simulate only the egress part of the problem. Even in this case the user should read carefully the Users Guide of FDS [2], because the evacuation simulation geometry is constructed similarly as the re simulation geometry.

7.1

Starting a FDS+Evac Calculation

A FDS+Evac simulation is run similarly as a FDS re simulation, so read the Users Guide of FDS [2], where you can nd information on how to run the re simulation and see the results by using Smokeview [12]. Below is a short description how to run FDS+Evac on MS Windows. Assuming that an input le called CHID.fds exists in some directory, the user must run the program in a DOS command shell as follows: Open up a Command Prompt window, and change directories to where the input le for the case is, then run the code by typing fds5.exe CHID.fds

48

7. Running FDS+Evac

to begin a run, which will output some text on the Command Prompt window. If the user wants to save the text output going on the Command Prompt window, she/he should type fds5.exe CHID.fds 2&>1 > CHID.err to begin a run. FDS+Evac can also be run using the multiple processor version of the programme (fds5_mpi.exe). You should rst learn how to run parallel re calculations by reading the Users Guide of FDS. The combined re and evacuation simulation can be run almost similarly, but you should be sure that all re mesh denitions are preceding all evacuation mesh denitions, because all the evacuation meshes are treated as a single thread, i.e., all evacuation meshes are assigned to same process number. For example, if you are using MPIH2, the example config.txt le given in the Users Guide of FDS should be modied as: exe \\fire_1.nist.gov\NIST\FDS\fds5_mpi.exe job_name.fds dir \\fire_1.nist.gov\Projects\ hosts fire_1.nist.gov 2 fire_2.nist.gov 2 fire_3.nist.gov 2 So the rst ve processes are re meshes and the evacuation calculation is using the sixth process, i.e., it is run in the machine re_3.nist.gov. Note that for now the evacuation part of the programme is always run as a single thread, i.e., all evacuation calculation meshes are run on a single processor. This means that the model size is limited by the computer memory, because the evacuation calculation can not be spread over many processors and computers.

7.2

Updating an Existing FDS Input File to a FDS+Evac Input File

Make a FDS re input le for your project and do the re/smoke spread calculations using the FDS executable. If the memory requirements of your re calculation demand the use of the MPI version of FDS then you can do simultaneous re and evacuation simulation using the parallel version so that the different re meshes can be divided to different processor and the evacuation calculation to some other processor. If you are going to run FDS+Evac only in the re drill mode then it is best to use the serial version of the executable, because all evacuation meshes are always calculated as a single thread, i.e., evacuation calculation utilises just one processor. Save the re input le to some other name (and change also the CHID on the HEAD namelist group). Add the following line to your input le: &SURF ID='OUTFLOW', VEL=+0.000001, TAU_V=0.1 /

49

7. Running FDS+Evac

Dene the main evacuation meshes with the MESH namelist groups, which have both the EVAC_HUMANS and the EVACUATION keywords set to .TRUE. Each oor of the building should have its own mesh main evacuation mesh. The z coordinates for these meshes should be at a level, where the most obstacles for the movement are, usually about one meter above the oor. The EVAC_Z_OFFSET parameter denes the oor level of this mesh measured from the mid z level of the mesh. See Figure 27 and Sec. 8.1. Note, that the smoke and other re related quantities are taken at the level dened by the HUMAN_SMOKE_HEIGHT parameter on (some) PERS namelist. Try to make the mesh division such that the mesh cell sizes in the x and y are nice round numbers, like 0.25 m, 0.35 m, 0.5 m, etc, depending on the widths of the egress paths. If your are using the parallel version of FDS executable, then note that the evacuation meshes should be dened after all re meshes in the input le. This order of meshes is assumed by the programme when it assigns processes for different meshes. Put T_END=0.0 on the TIME namelist group, comment out the re meshes, i.e., remove ampersands at the beginnings of the re mesh lines, and run FDS+Evac. Use Smokeview to see, if the 2D geometry is looking right. You can play around with the zmin and zmax to take the evacuation layout at different heights. Note: If you are using devices and controls in the re calculation you might need to comment these things out also, because these may not belong to some mesh anymore. Dene additional obstacles with EVACUATION=.TRUE., where you do not want agents walking. No need to dene SURF_ID for evacuation obstacles, because the default for these is INERT. Make additional holes with EVACUATION=.TRUE., where they are needed. Usually these are needed at exits or doors. See Figure 1 and Sec. 1.2. Run FDS+Evac (T_END=0.0) and see if the 2D geometry is looking correct. If not, correct it by adding more OBSTs and HOLEs. Dene evacuation ow eld vents (EVACUATION=.TRUE., MESH_ID=xx, SURF_ID=OUTFLOW) that suck uid out of the evacuation meshes at the places where you exit doors are. These vents should be placed at the doors and exits. Note, that in FDS5 vents should be dened on solid surfaces. If you are using multiple evacuation ow elds on a oor then you should specify the MESH_ID on the VENT lines. This species the evacuation mesh, where this vent is put. Same applies to holes and obstacles as well, but usually one can use same obstacles and holes on each ow eld. Many ow elds per a oor are needed if the door selection algorithm of FDS+Evac is wanted to be used. Remember to dene slice output les at your evacuation mesh heights, e.g., &SLCF PBZ=x.x, QUANTITY='VELOCITY',VECTOR=.TRUE./

50

7. Running FDS+Evac

Run a short simulation (T_END=1.0). Check the evacuation ow elds by using Smokeview, i.e., open the velocity vector slice les of the evacuation meshes. Check also that your evacuation geometry looks ne. If not, add obstacles or holes to the evacuation calculation. Dene your person classes, the PERS namelist groups. These namelists dene the properties of the agents in the model. Also the detection and reaction time distributions are given here. Dene your doors, exits, stairs, and entries using the DOOR, EXIT, CORR, EVSS, and ENTR namelists, respectively. Activate grid locations in Smokeview to see the actual positions of your obstacles in the evacuation meshes, which might be a little bit different than the values given in the input le due to the fact that FDS moves OBSTs, HOLEs, and VENTs to match the mesh cell boundaries. Note, that the Evac version 2.1.1 also moves the DOOR, EXIT, and ENTR to match the mesh cell boundaries. The older versions of FDS+Evac were not doing this matching to the underlying computational mesh. See Sec. 1.2 and Figure 1 how doors should be dened. Place the agents inside the building using the EVAC namelists. Use EVHO namelists if needed. Note, that agents should not be placed between outow vents and exits/doors, but this is no problem, because exits and doors are usually dened on solid OBSTs, see Figure 1. Once again, run a short simulation. See, that your agents have correct initial positions. You can change the way how agents are shown in Smokeview by using the menu Show/Hide and choosing different Avatars. Run a longer simulation and see that the agents are moving correctly, i.e., they are following correct ow elds and the exits, stairs, and doors are working correctly. You can speed up the calculation by just entering only a few agents in the calculation. Note that the reaction and detection time distributions given on the PERS lines should be shorter than the simulation time to see some movement (pre-evacuation time = detection time + reaction time). Do a full evacuation calculation and save the results, i.e., the CHID_evac.csv le. Repeat this step a dozen or so times and collect the results to some spreadsheet programme, where you can plot the results. Note, that the results are not exactly similar, because the agents have random properties and initial positions. These simulations correspond to a re drill. After this, activate the re meshes, i.e., put the ampersands back to the re mesh lines, and do a full FDS+Evac simulation. Now the re and evacuation simulations are done at the same time and a le CHID_evac.fed is written to the hard drive. This le can be used to run many evacuation simulations per one re simulation, i.e., no need to calculate the same re for many times. Note, that the CHID_evac.eff le is always (re)calculated when there are active re meshes.

51

7. Running FDS+Evac

If you are doing more than one evacuation calculation per one re scenario (as you should) then save the CHID_evac.eff and CHID_evac.fed les after the previous step, where re and evacuation calculations were done at the same time. Add a keyword EVACUATION_MC_MODE=.TRUE. on the MISC namelist, which will direct the FDS+Evac read the CHID_evac.eff le from the hard disk, if it exists. Then comment the re meshes out, i.e., the ampersands away once again, and rerun the case. Copy the results (CHID_evac.csv) to some other name or collect them directly to a spreadsheet and rerun once again, etc. For a given re, you should run the evacuation part a couple of dozen times, because the FDS+Evac is not deterministic model. After the runs, examine the results: plot the number of agents vs time, calculate averages, variances, etc.

7.3

Getting Help, Error Statements, Bug Reports

Send bug reports to: Timo.Korhonen@vtt.fi. The subject line should start with the characters FDS+Evac Bug:. Or use the FDS-SMV issue tracker to report bugs: http://code.google.com/p/fds-smv/issues/list Send help requests to: Timo.Korhonen@vtt.fi. The subject line should start with the characters FDS+Evac Help:. Or read and ask questions on the FDS-SMV discussion group: http://groups.google.com/group/fds-smv If the run stops early and the error message ERROR: FDS improperly set up is printed on stderr then the initialisation of agents failed, i.e., FDS+Evac was not able to put the agents on the areas specied in the input le. Check that you are not trying to put too many agents on a too small area. See the positions of those agents that FDS+Evac was able to generate by using Smokeview and check the diagnostic text le of the evacuation calculation, CHID_evac.out. Note, that in some runs with the exactly same input le you might get the error message and in some other runs not. The reason for this is that FDS+Evac uses random numbers to generate the properties of agents and their initial positions. The keyword DENS_INIT on the PERS namelist may be given a large value and the FDS+Evac will then try to put the agents more densely, but this is not helping to get more than about 4 agents per square metre.

52

8. Setting up the Input File for FDS+Evac

This section is a short manual to the FDS+Evac programme. Read rst the FDS Users Guide [2], because here only those features and keywords are presented, which differ from the ordinary FDS re input. The optional keywords are presented with a slanted typewriter font, like KAPPA, and the normal keywords with upright typewriter font, like XB. One can use the optional keywords to override the default values of different parameters. The units of the input numbers are the standard SI units if not stated otherwise. Note, that the FDS+Evac is still under construction and so is this manual. See the example FDS+Evac calculations and read through the example input les on the FDS+Evac web page. These example input les contain many comment lines, which explain all the major features of the FDS+Evac input le format and how to do a FDS+Evac simulation. Some general notes on FDS+Evac and some special features and warnings are listed below: New meshes must be dened for the evacuation calculation part. These meshes are not related to the re calculation meshes, i.e., their dx and dy may be different and the spatial extent of the meshes may also be different. Usually one denes one main evacuation mesh per one oor of the building, if the spaces on this oor are connected. If there are more than one evacuation zone on a given oor then different main evacuation meshes may (and should) be used for this oor. The evacuation input should be matched to the evacuation oor mesh denition. Check the actual locations of the obstacles using Smokeview. The evacuation related inputs, the namelists DOOR, EXIT, and ENTR are moved to the closest mesh points starting from the Evac version 2.1.1, whereas the other evacuation specic namelists are not. For now, Smokeview does not show these evacuation related objects. The evacuation meshes are two dimensional, i.e., they should have IJK=Nx ,Ny ,1 on the MESH lines, where Nx and Ny are the number of cells in the x and y directions, respectively. The present version of FDS+Evac places the different evacuation objects to the different evacuation meshes according to their x, y, z coordinates by default. One

53

8. Setting up the Input File for FDS+Evac

object should belong only to one main evacuation mesh. If the position of the evacuation objects, like exits and doors, is ambiguous then a keyword MESH_ID should be given to specify the correct main evacuation mesh. There are many keywords, which might be given in the FDS+Evac input le and these are also read in, but the values are not used yet. This manual only explains keywords, which actually have some effect on the calculation. (If one looks the evac.f90 source code, one nds a quite many non-used keywords.) The positions of doors and exits are not checked, i.e., the user should give VENTs and OBSTs so that in the nal FDS+Evac calculation geometry there is an evacuation VENT corresponding to every EXIT and DOOR in the main evacuation meshes or otherwise agents can not enter these doors, because they feel repulsive forces exerted by the solid objects behind the doors. Note that the outer boundary of meshes is solid by default, if there is no vents specied. It is a good practice to add SLCF output for velocity vectors at the levels of the evacuation meshes and see these vectors in Smokeview. Check your EVAC namelists that you are not putting agents in areas, where they should not be. You can use EVHO namelists to exclude the initialisation of agents at some place. If you want that the agents never go somewhere, then you should use evacuation OBST, not EVHO. Check also that agents can not go out of bounds, i.e., that there are no openings in the evacuation geometry where no door nor exit is dened. Check your EVAC namelists that you are not trying to put too many agents on a too small area. Typical diameter of an agent is somewhere between 0.50.6 m, so you can not put more than about four persons per a square meter. If you are trying to populate the oor denser, the programme will stop after the initialisation phase. Note, that the initial position of agents are random so different runs with the same input le may or may not stop for this reason, if the initial density is close to the critical value. Use Smokeview to see the initial positions of those agents who were positioned successfully and see the output on the diagnostic evacuation output le CHID_evac.out to see the position of the agent, which could not be placed correctly at the initialisation.

8.1

The MESH Namelist Group

The re and evacuation meshes are separate ones. One can do only a re calculation, only an evacuation calculation, or both at the same time. The calculation mode is chosen by activating the meshes or deactivating them, i.e., commenting the corresponding &MESH namelists out. EVACUATION Should be .TRUE. for all evacuation meshes. Default is .FALSE.

54

8. Setting up the Input File for FDS+Evac

Figure 27. A 2D evacuation mesh.

EVAC_HUMANS Should be .TRUE. for all main evacuation meshes. Default is .FALSE. ID The specic ID string of this mesh. An unique name should be given for each evacuation mesh. EVAC_Z_OFFSET The distance from the mid height of the main evacuation mesh to the oor. This parameter is used to show the bodies of the agents in Smokeview so that their feet are touching the oor (default is 1.0 m). This needs to be given only for the main evacuation meshes. This parameter also denes the reference oor level for the smoke and FED calculation, see the parameter HUMAN_SMOKE_HEIGHT on the PERS namelist. Evacuation mesh lines should have a keyword EVACUATION=.TRUE.. The default is .FALSE., i.e., the re meshes do not need the keyword EVACUATION. This is true also more generally, i.e., one can always run a re simulation even if there exists evacuation input in the input le. The FDS5 re calculation ignores all evacuation lines and keywords, if there is no active evacuation meshes. Main evacuation meshes should have also a keyword EVAC_HUMANS=.TRUE. (default is .FALSE.), which says that this mesh will contain agents. Usually, one main evacuation mesh represents a oor. You need more main evacuation meshes on a oor if there exists separate parts of the oor, where the agents are not going to be using same exit routes. If you have a main evacuation mesh, where two or more parts are not directly connected by open routes, then the ow eld of that mesh is not nice. Note also that the evacuation calculation is faster if you dene different meshes for the parts, which do not interact with each other, because the computational cost is additive between different

55

8. Setting up the Input File for FDS+Evac

meshes and inside one mesh there are loops which scale as N 2 , where N is the number of the agents. All evacuation meshes should have a name, i.e., a keyword ID should be given on the &MESH line. The name of the mesh should not be too long, max 26 characters. Of course, the names of different meshes can not be the same. The ID is used later to specify the mesh, where some additional evacuation objects are placed. Evacuation meshes should have only one cell in the z direction, i.e., they are two dimensional horizontal meshes, see Figure 27. Choose IJK and XB so that the dx and dy are nice round numbers that will t nicely to your geometry. You should give the positions of all evacuation objects as multiples of dx and dy . This is not obligatory but one makes less mistakes this way. The earlier FDS+Evac versions did not move the evacuation objects to the closest mesh points, but the present version (2.1.1) and onwards the namelists DOOR, EXIT, and ENTR are move to closest mesh points. Evacuation meshes, which are only used to calculate the (additional) evacuation movement ow elds towards different doors/exits should have EVAC_HUMANS=.FALSE. or just no EVAC_HUMANS keyword at all. Note, that these meshes should have exactly the same IJK and XB denitions as the corresponding main evacuation meshes. This is not (yet) checked by the program so the user should do the check.

8.2

The TIME Namelist Group

EVAC_DT_FLOWFIELD is the time step of the calculation of the evacuation ow elds. These elds are calculated before the re and evacuation calculation, i.e., simulation time has negative values. (Default is 0.01 s.) EVAC_DT_STEADY_STATE is the maximum time step of the agent movement algorithm, this should not be too large, should not be larger than 0.1 s. Note that the time step in the output les will not be shorter than this value. This parameter denes the minimum coupling frequency of different main evacuation meshes. Coupling is faster if the time step of the re calculation is shorter. (Default is 0.05 s.)

8.3

The SURF Namelist Group

One should always dene a new surface type for the evacuation calculation, which is used to construct the ow elds that guide the agents to the doors (or to other targets), see Figure 5. The following line should be given on the input le: &SURF ID = 'OUTFLOW', VEL = +0.000001, TAU_V=0.1 / Note, that VEL should be a really small number, otherwise one might not get a nice 2D potential ow solution.

56

8. Setting up the Input File for FDS+Evac

8.4

The MISC Namelist Group

EVACUATION_MC_MODE This parameter has only an effect when there are no re meshes in the calculation. If the EFF le is wanted to be read in then this keyword should be set to .TRUE.. The default is .FALSE., i.e., the evacuation ow elds are (re)calculated. EVAC_SURF_DEFAULT is the surface default for the evacuation meshes. The default is INERT. You could specify some other solid material for the default surface material, but FDS+Evac uses only the colour information. EVAC_PRESSURE_ITERATIONS is the number of Poisson solver iterations at each evacuation ow eld time step. If you evacuation ow elds do not look nice, you might need to increase this. A too large number makes the ow eld calculation to take too much CPU time. (Default is 50.) EVAC_TIME_ITERATIONS is the number of evacuation ow eld calculation time steps. One should have a nice converged evacuation ow eld, so some iterations are needed. A too large number means too long CPU time. (Default is 50.) The ow elds, which are used to guide agents out of the building or to some other targets, are calculated before the actual re and evacuation simulation, i.e., ow eld calculation has t < tstart . The product of the keywords tow = EVAC_TIME_ITERATIONS EVAC_DT_FLOWFIELD denes the duration of the evacuation ow eld calculation. The elds should reach steady-state during this time. Note, that the ramp up time of the boundary conditions TAU_V=0.1 is given on the &SURF ID=OUTFLOW line and it should be well below the duration of the ow eld calculation tow . Default tow is 50 0.01 s = 0.5 s.

8.5

The VENT Namelist Group

EVACUATION Should be .TRUE. for all evacuation ow eld vents used to generate the guiding ow eld towards different exits and doors. Default is .FALSE., i.e., re mesh vents are not noticed in the evacuation meshes. There should be an evacuation VENT dened at each exit/door on the main evacuation meshes, or otherwise the agents will not be able to use these doors. MESH_ID This parameter is used to specify the evacuation mesh, where this VENT is applied. Because one needs to specify special VENTs for the evacuation calculation, the VENT namelist group has an additional logical item EVACUATION. If it is .TRUE. then this VENT is omitted in the re calculation. The default value is .FALSE., i.e., the re calculation boundary conditions are not used in the evacuation geometry. The keyword MESH_ID should also be given, if the VENT is not needed in all evacuation ow eld calculations on this oor. Note, that an evacuation VENT without MESH_ID is put on

57

8. Setting up the Input File for FDS+Evac

every evacuation ow eld on this oor. This means that it is better always to have the item MESH_ID specied, if EVACUATION=.TRUE. is given. Note, that in FDS5 VENT must always be dened on a solid surface or on the outer boundary of the computational domain. Thus, the user may need to place additional evacuation OBSTs behind the VENTs used to generate the evacuation ow elds.

8.6

The OBST Namelist Group

EVACUATION Should be .TRUE. for all evacuation mesh obstacles, which are not needed in the re calculation. If it is .FALSE. then this OBST is only applied in the re calculation meshes. Default is not dened, i.e., the OBST is applied both to re and evacuation meshes. MESH_ID This parameter is used to specify the evacuation mesh, where this OBST is applied. One may need to specify special OBSTs for the evacuation calculation, which are not present in the re calculation. Thus, the OBST namelist group has an additional logical item EVACUATION. If it is .TRUE. then this OBST is omitted in the re calculation. If the evacuation ow elds need different obstacles for different evacuation ow elds, then the item MESH_ID should be given for the evacuation obstacles. Usually these additional evacuation obstacles are introduced at places, where agents are not allowed to walk.

8.7

The HOLE Namelist Group

EVACUATION Should be .TRUE. for all evacuation mesh obstacles, which are not needed in the re calculation. If it is .FALSE. then this HOLE is only applied in the re calculation meshes. Default is not dened, i.e., the HOLE is applied both to re and evacuation meshes. MESH_ID This parameter is used to specify the evacuation mesh where this HOLE is applied. This is similar to the OBST namelist group. If the evacuation ow elds need different holes for different elds, then the item MESH_ID should be given for the evacuation calculation holes.

8.8

The PERS Namelist Group

This namelist group is used to dene agent types. Properties like body diameters, walking speeds, pre-evacuation times, and force constants of the agents are given here. Some of the values might be given as distributions. There are ve default agent types dened and they are Adult, Male, Female, Child, and Elderly, see Table 1 for their body sizes and walking speeds. Note, that the body sizes and walking speeds are generated from

58

8. Setting up the Input File for FDS+Evac Table 3. Statistical distributions, which may be used to dene the characteristics of the agents on the PERS namelists. The most used ones are: 0) no distribution, x_MEAN is used; 1) uniform distribution, x_LOW and x_HIGH are used; 2) normal distribution, x_MEAN is the mean, x_PARA is the std.dev., x_LOW and x_HIGH are the cut offs, i.e., the values are within the interval (x_LOW,x_HIGH). If x_LOW is not given x_LOW=0.0. If x_HIGH is not given, then x_HIGH is a very large number. Above, x refers to one of the strings DIA, VEL, TAU , DET, or PRE. See Eqs. 1520 for the denition for the distributions.

uniform distributions, whose ranges are also given in the table. The default values of the other agent related parameters are listed at the end of Ch. 3.2. The user should not usually change any of the optional parameters. It is enough to give some predened agent type and set the detection and reaction time distributions. Sometimes also the parameter L_NON_SP could be set to a value of 0.3, see Chapters 5 and 6. This namelist is also used to set some miscellaneous (global) parameters for evacuation calculation, which need to be given only on some PERS namelist group. DEFAULT_PROPERTIES Adult, Male, Female, Child, or Elderly. If not given, default values are used, see the end of Sec. 3.2. Note, that the default values of these agent types may be overridden if the various values are explicitly given in the PERS namelists. DET_EVAC_DIST The type index of the detection time distribution, see Table 3 and Section 9.1. DET_MEAN,DET_PARA,DET_PARA2,DET_LOW,DET_HIGH The parameters of the detection time distribution, see Table 3. PRE_EVAC_DIST The type index of the reaction time distribution, see Table 3 and Section 9.1. PRE_MEAN,PRE_PARA,PRE_PARA2,PRE_LOW,PRE_HIGH The parameters of the reaction time distribution, see Table 3.

59

8. Setting up the Input File for FDS+Evac

DIAMETER_DIST The type index of the body size distribution, see Table 3. Note, that the distribution is given for the diameter of the large body circle, which encircles the whole body ellipse, see Figure 2. DIA_MEAN,DIA_PARA,DIA_PARA2,DIA_LOW,DIA_HIGH The parameters of the distribution used for the diameter of the agent circle (2Rd ), see Figure 2 and Tables 1 and 3. VELOCITY_DIST The type index of the unimpeded walking speed distribution, see Table 3. VEL_MEAN,VEL_PARA,VEL_PARA2,VEL_LOW,VEL_HIGH The parameters of the 0 target walking speed, vi , distribution, see Eq. 2 and Tables 1 and 3. TAU_EVAC_DIST The type index of the relaxation time parameter distribution, see Table 3. TAU_MEAN,TAU_PARA,TAU_PARA2,TAU_LOW,TAU_HIGH The parameters of the relaxation time, i , distribution, see Eq. 2 and Table 3. FCONST_A,FCONST_B,L_NON_SP Social force parameters Ai , Bi , i , see Eq. 3. C_YOUNG,KAPPA Contact force parameters ki and i , see Eq. 4. D_TORSO_MEAN,D_SHOULDER_MEAN The mean diameters of the torso and shoulder circles, see Table 1 and Figure 2. The variations of these diameters are determined by the diameter distribution of the agent circle (2Rd ). TAU_ROT The relaxation time, iz , for the rotational equation of motion, see Eq. 9. M_INERTIA The moment of inertia, Iiz , for the rotational equation of motion, see Eq. 5. NOTE: For the keywords listed below, only the last values read from PERS namelists are used. So, it is nice practice to give these keywords just on one PERS namelist group or have exactly same values on every PERS namelist group. Some of these keywords set some global model parameters for all agents and some are used to specify the outputs and the mode of operation of the programme. FAC_A_WALL Social force constant Aw for wallagent interaction is FAC_A_WALLAi . FAC_B_WALL Social force constant Bw for wallagent interaction is FAC_B_WALLBi . LAMBDA_WALL Social force constant w for wallagent interaction. FC_DAMPING Damping coefcient cd of the radial contact force, see Eq. 4. V_ANGULAR Maximum target angular speed of the agents, 0 , see Eq. 9. NOISEME,NOISETH,NOISECM Gaussian noise, see Eqs. 1 and 5. These parameters determine both the noise in the translational equation, i in Eq. 1, and the noise in z the rotational equation, i in Eq. 5.

60

8. Setting up the Input File for FDS+Evac

HUMAN_SMOKE_HEIGHT Species the level above the oor, where the smoke and FED information is taken. Note, that the parameter EVAC_Z_OFFSET and the coordinates XB on the evacuation mesh namelists dene the oor levels. (Default is 1.6 m.) TDET_SMOKE_DENS If > 0.0 then an agent detects the re when the smoke density (mg/m3 ) is larger than the given value at the position of the agent if the agent has not yet detected the re due to the detection time distribution. Default is no detection by smoke. FED_DOOR_CRIT This sets the amount of smoke which is used to decide if some door is considered to be smoke free in the door selection algorithm of FDS+Evac. If > 0.0 then a door is considered to be smoke free, if the estimated FED value for this agent is less than the given value. If < 0.0 then the absolute value is the visibility distance (m) which is used by the door selection algorithm to rank a door as smoke free (visibility S = 3/K ). See Sec. 3.3. Default is 0.000001. SMOKE_MIN_SPEED This sets the minimum speed of the agents when they are moving 0 0 in smoke, vi, min = SMOKE_MIN_SPEED vi in Eq. 10. Default is 0.1. DENS_INIT If > 2.0, then agents are tried to put on the initial positions so that they can be touching. The default is to leave some space between agents and very large agent densities are not possible. Note that FDS+Evac puts agents randomly in their initial positions and, thus, the initial density of agents can not be much larger than four agents per square meter. Default is 0.0. EVAC_DT_MAX The maximum time step for the agent movement algorithm, default 0.01 s. EVAC_DT_MIN The minimum time step for the agent movement algorithm, default 0.001 s. NOT_RANDOM If .TRUE. do not use random seed when generating the initial positions and characteristics of agents. Default is .FALSE. COLOR_METHOD How agents are shown in Smokeview. -1: use standard colors in Smokeview, 0: use avatar colors given on the EVAC lines, 3: use avatar colors given on the PERS lines, 4: color the agents according the target door/exit colors, 5: color the agents according the exit selection algorithm, see Table 2. The default is -1. AVATAR_COLOR Color of the agents seen in Smokeview if COLOR_METHOD=3. See the FDS Users Guide and FDS web page for the list of available color names. AVATAR_RGB Three integers (0255) specifying a color of the agents seen in Smokeview if COLOR_METHOD=3. Note, that AVATAR_COLOR overrides this option.

61

8. Setting up the Input File for FDS+Evac

DEAD_COLOR Color of the dead agents seen in Smokeview. See the FDS Users Guide and FDS web page for the list of available color names. Default color for dead agents is cyan. DEAD_RGB Three integers (0255) specifying a color of the dead agents seen in Smokeview. Note, that DEAD_COLOR overrides this option. Default color for dead agents is cyan. OUTPUT_SPEED If .TRUE. then the movement speeds of the agents are saved in the ouput le to be shown in Smokeview as a color bar. OUTPUT_FED If .TRUE. then the FED doses of the agents are saved in the ouput le to be shown in Smokeview as a color bar. OUTPUT_CONTACT_FORCE If .TRUE. then the contact forces acting on the circumferences (N/m) of the agents are saved in the ouput le to be shown in Smokeview as a color bar. OUTPUT_TOTAL_FORCE If .TRUE. then the total forces (contact + social) acting on the circumferences (N/m) of the agents are saved in the ouput le to be shown in Smokeview as a color bar. Below the probability density functions are listed for those distributions in Table 3, where the naming of the parameters is not trivial. The denition of the probability density function of the Gamma distribution is: f (x) = 1 x1 ex/ , x > 0, , > 0 () (15)

WARNING: Change only the reaction and detection time parameters, other parameters should have the default values and use the predened person types, unless you know what you are doing. The parameter L_NON_SP may be changed from its default value 0.5 to a value 0.3, if a more relaxed egress is wanted, see Chapters 5 and 6.

62

8. Setting up the Input File for FDS+Evac

8.9

The EVAC Namelist Group

Places agents in the evacuation meshes, i.e., this namelist group is used to dene the initial positions of the agents. ID ID string of the group of agents. XB Denes the rectangle, where the agents are put, z should belong to the correct main evacuation mesh. If the coordinates XB intersects many evacuation meshes then the keyword MESH_ID should be given. MESH_ID If there are overlapping main evacuation meshes then this parameter could be used to specify the mesh, where this EVAC namelist is applied. NUMBER_INITIAL_PERSONS How many persons are put in the rectangle XB. PERS_ID The ID string of the PERS namelist, which is used to dene the characteristics of the (randomly) generated agents. ANGLE By default the orientation of agents is random, but by giving an angle (0360) the orientation of the agents can be specied. Angle 0 means that the agents are facing towards +x and the positive direction of the angle is anti-clockwise. AVATAR_COLOR Colour of the agents seen in Smokeview if COLOR_METHOD=0. See the FDS Users Guide and FDS web page for the list of available colour names. AVATAR_RGB Three integers (0255) specifying a colour of the agents seen in Smokeview if COLOR_METHOD=0. Note, that AVATAR_COLOR overrides this option. FLOW_FIELD_ID Species which evacuation ow eld the agents are following if there are no known nor visible doors available at the main evacuation mesh, where the agents are placed. KNOWN_DOOR_NAMES The ID strings of the known doors and exits for the agents. KNOWN_DOOR_PROBS The probabilities that the exit doors are known. At the initialisation phase the known doors for agents are drawn using these probabilities. Default values are equal to ones, i.e., the listed known doors will be known to all agents generated by this EVAC namelist. NOTE: If no PERS_ID is given on EVAC lines, then the default values are used for the properties of persons. These default values are given inside the programme source code, and they might be changing during the development of the programme. So, one should not use the default values.

63

8. Setting up the Input File for FDS+Evac

8.10

The EVHO Namelist Group

Species a place where no agents are generated by the EVAC namelists. ID ID string of the hole. One can refer to this hole by its name. XB Denes the rectangle, where the agents are not put, z should belong to a main evacuation mesh. If XB intersects many evacuation meshes then the keyword MESH_ID should be given. MESH_ID If there are overlapping main evacuation meshes then this parameter could be used to specify the mesh, where this EVHO namelist is applied. PERS_ID This hole applies just for this person type, i.e., it has effect only on those EVAC namelists, where PERS_ID matches. EVAC_ID This hole applies just for the given EVAC namelist. If both PERS_ID and EVAC_ID are given, they are treated using the logical operator OR.

8.11

The EXIT Namelist Group

Denes an exit, which removes agents from the calculation for good. Note, that an outow vent is not automatically created, so the user should give a separate VENT namelist for each exit. Exits might be used just to count agents, then the keyword COUNT_ONLY=.TRUE. is used and, thus, these can be placed anywhere inside the building. Agents, which move through an exit (COUNT_ONLY=.FALSE.), are removed from the calculation, i.e., they are supposed to be gone outside of the building and be safe. ID ID string of the exit. One can refer to this exit by its name. XB Denes the position of the exit, should be a line in the (x, y ) plane, the z should belong to a main evacuation mesh. If XB intersects many evacuation meshes then the keyword MESH_ID should be given. Note, that the FDS+Evac versions 2.1.1. and later are moving the corners of the rectangle dened by XB to the closest grid cell corners. MESH_ID If there are overlapping main evacuation meshes then this parameter could be used to specify the mesh where this exit is applied. XYZ Coordinates, which are used in the exit door selection algorithm to decide if the exit is visible or not. Default is the mid-point of XB. IOR Direction of the door, e.g., +1 agents are going +x direction, -2 agents are going y direction (direction means: room exit outside of the building) COUNT_ONLY If .TRUE., agents are not removed, they are just counted (default is .FALSE.). The CHID_evac.csv le has a column for each EXIT regardless if COUNT_ONLY is true or false.

64

8. Setting up the Input File for FDS+Evac

VENT_FFIELD The ID string of the evacuation ow eld mesh behind this exit door. The agents are guided to this exit door by the specied ow eld. If none is given then the agents, whose target this exit is, are following the ow eld of the current main evacuation mesh, i.e., they are just going where the ow goes and not towards this exit. This parameter should be given if the exit selection algorithm of FDS+Evac is being used. FLOW_FIELD_ID Used, if this exit is a target for some other evacuation element and there are no known doors nor visible ones available. If FLOW_FIELD_ID is not given, then the main evacuation mesh ow eld is used. WARNING: It is better to use a door or an entry instead of an exit if it is a target of some other evacuation element. COLOR Colour of the agents seen in Smokeview if COLOR_METHOD=4. See the FDS Users Guide and FDS web page for the list of available colour names. RGB Three integers (0255) specifying a colour of the agents seen in Smokeview if the COLOR_METHOD=4 is specied on (some) PERS namelist. Note, that the COLOR keyword overrides this option. TIME_OPEN The time (s) when this exit becomes usable. The default is that the exit is always usable. TIME_CLOSE The time (s) when this exit becomes unusable. The default is that the exit is always usable.

8.12

The ENTR Namelist Group

Denes an entry. An entry can enter agents to the calculation at a constant frequency. An entry with frequency zero can just be used as an end point of a corridor or stairs. An entry corresponds to a one way door, i.e., agents can only come out from this door. ID ID string of the entry. One can refer to this entry by its name. XB Denes the position of the entry, should be a line in the (x, y ) plane, the z should belong to a main evacuation mesh. If XB intersects many evacuation meshes then the keyword MESH_ID should be given. Note, that the FDS+Evac versions 2.1.1. and later are moving the corners of the rectangle dened by XB to the closest grid cell corners. MESH_ID If there are overlapping main evacuation meshes then this parameter could be used to specify the mesh where this ENTR line is applied. IOR The direction of the entry, e.g., +1 agents are entering towards +x direction -2 agents are entering towards y direction (direction means: somewhere entry room). Note that the namelist EXIT has just the opposite rule for the sign of IOR.

65

8. Setting up the Input File for FDS+Evac

MAX_FLOW How many agents per second are introduced in the calculation. The actual ow may be smaller, if the area in front of the entry is crowded. The default is zero. MAX_HUMANS The maximum number of agents to be introduced in the calculation by this entry, the default is a very large integer. TIME_START The time (s) when this entry starts adding agents to the calculation. The default is the starting time of the simulation, the T_BEGIN keyword given on the TIME namelist group. TIME_STOP The time (s) when this entry stops adding agents to the calculation. The default is that an entry never stops introducing new agents to the calculation. PERS_ID The properties of agents are generated using these parameters, if they are not coming to this entry form some other node, i.e., they are new agents. If not given, the default values are used. FLOW_FIELD_ID Flow eld in the room/oor, which the agents are following after their entry, i.e., species to which door the agents try to go if no known nor visible doors are available. If not given, the ow eld of the main evacuation mesh is used. KNOWN_DOOR_NAMES The ID strings of the known exit doors. This only apply to agents that are generated at this entry by the MAX_FLOW, i.e., it does not apply to those agents who are transfered to this entry from somewhere else. KNOWN_DOOR_PROBS The probabilities that the exit doors are known. Only values equal to one or zero can be used for entries. Default values are equal to ones. AVATAR_COLOR Colour of the agents seen in Smokeview if COLOR_METHOD=0. See the FDS Users Guide and FDS web page for the list of available colour names. AVATAR_RGB Three integers (0255) specifying a colour of the agents seen in Smokeview if COLOR_METHOD=0. Note, that the AVATAR_COLOR keyword overrides this option.

8.13

The DOOR Namelist Group

Denes a door. Similar to EXIT, but the agents are not removed from the calculation. The agents are put to some other part of the calculation, e.g., to stairs or to a different room. ID ID string of the door. One can refer to this door by its name. XB Denes the position of the door, should be a line in the (x, y ) plane, the z should belong to a main evacuation mesh. If XB intersects many evacuation meshes then the keyword MESH_ID should be given. Note, that the FDS+Evac versions 2.1.1. and later are moving the corners of the rectangle dened by XB to the closest grid cell corners.

66

8. Setting up the Input File for FDS+Evac

XYZ Coordinates, which are used in the exit door selection algorithm to decide if the door is visible or not. Default is the mid-point of XB. MESH_ID If there are overlapping main evacuation meshes then this parameter could be used to specify the mesh where this door is applied. IOR Direction of the door, e.g., +1 agents are going +x direction, -2 agents are going y direction (direction means: room door some other place). Note that the namelist EXIT has the same rule for the sign of IOR. TO_NODE Where agents are going, when going inside this door. TO_NODE can be DOOR, EXIT, CORR, or ENTR namelist ID. EXIT_SIGN If .TRUE. then this door is considered as an exit door in the door selection algorithm. Agents can use this door even if it is not described as known door, i.e., it can be classied as a visible, unknown door in the door selection algorithm. (Default is .FALSE.) KEEP_XY saves the information on the position of the agent relative to the width of the door, i.e., if the target of this door is a DOOR or an ENTR then the agent is placed according to this information. If this is not set true, then the algorithm seeks randomly empty space in front of the target node. One should set this true, if one is modelling stairs or spectator stands using EVSS. Default is .FALSE. VENT_FFIELD The ID string of the evacuation ow eld mesh behind this door. The agents are guided to this door by the specied ow eld. If none is given then the agents, whose target this door is, are following the ow eld of the current main evacuation mesh, i.e., they are just going where the ow goes and not towards this door. This parameter should be given if the exit selection algorithm of FDS+Evac is being used. FLOW_FIELD_ID Used, if this door is a target for some other evacuation element and there are no known doors nor visible ones available. If no FLOW_FIELD_ID is given, then the main evacuation mesh ow eld of this oor is used. COLOR Colour of the agents seen in Smokeview if COLOR_METHOD=4. See the FDS Users Guide and FDS web page for the list of available colour names. RGB Three integers (0255) specifying a colour of the agents seen in Smokeview if the COLOR_METHOD=4 is specied on (some) PERS namelist. Note, that the COLOR keyword overrides this option. TIME_OPEN The time (s) when this door becomes usable. The default is that the door is always usable. TIME_CLOSE The time (s) when this door becomes unusable. The default is that the door is always usable.

67

8. Setting up the Input File for FDS+Evac

8.14

The CORR Namelist Group

Denes stairs (or a horizontal corridor). Namelists CORR are used to move agents from one oor to the next one, i.e., from one main evacuation mesh to some other one. The corridor (actually stairs) model is a really simple one. One gives the length of the stairs and reduces the movement speed of the agents. One also gives the maximum number of persons inside the corridor. For now there is no relation between the density and the movement speed (nor specic ow) inside the stairs. ID ID string of the corridor. One can refer to this CORR by its name. MAX_HUMANS_INSIDE how many agents t inside the corridor. A rule of thumb: two persons per square metre. TO_NODE Where agents are going, when leaving this corridor. TO_NODE can be DOOR, EXIT, CORR, or ENTR namelist ID. XB, XB1, XB2 Used to specify the points, where FED data is taken for this corridor/stairs. If only one value is used for the corridor/stairs, give XB. If the values at the beginning and at the end of the corridor/stair is used, give both XB1 and XB2, respectively, and the FED data values are linearly interpolated between the start and the end of the corridor/stairs. FAC_SPEED How much slower agents move in the corridor/stairs compared to the walk0 in horizontal oors. (Default is 1.0) ing speed vi EFF_LENGTH The effective length of the corridor/stairs. The movement time of the 0 ). agents inside the stairs is calculated as EFF_LENGTH/(FAC_SPEED vi Note, that CORR is usually used to dene stairs between two oors: Door2nd oor Corr Door1st oor . Stairs could also be constructed using the EVSS namelists, but this is not as straight forward as to use CORR constructions. See the example input les on the FDS+Evac web pages. If you have merging ows in stairs, then you should model the landings explicitly and you can use CORR to move the agents from one landing to the next one.

8.15

The EVSS Namelist Group

Denes an incline, e.g., stairs, a spectator stand, or an escalator. The dened incline could also be horizontal. Then it species a piece of the current oor at different vertical position than given on the MESH line of the evacuation oor. This way intermediate landings in stairs could be modelled, see the stairs example case on the FDS+Evac web pages. The EVSS namelists just change the z coordinates of the agents, when these are saved on the hard disk to be plotted by Smokeview. Thus, the internal agent movement algorithm of FDS+Evac does not use the z coordinates. All agents on a given main evacuation mesh are always projected to the same horizontal plane. EVSS can also be used just to change the movements speeds of the agents at some parts of the oor.

68

8. Setting up the Input File for FDS+Evac

ID ID string of the incline. XB Denes the position of this incline, should dene a rectangle in the (x, y ) plane, the z should belong to a main evacuation mesh. If XB intersects many main evacuation meshes then the keyword MESH_ID should be given. IOR Direction of the incline, e.g., +1 means that the +x edge of the EVSS plane is a horizontal line at a height HEIGHT0 above (or below if < 0 m) the main evacuation plane dened by the z of XB and the -x edge is a horizontal line a height HEIGHT above (or below if < 0 m) the main evacuation plane. MESH_ID If there are overlapping main evacuation meshes then this parameter could be used to specify the mesh where this EVSS line is applied. HEIGHT The height of the -IOR edge of the incline measured from the level of the main evacuation plane dened by the z of XB. This edge has z = zXB + HEIGHT . HEIGHT can have a positive or a negative value. Default is 0 m. HEIGHT0 The height of the IOR edge of the incline measured from the level of the main evacuation plane dened by the z of XB. This edge has z = zXB + HEIGHT0. HEIGHT0 can have a positive or a negative value. If HEIGHT0=HEIGHT the EVSS denes a horizontal plane and IOR has no effect. Default is 0 m.0 FAC_V0_UP The unimpeded speed of an agent upwards is FAC_V0_UP vi . 0 . FAC_V0_DOWN The unimpeded speed of an agent downwards is FAC_V0_DOWN vi 0 FAC_V0_HORI The unimpeded speed of an agent horizontally is FAC_V0_HORI vi .

ESC_SPEED The speed of an escalator (m/s). The EVSS can be used to model a simple escalator, where all agents are moving with the specied velocity ESC_SPEED along the escalator, i.e., they are not overtaking each others nor walking on the escalator. The escalator is running along the IOR direction, i.e., from the HEIGHT0 edge towards the HEIGHT edge with a speed ESC_SPEED .

69

9. Miscellaneous Information9.1 Controlling the Start Time of the Egress Movement

The reference time for the evacuation calculation is the starting time of the FDS simulation, which is by default zero. This value can be changed on the TIME namelist group by giving the keyword T_BEGIN in seconds. The detection time distributions (DET_EVAC_DIST) are given with respect to this reference time. The reaction time distributions (PRE_EVAC_DIST) are given with respect to the detection times, so the agents start to move towards the exits when tmove = tbegin + tdet + tpre , (21)

where tdet and tpre are the detection and reaction times for this agent generated from the distributions, respectively. Note, that the detection time in the above equation could be shorter than the value that is generated from the detection time distribution, if the detection by smoke feature of the programme is used, see the TDET_SMOKE_DENS keyword on the PERS namelist group.

9.2

Additional FDS+Evac Input Files

The FDS+Evac calculation might have also other input les than the CHID.fds le. These les are not needed but they may be used to speed up the calculation and also to separate the re and evacuation parts of the calculation. The le CHID_evac.eff contains the converged evacuation ow elds, which are calculated at the beginning of the FDS+Evac calculation. This le depends only on the evacuation meshes. By default, this le is always (re)calculated. If the keyword EVACUATION_MC_MODE=.TRUE. is given on the MISC namelist group then this le is tried to read in, if this le exist and there are no re meshes in the FDS+Evac input le. Otherwise it is always (re)calculated and saved on the disk. Same is true, if there occurs some read error. Because FDS+Evac is a stochastic egress simulation programme, one should always run the same FDS+Evac simulation a dozen or so times to see the stochastic variability in the results. This is why the EFF le is useful. The same is true when one is doing many

70

9. Miscellaneous Information

egress calculations using exactly the same geometry but with different egress scenarios, e.g., varying the number of the agents and the demographics of the agents. One do not need to recalculate the evacuation ow elds and, thus, one is saving some CPU seconds. This le need not to be recalculated, if only the namelists EVAC, EVHO, PERS, EVSS, and ENTR are changed in the FDS+Evac input le. Also the simulation time T_END on the TIME namelist may be changed together with any only re mesh related changes that do not change the evacuation geometry. The le CHID_evac.fed contains the smoke and gas concentration information from the FDS re calculation. This le is tried to read in, if there are no re meshes specied in the input le. If there is at least one re mesh specied and also at least one main evacuation mesh (EVAC_HUMANS=.TRUE. and EVACUATION=.TRUE.) specied, then this le is (re)calculated and saved on the disk. Because FDS+Evac is stochastic, one should do a couple of dozens evacuation simulation per one re calculation and then this le will speed up the calculation very much, i.e., the re calculation has to be done only once. See also Ch. 7.2. The FED le should be recalculated if the main evacuation meshes are changed of the namelists DOOR, EXIT, or CORR are changed. Note, that the FED le is always (re)calculated and saved to the hard disk when there are both re and main evacuation meshes present in the input le. Note, that both les CHID_evac.eff and CHID_evac.fed are assuming that the (main) evacuation meshes and the evacuation geometry are exactly the same in the new calculation than was in the one, which wrote the les. One can add more additional door ow eld meshes to the evacuation calculation and still use the old FED le. The FED le is just written for the main evacuation meshes. This is sometimes very useful if there are problems with the amount of the available RAM memory. One can do the re calculation and dene just the main evacuation meshes to produce the FED le. Then one can add additional evacuation door ow elds and deactivate the re meshes and read the FED le, so the evacuation calculation is using the re information.

9.3

FDS+Evac: Output Files

FDS+Evac produces a le CHID_evac.csv, which has information on the number of agents on the different oors and stairs at a given time as well as the total number of agents inside the building. The le also list the number of agents gone through each exit and door. The keyword DT_HRR on the DUMP namelist denes the output time step. The rst column is the time and the second column is the number of agents inside the whole building. Then the number of agents in each main evacuation meshes (oors) and in each corridor/stairs (CORR namelists) are given. After these the number of agents gone through various exits and doors are reported. The next columns are counters for the exit selection algorithm. They report the number of agents heading to the different exits and doors. The last three columns are printed only if the FED is used, i.e., the smoke and toxic gas information is available. The rst of these columns reports the number of dead agents, i.e., those whose FED values are larger than unity. The next column is the maximum value of FED among all agents, dead or alive. Note, that the FED value of the dead agents will continue to build up as if they would be alive. Finally, the last column

71

9. Miscellaneous Information

is the maximum FED value of the agents which are alive at a given time. Agent movement may be visualised by Smokeview, where Evacuation is shown on the Load/Save menu. The agents are saved on .prt5 les. You can change the appearance of the agents using the Show/Hide menu and the Use Avatar: sub menu. The colouring scheme of the agents can be changed using the Show/Hide menu and the sub menu Humans if the chosen COLOR_METHOD on the PERS namelist allows that. The DT_PART keyword on the DUMP namelist denes the output frequency for the agents to be shown in Smokeview. The evacuation particle les are using same format as the FDS re calculation particle les, see the FDS Users Guide for the details on the format. During the run of FDS+Evac some evacuation information is printed on the text le CHID_evac.out, like the initial positions and characteristics of the agents. A FDS+Evac run always produces the le CHID_evac.eff, which contains the evacuation ow elds used to guide the agents towards the different doors and exits. This le can be used to speed up the initialisation phase of FDS+Evac run, if the evacuation geometry is not changed between different runs, see Ch. 9.2. A FDS+Evac run, which has both re and main evacuation meshes present, produces the le CHID_evac.fed contains the smoke and gas concentration information for the evacuation calculation. This le can be used later, if more evacuation calculations are done using the re scenario and same evacuation geometry, e.g., if one is doing a Monte Carlo simulation of the egress scenario, see Chapters 7.2 and 9.2.

72

10. Sample Input Files

Below two example inputs les of FDS+Evac are given. These input les are not representing any real building, they are just used to show some of the keywords and parameters, which can be used in FDS+Evac egress calculation. These les can be downloaded from the FDS+Evac web pages, where the latest versions of these les can be found. The web pages contain also many more examples. Note that the examples on the web page have much more comment lines than the printed examples below. Do not cut-and-paste the les from this manual, go to the web pages and download the les. Note also that the les on the web pages are usually in the Unix-mode, i.e., they are having the Unix line endings, so they do not open correctly in Notepad in Windows operating system. You should use Wordpad or some other (plain) text editor to open these les. In Wordpad you can save the le as Text Document - MS-DOS Format. This will change the line endings to the DOS style. The rst input le species a re in a room with two doors, see Figure 28. Agents are using both doors and they select the door by using the exit door selection algorithm, thus, each of the two doors needs its own evacuation ow eld. This means that one needs to dene the main evacuation mesh and two additional door ow eld meshes for this case besides the re mesh.

The fire as a burner. &OBST XB= 3.00, 4.00, 3.00, 4.00, 0.00, 0.60, SURF_ID='INERT' / &VENT XB= 3.00, 4.00, 3.00, 4.00, 0.60, 0.60, SURF_ID='BURNER' / &VENT MB='YMIN',SURF_ID='OPEN' / &VENT MB='YMAX',SURF_ID='OPEN' / Evacuation geometry input. Define the evacuation vents for the main evacuation mesh, there should be an evacuation vent at every place, where humans can go 'inside' some door, exit, etc object. This vent is not at an outer boundary of the domain nor at a solid object, thus, there should be an OBST behind it (FDS5 restriction). Left Exit: &VENT XB= -0.20,-0.20, 4.40,5.60, 0.40,1.60, SURF_ID='OUTFLOW', MESH_ID='MainEvacGrid', EVACUATION=.TRUE., RGB=0,0,255 / &OBST XB= -0.40,-0.20, 4.40,5.60, 0.40,1.60, SURF_ID='INERT', EVACUATION=.TRUE., RGB=30,150,20 / This vent is at the outer boundary of the domain, i.e., it is on a solid object (by default). Right Exit:

The second input le species a two-oor building, see Figure 29, each oor consisting of one egress area, thus only one main evacuation mesh per oor is needed. There is a re in downstairs and the smoke is going to the second oor by an opening at the ceiling. The second oor is connected to the rst oor in the egress calculation, i.e., the second oor agents are transfered to the rst oor by the combination of doors and stairs. The second oor has two exit doors, one leading to the stairs going to the rst oor (the right exit door) and one leading to the stairs leading directly to outside of the building (the left exit). The rst oor has two exit doors and one entry, which the agents from the second oor are using when entering the rst oor.

10. Sample Input Files FYI='Elderly diameter and velocity', DEFAULT_PROPERTIES='Elderly', PRE_EVAC_DIST=1,PRE_MEAN=10.0,PRE_LOW=5.0,PRE_HIGH=15.0, DET_EVAC_DIST=1,DET_MEAN=10.0,DET_LOW=5.00,DET_HIGH=15.0 / Initial positions of the humans 1st Floor: These humans will use the left exit, if it is not blocked by smoke. &EVAC ID = 'HumanLeftDoorKnown', NUMBER_INITIAL_PERSONS = 25, XB = 1.0,9.0, 1.0,9.0, 0.4,1.6 AVATAR_COLOR = 'BLUE', KNOWN_DOOR_NAMES = 'LeftExit', KNOWN_DOOR_PROBS = 1.0, PERS_ID = 'Male' / These humans will use the right exit, if it is not blocked by smoke. &EVAC ID = 'HumanRightDoorKnown', NUMBER_INITIAL_PERSONS = 25, XB = 1.0,9.0, 1.0,9.0, 0.4,1.6 AVATAR_COLOR = 'RED', KNOWN_DOOR_NAMES = 'RightExit', KNOWN_DOOR_PROBS = 1.0, PERS_ID = 'Female' / These humans know both doors so they will use the nearest visible known door which is not blocked by smoke. &EVAC ID = 'HumanBothDoorsKnown', NUMBER_INITIAL_PERSONS = 25, XB = 1.0,9.0, 1.0,9.0, 0.4,1.6 AVATAR_COLOR = 'GREEN', KNOWN_DOOR_NAMES = 'LeftExit','RightExit', KNOWN_DOOR_PROBS = 1.0,1.0, PERS_ID = 'Child' / These humans do not have a known door and they will try to go to the nearest visible exit door. &EVAC ID = 'HumanNoDoorKnown', NUMBER_INITIAL_PERSONS = 25, XB = 1.0,9.0, 1.0,9.0, 0.4,1.6 AVATAR_COLOR = 'BLACK', PERS_ID = 'Adult' / 2nd Floor: All of these humans know the right door on the 2nd floor and the right exit on the first floor. On the average, only 50 \% know the left door on the second floor and none knows the left exit on the first floor.

11. ConclusionThe development work of FDS+Evac is an undergoing project. Read carefully through the Chapters 1.2 and 2.7 of this guide, where the features and limitations of the current version of the programme are listed. Read also Ch. 1.3 and the Readme.txt le on the FDS+Evac web pages to see the latest changes to the user inputs. The development work of FDS+Evac is nicely summarised on the VTTs project summary report [10]. The verication and validation work of FDS+Evac is reported on this manual and some additional work is presented on the FDS+Evac web pages at http://www.vtt.fi/fdsevac/. The present status of the FDS+Evac (FDS 5.3.0, Evac 2.1.1) is: Smoke vs walking speed correlations are included. Fractional Effective Dose is calculated and used to incapacitate agents, but only CO, CO2 and O2 concentrations are used. Smoke density can be used to trigger agent movement (detection by smoke). A simple exit door selection algorithm is implemented. Inclines, stairs, and escalators can be modelled explicitly by using the equations of motion for each person. A simple stairs algorithm without merging ows is implemented. If there are merging ows in stairs then these should be modelled explicitly, which means some additional work to construct the input le containing the landings and stairs using. The ows through doors, stairs and corridors are reproduced nicely by the underlying dynamics. Congestion can be studied. The effect of the many input parameters of the agent movement model are understood well and their effect on the specic ows is known. Below the TO DO list of the development work of FDS+Evac is presented. Note that some of the items on the list are already added to the programme source code but these are not discussed on this manual. These features are still work-on-progress stage.

86

11. Conclusion

Merging ows in stairs: An easy to use staircase model with merging ows and smoke information is implemented and it is now in V&V phase. More predened human types, especially those referred in the IMO circular [29]. More intelligence in the exit door selection algorithm, e.g., estimated queueing time due to the other agents heading/queueing for the same exit door, which is already implemented and it is on a testing phase. Better treatment of the non-visible known doors. Social interactions like herding, small groups, etc.. A small group feature is already implemented but it is not yet validated. Spreading of the information: agent to agent communication like re detection. Easier generation of the input le. Counterow is implemented but need still V&V work. More optimal computer memory usage. Parallelisation of the evacuation calculation using MPI/OpenMPI. The shortcomings of FDS+Evac are: Restrictions on the geometry and the computational mesh due to the rectangular nature of the FDS geometry, i.e., objects, whose edges are along the x and y , are the main elements used to construct the geometry, including inclines and stairs. Merging ows in stairs are not easy to model. No elevators. The evacuation objects, like exits, doors, etc., are not visualised on the Smokeview window. The user input is not easy to give, i.e., no support for importing CAD drawings for the evacuation calculation. There exists commercial software tools that generate FDS re input and these tools can be used to generate an FDS model of the building. CPU and RAM memory intensive. Users should notice that the evacuation part of FDS5 is under development, and the features and user input may change in the future. Thus, one should always use the latest version of FDS, which can be downloaded from http://www.re.nist/fds/downloads.html. One should also check the FDS+Evac web pages at http://www.vtt./fdsevac/ for the latest version of this manual. This page also contains more verication and validation results and example cases than this manual and the example les there are up to date with the most resent version of the programme.

87

AcknowledgementsThe Evacuation Module of the Fire Dynamics Simulator has been under development for some years. Dr. Kevin McGrattan of NIST is acknowledged for helping to implement the evacuation subroutine in the FDS code and Dr. Glenn Forney of NIST is acknowledged for the modications needed in the visualisation program Smokeview. University of Helsinki and Helsinki University of Technology are acknowledged for the cooperation. The development work of FDS+Evac has been funded by the VTT Technical Research Centre of Finland, the Finnish Funding Agency for Technology and Innovation, the Finnish Fire Protection Fund, the Ministry of the Environment, and the Academy of Finland. The Building and Fire Research Laboratory at NIST is acknowledged for the hospitality during the visits of one of the authors (T.K.).

VTT CREATES BUSINESS FROM TECHNOLOGY Technology and market foresight Strategic research Product and service development IPR and licensing Assessments, testing, inspection, certification Technology and innovation management Technology partnership