Fire Dynamics Simulator with Evacuation: FDS+Evac

Transcription

1 VTT Technical Research Centre of Finland Fire Dynamics Simulator with Evacuation: FDS+Evac Technical Reference and User s Guide (FDS 6.6.0, Evac 2.5.2, DRAFT) Timo Korhonen VTT February 12, 2018

2 Preface This 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 2.5.2, which is embedded in the current FDS version (GIT FDS g47260e6). The most up to date version of this manual can be obtained from the FDS+Evac web page at fdsevac/. This FDS+Evac Technical Reference and User s 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: User s Guide [3] and the Smokeview, A Tool for Visualizing Fire Dynamics Simulation Data, Volume I: User s Guide [14]. Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification 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. 4

3 Disclaimer VTT 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 this tool. Users are warned that FDS+Evac is intended for use only by those competent in the fields of fire and evacuation simulation, and is intended only to supplement the informed judgement of the qualified user. The software package is a computer model that may or may not have predictive capability when applied to a specific 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. 5

4 Contents Preface 4 Disclaimer 5 1 Introduction Getting Started Features of Limited Functionality Most recent changes Intended Use of FDS+Evac Model Documentation Name and Development Environment Type of the Model Model Developers Relevant Publications Input Data Required to Run the Model Model Results Uses and Limitations Theoretical Basis for the Evacuation Model Introduction Agent Movement Model Counterflow Collision Avoidance Model Fire and Human Interaction Exit Selection Numerical Method and Other Details Testing and Verification Introduction Component Testing Functional Verification Qualitative Verification Numerical Tests Model Sensitivity Introduction

5 Contents 5.2 Numerical Mesh Sensitivity Human Parameter Sensitivity Sensitivity of the Counterflow Algorithm Summary Model Validation Introduction Comparisons with Test Data Comparisons with Other Evacuation Models Running FDS+Evac Starting a FDS+Evac Calculation Updating an Existing FDS Input File to a FDS+Evac Input File Getting Help, Error Statements, Bug Reports Setting up the Input File for FDS+Evac The MESH Namelist Group The TIME Namelist Group The SURF Namelist Group The MISC Namelist Group The OBST Namelist Group The HOLE Namelist Group The PERS Namelist Group The EVAC Namelist Group The EVHO Namelist Group The EXIT Namelist Group The ENTR Namelist Group The DOOR Namelist Group The CORR Namelist Group The EVSS Namelist Group The STRS Namelist Group Miscellaneous Information Controlling the Start Time of the Egress Movement Additional FDS+Evac Input Files FDS+Evac: Output Files Restarting a fire+evacuation calculation Sample Input Files Conclusion 108 Acknowledgements 111 References 112 7

6 1. Introduction This document describes how to simulate human egress using the Fire Dynamics Simulator (FDS) [4, 3, 5, 6], and in particular, the evacuation module [7, 8, 9, 10, 11]. This combined fire and evacuation simulation programme is called FDS+Evac in this document. FDS+Evac allows simultaneous simulation of fire and evacuation processes. It can also be used to simulate only the human egress process without any fire effects, e.g., a fire 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 floors of buildings. The basic algorithm behind the egress movement solves an equation of motion for each agent in a continuous two dimensional space (e.g., a horizontal xy-plane) and time, i.e., FDS+Evac is doing some kind of an artificial molecular dynamics for the agents. In this document the two dimensional spaces are the horizontal xy-planes representing the floors of the considered building and the positive z direction is taken to point upwards. The forces acting on the agents consist of both physical forces, such as contact forces and psychological forces exerted by the environment and other agents. The model behind the movement algorithm is the social force model introduced by Helbing s group [17, 18, 19, 20]. A modification of the model to describe better the shape of the human body was introduced by Langston et al. [21]. 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 verification tests of the programme and Ch. 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 7 11 contain the user s 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 first the User s Guide of FDS and learn how to do fire simulations. Even if the user wants to use the programme without fire, she/he should be acquainted with the FDS in order to 8

7 1. Introduction build up the simulation geometry and running the FDS simulations. 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 fire simulation. See the FDS User s Guide [3] for details. FDS+Evac results can be visualised using Smokeview [14, 15, 16] programme. Also, the computer hardware requirements are similar with FDS. The FDS fire calculation can be run parallel by using the MPI version of FDS, but the evacuation part is always calculated as a single thread (process). The evacuation module, FDS+Evac, is embedded in the latest released version of FDS (FDS 6.5.3), which can be obtained from the URL 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 results of the FDS+Evac simulations can be visualized using the Smokeview programme similarly as the fire results. The home page of FDS+Evac is This page contains the most recent version of this combined Technical Reference and User s Guide of FDS+Evac and some examples on the use of FDS+Evac. This web site is also used to store the validation and verification test cases including the input files. This (printed) manual refers to FDS Evac (GIT FDS g47260e6). 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 floors 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 floors 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 fully support the use of elevators during evacuation process. Wide stairs or inclines can also be used to connect different floors, but this is not as straightforward as to use the simple staircase model. FDS approximates the building geometry on a rectilinear mesh. Rectangular obstructions are forced to conform with the underlying mesh. It is possible to prescribe more than one rectangular mesh to handle cases where the computational domain is not easily embedded within a single mesh in the fire calculation. The user should note that the 9

8 1. Introduction building description in the fire calculation meshes is completely isolated from the building description in the evacuation meshes. The fire geometry and the evacuation geometry can be totally different, but this is not, of course, usually the case. The evacuation geometry is described using two-dimensional planes that cut the fire geometry at the heights representing best the floor geometries. The fire calculation obstacles show up in the evacuation meshes, but one should not that the evacuation meshes have their own rectilinear meshes that need not coincide with the fire meshes, so that the actual positions of the obstacles might be a little bit different due to the different spatial discretisations of the meshes. Usually the user needs to fine tune the obstacles in the evacuation meshes to represent the evacuation scenario correctly. This is done by adding or removing obstacles in the evacuation meshes as needed. These changes do not affect the fire meshes. The evacuation calculation needs, in addition to the fire calculation meshes, its own two dimensional evacuation meshes describing the different floors of buildings. If no fire related data is needed in the evacuation calculation then there are no need for fire meshes and FDS+Evac can be run in a fire drill mode. Evacuation meshes should not be too fine, because then one might face problems with the evacuation flow fields, which are used to guide the agents towards the exits. This difficulty can be addressed by an experience user, but an easier way is always to use evacuation meshes, which are not too fine. 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 some 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 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 fire mesh definitions (in a fire drill mode). Then Smokeview shows just the evacuation geometry. It is a good practice to construct first the FDS fire calculation input file and do a short test run. After this one can add the evacuation meshes to the calculation and run the code in a fire drill mode, i.e., simulate and see just the evacuation part of the calculation. When the evacuation part of the input file seems to be working as it should then a full fire + evacuation calculation could be done. Note that while the FDS fire 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 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/exits. For now, the number of agents placed in the same evacuation mesh is limited by a default amount. The programme stops and writes out an error message if more than agents are tried to place on the same evacuation mesh. This can be overridden by a user given keyword but the user should note that the CPU time needed for large crowds might be quite long. Usually, one evacuation mesh extends over a whole floor of a building. Several evacuation meshes may coexist, e.g., the different floors of the building, 10

9 1. Introduction 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 file of the evacuation calculation. If higher densities are needed, then the option for ordered placements of the initial agents should be used. Here the user can place the agents as close to each other as possible (agents should not overlap too much). FDS+Evac enables coupled fire and evacuation simulations. The smoke and gas concentrations from the fire calculation affect the movement and decision making of the evacuating humans. In principle, the coupling could also be made to the other direction, i.e., humans could influence the fire calculation, e.g., by opening doors, but this feature is not yet implemented in FDS+Evac. The gas phase concentrations of O 2, CO 2, and CO are used by default to calculate Purser s Fractional Effective Dose (FED) index [29], indicating the human incapacitation. The effects of some other gases, (NO, NO 2, CN, HCl, HBr, HF, SO 2, C 3 H 4 O, CH 2 O) are also considered, if the user gives corresponding inputs. 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 fire, 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 fire if the user does not explicitly define the evacuation geometry to take this in to account (e.g., by giving reasonable opening and closing times for doors and exits). 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 are small random forces and torques on each agent s equation of motion. Thus, same results are not obtained for a given input file 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 fire simulation and the calculation of the guiding door flow fields for evacuation movement need to be calculated only once for each given geometry. This is the so called Monte Carlo mode dictated by the logical keyword EVACUATION_MC_MODE. The present version of FDS+Evac does not fully support parallel CPU calculations for the evacuation part. If a FDS+Evac calculation needs too much computer memory, then 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 fire meshes using the MPI version of the FDS executable. 11

10 1. Introduction 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 file, which is on the FDS+Evac web page. Read these changes carefully if you have used older versions of FDS+Evac and especially if you are using some old FDS+Evac input files as templates for new input files. Note that only the latest changes are listed below, the changes that were done for the FDS version 5 are not shown anymore. Also this guide describes only the new evacuation input style, but there is still some backward capability in the code to read the old evacuation input style Most recent changes, version vs The version of the evacuation module does not differ much from the version Just some bugs are corrected Most recent changes, version vs The version of the evacuation module does not differ much from the version Just some bugs are corrected and some old user input are disabled. This version does not support anymore FDS 5 style evacuation inputs. Now just the main evacuation meshes are defined by the user and no outflow vents are defined. The STRS namelist for the staircases is more automatic, it defines its own mesh(es) automatically. The main evacuation meshes can have many separated (sealed) evacuation zones, older versions had the constraint that the (main) evacuation mesh should be one zone. In short: The user needs just to define: The main evacuation mesh (usually one per building floor) Final exits (EXIT namelists) Internal door connections (DOOR and ENTR namelists) that move agents from one mesh (floor) to some other mesh (floor) Inclines, stairs, staircases, etc (EVSS and STRS namelists) Agent properties and initial positions (PERS and EVAC namelists) Most recent changes, version vs Simple elevator model using CORR namelist: WAIT_AT_XYZ, LOCKED_WHEN_CLOSED, and TARGET_WHEN_CLOSED logical parameters in EXIT/DOOR namelist. The CORR has parameters ELEVATOR=.TRUE., TRAVEL_TIME=10.0. If a door has an elevator CORR at its TO_NODE then the door open/close is checking the position of the elevator car. 12

11 1. Introduction Most recent changes, version vs The door algorithm uses different height for see or not than the main evacuation mesh that contains the obstacles for movement. The see or not mesh is at the height z smoke defined by HUMAN_SMOKE_HEIGHT and the EVAC_Z_OFFSET. The z 1 = z smoke - EVAC_DELTA_SEE and z 2 = z smoke + EVAC_DELTA_SEE are used for the z range of this see or not mesh. The names of these additional meshes are like ID= Emesh_MESH_ID, where MESH_ID is the name of the corresponding main evacuation mesh. One may have to use these mesh IDs to specify additional HOLEs and OBSTs for these see-or-not meshes, but usually just specifying EVACUATION=.TRUE. is enough is enough for these obstacles. No need to specify STRS meshes. The XB size hole is generated automatically and also the core OBST is generated automatically. The automatically generated mesh have ID= Emesh_STRS_ID, where STRS_ID is the ID of the STRS namelist. This ID may be used to put some additional obstacles to the stairs, if needed. Usually just specifying EVACUATION=.TRUE. is enough for these obstacles. No need to specify the additional door flow fields. No need to define "outflow" vents. No need to define additional OBSTs for the "outflow" vents. The user should only define the main evacuation meshes and the EXITs and DOORs, all the above other things are generated automatically. If CORR is used and its TO_NODE is an "dummy" EXIT then the exit should have COUNT_ONLY=.TRUE. so that there will be no mesh (and flow field calculation) for this dummy exit. Also SHOW=.FALSE. might be good, i.e., do not show the dummy exit in Smokeview. Added logical keyword LOCKED_WHEN_CLOSED (default is false) to the EXIT/DOOR namelists. If it is set true then the agents stop at the door line if the door/exit is closed. In normal mode the agents can go through closed doors, but they do not use closed doors in the door selection algorithm. Added logical keyword TARGET_WHEN_CLOSED (default is false) to the EXIT/DOOR namelists. If it is set true then the door/exit is included in the door selection algorithm even if it is closed. The agents will go towards closed doors and will go through the closed doors if LOCKED_WHEN_CLOSED is not set to true. Added a logical keyword to (some) PERS namelist: EVAC_FDS6 is by default.false. (Note: In version it is set to true.) If it is set to.true. then the agents aim straight towards the doors that they can see. First they aim towards XYZ and when they are close enough then they start to aim towards XB. Aim towards XB or XYZ does not mean straight to that point. The agents aim between the door posts (minus 30 cm for the body size effect) and the mid point of the door (XYZ is a point but the door width is also used here to place door posts for this point). If the agents are within the door posts of the door (say, door has IOR=+1, and y 1 = 4.0 m and y 2 = 6.0 m, then if the agent has y = 4.3 m to 5.7 m) then the agent will (try to) move directly along the +x direction. If the agent density is high around the agents (more than 2 p/m 2 ) then the guiding flow field of the target door is used. Same is true when no XB nor XYZ are visible. The left and right side densities are checked separately (close to a wall or at the outer boundary of a agent crowd). If straight towards door would mean turning towards a high left (or right) 13

12 1. Introduction density then the flow field is used instead. If EVAC_FDS6=.TRUE. is given then the user should not give any additional evacuation flow fields nor vents. There are two basic levels in the evacuation meshes. One is the main evacuation mesh location at the z-level given by the XB on the mesh line. The OBSTs (and HOLEs) on this mesh will be used to the movement of the agents. These are also used to calculate the guiding flow fields towards different exit doors. The other z-level is defined with the HUMAN_SMOKE_HEIGHT parameter (measured from the floor level ). This gives its mid z-position, the z-range is ±EVAC_DELTA_SEE (default 0.29 m), which can be given on (some) PERS namelist. This new level is used with the door selection algorithm to decide what the agents are able to see. Also the smoke information is at this level. 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 flows 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/method to study evacuation. If the two (or more) methods give similar results then the predictions of the computational modelling should be quite good. The user should read carefully through this manual and see how well the presented validation cases will cover the intended use of the programme. It is not the purpose of this document to give instructions on how to define 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. 14

13 2. Model Documentation This 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 [4, 3, 5, 6] 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 [14, 15, 16]. 2.1 Name and Development Environment The underlying fire simulation programme, Fire Dynamics Simulator (FDS), is a computational fluid dynamics (CFD) model of fire-driven fluid flow. FDS is written using Fortran 2003 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 development and maintenance of the programme has utilised a version control system. 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 fixes, incremental versions are released, referenced according to fractions of the integer version numbers. In addition, day-to-day bug fixes 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 file. The latest official release version of FDS is obtainable on the web site The latest documentation on the evacuation part of FDS+Evac can be found on the web page 1 The server is hosted by GitHub ( 15

14 2. Model Documentation 2.2 Type of the Model FDS+Evac is a combined agent-based egress calculation model and a Computational Fluid Dynamics (CFD) model of fire-driven fluid flow, where the fire and egress parts are interacting. FDS+Evac can also be used just to calculate the egress problem without any fire-driven fluid flow calculation, e.g., it can be used to simulate fire drills. FDS+Evac models the egress of the agents using continuous space and time, but the building geometry is fitted to the underlying rectilinear mesh. FDS+Evac uses simple rules and artificial 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 Acknowledgements. 2.4 Relevant Publications Each version of FDS+Evac is documented by this publication the FDS+Evac Technical Reference and User s Guide. The User s 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 verification 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 flows. Note that the most up to date verification 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 Helbing s group [17, 18, 19, 20]. The implementation of this algorithm inside the FDS programme environment was introduced by Korhonen et al. [7]. Later the model was modified along the lines given in the paper by Langston et al. [21] to a three circle representation of agents by Korhonen et al. [8, 9, 10, 11]. Later the model was enhanced to deal better bi-directional flow situations by introducing a counterflow algorithm [45]. 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 file, which is the same one that is used for FDS, created by the user. For the fire-driven fluid flow related parameters, see the 16

15 2. Model Documentation FDS documentation [3]. The input file of FDS+Evac is such that it can be used with just a minor modification to run an ordinary FDS calculation without evacuation calculation. Usually the user need just to set the keyword NO_EVACUATION=.TRUE. on the MISC namelist. Same is true for the other way around, i.e., by setting the keyword EVACUATION_DRILL=.TRUE. on the MISC namelist one can make easily do test runs to see that the construction of the evacuation calculation part is done correctly. A complete description of the input parameters required by the evacuation module of FDS can be found in the User s 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 Smokeview programme [14]. 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 file, that can be plotted using a spreadsheet programme. Some additional, quite detailed, information are written to the diagnostic evacuation text file 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 efficiency 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 fire meshes, thus the same limitations apply to the evacuation part of the programme. 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 finest 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 [30], where larger smoke concentrations were used than in the experiments by Jin [31]. This correlation is the default, but an experienced user could give any other linear relationship as desired by using correct values for the appropriate keywords. 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. The more sophisticated and easier to use staircase model, STRS, does not yet use any smoke information, i.e., it models a staircase where no smoke can enter. 17

16 2. Model Documentation Incapacitation: The incapacitation model is the FED concept introduced by Purser [29], 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 O 2 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 dictated by the user inputs. Note also, that the effects of, e.g., HCN nor HCl, are not modelled by default and that the toxic effects of CO 2 are not modelled; only its hyperventilation factor is included. Exit Route Selection: The exit door selection algorithm is still a relatively simple one. The user has more or less full control on the doors which different agents will be using. In some applications this can be listed as a benefit of the model, but the requirements for user s responsibility and expertise should be recognised. The present version of the programme has some ability to treat herding and follow others type behaviours, which will take some control from the model user to the programme itself. But these new social type behaviours are not yet validated. Detection and Reaction Times: The pre-movement time of the evacuating agents is decided by the user input by giving distributions for the detection and reaction times. In addition to the detection time given by the user, the local smoke concentration can be used to trigger the detection of a fire. Currently, the fire detection can also be connected to the control logic of FDS, e.g. the smoke/heat detectors in FDS fire calculation can also be used to trigger the movement of the agents. Applications: There is no feasible model for elevators in the current version of the FDS+Evac. There is a really simple elevator model implemented in the programme, but it is mostly there for illustrative purposes only. There is no specific objects relevant to maritime applications, just the person types listed in the IMO document [33] are defined so that the user can define these person types easily. Concert halls and sport facilities may be difficult to model due to the limitations dictated by the rectangular computational mesh. Also the lack of validation studies of seat rows etc. are hinder the use of the programme to model these types of buildings. There are in principle no limitation on the number of agents that can be modelled but if there are more than a couple of thousand agents in an evacuation mesh then the calculation will take long time. The present version of FDS+Evac supports parallel calculation only for the fire 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 FDS (the MPI parallelization). This sets the upper limit on the complexity of geometry, which can be modelled due to the available computer RAM memory. Memory problems may be avoided by changing to a 64 bit operating system and downloading the 64 bit versions of the FDS executables. 18

17 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 fire 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 two dimensional horizontal geometries representing the floors of buildings. The size of each agent is represented by three circles approximating the elliptical cross sectional shape of the human body, see Fig. 1, just like in the Simulex programme [23, 26, 27, 28], in the MASSEgress programme [25], and in the CrowdDMX model [21, 22]. 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 fire simulation environment of FDS is used to minimise the programming effort to write an egress programme. For visualisation, the existing Smokeview programme [14] developed at NIST is used. Additional benefit of using FDS as the platform of an egress model is the direct and easy access to the fire 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 fire calculation would easily allow the evacuation calculation to change the flow of the fire calculation, e.g., by allowing the evacuees to open or close doors and windows, but this is not yet possible with the present 19

18 3. Theoretical Basis for the Evacuation Model R R t d Figure 1. The shape of the human body is approximated by a combination of three overlapping circles. Shown are also the definitions of the body size variables. R s version of the FDS+Evac programme. 3.2 Agent Movement Model The method of Helbing s 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 Fig. 2. This model is shortly described below. For a longer description, see the papers by Helbing s group [17, 18, 19, 20] and references therein. For the modification of the one-circle representation of an agent to a three-circle one, see the papers by Langston et al. [21] and Korhonen et al. [8, 9, 10, 11]. 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: m i d 2 x i (t) dt 2 = f i (t) + ξ i (t), (1) where x i (t) is the position of agent i at time t, f i (t) is the force exerted on agent i by the surroundings, m i is the mass, and the last term, ξ i (t), is a small random fluctuation force. The velocity of agent i is given by v i (t) = dx i /dt. Table 1. Unimpeded walking velocities and body dimensions in FDS+Evac. The offset of shoulder circles is given by d s = R d R s, for the definition of the other body size variables, R d, R t, R s, see Fig. 1. The body sizes and walking velocities of the agents are personalised by using them from uniform distributions, whose rages are also given. Body type R d R t /R d R s /R d d s /R d Speed (m) (-) (-) (-) (m/s) Adult 0.255± ±0.30 Male 0.270± ±0.20 Female 0.240± ±0.20 Child 0.210± ±0.30 Elderly 0.250± ±

19 3. Theoretical Basis for the Evacuation Model r soc soc soc Fiw Fij Fji Figure 2. The concept of the social force. r The force on the agent i has many components: f i = m i ( ) ( ) v 0 τ i v i + f soc ij + fij c + fij att + i j i w (f soc iw + f c iw) + k f att ik, (2) where the first sum describes agent agent interactions, the sum over w describes agent wall interactions, and the terms in the last sum, fik att, may be used for other agent environment interactions, like the fire agent repulsion. The first term on the right hand side describes the motive force on the evacuating agent. Each agent tries to walk with its own specific walking speed, vi 0 = vi 0, towards an exit or some other target, whose direction is given by the direction of the field vi 0. The relaxation time parameter τ i sets the strength of the motive force, which makes an agent to accelerate towards the preferred walking speed. The agent agent interaction force in Eq. (2) has three parts. For the social force term,, the anisotropic formula proposed by Helbing et al. [19] is used f soc ij ( fij soc = A i e (d ij r ij )/B i λ i + (1 λ i ) 1 + cos ϕ ) ij n ij, (3) 2 where d ij is the distance between the centres of the circles describing the agents, r ij is the sum of the radii of the circles, and the vector n ij is the unit vector pointing from agent j to agent 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 agent i feeling the force and the direction to agent j, which is exerting the repulsive force on agent i. The parameters A i and B i 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 wall agent interaction, fiw soc, is treated similarly, but values A w, B w, and λ w are used for the force constants. The physical contact force between the agents, fij, c is given by f c ij = ( k ij (r ij d ij ) + c d v n ij) nij + κ ij (r ij d ij ) v t ij t ij, (4) where v t ij is the difference of the tangential velocities of the circles in contact, v n ij is the difference of their normal velocities, and vector t ij is the unit tangential vector of the contacting circles. This force applies only when the circles are in contact, i.e., 21

20 3. Theoretical Basis for the Evacuation Model R soc f soc c R Figure 3. Definitions of the radial vectors R c and R soc. r ij d ij 0. The radial elastic force strength is given by the force constant k ij 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 c d that was added by Langston et al. [21]. The original model by Helbing et al. did not have this force. This parameter reflects the fact that the collision of two humans is not an elastic one. The physical wall agent interaction, fiw, c is treated similarly and same force constants are used. The term fij att can be used to describe attraction (or repulsion) between agents, like a herding behaviour or an adult children interaction. It could also be used to form pairs of agents, e.g., describing a fire fighter pair entering the building, but these kind of interactions are not yet implemented in FDS+Evac. All of the force terms in Eq. (2) are relatively short ranged and they need a line-of-sight connection. Longer ranged forces could be taken in to account by changing the preferred walking velocity field vi 0 of the agents. Equations 1 4 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: I z i f c d 2 ϕ i (t) dt 2 = M z i (t) + η z i (t), (5) where ϕ i (t) is the angle of agent i at time t, Ii z is the moment of inertia, ηi z (t) is a small random fluctuation torque, and Mi z (t) is the total torque exerted on the agent by its surroundings Mi z (t) = Mi c (t) + Mi soc (t) + Mi τ (t), (6) where Mi c, Mi soc, and Mi τ are the torques of the contact, social, and motive forces, respectively. The torque of the contact forces is calculated as M c i = j i ( ) R c i fij c, (7) where R c i is the radial vector, which points from the centre of agent i to the point of contact, see Fig. 3. In FDS+Evac, also the social forces exert torques on the agents and these are given by the formula M soc i = j i ( R soc i ) fij soc, (8) 22

21 3. Theoretical Basis for the Evacuation Model where only the circles, which are closest to each other, are considered. The vector R soc i points from the centre of agent i to the fictitious contact point of the social force, see Fig. 3. Analogous to the motive force, the first term on the right hand side of Eq. (2), a motive torque is defined as M τ i (t) = Iz i τ z i ( ϕi (t) ϕ 0 i π ) ω 0 ω i (t) = Iz i τi z ( ω 0 i (t) ω i (t) ), (9) where ω 0 is the maximum target angular velocity of a turning agent, ω i (t) = dϕ i /dt is the angular velocity of agent i, ϕ i (t) is the current body angle, and ϕ 0 i is the target angle, i.e., where the vector v 0 i is pointing. The target angular speed, ω 0 i, defined in Eq. (9) is larger when the body angle differs much from the desired movement direction. Langston et al. [21] 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 vector field, v 0 i, and this field is obtained using the flow solver of the FDS. This vector field is obtained as an approximate solution to a potential flow problem of a two-dimensional incompressible fluid to the given boundary conditions, where all walls are inert and the chosen exit door acts as a fan, which extracts fluid out of the domain. This method, or rather a trick, produces a nice directional field for egress towards the chosen exit door, see Fig. 4. A field 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 field will guide more agents to the wider escape routes than on the narrower ones due to the fact that the field is a solution to an incompressible flow. The analogy to an incompressible fluid flow is not a bad starting point to find 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 flow to the outside of the building without much control on the process. If the target exit door is visible to an agent then it aims directly toward the door and does not follow the guiding vector field if the density of the agents is not too high towards the door. The agent movement method presented in Eqs. (1) (9) has many parameters. Some of these parameters are related to physical dimensions of humans, like m i and I z i, but many parameters are related to the chosen model. Some of these parameters are chosen to be the same as found in the literature [18, 21] and some are estimated from test calculations. The parameters of the social force were chosen such that the specific flows 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 performed to see, which are the most important model parameters and further analysis was focused on those parameters. The first choice for the social force parameters of the agent agent interaction was A i = 2000 N, B i = 0.04 m, and λ i = 0.5. For the agent wall interaction values A w = 2000 N, B w = 0.08 m, and λ w = 0.2 were used. It was noticed that these 23

22 3. Theoretical Basis for the Evacuation Model Figure 4. An example of the 2-dimensional flow fields that are used to guide the agents towards the exit doors. values are not good for congested situations if three circles are used to describe the human body. These parameters were modified such that the interaction strength parameter A i was made velocity dependent, A i (v i ) = 2000 Max(0.5, v i /vi 0 ) N, and the anisotropy parameter value was decreased to λ i = 0.3. For the contact force parameters, values k ij = kg m -2, κ ij = kg s -1 m -1, and c d = 500 kg s -1 are used both for the agent agent and for the agent wall interactions. Note that in Eq. (4) the effective elastic constant between two agents is calculated as k ij = (k i k j )/(k i + k j ), where k i and k i are the elastic constants of the agents, i.e., if the agents have same elastic constants then k i = 2k ij. The friction coefficient between two agents is simply assumed to be independent of the agents in contact, κ ij = κ i. The mass of a default male agent is m i = 80 kg and its moment of inertia was chosen to be Ii z = 4.0 kg m 2. 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 /m i = 0.1 m s -2, and it is truncated at three times of the standard deviation. The random torque in Eq. (5) is treated similarly and its standard deviation is ηi z /Ii z = 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 Counterflow Collision Avoidance Model The original model of Helbing et al. is not well suited for situations, where there are agents going to different directions and their paths are crossing or opposite to each other. The agents do not react to the oncoming agents explicitly. There is just a small implicit 24

23 3. Theoretical Basis for the Evacuation Model action by the social forces, but this is not large enough to hinder the agents from colliding. To overcome this deficiency, a short range counterflow model [45] was introduced in FDS+Evac version In the counterflow model, the area in front of agent i is divided into three overlapping sectors, Si θ = {S θ i, Si 0, S +θ i }, which are pointing to the left, u θ i, straight ahead, u 0 i, and to the right, u +θ i, see Fig. 5. Straight ahead means always the preferred direction, vi 0 in Eq. (2), where the agent would go without the effect of the counterflow model, e.g., the direction towards an exit door. The basic idea of the counterflow model is to choose the sector with least counterflow. This is formulated as an optimisation problem, where each agent lying within a sector either increases or decreases the score of the sector depending on its location and moving velocity. If the front sector of agent i is non-empty, it selects the movement direction u i with the highest score among the directions of the sectors, U θ i = {u θ i, u 0 i, u +θ i }, ten times in every second, on the average. Agent i maximises the following expression u i = arg max u θ i Uθ i j S θ i, c df + d df v j v i, u 0 i max(0.2, D ij ) j S θ i, c cf d cf v j, u 0 i max(0.2, D ij ) + + c v0 (δ θ>0 δ θ<0 ) + c v0 v i δ θ=0 + N 0 (c ncf + d v0 v i )δ θ=0 δ N cf 0 =0, (10) where u 0 i = vi 0 / vi 0 is the original direction towards the target door of agent i. D ij is the skin-skin distance between the agents j and i, and v j and v i are their velocities. The angle brackets express inner products of the arguments and c df, d df, c cf, and d cf are constants. The maxima in the denominators are used to avoid divisions by zero. The agents inside the sectors Si θ are divided to counterflow ( ) and non-counterflow ( ) agents by projecting their desired moving direction, u 0 j, along the desired moving direction of the current agent, u 0 i. The symbol δ θ>0 is equal to one if θ > 0 and zero otherwise and similarly for the other ones. There are terms in the above maximisation problem that prefer the right (and straight ahead) to the left to produce observed right handed traffic [34]. The right (left) sector gets an additional weight c v0 ( c v0 ) and the front sector a weight c v0 v i. Note, that by giving a negative value for the parameter c v0 one could prefer the left to the right. If there are no counterflow agents inside the front sector, N0 cf = 0, then this sector is preferred by a term N 0 (c ncf + d v0 v i ), where c ncf and d v0 are constants and the number of agents in the front sector is N 0. Without this term the agents could start to move sideways around the end of a queue at a door, which seems not a realistic behaviour. Equation (10) describes the avoidance of counterflow agents in the absence of walls. If a sector touches a wall then some additional relatively large negative weights are given to that sector using parameters c 1w and c 2w. The first parameter is used to give a negative weight that depends on the agent speed and the distance to the wall measured along the direction of the sector, u θ i. Sectors with walls are disliked more when the agent moves fast and the closer a wall is the more negative weight is given to that sector. The second 25

24 3. Theoretical Basis for the Evacuation Model Figure 5. The definition of the sectors used in the short range collision avoidance model. parameter is used to give a large negative weight for a sector which is more or less totally inside a wall, i.e., the agent is already as close to that wall as it can be. The social force parameters A i, A w, B i, and the motive force parameters τ i and τi z in Eqs. (2), (3), and (9) are changed when an agent faces strong counterflow and the speed of the agent is slow, as it usually is in such situations. The social force strength is reduced by a factor a min,cf (a w,cf for walls) at most and the range of the social force is reduced by a factor b min,cf at most. This allows higher densities for counterflow situations. Reducing the agent-wall social force takes into account the behaviour that one is willing to move closer to walls when bypassing other people. The translational and rotational motive forces are increased by reducing the relaxation time constants by a factor c τ up to τ min and τmin z at most, respectively. At the same time, the target motive angle of the body is also changed so that the agent tries to move shoulder first. Similar rotation of the body angle is done if the agent is close to a wall and it finds it difficult to move ahead. The presented counterflow model is designed for dense crowds and thus, the extents of the sectors are not very large. The range of the sectors extends maximally to three metres ahead of an agent and on the sides the sectors extend up to 1.5 m. If the speed of the agent is low then the maximal range straight ahead is approaching 1.5 m and the sectors form a semi circle as the angle of the sectors, θ, is increased from 40 degrees to 45 degrees, when the speed goes towards zero. The origin of the sectors, the point P in Fig. 5, is little bit in front the torso circle if the agent is moving freely and it is moved continuously to little bit behind the torso circle when the walking speed goes towards zero. This shift is at most ±R d, see Table 1. It is important to include the agents at the sides to the optimization problem, when the speed is low. When the speed is large the agent looks more forward and the agents at the sides are considered already to be bypassed. There are many parameters in the model so these were carefully investigated. The values of some parameters could be just found by trial-and-error. It was seen that the movement of the agents was reasonable and that the movement of the agents did not seem to much different than the old version of the programme when all the agents were mainly going towards the same direction, because the good results of the existing programme was not wanted to be thrown away. Also a Monte Carlo study was made to see how much the parameters were affecting the results and for some parameters a further study on their effect on the results were made. See the Sec. 5.4 below. 26

25 3. Theoretical Basis for the Evacuation Model 3.4 Fire and Human Interaction By using FDS as the platform of the evacuation calculation we have direct and easy access to all local fire related properties, like gas temperature, smoke and gas densities, and radiation levels. Fire influences evacuation conditions; it may incapacitate humans and in extreme cases block major exit routes. On the other hand, humans may influence the fire by opening doors or actuating various fire protection devices. For now, the effect of smoke on the movement speeds of agents and the toxic influence 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. The smoke density can also be used to trigger the detection of fire in addition to the user given detection time distribution. Smoke reduces the walking speed of humans due to the reduced visibility, its irritating and asphyxiant effects. Recently, Frantzich and Nilsson [30] made experiments on the effect of smoke concentration on the walking speeds of humans. They used larger smoke concentrations than Jin [31] and they found the walking speed decreasing with increasing smoke concentration according to the formula v(k s ) = α + βk s to the experimental values, where K s is the extinction coefficient ([K s ]=m -1 ) and the values of the coefficients α and β are m s -1 and m 2 s -1, respectively. The walking speed in smoke is reduced in FDS+Evac along the lines given by these experiments conducted by Frantzich and Nilsson. It is assumed that the walking speed in smoke compared to the walking speed without smoke is same for all agents regardless of their different unimpeded walking speeds. Thus, FDS+Evac reduces the walking speed of agent i in smoke, v 0 i (K s ), using the formula { ( vi 0 (K s ) = Max vi,min, 0 vi β )} α K s, (11) where the minimum walking speed of agent i is v 0 i,min = 0.1 v 0 i by default, 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 fire products. The standard deviations of the experimental parameters α and β are reported to be σ α = m s -1 and σ β = m 2 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 fire products are treated by using Purser s Fractional Effective Dose (FED) concept [29]. The FED value is calculated as FED tot = (FED CO + FED CN + FED NOx + FLD irr ) HV CO2 + FED O2 (12) The fraction of an incapacitating dose of CO is calculated as FED CO = t (C CO (t)) dt (13) where t is time in minutes and C CO is the CO concentration (ppm). The fraction of an 27

26 3. Theoretical Basis for the Evacuation Model incapacitating dose of CN is calculated as ( ) t FED CN = exp CCN(t) dt (14) where t is time in minutes and C CN is the concentration (ppm) of HCN corrected for the protective effect of NO 2. C CN is calculated as C CN = C HCN C NO2 (15) The fraction of an incapacitating dose of NO x is calculated as FED NOx = t 0 C NOx (t) 1500 dt (16) where t is time in minutes and C NOx is the sum of NO and NO 2 concentrations (ppm). The Fractional Lethal Dose (FLD) of irritants is calculated as t ( CHCl (t) FLD irr = + C HBr(t) + C HF(t) + C SO 2 (t) + C NO 2 (t) + C C 3 H 4 O(t) 0 F FLD,HCl F FLD,HBr F FLD,HF F FLD,SO2 F FLD,NO2 F FLD,C3 H 4 O (17) where t is time in minutes, the nominators are the instantaneous concentrations (ppm) of each irritant and the denominators the exposure doses of respective irritants predicted to be lethal to half the population. The lethal exposure doses [29] are given in the table 2. To include the effect of an irritant gas not listed in the table, the user should specify F FLD in ppm min using the FLD_LETHAL_DOSE property of the corresponding SPEC line. + C ) CH 2 O(t) F FLD,CH2 O Table 2. Coefficients used for the computation of irritant effects of gases. HCl HBr HF SO 2 NO 2 C 3 H 4 O CH 2 O F FLD (ppm min) F FIC (ppm) The fraction of an incapacitating dose of low O 2 hypoxia is calculated as FED O2 = t 0 dt 60 exp [ (20.9 C O2 (t))] where t is time in minutes and C O2 is the O 2 concentration (volume per cent). The hyperventilation factor induced by carbon dioxide is calculated as HV CO2 = exp( C CO 2 (t) ) 7.1 where t is time in minutes and C CO2 is the CO 2 concentration (percent). Note that the effect of CO 2 is only due to the hyperventilation, i.e., it is assumed that the concentration of CO 2 is such low that it does not have direct narcotic effects. (18) (19) 28

27 3. Theoretical Basis for the Evacuation Model 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 from the other agents and walls and whose target movement speed, v 0 i, 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 modified in later versions of FDS+Evac. 3.5 Exit Selection According to socio-psychological literature [25, 32], the familiarity of exit routes is an essential factor influencing 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 fire drills. Also a common observation from real life evacuations has been that many occupants tend to select the exit where the majority of the others are heading. Such behavior seems to occur even if shorter and faster routes were available and clearly visible. This behavior is usually called herding. Recent observations on different egress situations (Rinne et al. [44]) give many examples where the exit usage during egress is not optimal. In almost all cases studied in that work, occupants used the exits of the buildings inefficiently. In some cases just one leaf of double leaf doors was used even though the other leaf could be opened just by pushing it. People decide to follow others using the part of the door that had the leaf already opened or held open by someone in front. This was seen to happen also when there was congestion in front of the doors, i.e., people had to slow down and wait a little bit to go through the door that had the leaf already opened. A related example is a fire drill in a vocational high school that had a staircase ending at ground level, where the usual way out was through the entrance hall. But there was also an emergency exit on a side wall at the bottom of the stairs. During the fire drill, it was observed that it took two and a half minutes before the emergency exit was opened, apparently by a safety organization member, and the evacuees started to use this way out. Just one person was enough to trigger the use of an emergency exit. Many prescriptive fire codes implicitly assume that the total exit width of buildings is used in egress. Herding behavior, as well as people s tendency to favor the familiar routes, may easily lead to outcomes that contradict with these assumptions. The exit selection algorithm of FDS+Evac was modified so that these kinds of phenomena could be modeled. Three new agent types were introduced in FDS+Evac so now there are four types: conservative type, active type, follower type, and herding type. The conservative type is the original agent type in FDS+Evac. The exit selection algorithm of FDS+Evac is based on a game theoretic model described and analyzed in detail by Korhonen and Hostikka [42], Ehtamo et al. [41], and Helià vaara et al. [43]. The agents observe the actions of the others and select the target exit through which the evacuation is estimated to be the fastest. The evacuation time of each agent to each exit is calculated from the distances to the exits and the congestion in front of the exits. The estimated evacuation time is not the only criterion considered in the model; also the visibility of the exits and the fire related conditions at the exits affect 29

28 3. Theoretical Basis for the Evacuation Model the decision, as well as the familiarity with the different exits, which can be defined for each agent by the user. These three criteria define five different exit groups as presented in Table 3. Note that the groups 4a-4c belong to the same preference order category. An agent regards a visible exit as a no smoke exit if there is less smoke than a user given amount along the bee line to the exit. For non-visible exits the smoke concentration at the position of the agent is used to estimate the presence of smoke or not. If there is no sign of smoke then it is assumed that there is no reason for the agents to prefer other routes than the familiar ones. If there is clues of smoke then the agents are more willing to use visible exits, familiar or not, than non-visible ones to get out safely. The agents select an exit with the smallest preference number, and only if two or more exits share the smallest preference, the decision between these is made by minimizing the estimated evacuation time. It is 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. Previously, all agents of FDS+Evac selected their target exits using this algorithm. This original agent type of FDS+Evac is the conservative agent type. The first new agent type is active agents, who use a different preference order for the exits than the conservative type. Active agents regard all visible exits also to be in the same preference group as familiar exits. The second new agent type is herding agents. Herding agents use only the familiar exits, if any given by the user. If there is no familiar exit at the current floor of the building then a herding agent looks its nearest neighbor agents and tries to follow them. The third new agent type is follower agents. A follower agent looks its nearest neighbors in front of it and check if exit where the neighboring agents are going is better than the current exit choice of the follower agent, i.e., the follower agent treats its neighbors target exit doors as familiar doors. The familiarity of each exit for each agent can be determined by the user in the inputfile 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 for the generated agents. 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 fire-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 lethal conditions at the visible part of the route, then exit has no preference. 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 approximation made, see Sec. 3.6 for details Conservative Agents The conservative agent type in the present versions of FDS+Evac (2.3.0 onwards) is modified from the older versions (prior 2.3.0). If there is some smoke at the exit routes then the preference order is modified a little bit. All visible exits and all known exits are put to the same preference group regardless of their familiarity when there is smoke on the exit 30

29 3. Theoretical Basis for the Evacuation Model routes as shown in Table 3, where these are all listed at the preference level four (4a 4c). It is assumed that the agents have higher stress and are willing to change their behavior such that any exit that leads out of the smoke is used. The other modification in the present program version is that L1 distance is used to describe the walking distance to the nonvisible exits and L2 distance is used only for the visible ones. L2 distance is the straight Euclidean distance between two points, while L1 distance is the sum of absolute differences in the coordinates of the points. The L1 distance is also called Manhattan metric. The name alludes to the grid layout of the streets of Manhattan, which causes the shortest path between two points to be equal to the L1 distance. We use the Manhattan metric to approximate the walking distance to non-visible exits because corridors and obstacles often make buildings resemble grid geometries. This approximation is used because the current version of FDS+Evac does not include calculation of the actual shortest path to non-visible exits. While the shortest path calculation is likely to be implemented in the future, L1 distance gives rather accurate approximations in most building geometries. The movement of the conservative agent type is triggered by the user given detection time and reaction time distributions. The detection time can be shorter than the user given distribution if there is enough smoke to trigger the detection. The smoke can be detected either by the local smoke concentration at position of the agent (detection by senses) or detection by a device (usually a smoke or a heat detector). If a conservative agent gets lost then it starts to behave like a herding agent for a while until it is able to locate an exit by its own reasoning. An agent is lost when it cannot see any exit and does not have any familiar exit in that part of the building. This might happen if an agent is using some visible but not familiar internal door to go to some other floor or connected space within the building. It might also happen that some of the familiar routes are blocked by smoke and the agent ends up using an unfamiliar route. Conservative type agents could be used in many building evacuation situations, e.g., the customers in a shopping mall, who know the main exits but are not so willing to use special emergency exits. Table 3. 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, if this colouring option is chosen by the user. Preference Visible Familiar Disturbing conditions 1 yes yes no black 2 no yes no yellow 3 yes no no blue 4a yes yes yes red 4b no yes yes green 4c yes no yes magenta No preference no no no cyan No preference no no yes cyan 31

30 3. Theoretical Basis for the Evacuation Model Active Agents The active agent type is very similar to the conservative agent type. The difference is that active agents observe their environment actively to find the fastest exit route. Hence, active agents prefer all visible exits similarly regardless if the exits are familiar or not. Detection and reaction times are like those of conservative agents and lost active agents are treated similarly to lost conservative agents. Heterogeneous crowds contain more and less observant occupants. The less observant will head to their familiar exits or follow others, while the more observant ones actively look for possible faster egress routes. The active agent type can be used to model these more observant crowd members. The existence of active agents may be very significant to the outcome of evacuations as, in addition to themselves, they may also lead herding agents to some normally unused exits. This kind of behavior was observed quite often in the evacuation drills and real fire alarms in Finland analyzed by Rinne et al. [44] Herding Agents The second new agent type is herding agents. These are assumed to be unfamiliar with the geometry and they will not use any exit, unless it is regarded as a familiar exit. Usually just the doors that they used to enter the building could be regarded as familiar exits. This agent type represents also lost agents, who can not figure out any available exit. Herding agents are looking around and seeing what the other agents are doing and, if some of the others are heading towards an exit, they start to follow these other agents. A herding agent will remain still even after detecting the fire and its reaction time has passed if it has not been able to select any exit either by being familiar with it or by observing other agents. If the nearest neighbors of a herding agent are heading towards some exit then the herding agent starts to follow these agents almost immediately regardless of its detection and reaction times. If there are available familiar exits at a given floor for a herding agent then it behaves like a conservative agent, i.e., the familiar route behavior overrides the herding behavior. A herding agent looks always around and checks where its nearest neighbors are heading. By default five nearest neighbors that are within a radius of 5 meters are included. The herding agent will follow the majority of its nearest neighbors. Only those nearest neighbors are considered that are heading away from the herding agent (cosine of the angle less than -0.2). This mimics the fact that the herding agent wants to follow other agents, not to lead them. The default distance is 5 m but the user may change this if it is not appropriate for the application in question. The default value was selected after some test simulations as it was seen to operate reasonably well for the verification cases. In principle, the distance should depend on the agent density and the typical room size of the building. But it was seen that this distance had no effect with reasonable design densities, because most of the agents have at least one neighbor within 5 m distance. If a herding agent has not been able to get any exit information from its nearest neighbors nor has it any familiar exit route available, then it looks for all visible agents and tries to find the nearest agent that is heading to some exit. It constantly updates this informa- 32

31 3. Theoretical Basis for the Evacuation Model tion as long as there are some visible agents heading towards exits. Note that also here the walking directions of the other agents have a similar effect as the effect of the moving directions of the nearest neighbors: If the other agent is heading towards the herding agent the direction is recorded when the moving agent has passed the herding agent. If all moving agents have disappeared then the herding agent will remember where the last visible moving agent went. If the herding agent has detected the fire and the reaction time has passed then the agent starts to move towards this previously recorded exit direction. If an agent is not able to find an exit after entering a floor through a door, it starts the herding behavior by checking the nearest neighbors and other visible agents. If the agent is not able to find any information of exits, it moves away from the entering door a couple of meters, stops there, and continues to observe other agents. At this point, the herding agent has already started to evacuate the building so the detection times and reaction times are not used anymore, i.e., the agent will continue to move immediately when it gets information on a new target exit to be used. The herding behavior could be easily modified to take into account effects like patron vs. personnel, child vs. adult, etc., where some agents are more likely to be followed than others. This could be modeled by giving different weights to the influence of different agent types. For now, the only effect that the user can specify is the distance dependence of the effect of the nearest neighbors on the decision of the herding agent. The user can specify that the nearer neighbors have larger weights than the more distant ones using a linear function Follower Agents The third new agent type is the follower agents, which are somewhere between conservative agents and herding agents. Follower agents use the same door selection procedure than the conservative agents, but they also see where the nearest neighbor agents in front of them are heading and include those exit doors in their list of possible exit doors. A follower agent will add the target exit door of its nearest neighbors to the familiar door list in the door selection algorithm. Thus, the follower agent will change its target door if the nearest neighbors seem to go to a "better" door, where "better" means shorter exit time constrained by the preference order table. Otherwise the follower agents behave like the conservative agents. 3.6 Numerical Method and Other Details The translational and rotational equations of motion are solved using a modified velocity- Verlet algorithm, where the translational motive force part is solved using a self-consistent dissipative velocity-verlet algorithm [35] 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 seconds, by default. The estimated evacuation time used in the exit door selection algorithm is approximated 33

32 3. Theoretical Basis for the Evacuation Model in the present version of FDS+Evac. The walking time to the exit door is simply approximated 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 for the visible doors (L2 distance) and for non-visible doors the L1 metric is used. The queueing time is calculated for the visible doors by counting how many agents are closer to the door than the present one and by dividing this number by an estimated flow through the door. The estimated human flow is given by the door width times the specific flow value given by the user (default 1.3 1/m/s). The presently chosen door is favoured so that 10 % longer time is tolerated by default. For the non-visible doors distance should perhaps be calculated along the exit path and also some kind of an estimated queueing time at the door should be added to the estimated evacuation time, but this is not yet implemented in the model. The queueing time is only estimated for those visible doors, which do not have disturbing conditions due to the fire. If there is disturbing conditions then the agents try to choose a door where the conditions are best. The default method to rank the best conditions is to choose the door, which is most visible through the smoke. The agents are updating their target exit doors on every second, on the average. The smoke density calculated by the FDS fire simulation can be used to detect a fire. 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 fire then user should give the detection threshold concentration (mg/m 3 ). An agent detects a fire 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 concentration affects the exit door selection algorithm. The user gives a threshold visibility value for a door to be considered as a smoke free door. A door is usable as long as the visibility is larger than half the distance to the door, where local visibility = 3/extinction coefficient. Similarly as for the smoke free case, the presently chosen door is favoured so that 10 % more smoke is tolerated by default. This makes the door selection algorithm more stable to a small changes in the smoke concentration. If there is no line-of-sight to the door, then the local concentrations at the position of the agent are used and the distance that is used is the L1 metric distance to the door. 34

33 4. Testing and Verification 4.1 Introduction In the verification test cases the default parameter values of FDS+Evac for the different predefined agent types were used unless otherwise stated. In many cases the simulation runs were also done using a value of λ i = 0.5 for the anisotropy parameter of the social force instead of the default value of λ i = 0.3, see Eq. (3). An archive of the verification tests of FDS+Evac are at the FDS+Evac web pages 1. 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 and random numbers are also used in the door selection and counterflow algorithms. For the qualitative verification, however, it is enough just to run the model once for each scenario. Same is true for the numerical verification of some of the sub-models. Some of the qualitative verification cases of the agent movement algorithm are based on the International Maritime Organization (IMO) document Guidelines for Evacuation Analyses for New and Existing Passenger Ships [33], where eleven different test cases are listed. These tests are referred below as IMO 1, etc. Note, that the IMO document specifies the test persons to be years old males defined in the table 3.4 of the IMO document [33]. This person group is similar to the default Male of FDS+Evac, but the unimpeded walking velocities are generated from an uniform distribution between 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 speeds. The tests suggested by IMO do not include any quantitative verification, because IMO sees that At this stage of development there is insufficient reliable experimental data to allow a through quantitative verification of egress models. Until such data becomes available the first three components of the verification process are considered sufficient.,

34 4. Testing and Verification where the first three components are component testing, functional verification, and qualitative verification. 4.2 Component Testing The movement algorithm of FDS+Evac was tested first 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 specified in the input. These simulations were performed in an evacuation trial mode, i.e., there was no smoke or fire 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 files of the test simulations from the FDS+Evac web pages and rerun the cases. This is especially true for some IMO verification 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. Two existing models for staircases (&CORR and &EVSS namelists in the input) were used. The third staircase model (&STRS namelist) was not used, because it models whole staircase including landings, so it can not be used to model one single flight of stairs. The 10 m distance was assumed to be measured along the incline and the speed was also calculated along the incline. 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 specifies if the agent is going up or down the stairs. 4. IMO 4 Exit flow rate: 100 persons in a room with a 1.0 m exit, the flow rate should not exceed 1.33 p/s. FDS+Evac passed the test, if an Male with the default parameter value λ i = 0.3 is used (1.24 p/s), see Fig. 6. If the a Male with (λ i = 0.5) is used then the flow is somewhat larger, 1.54 p/s. See also the door flow test case in Sec It should be noted that larger specific flows through doors than 1.33 p/s/m are obtained if wider doors are used even for the default case λ i = 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. This test is a little bit odd, because there is only 10 36

35 4. Testing and Verification Number of Persons y = -1.30x y = -1.52x Time (s) Adult 1 Adult 2 Slope 1 Slope 2 Figure 6. FDS+Evac results for the IMO test case 4. Day 1.0 Night 1.0 Prob. Density Density Evac, Dens. Distribution Evac, Distr Prob. Distribution Prob. Density Density Evac, Dens. Distribution Evac, Distr Prob. Distribution Time (s) Time (s) Figure 7. A response time test for truncated logarithmic normal distributions. agents in the simulation so one can not get out any good statistics. But one could see that each agent is starting accordingly to its randomly generated response time (both the response time and coordinates of the agent are printed out). To test better the random distribution properties, the IMO test case 9 was used, where there are 1000 agents. Two different response time distributions were used, the day and night case ones of the IMO document [33]. These are both truncated logarithmic normal distributions. The results of these tests are given in Fig 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. 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 specified in the input. FDS+Evac passed the test, see the test number IMO 5 above. The obtained distribution parameters for a FDS+Evac run were: variance=0.041 (0.035), average=1.282 (1.295), median=1.290 (1.295), 37

36 4. Testing and Verification FED1 All FED2 All FED3 All FED1 O2 FED2 O2 FED3 O2 FED1 CO FED2 CO FED3 CO FED1 CO2 FED2 CO2 FED3 CO2 FED Index (-) Time (s) Figure 8. A FED test. min=0.980 (0.970), max=1.620 (1.62), where the number in parentheses are the corresponding ones of the uniform distribution. The same analysis was made for the IMO test case 9. This case has 1000 agents, so the statistical significance of the test for the distribution is much better. The FDS+Evac results were: variance=0.036 (0.035), average=1.280 (1.295), median=1.280 (1.295), min=0.970 (0.970), max=1.620 (1.62), so it can be said that FDS+Evac passed the test. 8. FED calculation: To test the implementation of Fractional Effective Dose (FED) concept [29], a simple one room geometry with no fire source and one agent in the middle of the room is used. The agent is fixed at its initial position by setting the detection time large and by setting random noise of the movement equations to zero. FDS point measurements of the gas concentrations and FED are placed at the position of the agent. The room is initialized with different CO, CO 2, and 0 2 concentrations to test the overall FED calculation and each different component separately also. The concentrations for the four different calculations were: (2, 0.1, 15) %, (0, 0, 12) % (0, 0.1, 21) %, and (3.43, 0.1, 21) % for the (CO 2, CO, O 2 ) volume fractions. The room stays at the specified initial conditions, because there is nothing to generate a flow and also the initial random noise of FDS flow calculation is switched off. The FDS+Evac output for the FED index of the agent is compared to a value computed using an external worksheet and the FDS point measurements for gas concentrations and for the FED index. The results of the comparison are shown in Fig. 8. The results indicate that the FED calculation in FDS+Evac is implemented correctly (and that the FED point measurement output is also 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 10 m long corridor geometry. The unimpeded walking velocity for a smoke clear environment 38

37 4. Testing and Verification Velocity (m/s) Extinction coefficient (1/m) Theory FDS+Evac Soot density (mg/m 3 ) Figure 9. A smoke vs speed test. was set to 1.5 m/s. Four different calculations with soot densities of 0, 500, 1000, and 1500 mg/m 3 were performed. Soot was introduced in the calculations as an initial mass fraction and the default initial random fluctuations of FDS were set to zero and no flow was introduced in the corridor so the constant initial conditions prevail the same during the simulation. The result of this test is shown in Fig. 9. The line labeled as Theory is the experimental correlation given by Eq. (11). The velocities of the agents in FDS+Evac simulations were calculated using the time needed to travel the last 5 m in the corridor. The results show that FDS+Evac accurately reproduces the anticipated reduction of walking speed. 4.3 Functional Verification For the functional verification 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, the FDS+Evac web pages, and the open source code of the programme hosted by Google Code 2 satisfy this criterion. 4.4 Qualitative Verification 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 performed in an evacuation trial mode, i.e.,

38 4. Testing and Verification there was no smoke or fire 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 files 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 programme is working as it should. 1. IMO 8 Counterflow two rooms connected via a corridor: Two m 2 rooms are connected with a 10 m 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 counterflow increases. FDS+Evac results were s, s, s, and s for the four cases, where there were 0, 10, 50, and 100 persons in the room 2, respectively. FDS+Evac passed the test. 2. IMO 9 Exit flow crowd dissipation from a large public room: A m 2 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 s and s when all four doors were open and when two doors were closed, respectively. These times were s and s when the parameter value λ i is changed to 0.5. Note that the flows through the 1.0 m wide doors were below 1.33 p/s when an Male with the default parameter value λ i = 0.3 were used (1.19 and 1.23 p/s for the cases all doors open and two doors open, respectively). For the parameter value λ i = 0.5 the flows through the doors are slightly larger, 1.67 and 1.67 p/s. See also the door flow test case in Sec 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 file 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 fine mesh to construct the guiding floor flow fields 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. This problem did not arise also when a grid cell sizes of 0.3 m was used both for the x and y directions. Using this mesh the test geometry was modified just a little bit, the cabinet depths were 5.1 m, not 5.0 m as specified in the IMO document. 40

39 4. Testing and Verification Figure 10. The IMO 11 staircase test case modelled by FDS+Evac using the EVSS method. Figure 11. 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. 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 m wide stairs going upwards. The expected result is that congestion appears at the exit from the room, which produces a steady flow 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 definition of the staircase. The &EVSS model for staircases was used, see Fig. 10. The third staircase model (&STRS namelist) was not used, because it models whole staircase including landings, so it can not be used to model one single flight of stairs. 5. Decision making model without smoke: The verification of the exit door selection algorithm of FDS+Evac was tested using the geometry shown in Fig. 11. On the left the the agents are coloured according to their target exit doors (blue: right bottom exit; green: top left exit) and on the right the colours of the agents mark the preference categories of the exit door selection algorithm (black: known visible 41

40 4. Testing and Verification Figure 12. 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. Shown is also the calculated visibility, where red indicates good and blue very bad visibility, see the colour bar. 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 defined as known doors in the input. Figure 11 verifies that the door selection algorithm works as intended when there is no smoke. The agents first 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 (L2 norm) 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 or using L1 norm. 6. Decision making model with smoke: The above test was modified by adding a fire that produces smoke to the building. In Figure 12 the visibility is shown at the height of the human eyes after 15 s from the ignition as a colour bar. On the right the agents are coloured according to their target exit doors and on the right the colours of the agents mark the preference categories of the exit door selection algorithm. Now the smokiness has changed the preferences. First choices are still the doors with no smoke. The input files for the exit selection tests are on the FDS+Evac web page an interested reader is able to reproduce 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. [11]. The properties of 42

41 4. Testing and Verification the exit selection algorithm are examined in the paper by Ehtamo et al. [41]. 43

42 5. Model Sensitivity 5.1 Introduction This section concentrates on the effects of different input parameters on the FDS+Evac results. Especially the flows through doors, corridors, and stairs are examined, because these are usually the main bottlenecks of an evacuation event in 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 were done in a fire drill mode, i.e., the egress processes were simulated without any fire calculation. Note that many of these sensitivity studies are done using program version: FDS 6.0.0, Evac These results should also apply to the current version (FDS 6.5.3, Evac 2.5.2), because the basic movement algorithm has not been changed and the (default) parameters of the movement models are the same. 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 define the geometry of the calculation. The most obvious mesh sensitivity issue is that the spatial resolution of the obstructions, like doors, stairs, etc., is the resolution of the underlying mesh. The other, subtler effect, is the way how the mesh resolution changes the flow fields of the evacuation meshes, which are used to guide the agents towards the exit doors. In some cases, a finer grid does not always mean a better guiding field for agents. If the evacuation mesh resolution is much less than half of the body dimension then one may find some difficulties to obtain nice evacuation flow fields, see the IMO test case 10 in Sec. 4.4 and the FDS+Evac web pages for further details. The FDS fire 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 inside each evacuation mesh cell. How accurate are the predictions of FDS for the fire products will, of course, depend on the FDS mesh resolution. See the 44

43 5. Model Sensitivity 2 m 10 m 2 m 10 m 5 m 5 m 2 m 10 m m 2 m Figure 13. Test geometries used to calculate the specific flows through doors and corridors. FDS Technical Guide [4, 5, 6] for the effects of the mesh resolution on the FDS fire calculation. The evacuation calculation interpolates the fire calculation results to the 2D evacuation meshes and the evacuation mesh resolution will have an effect on the spatial accuracy of this fire related information, but usually grid sizes are equal or less than the dimensions of a human body and, thus, the accuracy of the fire information in the evacuation meshes is fine enough for the accuracy level of the evacuation calculation. The default height, where the toxic gas concentrations are taken, is 1.6 m above the floor level. Changing this value will have large effect on the FED index calculation, of course. If the user wants to be on the safe side, then one should use height which is a little bit above the head positions of the escaping humans, but this depends on the room geometry, especially the height of the room. There are many more important factors affecting the calculation of the fire agent interaction than the spatial resolution of the evacuation and fire 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 model, τ i, τ z i, ω 0 i, the parameters of the social force, A i, B i, λ i, and the parameters of the contact force, k i, κ i, c d. To test the relative importance of these parameters, Monte Carlo simulations were performed to find the parameters, which have the greatest effect on specific flows. The calculations were done using Evac version Two different geometries were used in the Monte Carlo simulations, see Fig. 13. One of the geometries was used to study the flow through a narrow door and through a wide door and the other geometry was used to study flows in a corridor using densities 1.0 and 2.0 persons per square metre. There were 100 agents randomly located at the 5 5 m 2 square in the door flow calculations. Corridor flow calculations had 96 or 192 agents inside the corridor depending on the density. Thousand egress simulation with 45

44 5. Model Sensitivity v 0 Corr 2.0/m2 Corr 1.0/m2 Door 0.8 m Door 2.0 m w z A w A B B w Corr 2.0/m2 Corr 1.0/m2 Door 0.8 m Door 2.0 m 0 c d I z Rank Correlation Coefficient Rank Correlation Coefficient Figure 14. Rank correlation coefficients (RCC) for specific flows 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. 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 twelve model parameters, A i, B i, λ i, v 0 i, τ i, A w, B w, λ w, ω 0 i, τ z i, I z i, c d were varied ±20 % about their means using uniform distributions. The monitored output quantity was the specific flow in all cases and the Spearman s rank correlation coefficients (RCC) were calculated for these four cases and they are shown in Fig. 14. It is seen from Fig. 14 that the parameters A i, B i, λ i, v 0 i, τ i, and B w have the largest impact on the specific flows through doors and corridors. Thus, further simulations were 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 flow was calculated using a density of 2.0 persons per square metre, because it is known that around this density the specific flow has its maximum value. For the density 1.0 persons per square metre the corridor flow is mainly specified 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 simulations, are shown in Fig. 15, where each marker represents the average of 100 simulations. Note that in FDS+Evac the initial properties and positions of the agents are not deterministic, because agents are randomly positioned, the parameters R d, v 0 i, and τ i, are sampled from random distributions and there are small random forces in Eqs. (1) and (5). Increasing the values of A i and B i increases the social force which tries to keep agents apart from each other and, thus, the specific flow 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 i and/or B i, will make a forward walking person to reduce his/her speed in order not to step on someone s heels, when the anisotropy parameter, λ i, is less than unity. Increasing the walking velocity will, of course, increase the specific flow. Decreasing τ i, i.e., increasing the motive force to go forward, increases specific flows 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 46

45 5. Model Sensitivity Specific Flow (p/m/s) Corr 2 p/m2 Door 2 m Door 1 m Specific Flow (p/m/s) Corr 2 p/m2 Door 2 m Door 1 m Specific Flow (p/m/s) Corr 2 p/m2 Door 2 m Door 1 m A i (N) B i (m) i (-) Specific Flow (p/m/s) Corr 2 p/m2 Door 2 m Door 1 m Specific Flow (p/m/s) Corr 2 p/m2 Door 2 m Door 1 m Specific Flow (p/m/s) Corr 2 p/m2 Door 2 m Door 1 m v 0 i (m/s) i (s) B i (m) Figure 15. Effects of different model parameters, A i, B i, λ i, v 0 i, τ i, and B w on the specific flows 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. 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 B w is to modify the effective width of doors and corridors, thus, increasing its value will make the effective width smaller and this will decrease specific flows slightly. 5.4 Sensitivity of the Counterflow Algorithm The agent movement algorithm to deal with counterflows in FDS+Evac has many parameters. To test the relative importance of these parameters, Monte Carlo simulations were performed to find the parameters, which have the greatest effect on specific flows. The calculations were done using FDS+Evac version In total fifteen different parameters introduced in the collision avoidance algorithm were varied. The default values of the parameters are listed in Table 4. Two different geometries were used in the Monte Carlo simulations. One was the door 47

46 5. Model Sensitivity c df c ncf d df a min,cf c cf a w,cf Corr 2.0 m Corr 4.0 m Door 1.0 m Door 2.0 m c 1w d v0 d cf c 2w c v0 Corr 2.0 m Corr 4.0 m Door 1.0 m Door 2.0 m c min b min,cf z min Rank Correlation Coefficient Rank Correlation Coefficient Figure 16. Rank correlation coefficients (RCC) for the emptying time through doors and corridors. Door widths 1.0 m and 2.0 m were used for doors and widths of the corridors were 2.0 m and 4.0 m were used for corridors in the IMO test case 8 geometry. geometry shown in 13, where 1.0 m and 2.0 m wide doors were used. There were 100 agents randomly located at the 5 5 m 2 square in the door flow calculations. The other test geometry was the IMO test case 8 geometry, which has two m 2 rooms connected by a 10 m long corridor. Corridor widths of 2.0 m and 4.0 m were used and both rooms contained initially 100 agents. The monitored output quantity was the specific flow in the door geometry and in the corridor case the entering time of the last agent from the left room to the right room was recorded. The Spearman s rank correlation coefficients (RCC) were calculated for these four cases and they are shown in Fig. 16. 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 fifteen different parameters of the counterflow model were varied about their means using uniform distributions. According to the RCC calculations some of the most important parameters of the counterflow model were examined further by doing a parametric studies, where different parameters were varied separately and 100 simulations were done for each discretely chosen value of the parameters. Chosen geometries were the IMO test case geometry with 2.0 m wide corridor and door geometries with 1.0 m and 2.0 wide doors, but these were not used for all the chosen model parameters. Only those parameter vs geometry cases were chosen where the RCC were reasonably large. The results are shown in Fig. 17, the markers are averages of the 100 simulations and standard deviations of the 100 simulations are shown as error bars. It can be seen that the chosen model for the collision avoidance does not have a large effect on the flows through doors if reasonably parameter values are used. This is a good result, because the intention was not to change the calculated flows through doors in situations where there is no counter flow. The earlier versions of FDS+Evac were already doing a nice job in these situations. For the counterflow test case, IMO test 8, there can be some variations of the results as the different parameters are varied, but these variations are not generally large and in quite many cases are within the error bars. Finally, it was decided to use the values given in Table 4 for the different parameters of 48

47 5. Model Sensitivity IMO 2m IMO 2m IMO 2m Door 1m Time (s) Time (s) Time (s) Specific Flow (p/m/s) C (-) C 1w (-) A min,cf (-) IMO 2m Door 2m Door 1m Door 2m IMO 2m Time (s) Specific Flow (p/m/s) Specific Flow (p/m/s) Time (s) C ncf (-) D v0 (-) C v0 (-) Door 2m IMO 2m Door 1m Door 2m Specific Flow (p/m/s) Time (s) Specific Flow (p/m/s) C 2w (-) D df (-) C df (-) Figure 17. Effects of different counterflow model parameters on the specific flows through doors and on the emptying time of the left room for IMO test case 8. The corridor in the IMO case is 2.0 m wide, and two different doors widths, 1.0 m and 2.0 m, are used. the counterflow model. These parameters are probably not optimal for counterflow, but they are at least working moderately good. And by changing them a little bit would not affect the outcome of the calculation much. For now the collision avoidance method is quite short range and it does not try to model the way finding of real humans in crowds too realistically. The main idea of the model to enable counter flow with reasonable high agent densities using a short range collision avoidance. The parameters which are used to 49

48 5. Model Sensitivity Table 4. The default values used for the short range collision avoidance algorithm in FDS+Evac. Most of the values are just dimensionless factors but the two minimum relaxation time constants have dimensions. The lables before the default values are the keywords that can be used on the PERS namelist to change the values. c df CONST_DF=2.0 Prefer agents same direction d df FAC_DF=1.0 Prefer agents same direction c cf CONST_CF=1.0 Dislike agents opposite direction d cf FAC_CF=2.0 Dislike agents opposite direction c 1w FAC_1_WALL=5.0 Dislike directions towards walls c 2w FAC_2_WALL=10.0 Dislike much if going if too close to a wall c v0 FAC_V0_DIR=1.0 If counterflow, prefer straight ahead + right d v0 FAC_V0_NOCF=1.0 Prefer v0 if no counterflow c ncf FAC_NOCF=2.0 Prefer v0 if no counterflow a min,cf CF_MIN_A=0.5 If counterflow decrease social force b min,cf CF_MIN_B=0.3 If counterflow decrease social force a w,cf CF_FAC_A_WALL=1.0 If counterflow decrease social force c τ CF_FAC_TAUS=0.25 If counterflow increase motive force τ min CF_MIN_TAU=0.1 s If counterflow increase motive force τmin z CF_MIN_TAU_INER=0.05 s If counterflow increase motive force avoid the directions towards walls in the collision avoidance algorithm are mainly chosen by trial and error. It was checked that these were not affecting the normal situation (no counterflow) and that in counterflow situations the agents did not try to push too hard against the walls in some different geometries. Some other parameters were chosen similarly by checking their possible ranges so that they did not change the behaviour of FDS+Evac when there was no counterflow. For example, if there are crowding but every agent is trying to go more or less towards the same direction then the original v 0 direction is preferred. For this kind of short range collision avoidance method it is better that the agents are not changing their behaviour in the normal situation. Optimizing the decision making of an agent in general would need much more long range route planning including vision. If there are dense crowds at the doors queueing then the exit selection algorithm will mainly decide the outcome of the overall evacuation event, not this kind of short range interaction at the crowded doors, where there is no matter who is getting first out on the overall performance of the evacuation situation. 5.5 Summary One should be very careful when constructing the geometry, where agents are moving. One should use Smokeview to see the guiding flow fields for the agents before making a full evacuation simulation. To see the actual evacuation geometry and the flow fields, one should do just a plain evacuation calculation without any fire meshes and see the results in Smokeview. One should especially check that there are no smaller than about 0.7 m 50

49 5. Model Sensitivity 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. (1) (9), are understood well and user should not usually use any other than the predefined person types in FDS+Evac. The default predefined person types use a value of 0.3 for the anisotropy parameter, λ i, of the social force. For some applications the resulting specific flows may be considered to be too low. If this is the case then the user should use 0.5 as the value of λ i. Note that in the earlier versions of the programme the default value of this parameter was

50 6. Model Validation 6.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 confidence 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, the model predictions are tested against experimental data from evacuation experiments and trial evacuations in this chapter. The model predictions are also compared to the predictions of some 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 flows on horizontal paths and stairs. Most of the calculations were done using FDS version (Evac version 2.5.2). The specific flows through doors and corridors were done using FDS version (Evac version 2.5.2). These should be valid for the version 6.5.3, because the evacuation calculation should be the same (except some minor bug fixes etc.) and these test cases are done in fire drill mode, i.e., no fire meshes are defined. 1. Specific flows through corridors: In the research of pedestrian flows, the dependence of the specific human flow rate on the human density is called as fundamental diagram. It shows how the specific flow first 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 specific flow rates given by the FDS+Evac code are compared to experimental walking velocities on horizontal floors in corridor geometry. The geometry is shown in Fig. 13. The corridor is modelled as a loop to avoid the effects of inflow and outflow boundary conditions. In Figure 18, the predicted flow rates are compared against some experimental results for pedestrian traffic flows taken from Daamen s thesis [36]. Note that almost all of the experimental information is obtained by studying bidirectional pedestrian flows, the results for 52

51 6. Model Validation 3.0 Specific Flow (1/m/s) FDS+Evac Default Fruin Navin & Wheeler Pauls Sarkar & Janardhan Virkler & Elayadath FDS+Evac Fast Lam et al. Older Polus et al. Tanariboon et al. SFPE Density (1/m 2 ) Figure 18. The specific flows in corridors, FDS+Evac results are compared to experimental values Adult Male Female Elderly SFPE: Nelson Adult, fast Male, fast Female, fast Elderly fast Flow (1/m/s) Density (1/m 2 ) Figure 19. The specific flows in corridors for the different default agent types of FDS+Evac. unidirectional flows might give different results. The FDS+Evac simulations were performed with two different parameter sets, labels default refer to the defaults of FDS+Evac and labels fast refer to parameter sets, where λ i = 0.5 is used. In Figure 19 the calculated specific flows in the corridor geometry are shown for four predefined agent types in FDS+Evac. Calculations were done using FDS version

52 6. Model Validation 2. Staircase of an office building: An evacuation experiment at a large office building [13] was modelled using FDS+Evac. Since the experiment was strongly focused on just one staircase, only this staircase was modelled. Figure 20 shows the geometry of the studied staircase. The actual dimensions and door positions can be found in the experimental report [13]. The experimental entry times of humans to the stair landings were taken as inputs to the simulations. The standard adult person type of FDS+Evac was used in the simulations. Two different values were used for the anisotropy parameter of the social force, λ i = 0.3 which is the default, and λ i = 0.5 which corresponds to more rapid egress. The calculations for staircases were performed using all models for staircases available in FDS+Evac. In Figure 21 the experimental observations are compared to the simulation results obtained by using the simple staircase model (type 1). This model is implemented using the CORR namelist, which is a crude model for stairs. The simulations were run several times corresponding to different values of the staircase speed reduction parameter. Reducing the unimpeded walking speed by a factor 0.5 seems to give a good agreement with the observations. Two different values of the anisotropy parameter of the social force are used, λ i =0.3 (the default in FDS+Evac) and λ i =0.5. The λ i =0.5 results seem to reproduce the experimental findings better than the default value 0.3. A speed reduction factor 0.5 seems to produce more or less quite constant flow at the exit door, i.e., at these speed reduction values the stairs are feeding the front door fast enough. For the case with λ i =0.3 the specific flow in FDS+Evac simulations is about 1.16 p/s/m and for the case with λ i =0.5 the flow is about 1.30 p/s/m at the final exit door (speed factor 0.75). The observed flow rate at the final exit door (width 1.07 m) was 1.35 p/s in the experiment. Figure 20. A snapshot from a FDS+Evac simulation showing the geometry of the staircase. 54

53 6. Model Validation Count Stairs, type 1, l = 0.3 Evac, k=0.2 Evac, k=0.5 Evac, k=0.6 Evac, k=0.7 Evac, k=0.75 Evac, k=0.8 Evac, k=0.9 Evac, k=1.0 Exper Count Stairs, type 1, l = 0.5 Evac, k=0.2 Evac, k=0.5 Evac, k=0.6 Evac, k=0.7 Evac, k=0.75 Evac, k=0.8 Evac, k=0.9 Evac, k=1.0 Exper Time (s) Time (s) Figure 21. Comparison of FDS+Evac (staircase model type 1) and experimental observations of a staircase flow. Values λ i = 0.3 (left) and λ i = 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. Count Stairs, type 2, l = 0.3 Evac, k=0.2 Evac, k=0.5 Evac, k=0.6 Evac, k=0.7 Evac, k=0.75 Evac, k=0.8 Evac, k=0.9 Evac, k=1.0 Exper Count Stairs, type 2, l = 0.5 Evac, k=0.2 Evac, k=0.5 Evac, k=0.6 Evac, k=0.7 Evac, k=0.75 Evac, k=0.8 Evac, k=0.9 Evac, k=1.0 Exper Time (s) Time (s) Figure 22. Comparison of FDS+Evac (staircase model type 2) and experimental observations of a staircase flow. Values λ i = 0.3 (left) and λ i = 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. The results using a more sophisticated way of defining staircases (type 2) are compared to the observed values in Fig. 22. In these simulations, the stairs are modelled as inclines (EVSS namelist), where agents move at reduced speed. Reducing the unimpeded walking speed by a factor 0.7 seems to give a good agreement with the observations. Note that there exists some queuing at the final exit door opening to the street in the experiment and this is also seen in the simulation results, when the speed reduction parameter is not too low. For the case with λ i =0.3 the specific flow is about 1.17 p/s/m and for the case with λ i =0.5 the flow is about 1.30 p/s/m at the final exit door (speed factor 0.75). Similar flows were also obtained when using the simple staircase model (type 1). When a speed reduction factor 0.7 is 55

54 6. Model Validation Count Stairs, type 3, l = 0.3 Evac, k=0.2 Evac, k=0.5 Evac, k=0.6 Evac, k=0.7 Evac, k=0.75 Evac, k=0.8 Evac, k=0.9 Evac, k=1.0 Exper Count Stairs, type 3, l = 0.5 Evac, k=0.2 Evac, k=0.5 Evac, k=0.6 Evac, k=0.7 Evac, k=0.75 Evac, k=0.8 Evac, k=0.9 Evac, k=1.0 Exper Time (s) Time (s) Figure 23. Comparison of FDS+Evac (staircase model type 3) and experimental observations of a staircase flow. Values λ i = 0.3 (left) and λ i = 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. used seems to produce more or less quite constant flow at the exit door, i.e., at these speed reduction values the stairs are feeding the front door fast enough. The results using a most sophisticated way of defining staircases (type 3) are compared to the observed values in Fig. 23. In these simulations, the whole stairs are modelled as one single object using STRS namelist, where agents move at reduced speed on stairs flights and normal speeds on landings. Reducing the unimpeded walking speed by a factor 0.6 seems to give a good agreement with the observations. Note that there exists some queuing at the final exit door opening to the street in the experiment and this is also seen in the simulation results, when the speed reduction parameter is not too low. For the case with λ i =0.3 the specific flow is about 1.18 p/s/m and for the case with λ i =0.5 the flow is about 1.40 p/s/m at the final exit door (speed factor 0.75). Similar flows were also obtained when using the other staircase models. When a speed reduction factor 0.6 is used seems to produce more or less quite constant flow at the exit door, i.e., at these speed reduction values the stairs are feeding the front door fast enough. 3. Public library: An observed evacuation experiment of a public library [13] was simulated to study the capability to predict the entire movement phase of the evacuation, consisting of movement inside the floor, queueing to the staircase and finally movement through a narrow staircase to the exit. The simulation geometry and the initial positions of the persons are shown in Fig. 24. 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 first floor. In the simulations, only the second floor of the building was simulated and people originating from the first floor were placed into the second floor. The north door was the only door with observed crowding. The decision making processes were not modelled. Instead, the people were allo- 56

55 6. Model Validation NORTH DOOR MAIN EXIT B MAIN EXIT A WEST DOOR Figure 24. A snapshot from a FDS+Evac simulation shows the geometry of the FDS+Evac model for the second floor of the public library. Number of Persons Evac k=0.5 N Evac k=0.6 N Evac k=0.7 N Evac k=0.8 N Evac k=0.9 N Evac k=1 N North Door l = 0.3 Evac k=0.5 W Evac k=0.6 W Evac k=0.7 W Evac k=0.8 W Evac k=0.9 W Evac k=1 W West Door Number of Persons Evac k=0.5 N Evac k=0.6 N Evac k=0.7 N Evac k=0.8 N Evac k=0.9 N Evac k=1 N North Door l = 0.5 Evac k=0.5 W Evac k=0.6 W Evac k=0.7 W Evac k=0.8 W Evac k=0.9 W Evac k=1 W West Door Time (s) Time (s) Figure 25. Comparison of FDS+Evac simulation results and observations at the north and west doors of the public library. cated for the north and west doors according to the ratio observed in the experiment. The simulations were performed using the standard agent type Adult and the stairs at the north and west doors were modelled using the EVSS namelists. The pre-movement 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 flows is shown in Fig. 25. On the left hand side the results of the simulations with default parameters is shown and on the right hand side the anisotropy parameter of the social force is increased from the default value (λ i = 0.3) to λ i = 0.5. The calculations have been done using different values for the speed reduction factor in stairs, values 0.5, 0.6, 0.7, 0.8, 0.9, and 1.0 were used. As can be seen, the predicted flow rates agree in general 57

56 6. Model Validation with the experiments. The default value for λ i gives a little smaller flows than the experiment whereas the increased value for λ i produces a little bit too fast flows. From these results it can be argued that a moderate, say , speed reduction factor in stairs seems to produce good results. For the west door, the results reflect the goodness or badness of the assumed pre-movement time distribution because the flow rate through the door is quite small. For the north door, the simulation is very relevant, because the flow rate is mainly determined by the geometry and the crowd dynamics during the queueing process. 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 files 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 [12]. These calculations were done using FDS+Evac version Sports hall: FDS+Evac simulations were compared to Simulex [23, 26, 27, 28] simulations in a sports hall shown in Fig. 26. The hall was previously analysed by Paloposki et al. [37]. 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 wide double leaf door. 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 fire starts close to 18 m 74 m 18 m Door 4 Door 5 20 m 5 m 72 m 25 m Door 2 3 m 44.5 m Door 1 Door 3 Figure 26. 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 fire location, which is close to door 3 and, thus, this door is not used. 58

57 6. Model Validation Number of Humans Sim LogN Sim Normal Evac LogN Evac Normal Evac2 LogN Evac2 Normal Time (s) Figure 27. The comparison of FDS+Evac to Simulex in a sport hall case. The average of five different simulations are shown for each case. door 3 (the shaded rectangle in Fig. 26) 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. These numbers are user input, so the door selection algorithm of FDS+Evac is not used in this example case, because also in the Simulex simulation the usage of the doors was described before the simulation. Persons are initially located at the east end of the hall in an area of m 2 (the open rectangle in Fig. 26). Two different reaction time scenarios were considered, one having a normal distribution with a standard deviation of 15 s and mean 60 s, and the other one having a log-normal distribution (median 75 s, standard deviation of the logarithm of reaction time was 0.7). Actually, the lognormal 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, see the report by Paloposki [37] for further details. The results of the simulations are shown in Fig. 27. The FDS+Evac simulations were done using 0.5 m mesh cell division, so the door widths were fitted to this resolution. The door widths used in the simulations were 1.0 m (doors 4 and 5), 4.0 m (door 2), and 1.5 m for the main entrance. Since both FDS+Evac and Simulex are modelling human egress as a stochastic process, the presented results were collected from five 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 flow through this door is larger in Simulex than in FDS+Evac. The flow through this door in the FDS+Evac simulations is 1.29 p/s for the case, where normal distribution was used for the reaction times and the default values for the anisotropy parameter λ i is used ( Evac2 ). If a value of 0.5 is used for the anisotropy parame- 59

58 6. Model Validation Exit 2 Exit 3 Exit 1 Figure 28. The geometry of the open floor office test case. ter λ i the flow is increased to 1.67 p/s ( Evac ). The other doors are not as crowded and there the capacities of the doors do not show up as much. 2. Open floor office: This test geometry was an open floor office, whose floor plan is shown in Fig. 28. The floor has dimensions of m 2 and there are initially 216 persons on this floor. The properties of these agents were assumed to be as the Office 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. Number of Humans Evac d123 Evac d23 Evac d13 Evac d12 Evac d1 Evac d2 Evac d3 Sim d123 Sim d23 Sim d13 Sim d12 Sim d1 Sim d2 Sim d Time (s) Figure 29. The comparison of FDS+Evac to Simulex in an open floor office case. 60

59 6. Model Validation 12.8 m 7.2 m 20 m 21.4 m 7.2 m 50 m 7.2 m 10 m 60 m Figure 30. A snapshot from (a) FDS+Evac, (b) Simulex calculation. The widths of the doors opening to the stairs are 1.2 m. In total seven different 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 Fig. 29. 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, but it can be noticed that FDS+Evac predicts somewhat longer evacuation times than Simulex. This can once again be traced back to the fact that FDS+Evac with the default value of 0.3 for the anisotropy parameter of the social force gives little bit smaller specific flows at doors than Simulex. It should be mentioned, that in the FDS+Evac simulations, the initial (random) positions of agents do not change between different door scenarios (see Fig. 28), 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. 61

60 6. Model Validation Number of Humans Evac, corr Evac, door Evac2, corr Evac2, door Sim, corr Sim, door Exo, corr Exo, door Time (s) Figure 31. The comparison of FDS+Evac to buildingexodus and Simulex in an assembly space. 3. Assembly space: The third test case is a large fictitious assembly space having dimensions of m 2 and 1000 people initially inside. There is only one 7.2 m wide corridor leading to the exit. The geometry is shown in Fig. 30. The FDS+Evac results ( Evac2 ) are compared to those of Simulex ( Simulex ) and buildingexodus [38] ( Exodus ) in Fig. 31. Note, that the FDS+Evac simulations were also done using parameters describing more rapid egress (labels Evac ), where the value of the anisotropy parameter of the social force, λ i, had a value of 0.5 instead of the default 0.3. 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 Fig. 30. Simulex and buildingexodus are not using the whole width of the corridor efficiently, 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. The calculated specific flows (1/p/m) are: Simulex 0.47, Exodus 0.69, FDS+Evac 1.23 (λ i = 0.3), and 1.57 (λ i = 0.5). In Figure 31 also shown are the results of the simulations for a case, where there is 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 specific flows (1/p/m) are: Simulex 1.59, Exodus 1.95, FDS+Evac 1.62 (λ i = 0.3), and 2.01 (λ i = 0.5). 4. Specific flows through doors: The fourth test geometry is the same one as used in Sec. 5.3 for human parameter sensitivity studies and it is shown on the left hand side in Fig. 13. This geometry is commonly used in the literature to calculate the specific flows through doors. In the test, there are 100 agents randomly located at 62

61 6. Model Validation the 5 5 m 2 square in front of the door. In Figure 32, the results of FDS+Evac simulations for specific flows through doors are compared to simulation programmes Simulex and MASSEgress [25]. The FDS+Evac results are the the averages of 100 simulations and shown are also standard deviations as error bars. The results of the programmes MASSEgress and Simulex are extracted from Pan s thesis [25], where Simulex version from year 1998 was used. Shown are also results calculated using Simulex version ( Simulex, VTT ), where the standard Simulex person type Office Staff was used and the exit was about 2.5 m behind the hole describing the door line, which allows the agents queueing at the door to feel the agents that have just gone past the (imaginary) door line. If agents are removed right at the door then the (specific) flows could be much larger as stated in the Simulex User Guide [24]. The FDS+Evac simulations are performed with two different parameter sets, labels Male / Female / Adult / Elderly refer to the corresponding default agent types of FDS+Evac and labels Male 2 / Female 2 / Adult 2 / Elderly 2 refer to parameter sets, where λ i = 0.5 is used. It is seen that FDS+Evac is able to produce reasonable flows through doors. For some applications, the flows generated by the default parameter values may be considered too low, but it is quite straightforward to modify the parameters of FDS+Evac to reach specific flows that are more relevant to a specific egress case. 2.5 Specific Flow (1/m/s) MASSEgress Simulex, Pan Simulex, VTT FDS+Evac: Default FDS+Evac: Fast Door Width (m) Figure 32. The specific flows through doors. 63

62 6. Model Validation 2.5 Specific Flow (1/m/s) Adult Adult, fast Male Male, fast Female Female, fast Elderly Elderly, fast Door Width (m) Figure 33. The specific flows through doors for the predefined FDS+Evac agent types. Labels fast refer to agent types, where the social force parameter lambda is

63 7. Running FDS+Evac NOTE: THIS SECTION IS NOT YET UPDATED FULLY FOR FDS 6 BASED EVACU- ATION MODULE. Check the web pages and the fds-smv discussion forum for the usage of the FDS6 based evacuation module. The V&V part of this manual is already updated for FDS6. The instructions below are valid for the FDS version 6 based evacuation module, but many new keywords are not listed and explained there. Running FDS+Evac is similar to running FDS, i.e., relatively simple. All of the parameters that describe a given fire and egress scenario are typed into a text file that will be referred to as the fds or the input file. In this document, the user input data file 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 file name so that all of the files associated with a given calculation will have a common prefix. In Chapter 10, two example input files will be presented. Several other example files exist at the FDS+Evac web site It is suggested that a new user starts with an existing input file, runs it as is, and then makes the appropriate changes to the input file 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 files. If the user wants to do a combined fire and evacuation simulation, she/he should first learn how to do fire simulations using FDS. If the user is not experienced on doing FDS fire simulations, it is suggested that the user uses FDS+Evac just to simulate fire drills, i.e., simulate only the egress part of the problem. Even in this case the user should read carefully the User s Guide of FDS [3], because the evacuation simulation geometry is constructed similarly as the fire simulation geometry. The evacuation geometry is constructed using two-dimensional horizontal cuts of the true three-dimensional (fire) geometry. The evacuation geometry should contain the walls but not the floors or ceilings. One should keep this in mind when defining the z-coordinates of the evacuation meshes. The floor and ceiling should be outside of the z-range of the evacuation mesh in question. 65

64 7. Running FDS+Evac 7.1 Starting a FDS+Evac Calculation A FDS+Evac simulation is run similarly as a FDS fire simulation, so read the User s Guide of FDS [3], where you can find information on how to run the fire simulation and see the results by using Smokeview [14]. Below is a short description how to run FDS+Evac on MS Windows. Assuming that an input file called CHID.fds exists in some directory, the user must run the programme in a DOS command shell as follows: Open up a Command Prompt window, and change directories to where the input file for the case is, then run the code by typing fds.exe CHID.fds 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 fds.exe CHID.fds 2&>1 > CHID.err to begin a run. FDS+Evac can also be run using the multiple processors. You should first learn how to run parallel fire calculations by reading the User s Guide of FDS. The combined fire and evacuation simulation can be run almost similarly, but you should be sure that all fire mesh definitions are preceding all evacuation mesh definitions, because all the evacuation meshes are treated in the last single thread, i.e., all evacuation meshes are assigned to same process number. For example, if you are using MPICH2, the example config.txt file given in the User s Guide of FDS should be modified as: exe \\fire_1.nist.gov\nist\fds\fds_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 first five processes are fire meshes and the evacuation calculation is using the sixth process, i.e., it is run in the machine fire_3.nist.gov. Note that there should always be one more process ( thread ) defined for MPICH2 in fire+evacuation calculation than the corresponding fire calculation would have. This one extra thread should contain only the evacuation meshes. If the user gives the number of threads for MPICH2 so that there will be fire and evacuation meshes at a same thread then there will be some (cryptic) error message and the programme ends with a crush. 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. If a fire drill is modelled then there is no use to do any parallel calculations, because no fire meshes are needed and the calculation is a plain evacuation calculation. There is an OpenMP parallelization version of FDS available (the default at the present FDS 6.5.3), but this does not yet do anything for the evacuation calculation, so this does not speed up much if one is just modelling a fire drill. 66

65 7. Running FDS+Evac 7.2 Updating an Existing FDS Input File to a FDS+Evac Input File Note that one can not do an evacuation calculation that utilizes fire information from a fire calculation, which did not have any evacuation meshes (and geometry) present. The evacuation meshes are needed in the input file to guide the fire calculation to save evacuation related fire information to the hard drive. So before starting a fire calculation one should make the evacuation geometry and check that it is correct. Then one can run the fire calculation with the evacuation meshes to produce fire information for further evacuation simulations. In these runs one could set the number of evacuees to zero to speed up the fire calculation (no evacuation movement at all, because no agents), but the evacuation geometry information is needed in order to correctly write the CHID_evac.fed file that contains the fire data needed by the evacuation calculation. The properties of the agents and their initial positions and how many agents there are do not interfere with the saving of the fire related data for evacuation calculation, it is just the evacuation geometry, which should be there before the FDS simulation. This is similar to the ordinary FDS fire simulation, where the user should know prior the calculation which output data he/she wants and add this information to the input file. Thus, a good advice is to do first a fire drill case, where one just calculates the evacuation case and see if it goes like it should. (Set at the MISC namelist EVACUATION_DRILL=.TRUE. to force a fire drill calculation.) After the fire drill case seems to work correctly, one could do a simultaneous fire+evacuation calculation. Usually the fire calculation takes much more CPU time, so one does not want to do the fire calculation many times due to some mistakes in the evacuation input geometry. Make a FDS fire input file for your project and do some fire/smoke spread test calculations using the FDS executable to see that your input for the fire case is correct. If the memory requirements of your fire calculation demand the use of the MPI version of FDS then you can do simultaneous fire and evacuation simulation using the parallel version so that the different fire 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 fire 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. Note: If you plan to do an evacuation simulation which uses smoke then you should not perform a full fire simulation before than you have specified the evacuation geometry input to your calculation. You need to know before any FDS simulations which output you want to save and the fire information for evacuation simulations is similar. This is specifically true if your fire simulation needs really much CPU time. Save the fire input file to some other name (and change also the CHID on the HEAD namelist group). Define the evacuation meshes with the MESH namelist groups, which have both the EVAC_HUMANS and the EVACUATION keywords set to.true. Each floor of 67

66 7. Running FDS+Evac the building should have its own main evacuation mesh. Use the ID keyword to give unique names for the evacuation meshes. The z coordinates for these meshes should span a level, where the most obstacles for the movement are, usually about one meter above the floor. The EVAC_Z_OFFSET parameter defines the floor level of this mesh measured from the mid z level of the mesh. See Fig. 34 and Sec Note, that the smoke and other fire related quantities are taken at the level defined by the HUMAN_SMOKE_HEIGHT parameter on (some) PERS namelist. Try to make the mesh division such that the mesh cell sizes dx and dy in the x and y directions are nice round numbers, like 0.25 m, 0.35 m, 0.5 m, etc, depending on the widths of the egress paths. Note: Do not include floors or ceilings accidentally to the evacuation geometry, the XB of the evacuation meshes should not be touching a floor nor a ceiling. All OBSTs, even if partly, in the XB range are thickened in the z direction. If your are using the parallel version of FDS, then note that the evacuation meshes should be defined after all fire meshes in the input file. 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 and add a logical keyword EVACUATION_DRILL=.T on the MISC namelist, and run FDS+Evac. Use Smokeview to see, if the 2D geometry is looking right. You can play around with the z min and z max to take the evacuation layout at different heights. Note also that you can give a logical keyword NO_EVACUATION=.TRUE. on the MISC namelist, if you want just to (re)run the plain fire calculation after you have added the evacuation meshes. Define additional obstacles with EVACUATION=.TRUE., where you do not want agents walking. No need to define SURF_ID for evacuation obstacles, because all obstacles in the evacuation meshes use same default boundary condition (INERT), which produces a default inert coloring in Smokeview, that might not be nice looking. This may be changed by giving EVAC_DEFAULT on some SURF namelist and using COLOR or RGB to give some other coloring information. You can add also COLOR or RGB on the additional obstacles namelist to see (recognise) these better in Smokeview. Usually these additional obstacles are needed to close some holes in the fire geometry, e.g. open windows, which the agents should not be using as egress paths. Make additional holes with EVACUATION=.TRUE., where they are needed. Usually these are needed at internal doors of a floor. 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. Define your doors, exits, stairs, and entries using the DOOR, EXIT, CORR, EVSS, and ENTR namelists, respectively. Set T_END=0.0 and do a run to see these in Smokeview. 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 68

67 7. Running FDS+Evac the values given in the input file due to the fact that FDS moves OBSTs, HOLEs, and VENTs to match the mesh cell boundaries. Note, that the also the DOOR, EXIT, and ENTR objects are forced to match the underlying grid. Define slice output files at your evacuation mesh heights, e.g., &SLCF PBZ=x.x, QUANTITY='VELOCITY', VECTOR=.TRUE., EVACUATION=.TRUE./ There is no need to change the DT_SLCF keyword for these plots, because FDS+Evac outputs these evacuation flow fields for all time steps during the initialization phase. These slices will produce the output for the guiding flow fields towards different exits and doors. Run a short simulation (T_END=0.1). Check the evacuation flow fields by using Smokeview, i.e., open the velocity vector slice files of the evacuation meshes. Check also that your evacuation geometry looks fine. There should be no leaks at the outer walls of the evacuation floor, except those at the EXITs and DOORs. There should also be no narrow paths, say below 0.6 m, in the evacuation geometry, because of the shoulder widths of the agents. Add obstacles or holes to the evacuation calculation to block too narrow paths and any other places where the agents should not go. The guiding flow fields for evacuation meshes should be like arrows painted to the floor that lead to a specific exit (or door). Define your person classes, the PERS namelist groups. These namelists define the properties of the agents in the model. Usually the predefined person classes Adult, Male, Female, Child, and Elderly are sufficient. The detection and reaction time distributions are given on these namelist groups, so if you have different groups of agents, which have different detection and reaction time distributions, then you should define a PERS namelist for each of these. Note that the detection and reaction time distributions can also be given on the EVAC namelists and these values override the PERS namelist values. Place the agents inside the building using EVAC namelists and use EVHO namelists where you do not want to put the agents (similarly like OBSTs and HOLEs). 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. The colouring method can be changed by using the menu Show/Hide and choosing Humans submenu. Note that not all avatars support colouring by the data. Run a longer simulation and see that the agents are moving correctly, i.e., they are following correct flow fields 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). 69

68 7. Running FDS+Evac Do a full evacuation calculation and save the results, i.e., the CHID_evac.csv and CHID_evac.out files. 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 fire drill. After this do a full FDS+Evac simulation (both the fire and evacuation, i.e., EVACUATION_DRILL=.FALSE., which is the default value. Now the fire and evacuation simulations are done at the same time and a file CHID_evac.fed is written to the hard drive. This file can be used to run many evacuation simulations per one fire simulation, i.e., no need to calculate the same fire for many times. Note, that the CHID_evac.eff file is always (re)calculated when there are active fire meshes and it is also (re)calculated by default if there are only evacuation meshes. By setting EVACUATION_MC_MODE=.TRUE. just the evacuation calculation is done and the file CHID_evac.eff is read in if it exists. If not, it is recalculated. If EVACUATION_DRILL=.FALSE. (the default) then also the file CHID_evac.fed is tried to read in. If successful, then the evacuation calculation is equal to a real fire+evacuation calculation, just much faster, because the fire is not calculated but just the fire results are read in. If you are doing more than one evacuation calculation per one fire scenario (as you should) then save the CHID_evac.eff and CHID_evac.fed files after the previous step, where fire 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 to read the CHID_evac.eff file from the hard disk, if it exists. The programme tries to read the smoke and fire information (the CHID_evac.fed file) from the hard disk if it exists. 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 fire, 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. Compare the results with and without the smoke/fed effects. Note that the keyword EVACUATION_DRILL on the MISC namelist forces a fire drill mode and no smoke (fed) information is read from the disk and all fire meshes are skipped. 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: Send help requests to: Timo.Korhonen@vtt.fi. The subject line should start with the characters FDS+Evac Help:. Or read and ask questions at the FDS-SMV discussion group: 70

69 7. Running FDS+Evac If the run stops early and the error message ERROR: FDS improperly set up is printed on stderr then the initialisation of agents may be failed, i.e., FDS+Evac was not able to put the agents on the areas specified in the input file. 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 file of the evacuation calculation, CHID_evac.out. Note, that in some runs with the exactly same input file 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. 71

70 8. Setting up the Input File for FDS+Evac This section is a short manual to the FDS+Evac programme. Read first the FDS User s Guide [3], because here only those features and keywords are presented, which differ from the ordinary FDS fire 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 files on the FDS+Evac web page. These example input files contain many comment lines, which explain all the major features of the FDS+Evac input file 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 defined for the evacuation calculation part. These meshes are not related to the fire calculation meshes, i.e., their dx and dy may be different and the spatial extent of the meshes may also be different. Usually one defines one evacuation mesh per one floor of the building, if the spaces on this floor are connected. The evacuation input should be matched to the evacuation floor mesh definition. 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, whereas the other evacuation specific namelists are not. For now, Smokeview shows only the namelists DOOR, EXIT, ENTR, EVSS, EVAC, and EVHO. The evacuation meshes are two dimensional, i.e., they should have IJK=N x,n y,1 on the MESH namelists, where N x and N y are the number of cells in the x and y directions, respectively. An unique ID string should be given to all evacuation meshes. In addition to the user defined meshes, there is automatically generated visibility meshes for each main evacuation mesh defined by the user. These meshes are located horizontally exactly at the same place as the main evacuation mesh, but 72

71 8. Setting up the Input File for FDS+Evac the z range is different. The mid z level is at the position defined by the keyword HUMAN_SMOKE_HEIGHT on (some) PERS namelist, the default is 1.6 m above the floor level. And the keyword EVAC_DELTA_SEE also given on (some) PERS namelist defines how much higher and lower are the zmax and zmin. The default value is 0.29 m. By choosing cleverly the z-coordinates of the obstacles (and holes) one is able to make these objects to show up in both the visibility and movement (the main evacuation meshes ) meshes or in one or in the other. These visibility evacuation meshes have their ID set automatically and they are Emesh_ ID, where ID is the ID of the main evacuation mesh. So, one can also use the keyword MESH_ID on the OBST and HOLE namelist to force the objects to go into some specific mesh. 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 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 file 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 finds a quite many non-used keywords.) The definitions of doors and exits are not checked. Note that the outer boundary of meshes is solid by default. It is a good practice to add SLCF output (with EVACUATION=.TRUE.) for velocity vectors at the levels of the evacuation meshes and see these vectors in Smokeview. The programme checks that the namelist objects DOOR, EXIT, and ENTR are not inside solid obstructions. Check your EVAC namelists that you are not placing 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 defined. 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 m, so you can not put more than about four persons per square meter. If you are trying to populate the floor 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 file 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 file CHID_evac.out to see the position of the agent, which could not be placed correctly at the initialisation. 73

72 8. Setting up the Input File for FDS+Evac 8.1 The MESH Namelist Group Figure 34. A 2D evacuation mesh. The fire and evacuation meshes are separate ones. One can do only a fire calculation, only an evacuation calculation, or both at the same time. The calculation mode is chosen by using logical keywords EVACUATION_DRILL, EVACUATION_MC_MODE, and NO_EVACUATION on the MISC namelist to control the calculation. EVACUATION Should be.true. for all evacuation meshes. Default is.false. EVAC_HUMANS Should be.true. for all evacuation meshes. Default is.false. ID The specific 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 evacuation mesh to the floor, z mid = 1(z z 2 ). This parameter is used to show the bodies of the agents in Smokeview so that their feet are touching the floor (default is 1.0 m). This parameter also defines the reference floor level for the smoke and FED calculation, see the parameter HUMAN_SMOKE_HEIGHT on the PERS namelist. All evacuation mesh lines should have a keyword EVACUATION=.TRUE.. The default is.false., i.e., the fire meshes do not need the keyword EVACUATION. This is true also more generally, i.e., one can always run a fire simulation even if there exists evacuation input in the input file. The FDS fire calculation ignores all evacuation lines and keywords, if there is no active evacuation meshes defined in the input file or the keyword NO_EVACUATION is set to.true. on the MISC namelist. 74

73 8. Setting up the Input File for FDS+Evac Evacuation meshes should have also a keyword EVAC_HUMANS=.TRUE. (default is.false.), which says that this mesh will contain agents. This keyword is going to be dropped of at some point, but for now it is needed for historical reasons. Usually, one main evacuation mesh represents a floor. Note that the evacuation calculation is faster if you define different evacuation meshes for the parts, which do not interact with each other, because the computational cost is additive between different meshes and inside one mesh there are loops which scale as N 2, where N is the number of the agents inside the mesh. 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 Fig. 34. Choose IJK and XB so that the dx and dy are nice round numbers that will fit 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 guiding flow fields for evacuation meshes should always be checked by using Smokeview, when building the geometry of the model. So it is a good practice to add a SLCF output (EVACUATION =.TRUE., QUANTITY = VELOCITY, VECTOR =.TRUE.) at the levels of the evacuation meshes and see these vectors in Smokeview. Load vector slice file of an evacuation mesh at a time and see that it has arrows pointing towards the exit(s) and door(s) that is(are) present in that evacuation mesh. Read the Smokeview manual how to clip the geometry, especially in the z-direction, in order to see just one floor of the building. See also that the evacuation flow fields are converged, you should not see oscillations when the time goes by. At least you should see that the possible oscillations are small and converging to a steady state solution as the time zero is approached. Check also that the guiding flow field vectors of the evacuation meshes inside your building are leading to the doors (the outflow vents) and that the vectors are not pointing towards walls, which might happen if the fields are not converged to steady state solutions. There are a couple of parameters on the TIME and MISC namelists that you can use to make the flow fields more converged. How you can tell that the fields are looking good? Think of yourself in the building and following strictly the arrows like they would be painted on the floor. If you are able to get from anywhere inside the building to (some) door then the fields are good. 8.2 The TIME Namelist Group The FDS+Evac calculation can be divided to two phases, where different time steps are used. The first part is the initialization of the guiding flow fields for evacuation and the second is the (fire+)evacuation calculation. The guiding flow fields of the evacuation meshes are calculated at the initialization phase using a time step EVAC_DT_FLOWFIELD and the number of these time steps is dictated by EVAC_TIME_ITERATIONS. The main time step of the actual evacuation calculation depends on the FDS fire calcu- 75

74 8. Setting up the Input File for FDS+Evac lation time step if there are fire meshes present in the calculation, it is less or equal to the fire mesh time step and it is given by the keyword EVAC_DT_STEADY_STATE. Note that the FDS fire time step is adjusted during the calculation, so the main loop time step for evacuation may also change. There is also an internal time step inside each evacuation mesh, which is changing according to how densely packed the agents are. If the agents are touching each others then a quite small time step is needed to solve the movement equations. This internal time step can be modified using the keywords in the PERS namelist. The time loop strategy is: T_fire = T_evac = T_BEGIN Do Dt_fire_mesh T_fire = T_fire + Dt_fire Do Dt_main_evac Until T_evac = T_fire T_evac = Min(T_fire, T_evac + Dt_main_evac) Do Evac_meshes Until T_evac_int = T_evac T_evac_int = Min(T_evac, T_evac_int + Dt_evac_int) EndDo EndDo EndDo If there are no fire meshes then the situation is similar, just the main fire loop time step stays constant during the whole calculation. The understanding of the time stepping is important to understand how the different meshes are connected to each others. Evacuation and fire meshes can not exchange information faster than the main loop time step in FDS, i.e., the time step of the fire meshes. The evacuation meshes are exchanging information at every iteration of the main evacuation time step loop, i.e., at least every EVAC_DT_STEADY_STATE seconds. This is important when the agents are going from one mesh to the next mesh, like using stairs to go to the next level or if there is merging flows in staircases. It should be also noted that the FDS main loop time step sets the upper limit to the frequency at which output is written to the hard drive. EVAC_DT_FLOWFIELD is the time step of the calculation of the evacuation flow fields. These fields are calculated before the fire and evacuation calculation, i.e., simulation time has values less than T_BEGIN. Default is 0.01 s. Usually the user should not change this but if there are problems to obtain a converged, steady state, guiding flow fields for evacuation then this parameter together with the parameters EVAC_TIME_ITERATIONS and EVAC_PRESSURE_ITERATIONS given at the MISC namelist could be changed. 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 76

75 8. Setting up the Input File for FDS+Evac step in the output files will not be shorter than this value. This parameter defines the minimum coupling frequency of different main evacuation meshes. Coupling is faster if the time step of the fire calculation is shorter. (Default is 0.05 s.) 8.3 The SURF Namelist Group One can add a keyword EVAC_DEFAULT=.TRUE. to a surface namelist. The default surface for evacuation meshes is INERT. You could specify some other solid material for the default surface material, but FDS+Evac uses only the colour information. The colour of the default inert material is not really nice in Smokeview, so the user usually defines this keyword and gives just the colouring information on the SURF line. This also makes it easier to distinguish the evacuation mesh obstacles and the fire mesh obstacles from each others. If the TRANSPARENCY is equal to one (the default) then the evacuation mesh obstacles are drawn as outlines in Smokeview if there are both evacuation and fire meshes present in the calculation. 8.4 The MISC Namelist Group NO_EVACUATION If set to true then no evacuation calculation is done. If there are no fire meshes defined, then ERROR: No MESH line(s) defined is printed on the screen output. The default is.false., i.e., the default mode is fire+evacuation calculation. EVACUATION_MC_MODE If set to true then no fire meshes are read in and no fire calculation is done. The EFF and FED files are tried to read from the hard disk if they exist. The default is.false., i.e., (re)calculate the FED and EFF files, if appropriate. If EVACUATION_DRILL is also set true then the FED file is not used. EVACUATION_DRILL If set to true then no fire meshes are read in and no fire calculation is done. The EFF file is recalculated and no smoke information (the FED file) is used in the calculation. The default is.false., i.e., (re)calculate the FED and EFF files, if appropriate. EVAC_PRESSURE_ITERATIONS is the number of Poisson solver iterations at each evacuation flow field time step. If you guiding flow fields for evacuation do not look nice, you might need to increase this. A too large number makes the flow field calculation to take too much CPU time. (Default is 50.) EVAC_TIME_ITERATIONS is the number of evacuation flow field calculation time steps. One should have nice converged guiding flow fields for evacuation, so some iterations are needed. A too large number means too long CPU time. (Default is 50.) The flow fields of the evacuation meshes, which are used to guide agents out of the building or to some other targets, are calculated before the actual fire and evacuation simulation, i.e., flow field calculation has t < t begin. The product of the keywords t flow = 77

76 8. Setting up the Input File for FDS+Evac EVAC_TIME_ITERATIONS EVAC_DT_FLOWFIELD defines the duration of the evacuation flow field calculation per one exit or door. The fields should reach steadystate during this time. Default t flow is s = 0.5 s for each exit/door. 8.5 The OBST Namelist Group EVACUATION Should be.true. for all evacuation mesh obstacles, which are not needed in the fire calculation. If it is.false. then this OBST is only applied in the fire calculation meshes. Default is not defined, i.e., the OBST is applied both to fire 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 fire calculation. Thus, the OBST namelist group has an additional logical item EVACUATION. If it is.true. then this OBST is omitted in the fire calculation. Usually these additional evacuation obstacles are introduced at places, where agents are not allowed to walk. 8.6 The HOLE Namelist Group EVACUATION Should be.true. for all evacuation mesh obstacles, which are not needed in the fire calculation. If it is.false. then this HOLE is only applied in the fire calculation meshes. Default is not defined, i.e., the HOLE is applied both to fire and evacuation meshes. MESH_ID This parameter is used to specify the evacuation mesh, where this HOLE is applied. HOLE is similar to the OBST namelist group. 8.7 The PERS Namelist Group This namelist group is used to define different 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 five default agent types defined and they are Adult, Male, Female, Child, and Elderly, see Table 1 for their body sizes and unimpeded walking speeds. Note, that the body sizes and walking speeds are generated from 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 The user should not usually change any of the optional parameters. It is enough to give some predefined 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.5 if a more rapid egress is wanted, see Chapters 5 and 6. 78

77 8. Setting up the Input File for FDS+Evac Table 5. Statistical distributions, which may be used to define 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. (20) (26) for the definition for the distributions. Distribution Index Parameters No distribution 0 _MEAN (x) Uniform 1 _LOW, _HIGH (x min, x max ) Truncated normal 2 _MEAN, _PARA, _LOW, _HIGH ( x, σ, x min, x max ) Gamma 3 _PARA, _PARA2 (k, θ) Normal 4 _MEAN, _PARA ( x, σ) Log-normal 5 _MEAN, _PARA, _HIGH, _PARA2 (ln(x x 0 ),σ ln(x x0 ), x max, x 0 ) Beta 6 _PARA, _PARA2 (α, β) Triangular 7 _MEAN, _LOW, _HIGH (x peak, x min, x max ) Weibull 8 _PARA, _PARA2 (α, λ) Exponential 8 _PARA=1, _PARA2 (α=1, λ) Gumbel 9 _PARA (α) 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. If these are given on many different PERS namelist groups then the last values read in are used. DEFAULT_PROPERTIES Adult, Male, Female, Child, or Elderly. If not given then the default values are used, see the end of Sec Note, that the default values of these agent types may be overridden if the various values are explicitly given on the PERS namelists. The case of the letters matter somewhat, the forms like Adult, adult, or ADULT are accepted, others not. DET_EVAC_DIST The type index of the detection time distribution, see Table 5 and Sec The default is zero, i.e., no distribution, just a constant value (DET_MEAN) is used. The detection time distribution properties can also be given on the EVAC namelist and then these values override the values given at PERS namelist for these agents. DET_MEAN,DET_PARA,DET_PARA2,DET_LOW,DET_HIGH The parameters of the detection time distribution, see Table 5. PRE_EVAC_DIST The type index of the reaction time distribution, see Table 5 and Section 9.1. The default is zero, i.e., no distribution, just a constant value (PRE_MEAN) is used. The reaction time distribution properties can also be given on the EVAC 79

78 8. Setting up the Input File for FDS+Evac namelist and then these values override the values given at PERS namelist for these agents. PRE_MEAN,PRE_PARA,PRE_PARA2,PRE_LOW,PRE_HIGH The parameters of the reaction time distribution, see Table 5. DIAMETER_DIST The type index of the body size distribution, see Table 5. Note, that the distribution is given for the diameter of the large body circle, which encircles the whole body ellipse, see Fig. 1. DIA_MEAN,DIA_PARA,DIA_PARA2,DIA_LOW,DIA_HIGH The parameters of the distribution used for the diameter of the agent circle (2R d ), see Fig. 1 and Tables 1 and 5. The value of DIA_MEAN is used to scale the other body dimensions like D_TORSO_MEAN. If DIA_MEAN is not given (not needed for all distributions) then the distribution mean is used to scale the other body dimensions. VELOCITY_DIST The type index of the unimpeded walking speed distribution, see Table 5. VEL_MEAN,VEL_PARA,VEL_PARA2,VEL_LOW,VEL_HIGH The parameters of the unimpeded walking speed v 0 i distribution, see Eq. (2) and Tables 1 and 5. TAU_EVAC_DIST The type index of the relaxation time parameter distribution, see Table 5. TAU_MEAN,TAU_PARA,TAU_PARA2,TAU_LOW,TAU_HIGH The parameters of the relaxation time τ i distribution, see Eq. (2) and Table 5. FCONST_A,FCONST_B,L_NON_SP Social force parameters A i, B i, λ i, see Eq. (3). C_YOUNG,KAPPA Contact force parameters k i and κ i, see Eq. (4). D_TORSO_MEAN,D_SHOULDER_MEAN The mean diameters of the torso and shoulder circles, see Table 1 and Fig. 1. The variations of these diameters are determined by the diameter distribution of the agent circle (2R d ). E.g., R t,i = R t,mean R d,i /R d,mean TAU_ROT The relaxation time, τ z i, for the rotational equation of motion, see Eq. (9). M_INERTIA The moment of inertia, I z i, 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 A w for wall agent interaction is FAC_A_WALL A i. FAC_B_WALL Social force constant B w for wall agent interaction is FAC_B_WALL B i. 80

79 8. Setting up the Input File for FDS+Evac LAMBDA_WALL Social force constant λ w for wall agent interaction. FC_DAMPING Damping coefficient c d of the radial contact force, see Eq. (4). V_ANGULAR Maximum target angular speed ω 0 of the agents, 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 the rotational equation, η z i in Eq. (5). The three parameters are the mean, the variance and the cut-off multiplier, respectively, and their default values are listed at the end of Sec HUMAN_SMOKE_HEIGHT Specifies the level above the floor, where the smoke and FED information is taken. Note, that the parameter EVAC_Z_OFFSET and the coordinates XB on the evacuation mesh namelists define the floor levels. Default is 1.6 m. This parameter sets also the mid vertical position of the visibility meshes for each main evacuation mesh. TDET_SMOKE_DENS If > 0.0 then an agent detects the fire when the smoke density (mg/m 3 ) is larger than the given value at the position of the agent if the agent has not yet detected the fire 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 index 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 Default is SMOKE_MIN_SPEED This sets the minimum speed of the agents when they are moving in smoke, v 0 i,min = SMOKE_MIN_SPEED v 0 i in Eq. (11). Default is 0.1. See Fig. 9. 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. The larger the given values are the more random trials to place the agents is done and this increases the CPU time needed for the initialization. Default is 0.0. EVAC_DT_MAX The maximum time step for the agent movement algorithm, default 0.01 s. See Sec EVAC_DT_MIN The minimum time step for the agent movement algorithm, default s. See Sec

80 8. Setting up the Input File for FDS+Evac NOT_RANDOM If.TRUE. do not use random seed when generating the initial positions and characteristics of agents. Default is.false. For debugging purposes this should be set to true. Same is true if exactly the same random initial properties and positions of the agents are needed in two different runs, say, one with λ i = 0.3 and the other with λ i = 0.5 to see the effect of this parameter. COLOR_METHOD How agents are shown in Smokeview. -1: use standard colours in Smokeview, 0: use avatar colours given on the EVAC lines, 3: use avatar colours given on the PERS lines, 4: colour the agents according to the target door/exit colours, 5: colour the agents according to the exit selection algorithm, see Table 3. The default is -1. AVATAR_COLOR Colour of the agents seen in Smokeview if COLOR_METHOD=3. See the FDS User s Guide and FDS web page for the list of available colour names. AVATAR_RGB Three integers (0 255) specifying a colour of the agents seen in Smokeview if COLOR_METHOD=3. Note, that AVATAR_COLOR overrides this option. DEAD_COLOR Colour of the dead agents seen in Smokeview. See the FDS User s Guide and FDS web page for the list of available colour names. Default colour for dead agents is cyan. DEAD_RGB Three integers (0 255) specifying a colour of the dead agents seen in Smokeview. Note, that DEAD_COLOR overrides this option. Default colour for dead agents is cyan. OUTPUT_SPEED If.TRUE. then the movement speeds of the agents are saved in the output file to be shown in Smokeview as a colour bar. OUTPUT_FED If.TRUE. then the FED doses of the agents are saved in the output file to be shown in Smokeview as a colour bar. OUTPUT_CONTACT_FORCE If.TRUE. then the contact forces acting on the circumferences (N/m) of the agents are saved in the output file to be shown in Smokeview as a colour 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 output file to be shown in Smokeview as a colour bar. TAU_CHANGE_V0 How often, on the average, an agent tries to change direction in the counterflow collision avoidance algorithm. The default is 0.1 s. If the collision avoidance algorithm is not wanted to be used then the user should give a negative value for this parameter. See the Sec TAU_CHANGE_DOOR How often, on the average, an agent tries to change the target door/exit. The default is 1.0 s. See the Sec

81 8. Setting up the Input File for FDS+Evac FAC_DOOR_QUEUE The default is 1.3 p/s/m. If the estimated queuing time at the doors is not wanted to be used in the door selection algorithm then a value less than should be given, e.g., 0. See the Sec FAC_DOOR_WAIT How much the present target door is preferred over the other possible doors. This includes some kind of inertia or hysteresis to the door selection algorithm. The estimated escape time through the present target door is multiplied with this values, e.g., a value 0.9 means that the estimated time is reduced by 10 %. The default is 0.9. See the Sec FAC_DOOR_OLD This factor is used in the exit selection algorithm to decide how much more smoke there can be, before the presently chosen door is considered to be in the smoke category, see FED_DOOR_CRIT. Default is 0.1 which means that the FED_DOOR_CRIT is ten times larger for the presently chosen door, i.e., more smoke is tolerated. FAC_DOOR_OLD2 This factor is used in the exit selection algorithm to decide how much more smoke is too much, before the presently chosen door is considered to be in the too much smoke category, see FED_DOOR_CRIT. Default is 0.9 which means that the effect of smoke is reduced by multiplying the estimated FED index by factor, see FED_DOOR_CRIT. Similarly for the visibility if visibility criteria are chosen (FED_DOOR_CRIT<0). THETA_SECTOR Counterflow algorithm parameter, sets the sector angle θ, see Sec. 3.3 and Fig. 5. The other counterflow algorithm parameters that can be changed are listed in Table 4. FAC_V0_UP The unimpeded speed of an agent upwards along an EVSS incline is FAC_V0_UP v 0 i, if given here, otherwise the factor given at the EVSS namelist is used. FAC_V0_DOWN The unimpeded speed of an agent downwards along an EVSS incline is FAC_V0_DOWN v 0 i, if given here, otherwise the factor given at the EVSS namelist is used. FAC_V0_HORI The unimpeded speed of an agent horizontally on an EVSS incline is FAC_V0_HORI v 0 i, if given here, otherwise the factor given at the EVSS namelist is used. Below the probability density functions are listed for those distributions in Table 5, where the naming of the parameters is not trivial. The definition of the probability density function of the Gamma distribution is: f(x) = 1 Γ(k)θ k xk 1 e x/θ, x > 0, k, θ > 0. (20) The definition of the probability density function of the Normal distribution is: f(x) = 1 } { σ 2π exp (x x)2, σ > 0. (21) 2σ 2 83

82 8. Setting up the Input File for FDS+Evac The definition of the probability density function of the Log-Normal distribution is: const f(x) = { (x x 0 )σ 2π exp (ln(x x } 0) µ) 2, σ > 0, x < x 2σ 2 max, (22) where µ and σ are the mean and the standard deviation of ln(x x 0 ), respectively, and ln(x x 0 ) is normally distributed. The definition of the probability density function of the Beta distribution is: f(x) = const x α 1 (1 x) β 1, x [0; 1], α, β > 0. (23) The definition of the probability density function of the Weibull distribution is: f(x) = αλ(λx) α 1 exp( (λx) α ), x 0, α, λ > 0. (24) The definition of the probability density function of the Exponential distribution is: f(x) = λe λx, x 0, λ > 0. (25) The definition of the probability density function of the Gumbel distribution is: f(x) = αe αx exp( e αx ), α > 0. (26) WARNING: Change only the reaction and detection time parameters, other parameters should have the default values and use the predefined person types, unless you know what you are doing. The parameter L_NON_SP may be changed from its default value 0.3 to a value 0.5, if a more rapid egress is wanted, see Chapters 5 and The EVAC Namelist Group Places agents in the evacuation meshes, i.e., this namelist group is used to define the initial positions of the agents. ID ID string of the group of agents. XB Defines the rectangle, where the agents are put, z should belong to the correct main evacuation mesh. If the coordinates XB intersect 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. The default is zero. PERS_ID The ID string of the PERS namelist, which is used to define the characteristics of the (randomly) generated agents. 84

83 8. Setting up the Input File for FDS+Evac DET_EVAC_DIST The type index of the detection time distribution, see Table 5 and Sec The default is not defined, i.e., the values given at PERS namelist for these agents are used (the ones corresponding to PERS_ID). DET_MEAN,DET_PARA,DET_PARA2,DET_LOW,DET_HIGH The parameters of the detection time distribution, see Table 5. PRE_EVAC_DIST The type index of the reaction time distribution, see Table 5 and Sec The default is not defined, i.e., the values given at PERS namelist for these agents are used (the ones corresponding to PERS_ID). PRE_MEAN,PRE_PARA,PRE_PARA2,PRE_LOW,PRE_HIGH The parameters of the reaction time distribution, see Table 5. ANGLE By default the orientation of agents is random, but by giving an angle (0 360) the orientation of the agents can be specified. 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 User s Guide and FDS web page for the list of available colour names. AVATAR_RGB Three integers (0 255) specifying a colour of the agents seen in Smokeview if COLOR_METHOD=0. Note, that AVATAR_COLOR overrides this option. 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. 8.9 The EVHO Namelist Group Specifies 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 Defines a 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. 85

84 8. Setting up the Input File for FDS+Evac 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 The EXIT Namelist Group Defines an exit, which removes agents from the calculation for good. 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 Defines 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. MESH_ID If there are overlapping 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, should not be inside a solid. Default is the mid-point of XB. Note that the exits (not the count only exits) are shown in Smokeview as vertical rectangles at the x and y positions defined by XB and that there is a small cone at XYZ pointing to the IOR direction. 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). Note that the namelist DOOR has the same rule for the sign of IOR. COUNT_ONLY If.TRUE., agents are not removed, they are just counted (default is.false.). The CHID_evac.csv file has a column for each EXIT regardless if COUNT_ONLY is true or false. COLOR Colour of the agents seen in Smokeview if COLOR_METHOD=4. See the FDS User s Guide and FDS web page for the list of available colour names. The exits (not count only ones) are shown in Smokeview by rectangles at the exit location, which has the frontside coloured with this colour and the backside has colour FOR- EST GREEN if the exit is open and RED if the exit is closed (See the keywords TIME_CLOSE and TIME_OPEN). Default colour is FOREST GREEN. RGB Three integers (0 255) specifying a colour of the agents seen in Smokeview if the COLOR_METHOD=4 is specified on (some) PERS namelist. Note, that the COLOR keyword overrides this option. See also COLOR keyword for how exits are shown in Smokeview. 86

85 8. Setting up the Input File for FDS+Evac TIME_OPEN The time (s) when this exit becomes usable. The default is that the exit is always categorized as usable in the exit selection algorithm. TIME_CLOSE The time (s) when this exit becomes unusable. The default is that the exit is always categorized as usable in the exit selection algorithm. SHOW A logical switch used to control if the exit is shown in Smokeview or not. This switch has only effect on the real exits, the count only exits are never shown in Smokeview. The default is.true.. HEIGHT The height of the exit shown in Smokeview. The default is 2.0 m. PERS_ID This applies just for the COUNT_ONLY=.TRUE. exits. If given, then this counter just counts those agents, who were generated using the given PERS namelists. If EVAC_ID is also given then both IDs match if the agent is to be counted. EVAC_ID This applies just for the COUNT_ONLY=.TRUE. exits. If given, then this counter just counts those agents, who were generated using the given EVAC or ENTR namelists. Note that there is no ENTR_ID keyword, one uses just one keyword for both types of objects, which are generating new agents to the simulation. If PERS_ID is also given then both IDs should match if the agent is to be counted The ENTR Namelist Group Defines 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, a door, 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 Defines 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. MESH_ID If there are overlapping 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 namelists EXIT and DOOR has just the opposite rule for the sign of IOR. MAX_FLOW How many agents per second are introduced in the calculation. The actual flow may be smaller, if the area in front of the entry is crowded. The default is zero. MAX_HUMANS The maximum cumulative number of agents to be introduced in the calculation by this entry, the default is a very large integer. 87

86 8. Setting up the Input File for FDS+Evac MAX_HUMANS_RAMP The ID string of a ramp. The maximum cumulative number of agents to be introduced in the calculation by this entry at a given time can be given as a ramp e.g., &RAMP ID='xx', T= 0.0, F= 0 / &RAMP ID='xx', T=10.0, F= 5 / &RAMP ID='xx', T=40.0, F=30 / If a ramp is given then MAX_FLOW is not used and the agents are entered according to the ramp. If the front of the entry is crowded then the number of agents created may lag the ramp. Note that there is linear interpolation between the time points. The default is no ramp. 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 from some other node, i.e., they are new agents. If not given, the default values are used. KNOWN_DOOR_NAMES The ID strings of the known exit doors. This only apply to agents that are generated at this entry, i.e., it does not apply to those agents who are transferred 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 User s Guide and FDS web page for the list of available colour names. AVATAR_RGB Three integers (0 255) specifying a colour of the agents seen in Smokeview if COLOR_METHOD=0. Note, that the AVATAR_COLOR keyword overrides this option. COLOR Colour of the agents seen in Smokeview if COLOR_METHOD=4. See the FDS User s Guide and FDS web page for the list of available colour names. An entry is shown in Smokeview by rectangle, which has the front side coloured with this colour and the backside is SKY BLUE if the entry is open and RED if the entry is closed (see the keywords TIME_STOP and TIME_START). Default colour is SKY BLUE. RGB Three integers (0 255) specifying a colour of the entry seen in Smokeview. Note, that the COLOR keyword overrides this option. See also COLOR keyword for how entries are shown in Smokeview. 88

87 8. Setting up the Input File for FDS+Evac SHOW A logical switch used to control if the entry is shown in Smokeview or not. The default is.true.. HEIGHT The height of the entry shown in Smokeview. The default is 2.0 m The DOOR Namelist Group Defines 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 Defines the position of the door, should be a line in the (x, y) plane, the z should belong to a evacuation mesh. If XB intersects many evacuation meshes then the keyword MESH_ID should be given. XYZ Coordinates, which are used in the exit door selection algorithm to decide if the door is visible or not, should not be inside a solid. Default is the mid-point of XB. Note that the doors are shown in Smokeview as vertical rectangles at the x and y positions defined by XB and that there is a small cone at XYZ pointing to the IOR direction. MESH_ID If there are overlapping 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, STRS, 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 classified as a visible, unknown door in the door selection algorithm. see Sec Default is.true. 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. COLOR Colour of the agents seen in Smokeview if COLOR_METHOD=4. See the FDS User s Guide and FDS web page for the list of available colour names. The exits are shown in Smokeview by rectangles at the door location, which has the front of the 89

88 8. Setting up the Input File for FDS+Evac door coloured with this colour and the backside has colour FOREST GREEN if the door is open and RED if the door is closed (See the keywords TIME_CLOSE and TIME_OPEN). Default colour is FOREST GREEN. RGB Three integers (0 255) specifying a colour of the agents seen in Smokeview if the COLOR_METHOD=4 is specified on (some) PERS namelist. Note, that the COLOR keyword overrides this option. See also COLOR keyword for how doors are shown in Smokeview. TIME_OPEN The time (s) when this door becomes usable. The default is that the door is always categorized as usable in the exit selection algorithm. TIME_CLOSE The time (s) when this door becomes unusable. The default is that the door is always categorized as usable in the exit selection algorithm. SHOW A logical switch used to control if the door is shown in Smokeview or not. The default is.true.. HEIGHT The height of the door shown in Smokeview. The default is 2.0 m The CORR Namelist Group Defines stairs (or a horizontal corridor). Namelists CORR are used to move agents from one floor to the next one, i.e., from one main evacuation mesh to some other one. These stairs are just for one way movement and there can be no conterflow nor merging flows, so basically this namelist objects can be used to model a single flight of stairs or at most a flight an intermediate landing a flight combinations. IF a two way stairs is needed then the stairs should be modelled with EVSS or STRS namelists. 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. The speed reduction is uniform, so if one models (flight+landing+flight) combination one should give some effective values for the parameters. 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 specific flow) inside the stairs. ID ID string of the corridor. One can refer to this CORR by its name. MAX_HUMANS_INSIDE how many agents fit 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 smoke and 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 90

89 8. Setting up the Input File for FDS+Evac the end of the corridor/stairs. Note that the FED data at these points are saved to the FED file, so that you need to recalculate the FED file (i.e., do a full fire+evacuation calculation) if you change these values (or remove or add CORR namelists). FAC_SPEED How much slower or faster agents move in the corridor/stairs compared to the walking speed v 0 i in horizontal floors, speed=fac_speed v 0 i. (Default is 0.6) EFF_LENGTH The effective length of the corridor/stairs. The movement time of the agents inside the stairs is calculated as EFF_LENGTH/(FAC_SPEED v 0 i ) and there is no density-speed type correlation used in this calculation. Note, that CORR is usually used to define stairs between two floors: Door 2 nd floor Corr Door 1 st floor. Stairs could also be constructed using the EVSS namelists, but this is not as straightforward as to use CORR constructions. See the example input files on the FDS+Evac web pages. If you have merging flows 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. One could also use the STRS namelist to model the entire staircase just as a single object. This model was first introduced in the Evac version and it is now the recommend way of modelling whole staircases. This model can deal with merging flows and counterflows The EVSS Namelist Group Defines an incline, e.g., stairs, a spectator stand, or an escalator. The defined incline could also be horizontal. Then it specifies a piece of the current floor at different vertical position than that given on the MESH line of the evacuation floor. 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. A main evacuation mesh defines a floor, which can consist many different vertical levels if these can be projected to a single plane so that there are no places for the agents to go on top of each others. In this case the EVSS namelists can and should be used to show these different levels correctly in Smokeview and to define the inclines, stairs of spectator stands, which are needed to connect these horizontal levels at different heights. EVSS can also be used just to change the movements speeds of the agents at some parts of the floor. ID ID string of the incline. XB Defines the position of this incline, should define a rectangle in the (x, y) plane, the z should belong to a evacuation mesh. The z is not related to the actual (physical) coordinates of the incline (or horizontal landing ), but it is just used to decide to which evacuation mesh (to which floor ) this EVSS belongs. If XB intersects many evacuation meshes then the keyword MESH_ID should be given. 91

90 8. Setting up the Input File for FDS+Evac 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 defined 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 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 evacuation plane defined by the z of XB. This edge has z = z XB + 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 evacuation plane defined by the z of XB. This edge has z = z XB + HEIGHT0. HEIGHT0 can have a positive or a negative value. If HEIGHT0=HEIGHT the EVSS defines a horizontal plane and IOR has no effect. Default is 0 m. FAC_V0_UP The unimpeded speed of an agent upwards is FAC_V0_UP v 0 i. FAC_V0_DOWN The unimpeded speed of an agent downwards is FAC_V0_DOWN v 0 i. FAC_V0_HORI The unimpeded speed of an agent horizontally is FAC_V0_HORI v 0 i. 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 specified 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. SHOW A logical switch used to control if the incline is shown in Smokeview or not. The default is.true The STRS Namelist Group Defines an entire staircase. See the example cases at the FDS+Evac web page. Note that for a STRS staircase, a new main evacuation mesh should not be defined, because in the present FDS+Evac version it is created automatically. This automatic mesh is called as Emesh_ ID, where ID is the ID of the STRS namelist. See the examples at the FDS+Evac web page: and there the Stair Example case. ID ID string of the stairs. XB Defines the position of this staircase and the extent of the automatically generated evacuation mesh. IJK Like for the evacuation meshes, set how many cells span the x and y directions. K should always be equal to one. 92

91 8. Setting up the Input File for FDS+Evac EVAC_Z_OFFSET Like for the evacuation meshes. This parameter refers to the lowest level of the stairs. XB_CORES(1,:) The XB of the centre core of the stairs (an OBST that is between the stair flights). RIGHT_HANDED Logical, default is.true. LEFT_HANDED Logical, default is.false. VERTICAL_LANDING_SEPARATION The height of the stair flights connecting the landings. N_LANDINGS Number of the landings. FAC_V0_UP, FAC_V0_DOWN, FAC_V0_HORI Movement speed factors, see EVSS namelist input. XB_LANDINGS(ii,:) An array that list the positions of the landing slabs, where the first index, ii, is for the landings, and second one for the six numbers giving the XB of the landing. The positions of the two first landings are enough to give, the others are duplicated from these. Note: landing (1,:) is the bottom floor landing of the stairs, which is at the same level as the bottom floor. One could argue that this is not a landing, but it is counted as a landing. But the STRS geometry is such that there is always landings on both sides of the stair flights. 93

92 9. Miscellaneous Information 9.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 t move = t begin + t det + t pre, (27) where t det and t pre 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 files than the CHID.fds file. These files are not needed but they may be used to speed up the calculation and also to separate the fire and evacuation parts of the calculation. Note that if the keyword NO_EVACUATION is set to true then no evacuation calculation is done at all and if EVACUATION_DRILL is set to true then no fire calculation is done. The file CHID_evac.eff contains the converged evacuation flow fields, which are calculated at the beginning of the FDS+Evac calculation. This file depends only on the evacuation meshes. By default, this file is always (re)calculated. If the keyword EVACUATION_MC_MODE=.TRUE. is given on the MISC namelist group then this file is tried to read in, if this file exist and there are no fire meshes in the FDS+Evac input file. 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 94

93 9. Miscellaneous Information results. This is why the EFF file is useful. The same is true when one is doing many 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 flow fields and, thus, one is saving some CPU seconds. This file need not to be recalculated, if only the namelists EVAC, EVHO, PERS, EVSS, STRS and ENTR are changed in the FDS+Evac input file. Also the simulation time T_END on the TIME namelist may be changed together with any only fire mesh related changes that do not change the evacuation geometry. The file CHID_evac.fed contains the smoke and gas concentration information from the FDS fire calculation. This file is tried to read in, if there are no fire meshes specified in the input file. If there is at least one fire mesh specified and also at least one main evacuation mesh (EVAC_HUMANS=.TRUE. and EVACUATION=.TRUE.) specified, then this file is (re)calculated and saved on the disk. Because FDS+Evac is stochastic, one should do a couple of dozen evacuation simulation per one fire calculation and then this file will speed up the calculation very much, i.e., the fire calculation has to be done only once. See also Ch The FED file should be recalculated if the evacuation meshes are changed and if the namelists CORR are changed. Note, that the FED file is always (re)calculated and saved to the hard disk when there are both fire and main evacuation meshes present in the input file. If EVACUATION_DRILL is set to true then no fire calculation is done and the FED file is not tired to read in. Note, that both files 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 files. One can add more doors and exits to the evacuation calculation and still use the old FED file if there is no need to change the geometry (the OBSTs). NOTE: The CHID_evac.eff is sensitive to changes in the main evacuation mesh geometry and the CHID_evac.fed is sensitive to changes in the visibility mesh geometry. 9.3 FDS+Evac: Output Files FDS+Evac produces a file CHID_evac.csv, which has information on the number of agents on the different floors and stairs at a given time as well as the total number of agents inside the building. The file also list the number of agents gone through each exit and door. The keyword DT_HRR on the DUMP namelist defines the output time step. The first column is the time and the second column is the number of agents inside the whole building. Then the number of agents in each evacuation meshes ( floors ) and in each corridor/stairs (CORR and STRS 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 index is calculated, i.e., the smoke and toxic gas information is available. The first 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 95

94 9. Miscellaneous Information last column is the maximum FED value among 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 files. 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 defines the output frequency for the agents to be shown in Smokeview. The evacuation particle files are using same format as the FDS fire calculation particle files, see the FDS User s Guide for the details on the format. The namelists EXIT (not the COUNT_ONLY=.TRUE. exits, i.e., counters) and DOOR are shown as devices in Smokeview, which are vertical rectangles and whose front side has FOREST GREEN colour if the object is open and RED if it is closed (the keywords TIME_OPEN and TIME_CLOSE). Also a FOREST GREEN cone, whose head is at the position defined by XYZ, is shown and it points towards the IOR direction. The namelist ENTR is shown as vertical rectangle, whose front side has SKY BLUE colour if the entry is open and RED if it is closed (the keywords TIME_START and TIME_STOP). The backside colours of all these three devices can be defined in the input file. The EVSS namelist is shown as a rectangle, which is positioned accordingly and its colour is defined by the user. All of these devices are shown by default in Smokeview. The Smokeview submenu Devices in the menu Show/Hide allows to toggle between show and hide for these three different device classes. During the run of FDS+Evac some evacuation information is printed on the text file CHID_evac.out, like the initial positions and characteristics of the agents. A FDS+Evac run always produces the file CHID_evac.eff, which contains the evacuation flow fields used to guide the agents towards the different doors and exits. This file 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 A FDS+Evac run, which has both fire and main evacuation meshes present, produces the file CHID_evac.fed contains the smoke and gas concentration information for the evacuation calculation. This file can be used later, if more evacuation calculations are done using the fire scenario and same evacuation geometry, e.g., if one is doing a Monte Carlo simulation of the egress scenario, see Chapters 7.2 and Restarting a fire+evacuation calculation There is no way to restart an evacuation calculation. But a combined fire+evacuation calculation can be restarted so that it produces the smoke information for the evacuation calculation. For a given fire calculation many evacuation calculations with the same inputs are done, because FDS+Evac is a stochastic evacuation programme. If some evacuation calculation fails then it can be started once again and there should not be too much CPU time lost when comparing to the total time needed for the many different evacuation calculations. Just like a fire calculation restart, but might be a little bit fragile. This means that 96

95 9. Miscellaneous Information if the run crushed during the write of CHID_evac.fed file, there might be some problems. The restarted fire+evacuation calculation continues the fire calculation nicely, but there are no agents in the evacuation calculation, so do not use the evacuation output in your analysis. The restarted run produces nice CHID_evac.fed file, which one can use to do the evacuation calculation using correct smoke information. The results of a fire+evacuation and an evacuation+fed-file calculations are just the same. Both are full fire+evacuation calculations when evacuation part is considered. NOTE: The results are not same, because the evacuation part is stochastic: random numbers used to generate different things. 97

96 10. Sample Input Files Below two example inputs files of FDS+Evac are given. These input files 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 files can be downloaded from the FDS+Evac web pages, where the latest versions of these files 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 files from this manual, go to the web pages and download the files. Note also that the files 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 files. In Wordpad you can save the file as Text Document - MS-DOS Format. This will change the line endings to the DOS style. The first input file specifies a fire in a room with two doors, see Fig. 35. Agents are using both doors and they select the door by using the exit door selection algorithm. Figure 35. Example 1: Evacuation and fire calculation geometries. 98

97 10. Sample Input Files &HEAD CHID='evac_example1a', TITLE='Test 1, fire+evac' / Fire mesh(es). &MESH IJK=54,50,12, XB= -0.2,10.6, 0.0,10.0, 0.0,2.4 / Evacuation mesh: &MESH IJK=60,54,1, XB= -0.4,11.6, -0.4,10.4, 0.4,1.6, EVAC_Z_OFFSET=1.0, EVACUATION=.TRUE., EVAC_HUMANS=.TRUE., ID='MainEvacGrid' / &TIME T_END=200.0 / &MISC EVACUATION_MC_MODE=.FALSE., EVACUATION_DRILL=.FALSE., / &DUMP SMOKE3D=.TRUE., NFRAMES=200, DT_PART=0.5, DT_HRR=1.0, DT_SLCF=1.0, DT_BNDF=5.0, DT_PL3D=100.0, DT_ISOF=5.0 / &REAC ID= 'PROPANE', FUEL='PROPANE', SOOT_YIELD=0.10, CO_YIELD=0.05, / &SURF ID='BURNER', HRRPUA=1000., COLOR='RASPBERRY' / &MATL ID='GYPSUM PLASTER', CONDUCTIVITY = 0.48,SPECIFIC_HEAT= 0.84, DENSITY= / &SURF ID = 'WALL', DEFAULT=.TRUE., RGB = 100,100,100, MATL_ID = 'GYPSUM PLASTER', THICKNESS = /TMP_FRONT=500.0, &SURF ID='EVAC_WALL', RGB= 200,0,200, EVAC_DEFAULT=.TRUE. / or COLOR ============= FIRE FDS GEOMETRY STARTS ================ &OBST XB= -0.20, 0.00, -0.20, 10.20, 0.00, 2.40, SURF_ID='WALL' / &OBST XB= 10.00,10.20, -0.20, 10.20, 0.00, 2.40, SURF_ID='WALL' / &OBST XB= -0.20,10.20, -0.20, 0.00, 0.00, 2.40, SURF_ID='WALL' / &OBST XB= -0.20,10.20, 10.00, 10.20, 0.00, 2.40, SURF_ID='WALL' / &OBST XB= 10.00,11.60, 4.20, 4.40, 0.00, 2.40, SURF_ID='WALL' / &OBST XB= 10.00,11.60, 5.60, 5.80, 0.00, 2.40 / &HOLE XB= -0.21, 0.01, 4.39, 5.61, 0.00, 2.00 / &HOLE XB= 9.99,10.21, 4.39, 5.61, 0.00, 2.00 / The fire as an 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 XB=-0.2,-0.2, 4.4,5.6,0.0,2.0,SURF_ID='OPEN', COLOR='GREEN' / &VENT XB=10.6,10.6, 4.4,5.6,0.0,2.0,SURF_ID='OPEN', COLOR='GREEN' / ============= FIRE FDS GEOMETRY ENDS ================== ============= EVAC GEOMETRY STARTS ==================== &EXIT ID='LeftExit', IOR=-1, FYI= 'Comment line', 99

98 10. Sample Input Files COLOR='YELLOW', XYZ= 0.20, 5.00, 1.00, XB= -0.20,-0.20, 4.40,5.60, 0.40,1.60 / &EXIT ID='RightExit', IOR=+1, FYI= 'Comment line', COLOR='BLUE', XYZ= 11.40, 5.00, 1.00, XB= 11.60,11.60, 4.40,5.60, 0.40,1.60 / &EXIT ID='RightCounter', IOR=+1, FYI= 'Comment line', COUNT_ONLY=.TRUE., XB= 10.00,10.00, 4.40,5.60, 0.40,1.60 / Evacuation calculation, human properties &PERS ID='Adult', FYI='Male+Female diameter and velocity', DEFAULT_PROPERTIES='Adult', PRE_EVAC_DIST=1,PRE_LOW=5.0,PRE_HIGH=15.0, DET_EVAC_DIST=1,DET_LOW=5.0,DET_HIGH=15.0, TDET_SMOKE_DENS=0.1, HUMAN_SMOKE_HEIGHT=1.60, DENS_INIT=4.0, OUTPUT_SPEED=.TRUE., OUTPUT_FED=.TRUE., COLOR_METHOD=4, I_HERDING_TYPE=2, / &PERS ID='Male', FYI='Male diameter and velocity', DEFAULT_PROPERTIES='Male', PRE_EVAC_DIST=1,PRE_LOW=5.0,PRE_HIGH=15.0, DET_EVAC_DIST=1,DET_LOW=5.00,DET_HIGH=15.0 / &PERS ID='Female', FYI='Female diameter and velocity', DEFAULT_PROPERTIES='Female', PRE_EVAC_DIST=1,PRE_LOW=5.0,PRE_HIGH=15.0, DET_EVAC_DIST=1,DET_LOW=5.00,DET_HIGH=15.0 / &PERS ID='Child', FYI='Child diameter and velocity', DEFAULT_PROPERTIES='Child', PRE_EVAC_DIST=1,PRE_LOW=5.0,PRE_HIGH=15.0, DET_EVAC_DIST=1,DET_LOW=5.00,DET_HIGH=15.0 / &PERS ID='Elderly', FYI='Elderly diameter and velocity', DEFAULT_PROPERTIES='Elderly', 100

99 10. Sample Input Files PRE_EVAC_DIST=1,PRE_LOW=5.0,PRE_HIGH=15.0, DET_EVAC_DIST=1,DET_LOW=5.00,DET_HIGH=15.0 / Initial positions of the humans &EVAC ID = 'HumanLeftDoorKnown', NUMBER_INITIAL_PERSONS = 25, XB = 1.0,9.0, 1.0,9.0, 0.4,1.6 AVATAR_COLOR = 'BLUE', AGENT_TYPE=2, KNOWN_DOOR_NAMES = 'LeftExit', KNOWN_DOOR_PROBS = 1.0, PERS_ID = 'Male' / &EVAC ID= 'HumanRightDoorKnown', NUMBER_INITIAL_PERSONS= 25, XB= 1.0,9.0, 1.0,9.0, 0.4,1.6 AVATAR_COLOR= 'RED', AGENT_TYPE=2, KNOWN_DOOR_NAMES= 'RightExit', KNOWN_DOOR_PROBS= 1.0, PERS_ID= 'Female' / &EVAC ID= 'HumanBothDoorsKnown', NUMBER_INITIAL_PERSONS= 25, XB= 1.0,9.0, 1.0,9.0, 0.4,1.6 AVATAR_COLOR= 'GREEN', AGENT_TYPE=2, KNOWN_DOOR_NAMES= 'LeftExit','RightExit', KNOWN_DOOR_PROBS= 1.0,1.0, PERS_ID= 'Child' / &EVAC ID= 'HumanNoDoorKnown', NUMBER_INITIAL_PERSONS= 25, XB= 1.0,9.0, 1.0,9.0, 0.4,1.6 FLOW_FIELD_ID= 'MainEvacGrid', AVATAR_COLOR= 'BLACK', AGENT_TYPE=2, PERS_ID= 'Adult' / An evacuation hole, i.e., do not put humans here &EVHO ID= 'Evho_Fire', FYI= 'Do not put humans close to the fire', XB= 2.0,5.0, 2.0,5.0, 0.4,1.6 / Fire calculation output. &BNDF QUANTITY='WALL TEMPERATURE' / &SLCF PBX=3.50, QUANTITY='TEMPERATURE' / &SLCF PBX=3.50, QUANTITY='VELOCITY' / &SLCF PBX=3.50, QUANTITY='PRESSURE' / &SLCF PBY=5.0, QUANTITY='TEMPERATURE' / &SLCF PBY=5.0, QUANTITY='VELOCITY' / &SLCF PBY=5.0, QUANTITY='PRESSURE' / 101

100 10. Sample Input Files Figure 36. Example 2: Evacuation calculation geometry. Next line could be used to plot the evacuation flow fields: SLCF PBZ= 1.0, QUANTITY='VELOCITY', VECTOR=.TRUE., EVACUATION=.TRUE. / &TAIL / The second input file specifies a two-floor building, see Fig. 36. There is a fire in downstairs and the smoke is going to the second floor by an opening at the ceiling. The second floor is connected to the first floor in the egress calculation, i.e., the second floor agents are transferred to the first floor by the combination of doors and stairs. The second floor has two exit doors, one leading to the stairs going to the first floor (the right exit door) and one leading to the stairs leading directly to outside of the building (the left exit). The first floor has two exit doors and one entry, which the agents from the second floor are using when entering the first floor. FDS+Evac version: FDS 6.1.2, Evac (SVN 19770) &HEAD CHID='evac_example2a', TITLE='Test 2, fire+evac' / Fire mesh(es). &MESH IJK=54,50,25, XB= -0.2,10.6, 0.0,10.0, 0.0,5.0 / Evacuation mesh: &MESH IJK=60,54,1, XB= -0.4,11.6, -0.4,10.4, 0.4,1.6, EVAC_Z_OFFSET=1.0, EVACUATION=.TRUE., EVAC_HUMANS=.TRUE., ID='MainEvacGrid' / &MESH IJK=54,54,1, XB= -0.4,10.4, -0.4,10.4, 3.0,4.2, EVAC_Z_OFFSET=1.0, EVACUATION=.TRUE., EVAC_HUMANS=.TRUE., ID='MainEvacGrid2' / 102