An Introduction To: Fire Simulation

An introduction to
Fire Simulation
with FDS and Smokeview
Updated to FDS 5.5.1 and BlenderFDS

Development
Download a revised version of this document from:
• http://www.emanuelegissi.eu
You can participate in the development of this document. Please, contact me

at:
• [email protected]
This manual was produced using LYX and OpenOffice.org on Ubuntu Linux. The
LATEX file intro_to_fire_sim.tex was compiled on July 16, 2010.
Copyright notice
This work is licensed under the Creative Commons Attribution-Share Alike 3.0
License. To view a copy of this license, visit:
• http://creativecommons.org/licenses/by-sa/3.0/
You are free to use, share, adapt this work. Remember to cite the sources and
to use the same open license for derivative work.
About the Author
Emanuele Gissi ([email protected]) is a fire officer since 2002, serving

at the Comando provinciale dei Vigili del Fuoco, Genova (Italy), a branch of
the governmental fire safety national organization (http://www.vigilfuoco.it/).
He is a mechanical engineer and obtained a doctorate in Engineering
Physics (EP) in 2001. His work is focused on incident command, re-
view of performance based fire safety design, and fire investigation. He
provides basic and advanced training on fire simulation to fire officers and
professionals.
iii
iv
Preface
This manual was born as a small tutorial for students of fire safety engineering
courses. Then it grew to the current state.
The main goal of this manual is to introduce the student to the complex world of
fire simulation with Fire Dynamics Simulator and Smokeview, and complements
the official documentation. The official documentation remains an invaluable
source of reference for advanced users and this manual is heavily based on it.
Some large parts are even copy-pasted and adapted.
In this manual, topics are organized in a strict logical order and the basics are
thoroughly explained to improve the learning curve. Some advanced topics are
completely omitted for the sake of simplicity.
According to teaching experience, students understand the logic behind the Fire
Dynamics Simulator and become autonomous learners after 16 hours of course:
they learn to work independently and are able to develop reasonable engineering
level applications by themselves.
v
vi
Acknowledgments
People
The National Institute of Standards and Technology (NIST), a federal agency
within the Department of Commerce of the United States, is the major driving
force behind Fire Dynamics Simulator development.
The Fire Dynamics Simulator has been publicly released on 2000. Since its first
release, continued improvements have been made to the software based largely
on feedback from its users and on the hard work of some NIST employees.
Fire Dynamics Simulator documentation is written and maintained by Kevin
McGrattan, Bryan Klein, Simo Hostikka, and Jason Floyd from
various organizations. Their user support through the discussion group is always
complete, fast, and precious. In a simple word: friendly.
I owe to them large parts of this manual and most of my knowledge on fire
simulation. Thus, I thank them once more.
Ideas
This manual is open content and free, because it’s published in a format that
explicitly allows copying and modifying of its information by anyone.
Fire Dynamics Simulator itself is free and in the public domain. Linux1 and
Openoffice.Org2 are free and open source.
I thank the open source movement as a whole, as the best things in life are free.
1
Linux is an open source operating system. See http://www.ubuntu.com/ for an user
friendly Linux distribution.
2
Openoffice.org is an open source office and productivity program for Linux, MS Windows,
and MacOS X. See http://www.openoffice.org/ for further details.
vii
viii
Contents
1 Introduction 1
1.1 Complexity of fire phenomena . . . . . . . . . . . . . . . . . . . 1
1.2 Approaches to fire simulation . . . . . . . . . . . . . . . . . . . 2
1.3 Simplification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Inside FDS 7
2.1 What are FDS ans Smokeview? . . . . . . . . . . . . . . . . . . 7
2.2 Engineering applications . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Who develops FDS? . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Who uses FDS? . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 How much does it cost? . . . . . . . . . . . . . . . . . . . . . . 9
2.6 How does FDS work? . . . . . . . . . . . . . . . . . . . . . . . 9
2.6.1 Hydrodynamic model . . . . . . . . . . . . . . . . . . . 9
2.6.2 Combustion model . . . . . . . . . . . . . . . . . . . . . 9
2.6.3 Radiation transport . . . . . . . . . . . . . . . . . . . . 10
2.6.4 Geometry and multiple meshes . . . . . . . . . . . . . . 10
2.6.5 Parallel processing . . . . . . . . . . . . . . . . . . . . . 11
2.6.6 Boundary conditions . . . . . . . . . . . . . . . . . . . . 11
2.7 Limitations of FDS . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7.1 Low speed flow assumption . . . . . . . . . . . . . . . . 11
2.7.2 Rectilinear geometry . . . . . . . . . . . . . . . . . . . . 11
2.7.3 Fire growth and spread . . . . . . . . . . . . . . . . . . 12
2.7.4 Combustion . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7.5 Radiation . . . . . . . . . . . . . . . . . . . . . . . . . . 13
ix
x CONTENTS
3 Running FDS 15
3.1 Online resources and user support . . . . . . . . . . . . . . . . . 15
3.2 Graphical user interface . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Version numbers . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4 Hardware requirements . . . . . . . . . . . . . . . . . . . . . . . 16
3.5 Serial and parallel calculations . . . . . . . . . . . . . . . . . . . 17
3.6 Installing on Windows XP . . . . . . . . . . . . . . . . . . . . . 17
3.7 Installing on Ubuntu Linux . . . . . . . . . . . . . . . . . . . . . 18
3.7.1 First install . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.7.2 Installing a new version . . . . . . . . . . . . . . . . . . 20
3.8 Compiling an optimized binary . . . . . . . . . . . . . . . . . . . 20
3.9 Performing a calculation . . . . . . . . . . . . . . . . . . . . . . 20
3.9.1 Running serial FDS on Windows XP . . . . . . . . . . . . 20
3.9.2 Running serial FDS on Ubuntu Linux . . . . . . . . . . . 21
3.9.3 Running parallel FDS on Ubuntu Linux . . . . . . . . . . 21
3.10 Monitoring progress . . . . . . . . . . . . . . . . . . . . . . . . 23
3.11 Stop a calculation . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.12 Visualizing results . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.13 Output files . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4 Input file basics 27

4.1 Syntax of the input file . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Writing an input file . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3 The logic behind most FDS input files . . . . . . . . . . . . . . 31
4.4 Keep it simple . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.5 Each model, its input data . . . . . . . . . . . . . . . . . . . . . 35
4.6 Units of measurement . . . . . . . . . . . . . . . . . . . . . . . 36
4.7 Reference coordinate system . . . . . . . . . . . . . . . . . . . . 36
4.8 Prescribing geometric entities . . . . . . . . . . . . . . . . . . . 37
4.9 Prescribing orientations . . . . . . . . . . . . . . . . . . . . . . 38
4.10 Prescribing colors and aspect . . . . . . . . . . . . . . . . . . . 39
CONTENTS xi
5 General configuration 41
5.1 Naming the job, HEAD . . . . . . . . . . . . . . . . . . . . . . . 41
5.2 Simulation time, TIME . . . . . . . . . . . . . . . . . . . . . . . 42
5.3 Miscellaneous, MISC . . . . . . . . . . . . . . . . . . . . . . . . 42
6 Combustion and radiation 45

6.1 Combustion is not pyrolysis . . . . . . . . . . . . . . . . . . . . 45
6.2 Prescribing a fire . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.3 Modeling gas phase combustion, REAC . . . . . . . . . . . . . . 46
6.3.1 Ignition . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.3.2 Burning . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.4 CO production in under-ventilated fires . . . . . . . . . . . . . . 51
6.5 Flame extinction . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.6 Radiation transport, RADI . . . . . . . . . . . . . . . . . . . . . 52
7 Computational domain 55
7.1 Defining a mesh, MESH . . . . . . . . . . . . . . . . . . . . . . . 55
7.2 Multiple meshes . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7.3 Conformity to the mesh . . . . . . . . . . . . . . . . . . . . . . 58
7.4 Choosing the right mesh dimension:
a sensitivity study . . . . . . . . . . . . . . . . . . . . . . . . . 59
7.5 Initial conditions of the computational domain, INIT . . . . . . . 60
8 Materials 63
8.1 Defining a material, MATL . . . . . . . . . . . . . . . . . . . . . 63
8.2 Thermal properties . . . . . . . . . . . . . . . . . . . . . . . . . 64
8.3 Burning properties . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.3.1 Solids . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.3.2 Liquids . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.3.3 HEAT_OF_COMBUSTION in a MATL line? . . . . . . . . . . 67
8.4 Properties hell . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
8.5 Resources for material property data . . . . . . . . . . . . . . . 68
xii CONTENTS
9 Extra gas species 69

9.1 Defining extra gas species, SPEC . . . . . . . . . . . . . . . . . . 69
9.2 CARBON DIOXIDE and carbon dioxide . . . . . . . . . . . . . 70
10 Lagrangian particles 73
10.1 Defining Lagrangian particles, PART . . . . . . . . . . . . . . . . 73
10.2 Massless particles . . . . . . . . . . . . . . . . . . . . . . . . . 74
10.3 Water droplets . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
11 Boundary conditions 77
11.1 Defining boundary conditions, SURF . . . . . . . . . . . . . . . . 77
11.2 Predefined boundary conditions . . . . . . . . . . . . . . . . . . 79
11.3 Coloring boundary conditions . . . . . . . . . . . . . . . . . . . 80
11.4 Examples of boundary conditions . . . . . . . . . . . . . . . . . 81
11.4.1 Adiabatic surface . . . . . . . . . . . . . . . . . . . . . . 81
11.4.2 Fixed temperature and heat flux . . . . . . . . . . . . . . 81
11.4.3 Fans . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
11.4.4 Fans injecting extra gas species . . . . . . . . . . . . . . 83
11.4.5 Dynamic pressure at an open boundary . . . . . . . . . . 84
11.4.6 Prescribing an heat release rate . . . . . . . . . . . . . . 84
11.5 Geometric conformity and rates . . . . . . . . . . . . . . . . . . 85
11.6 Boundary conditions for solids . . . . . . . . . . . . . . . . . . . 85
11.6.1 Backing . . . . . . . . . . . . . . . . . . . . . . . . . . 86
11.6.2 Setting an initial temperature . . . . . . . . . . . . . . . 88
11.7 Time dependent boundary conditions . . . . . . . . . . . . . . . 88
11.7.1 Simplified ramps . . . . . . . . . . . . . . . . . . . . . . 88
11.7.2 User defined ramps . . . . . . . . . . . . . . . . . . . . 89
11.8 Injecting Lagrangian particles . . . . . . . . . . . . . . . . . . . 91
CONTENTS xiii
12 Solid geometry 93
12.1 Defining solid obstructions, OBST . . . . . . . . . . . . . . . . . 93
12.2 Creating voids inside obstructions, HOLE . . . . . . . . . . . . . . 96
12.3 Prescribing a different boundary condition, VENT . . . . . . . . . 97
12.4 Default boundary condition . . . . . . . . . . . . . . . . . . . . 99
12.5 How thick is a wall? . . . . . . . . . . . . . . . . . . . . . . . . 100
12.6 Thin sheet obstructions . . . . . . . . . . . . . . . . . . . . . . 101
12.7 Activating and deactivating objects . . . . . . . . . . . . . . . . 102
12.8 Stair stepping complex geometries . . . . . . . . . . . . . . . . . 102
12.9 Coloring individual objects . . . . . . . . . . . . . . . . . . . . . 103
12.10Making burning solids disappear . . . . . . . . . . . . . . . . . . 104
13 Devices and control logic 105

13.1 Devices, DEVC and PROP . . . . . . . . . . . . . . . . . . . . . . 105
13.2 Examples of devices . . . . . . . . . . . . . . . . . . . . . . . . 107
13.2.1 Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
13.2.2 Thermometer . . . . . . . . . . . . . . . . . . . . . . . 107
13.2.3 Smoke detector . . . . . . . . . . . . . . . . . . . . . . 107
13.2.4 Beam smoke detector . . . . . . . . . . . . . . . . . . . 108
13.2.5 Sprinkler and heat detector . . . . . . . . . . . . . . . . 108
13.3 Basic control logic . . . . . . . . . . . . . . . . . . . . . . . . . 109
13.4 Advanced control logic . . . . . . . . . . . . . . . . . . . . . . . 111
14 Output 113
14.1 Prescribing output . . . . . . . . . . . . . . . . . . . . . . . . . 113
14.2 Output control parameters, DUMP . . . . . . . . . . . . . . . . . 115
14.3 Point measurement devices, DEVC . . . . . . . . . . . . . . . . . 115
14.3.1 Record a gas phase quantity . . . . . . . . . . . . . . . . 116
14.3.2 Record a solid phase quantity . . . . . . . . . . . . . . . 116
14.3.3 Record integrated quantities . . . . . . . . . . . . . . . . 117
xiv CONTENTS
14.4 Animated planar slices, SLCF . . . . . . . . . . . . . . . . . . . 117

14.5 Animated boundary quantities, BNDF . . . . . . . . . . . . . . . 118
14.6 Animated isosurfaces, ISOF . . . . . . . . . . . . . . . . . . . . 120
14.7 Realistic smoke and fire . . . . . . . . . . . . . . . . . . . . . . 121
14.8 Heat release rate . . . . . . . . . . . . . . . . . . . . . . . . . . 122
14.9 Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
14.10Upper and lower layers . . . . . . . . . . . . . . . . . . . . . . . 123
14.11Heat fluxes and thermal radiation . . . . . . . . . . . . . . . . . 124
14.12Interfacing with structural models . . . . . . . . . . . . . . . . . 124
14.13Visualizing Lagrangian particles . . . . . . . . . . . . . . . . . . 125
14.14Frequently used output quantities . . . . . . . . . . . . . . . . . 125
15 Using BlenderFDS 129

15.1 A faster way to writing input files . . . . . . . . . . . . . . . . . 129
15.2 From the Community, to the Community . . . . . . . . . . . . . 130
15.3 Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . 131
16 Real world examples 133

16.1 Building a ventilator . . . . . . . . . . . . . . . . . . . . . . . . 133
16.2 Prescribing a simplified burning material . . . . . . . . . . . . . 133
16.3 Simulation and revelation of smoke of a smoldering fire . . . . . 134
16.4 A pan filled of ethanol . . . . . . . . . . . . . . . . . . . . . . . 135
16.5 A simple car parking . . . . . . . . . . . . . . . . . . . . . . . . 135
16.5.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . 135
16.5.2 Input file and results . . . . . . . . . . . . . . . . . . . . 137
16.6 An university building . . . . . . . . . . . . . . . . . . . . . . . 146
List of Figures
3.1 A cluster of Linux computers . . . . . . . . . . . . . . . . . . . 18

3.2 Starting a serial calculation on Windows XP and on Linux Ubuntu 21
3.3 Running a parallel calculation and monitoring the system on Ubuntu
Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 Running Smokeview on Windows XP and on Ubuntu Linux . . . . 24
4.1 The structure of an FDS namelist group . . . . . . . . . . . . . 27

4.2 Modeling reality in FDS . . . . . . . . . . . . . . . . . . . . . . 35
4.3 The reference system, a volume, a face, a segment, a point, and
a plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.1 Combustion is not pyrolysis . . . . . . . . . . . . . . . . . . . . 46

6.2 Combustion and pyrolysis in a flaming match . . . . . . . . . . . 47
6.3 Flame extinction criteria . . . . . . . . . . . . . . . . . . . . . . 52
7.1 The computational domain composed by four meshes . . . . . . 57

7.2 Mesh connections: (a) ideal, (b) allowed, and (c) forbidden . . . 58
7.3 Geometric object: before and after automatic shifting . . . . . . 58
11.1 Extending the computational domain beyond the vent . . . . . . 80

11.2 brick wall: multiple layers of different materials . . . . . . . . 86
11.3 HRRPUA as function of time after SURF activation . . . . . . . . . 89
11.4 VEL and TMP_FRONT as function of time after SURF activation . . 90
12.1 Boundary conditions prescribed with SURF_ID, SURF_IDS, and

SURF_ID6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
xv
xvi LIST OF FIGURES
12.2 OBST, HOLE and VENT . . . . . . . . . . . . . . . . . . . . . . . 97

12.3 Setting boundary conditions to exterior boundaries of the com-
putational domain . . . . . . . . . . . . . . . . . . . . . . . . . 98
12.4 Flow velocity on two sides of an oblique wall. Lower side has
SAWTOOTH=.FALSE. set. . . . . . . . . . . . . . . . . . . . . . . 103
14.1 Output of animated planar slices SLCF as viewed in Smokeview . 117

14.2 Output of animated boundary quantities, BNDF as viewed in Smoke-
view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
14.3 Output of animated isosurfaces, ISOF as viewed in Smokeview . . 120
14.4 Output of soot MASS FRACTION and HRRPUV as viewed in Smoke-
view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
15.1 A BlenderFDS session . . . . . . . . . . . . . . . . . . . . . . . 130

15.2 A BlenderFDS property panel . . . . . . . . . . . . . . . . . . . 131
15.3 Exporting a BlenderFDS model to an FDS input file . . . . . . . 132
16.1 Car parking plan . . . . . . . . . . . . . . . . . . . . . . . . . . 136

16.2 The entered geometry . . . . . . . . . . . . . . . . . . . . . . . 141
16.3 Heat release rate curve . . . . . . . . . . . . . . . . . . . . . . . 141
16.4 Thermocouples at the center of the car parking. . . . . . . . . . 142
16.5 Gas temperatures in front of window panes vs time. . . . . . . . 142
16.6 FED vs time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
16.7 Layer height vs time. . . . . . . . . . . . . . . . . . . . . . . . . 143
16.8 AST (Adiabatic Surface Temperature) boundary file at 1200 s. . . 144
16.9 Visibility slice file at 120 s. . . . . . . . . . . . . . . . . . . . . . 144
16.10Visibility (10 m) isosurface at 300 s. . . . . . . . . . . . . . . . . 145
16.11Net heat flux on boundary surfaces at 1200 s. . . . . . . . . . . 145
16.12The university building as modeled in BlenderFDS . . . . . . . . 146
16.13The exported FDS input file, as shown by Smokeview . . . . . . 146
List of Tables
4.1 Systematic organisation of the input file . . . . . . . . . . . . . . 33

4.2 COLOR values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1 HEAD parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2 TIME parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3 MISC parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.1 Mixture fraction species . . . . . . . . . . . . . . . . . . . . . . 49

6.2 REAC parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.3 RADI parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.1 IJK values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

7.2 MESH parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.3 INIT parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 61
8.1 MATL parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 63

8.2 RAMP (temperature) parameters . . . . . . . . . . . . . . . . . . 65
9.1 Predefined extra species . . . . . . . . . . . . . . . . . . . . . . 69

9.2 SPEC parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 70
10.1 PART parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 74
11.1 SURF parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 78

11.2 RAMP (time) parameters . . . . . . . . . . . . . . . . . . . . . . 90
xvii
xviii LIST OF TABLES
12.1 OBST parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 95

12.2 HOLE parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 96
12.3 VENT parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 99
13.1 DEVC parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 106
14.1 DUMP parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 115

14.2 Output of devices in mycase_devc.csv file . . . . . . . . . . . . 115
14.3 SLCF parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 118
14.4 BNDF parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 119
14.5 ISOF parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 121
14.6 Output of HRR in mycase_hrr.csv file . . . . . . . . . . . . . 122
14.7 Frequently used output quantities . . . . . . . . . . . . . . . . . 125
Chapter 1
Introduction
This chapter presents the problems embedded in fire simulation. The

text has been adapted from [FDS5 user’s guide], Introduction by
Howard Baum, NIST Fellow Emeritus.
1.1 Complexity of fire phenomena

The idea that the dynamics of a fire might be studied numerically dates back
to the beginning of the computer age. Indeed, the fundamental conservation
equations governing fluid dynamics, heat transfer, and combustion were first
written down over a century ago. Despite this, practical mathematical models
of fire, as distinct from controlled combustion, are relatively recent due to the
inherent complexity of the problem.
Indeed, in his brief history of the early days of fire research, Hoyt Hottel
noted:
“A case can be made for fire being, next to the life processes, the
most complex of phenomena to understand” [Hottel 1984].
The difficulties revolve about three issues:
• First, there are an enormous number of possible fire scenarios to consider

due to their accidental nature.
• Second, the physical insight and computing power required to perform all
the necessary calculations for most fire scenarios are limited. Any funda-
mentally based study of fires must consider at least some aspects of bluff
1
2 CHAPTER 1. INTRODUCTION
body aerodynamics, multi-phase flow, turbulent mixing and combustion,

radiative transport, and conjugate heat transfer; all of which are active
research areas in their own right.
• Finally, the fuel in most fires was never intended as such.
Thus, the mathematical models and the data needed to characterize the degrada-
tion of the condensed phase materials that supply the fuel may not be available.
Indeed, the mathematical modeling of the physical and chemical transformations
of real materials as they burn is still in its infancy.
In order to make progress, the questions that are asked have to be greatly sim-
plified.
To begin with, instead of seeking a methodology that can be applied to all fire
problems, we begin by looking at a few scenarios that seem to be most amenable
to analysis. Hopefully, the methods developed to study these simple problems
can be generalized over time so that more complex scenarios can be analyzed.
Second, we must learn to live with idealized descriptions of fires and approximate
solutions to our idealized equations.
Finally, the methods should be capable of systematic improvement. As our phys-
ical insight and computing power grow more powerful, the methods of analysis
can grow with them.
1.2 Approaches to fire simulation

To date, four distinct approaches to the simulation of fires have emerged. Each
of these treats the fire as an inherently three dimensional process evolving in
time.
Zone models The first to reach maturity, the zone models, describe compartment fires. Each
compartment is divided into two spatially homogeneous volumes, a hot upper
layer and a cooler lower layer. Mass and energy balances are enforced for each
layer, with additional models describing other physical processes appended as
differential or algebraic equations as appropriate. Examples of such phenomena
include fire plumes, flows through doors, windows and other vents, radiative
and convective heat transfer, and solid fuel pyrolysis. Model development has
progressed to the point where documented and supported software implementing
these models are widely available, such as CFAST1 .
The Consolidated Model of Fire and Smoke Transport (CFAST) is a two-zone fire model
1
used to calculate the evolving distribution of smoke, fire gases and temperature throughout
compartments of a building during a fire. Visit http://cfast.nist.gov/ for further information.
1.2. APPROACHES TO FIRE SIMULATION 3
The relative physical and computational simplicity of the zone models has led to
their widespread use in the analysis of fire scenarios. So long as detailed spatial
distributions of physical properties are not required, and the two layer description
reasonably approximates reality, these models are quite reliable. However, by their
very nature, there is no way to systematically improve them.
The rapid growth of computing power and the corresponding maturing of com-
putational fluid dynamics (CFD), has led to the development of CFD based field
models applied to fire research problems. Virtually all this work is based on the
conceptual framework provided by the Reynolds-averaged form of the Navier-
Stokes equations (RANS). The use of CFD models has allowed the description RANS
of fires in complex geometries, and the incorporation of a wide variety of physical
phenomena.
However, these models have a fundamental limitation for fire applications – the
averaging procedure at the root of the model equations.
RANS models were developed as a time-averaged approximation to the conser-
vation equations of fluid dynamics. While the precise nature of the averaging
time is not specified, it is clearly long enough to require the introduction of large
eddy transport coefficients to describe the unresolved fluxes of mass, momentum
and energy. This is the root cause of the smoothed appearance of the results
of even the most highly resolved fire simulations. The smallest resolvable length
scales are determined by the product of the local velocity and the averaging time
rather than the spatial resolution of the underlying computational grid.
Unfortunately, the evolution of large eddy structures characteristic of most fire
plumes is lost with such an approach, as is the prediction of local transient events.
It is sometimes argued that the averaging process used to define the equations is
an ensemble average over many replicates of the same experiment or postulated
scenario. However, this is a moot point in fire research since neither experiments
nor real scenarios are replicated in the sense required by that interpretation of
the equations.
The application of Large Eddy Simulation (LES) techniques to fire is aimed at LES
extracting greater temporal and spatial fidelity from simulations of fire performed
on the more finely meshed grids allowed by ever faster computers.
The phrase LES refers to the description of turbulent mixing of the gaseous
fuel and combustion products with the local atmosphere surrounding the fire.
This process, which determines the burning rate in most fires and controls the
spread of smoke and hot gases, is extremely difficult to predict accurately. This
is true not only in fire research but in almost all phenomena involving turbulent
fluid motion. The basic idea behind the LES technique is that the eddies that
account for most of the mixing are large enough to be calculated with reasonable
accuracy from the equations of fluid dynamics. The hope (which must ultimately
be justified by comparison to experiments) is that small-scale eddy motion can
either be crudely accounted for or ignored.
DNS The fourth approach is Direct Numerical Simulation (DNS). DNS is a simula-
tion in computational fluid dynamics in which the Navier-Stokes equations are
numerically solved without any turbulence model. This means that the whole
range of spatial and temporal scales of the turbulence must be resolved in the
computational mesh.
The computational cost of DNS is very high, even at low Reynolds numbers.
For the Reynolds numbers encountered in most industrial applications, the com-
putational resources required by a DNS would exceed the capacity of the most
powerful computers currently available.
1.3 Simplification
The equations describing the transport of mass, momentum, and energy by the
fire-induced flows must be simplified so that they can be efficiently solved for the
fire scenarios of interest. The general equations of fluid dynamics describe a rich
variety of physical processes, many of which have nothing to do with fires.
Retaining this generality would lead to an enormously complex computational
task that would shed very little additional insight on fire dynamics. The simplified
equations, developed by Rehm and Baum [Rehm 1978], have been widely adopted
by the larger combustion research community, where they are referred to as the
low Mach number combustion equations. They describe the low speed motion
of a gas driven by chemical heat release and buoyancy forces.
The low Mach number equations are solved numerically by dividing the physical
space where the fire is to be simulated into a large number of rectangular cells.
Within each cell the gas velocity, temperature, etc., are assumed to be uniform;
changing only with time. The accuracy with which the fire dynamics can be
simulated depends on the number of cells that can be incorporated into the
simulation. This number is ultimately limited by the computing power available.
Present day, single processor desktop computers limit the number of such cells
to at most a few million. This means that the ratio of largest to smallest eddy
length scales that can be resolved by the computation (the dynamic range of the
simulation) is on the order of 100. Parallel processing can be used to extend this
range to some extent, but the range of length scales that need to be accounted
for if all relevant fire processes are to be simulated is roughly 104 to 105 because
1.3. SIMPLIFICATION 5
combustion processes take place at length scales of 1 mm or less, while the length
scales associated with building fires are of the order of tens of meters.
Chapter 2
Inside FDS
This chapter gives a concise insight on how Fire Dynamics Simula-

tor works and its limitations. Possible engineering applications are
presented.
2.1 What are FDS ans Smokeview?

Fire Dynamics Simulator, version 5 (FDS) is a computational fluid dynamics FDS
(CFD) model of fire-driven fluid flow. The model solves numerically a form of
the Navier-Stokes equations appropriate for low-speed, thermally-driven flow with
an emphasis on smoke and heat transport from fires. The partial derivatives of
the conservation equations of mass, momentum and energy are approximated
as finite differences, and the solution is updated in time on a three-dimensional,
rectilinear grid. Thermal radiation is computed using a finite volume technique
on the same grid as the flow solver. Lagrangian particles are used to simulate
smoke movement, sprinkler discharge, and fuel sprays.
Smokeview is a companion program to FDS that produces images and animations Smokeview
of the results. Smokeview is able to visualize fire and smoke in a fairly realistic
way. Via its three-dimensional realistic renderings, Smokeview is an integral
part of the physical model, as it allows one to assess the visibility within a fire
compartment in ways that ordinary scientific visualization software cannot.
Although not part of the FDS/Smokeview suite maintained at NIST, there are
several third-party and proprietary add-ons to FDS either available commercially
or privately maintained by individual users.
The first version of FDS was publicly released in February 2000.
7
8 CHAPTER 2. INSIDE FDS
2.2 Engineering applications

Throughout its development, FDS has been aimed at solving practical fire prob-
lems in fire protection engineering, while at the same time providing a tool to
study fundamental fire dynamics and combustion.
Basic use It is generally recognized that FDS can be effectively used in engineering appli-
cations to model the following phenomenas:
• Low speed transport of heat and combustion products from fire;
• Radiative and convective heat transfer between the gas and solid surfaces;
• Sprinkler, heat detector, and smoke detector activation.
Advanced use FDS can be used to model the following problems, too:
• Pyrolysis;
• Flame spread and fire growth;
• Sprinkler sprays and suppression by water.
Currently, the users interested in engineering applications should probably avoid
using FDS to model the latter problems, as they are still subject to intense
research study in academic environments.
To date, about half of the applications of the model have been for design of
smoke control systems and sprinkler/detector activation studies. The other half
consist of residential and industrial fire reconstructions.
2.3 Who develops FDS?

Currently, FDS is maintained by the Building and Fire Research Laboratory
(BFRL) of National Institute of Standards and Technology. The developers at
NIST have formed a loose collaboration of interested stakeholders, including:
• VTT Technical Research Centre of Finland, a research and testing labora-
tory similar to NIST;
• The Society of Fire Protection Engineers (SFPE);
• Fire protection engineering firms that use the software;
• Engineering departments at various universities with a particular emphasis
on fire.
2.4. WHO USES FDS? 9
2.4 Who uses FDS?

The use of fire models currently extends beyond the fire research laboratories
into the engineering, fire service and legal communities.
FDS is intended for use only by those competent in the fields of fluid dynamics,
thermodynamics, heat transfer, combustion, and fire science, and is intended
only to supplement the informed judgment 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 fire safety.
Sufficient evaluation of any model is necessary to ensure that users can judge the
adequacy of its technical basis, appropriateness of its use, and confidence level
of its predictions.
2.5 How much does it cost?

FDS is free and its source code is in the public domain.
2.6 How does FDS work?

A brief description of the major features of FDS follows.
2.6.1 Hydrodynamic model

FDS solves numerically a form of the Navier-Stokes equations appropriate for low-
speed, thermally-driven flow with an emphasis on smoke and heat transport from
fires. The core algorithm is an explicit predictor-corrector scheme, second order
accurate in space and time. Turbulence is treated by means of the Smagorinsky
form of Large Eddy Simulation (LES). It is possible to perform a Direct Numerical
Simulation (DNS) if the underlying numerical mesh is fine enough. LES is the
default mode of operation.
2.6.2 Combustion model

For most applications, FDS uses a single step chemical reaction whose products
are tracked via a two-parameter mixture fraction model. The mixture fraction
is a conserved scalar quantity that represents the mass fraction of one or more
components of the gas at a given point in the flow field. By default, two com-
ponents of the mixture fraction are explicitly computed. The first is the mass
fraction of unburned fuel and the second is the mass fraction of burned fuel, as
for example the mass of the combustion products that originated as fuel.
A two-step chemical reaction with a three parameter mixture fraction decomposi-
tion can also be used with the first step being oxidation of fuel to carbon monoxide
and the second step the oxidation of carbon monoxide to carbon dioxide. The
three mixture fraction components for the two step reaction are unburned fuel,
mass of fuel that has completed the first reaction step, and the mass of fuel that
has completed the second reaction step. The mass fractions of all of the major
reactants and products can be derived from the mixture fraction parameters by
means of state relations.
Lastly, a multiple-step finite rate model is also available.
2.6.3 Radiation transport
Radiative heat transfer is included in the model via the solution of the radiation
transport equation for a gray gas, and in some limited cases using a wide band
model.
The equation is solved using a technique similar to finite volume methods for
convective transport, thus the name given to it is the Finite Volume Method
(FVM). Using approximately 100 discrete angles, the finite volume solver requires
about 20% of the total CPU time of a calculation, a modest cost given the
complexity of radiation heat transfer.
The absorption coefficients of the gas-soot mixtures are computed using [Grosshandler 1993]
narrow-band model. Liquid droplets can absorb and scatter thermal radiation.
This is important in cases involving mist sprinklers, but also plays a role in all
sprinkler cases.
2.6.4 Geometry and multiple meshes
FDS approximates the governing equations 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.
2.7. LIMITATIONS OF FDS 11
2.6.5 Parallel processing
It is possible to run an FDS calculation on more than one computer using the
Message Passing Interface (MPI).
2.6.6 Boundary conditions
All solid surfaces are assigned thermal boundary conditions, plus information
about the burning behavior of the material. Heat and mass transfer to and
from solid surfaces is usually handled with empirical correlations, although it is
possible to compute directly the heat and mass transfer when performing a Direct
Numerical Simulation (DNS).
2.7 Limitations of FDS

Although FDS can address most fire scenarios, there are limitations in all of its
various algorithms. Some of the more prominent limitations of the model are
listed here.
2.7.1 Low speed flow assumption
The use of FDS is limited to low-speed1 flow with an emphasis on smoke and heat
transport from fires. This assumption rules out using the model for any scenario
involving flow speeds approaching the speed of sound, such as explosions, choke
flow at nozzles, and detonations.
2.7.2 Rectilinear geometry
The efficiency of FDS is due to the simplicity of its rectilinear numerical grid and
the use of a fast, direct solver for the pressure field. This can be a limitation in
some situations where certain geometric features do not conform to the rectan-
gular grid, although most building components do. There are techniques in FDS
to lessen the effect of “sawtooth” obstructions used to represent non rectangular
objects, but these cannot be expected to produce good results if, for example,
the intent of the calculation is to study boundary layer effects. For most practical
1
Mach numbers less than about 0.3
large-scale simulations, the increased grid resolution afforded by the fast pressure
solver offsets the approximation of a curved boundary by small rectangular grid
cells.
2.7.3 Fire growth and spread

Because the model was originally designed to analyze industrial-scale fires, it can
be used reliably when the Heat Release Rate (HRR) of the fire is specified and the
transport of heat and exhaust products is the principal aim of the simulation. In
these cases, the model predicts flow velocities and temperatures to an accuracy
within 10% to 20% of experimental measurements, depending on the resolution
of the numerical grid2 .
However, for fire scenarios where the heat release rate is predicted rather than
specified, the uncertainty of the model is higher. There are several reasons for
this:
1. Properties of real materials and real fuels are often unknown or difficult to
obtain;
2. The physical processes of combustion, radiation and solid phase heat trans-
fer are more complicated than their mathematical representations in FDS;
3. The results of calculations are sensitive to both the numerical and physical
parameters. Current research is aimed at improving this situation, but it
is safe to say that modeling fire growth and spread will always require a
higher level of user skill and judgment than that required for modeling the
transport of smoke and heat from specified fires.
2.7.4 Combustion
For most applications, FDS uses a mixture fraction-based combustion model.
The mixture fraction is a conserved scalar quantity that is defined as the fraction
of gas at a given point in the flow field that originated as fuel. In its simplest
form, the model assumes that combustion is mixing-controlled, and that the
reaction of fuel and oxygen is infinitely fast, regardless of the temperature.
It is extremely rare to find measurements of local velocities and temperatures from fire
2
experiments that have reported error estimates that are less than 10%. Thus, the most accurate
calculations using FDS do not introduce significantly greater errors in these quantities than
the vast majority of fire experiments.
2.7. LIMITATIONS OF FDS 13
For large-scale, well-ventilated fires, this is a good assumption. However, if a fire

is in an under-ventilated compartment, or if a suppression agent like water mist
or CO2 is introduced, fuel and oxygen are allowed to mix and not burn, according
to a few empirically-based criteria.
The physical mechanisms underlying these phenomena are complex, and are tied
closely to the flame temperature and local strain rate, neither of which are readily-
available in a large scale fire simulation.
Subgrid-scale modeling of gas phase suppression and extinction is still an area of
active research in the combustion community.
Until reliable models can be developed for building-scale fire simulations, simple
empirical rules are used by FDS that prevent burning from taking place when the
atmosphere immediately surrounding the fire cannot sustain the combustion.
2.7.5 Radiation
Radiative heat transfer is included in the model via the solution of the radiation
transport equation (RTE) for a gray gas, and in some limited cases using a
wide band model. The RTE is solved using a technique similar to finite volume
methods for convective transport, thus the name given to it is the Finite Volume
Method (FVM).
There are several limitations of the model:
• First, the absorption coefficient for the smoke-laden gas is a complex func-
tion of its composition and temperature. Because of the simplified com-
bustion model, the chemical composition of the smokey gases, especially
the soot content, can effect both the absorption and emission of thermal
radiation.
• Second, the radiation transport is discretized via approximately 100 solid

angles, although the user may choose to use more angles. For targets far
away from a localized source of radiation, like a growing fire, the discretiza-
tion can lead to a non-uniform distribution of the radiant energy. This error
is called “ray effect” and can be seen in the visualization of surface tem-
peratures, where “hot spots” show the effect of the finite number of solid
angles. The problem can be lessened by the inclusion of more solid angles,
but at a price of longer computing times. In most cases, the radiative flux
to far-field targets is not as important as those in the near-field, where
coverage by the default number of angles is much better.
Chapter 3
Running FDS
This chapter explains how to obtain, install and run FDS and Smoke-
view. The explanation covers Ubuntu Linux and Windows XP.
3.1 Online resources and user support

The primary resource for detailed instructions on how to download executables,
manuals, source code and related utilities, is the FDS-SMV website:
• http://fire.nist.gov/fds
FDS has two separate manuals:
• [FDS5 technical reference];
• [FDS5 user’s guide].
The [FDS5 technical reference] guide is broken into three volumes:
• Mathematical model;
• Verification;
• Experimental validation.
Smokeview has its own manual:
• [Smokeview user’s guide].
15
16 CHAPTER 3. RUNNING FDS
The FDS and Smokeview user’s guides only describe the mechanics of using
the computer programs. The technical reference guides provides the theory,
algorithm details, and verification and validation work.
Along with the FDS manuals, there are resources available on the Internet. These
include an issue tracker, that allows you to report bugs, feature requests and ask
specific clarifying questions, and group discussions, which support more general
topics than just specific problems.
Before using these on-line resources, it is important to first try to solve your own
problems by performing simple test calculations, or debugging your input file.
3.2 Graphical user interface

FDS has an indepedently developed graphical user interface named BlenderFDS:
• http://www.blenderfds.org/
See specific chapter 15 on page 129 for more information.
3.3 Version numbers

Each release of FDS and Smokeview is identified by a version number such
as FDS_5.0.1 or SMV_5.0.1, where the first number is the major release (5),
the second number (0) is the minor release, and the third (1) indicates the
maintenance release number.
As a general pattern, major releases will occur every year or so. As the name
implies, they dramatically change the functionality or capabilities of the model.
Minor releases occur every few months, and may cause minor changes in func-
tionality. Maintenance releases are more frequent and are just bug fixes or small
refinements, and should not affect code functionality. The release notes can help
you decide whether the changes should effect the type of applications that you
typically do.
3.4 Hardware requirements

FDS requires one or more fast CPUs and a substantial amount of random-access
memory (RAM) to run efficiently. For minimum specifications, the system should
3.5. SERIAL AND PARALLEL CALCULATIONS 17
have at least a 1 GHz CPU, and 1 GB RAM. The CPU speed will determine how
long the computation will take to finish, while the amount of RAM will determine
how many mesh cells can be held in memory.
1 GB RAM can hold around 106 cells. To understand the physical meaning, a
20 m x 10 m x 5 m computational domain contains 106 cells, when discretized
with cubic cells of 10 cm side.
A large hard drive is required to store the output of the calculations. It is not
unusual for the output of a single calculation to consume many gigabytes of
storage space.
Smokeview needs an OpenGL graphic card. Look for graphics cards that specif-
ically list OpenGL support for the operating system you intend to use.
3.5 Serial and parallel calculations

FDS can perform serial and parallel calculations:
Serial calculations are performed in a single process that uses one only core of
current multi-core CPUs.
Parallel calculation splits the computational burden on many processes that

can be assigned to many different cores or CPUs. These CPUs can reside
on a single workstation or in a cluster of networked computers.
Setting up a cluster of computers is a complex task and it is out of the scope of

this manual.
3.6 Installing on Windows XP

To install or reinstall FDS and Smokeview on a Windows XP system, download
Windows installation package from official website.
The Windows file is a self-extracting compressed archive that will install FDS,
Smokeview and all associated files in the Program Files/FDS folder.
Launch the installation by double-clicking on the downloaded file.
At the end of the install process, your Windows XP system is ready to perform
serial calculations.
Figure 3.1: A cluster of Linux computers
3.7 Installing on Ubuntu Linux

These instructions require a basic knowledge of an Ubuntu Linux computer.
Ubuntu Linux operating system comes in two basic flavors:
Ubuntu Linux 32 bit, that can be installed on any type of computer.
Ubuntu Linux 64 bit, that can be installed on all AMD 64 bit CPUs with
AMD64 extension and all Intel CPUs with EM64T extension.
The 64 bit version has the ability to address more RAM memory than 32 bit
version (over 4 GB). The 32 bit version is limited to 4 GB of RAM memory.
Be aware that Smokeview works much better on a good dedicated graphic card.
Some cheap graphic cards can prevent you from using it on Linux.
3.7.1 First install
To install FDS and Smokeview on an Ubuntu Linux system, first, download the
latest version of the precompiled FDS and Smokeview for Linux from download
3.7. INSTALLING ON UBUNTU LINUX 19
page on the official web site. Depending on your Ubuntu flavor, download the
32 bit or the 64 bit compressed archive of the FDS distribution.
After downloading to your computer, extract the archive by right clicking on its
icon and selecting Extract here in the context menu.
Then, move the extracted FDS folder to your preferred location, for example
your home directory. In my case the resulting path to FDS folder would be
/home/egissi/FDS, as /home/egissi is my home folder.
After that, look at hidden files of your home folder by selecting View . Show
hidden files menu in the Nautilus file browser. Locate the .bashrc file in
your home directory, and open it for editing by double-clicking its icon.
Append the following text to the .bashrc file in the editor window:
### FDS and Smokeview environment

# Actual path to FDS folder
FDS=/home/egissi ← set your actual path here
echo "FDS setup ($FDS)"
# Setting limits
ulimit -s unlimited
ulimit -v unlimited
# Setting executable and library paths
export PATH=$PATH:$FDS/FDS5/FDS/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$FDS/FDS/FDS5/bin/lib32
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$FDS/FDS/FDS5/bin/lib64
Edit the emphasized line and set your actual path to the FDS folder. After that,
save the .bashrc file and close the text editor.
Open Synaptic package manager by selecting System . Administration . Synaptic
package manager menu and install:
On Ubuntu Linux 32 bit: lam-runtime software package;
On Ubuntu Linux 64 bit: lam-runtime and ia32-libs software packages.
Ubuntu Linux takes care for you of all the needed software dependencies.
Close your session and log-in again to put into effect the environment modifi-
cations. Your Ubuntu Linux system is now ready to perform serial and parallel
simulations on a multi-core or multi-CPU workstation.
3.7.2 Installing a new version
When installing a new version of FDS and Smokeview, just delete the old FDS
folder. After downloading the new version, extract the new FDS folder and drag
it to the same position as before.
Your Ubuntu Linux system is now ready to perform serial and parallel simulations
with the new version.
3.8 Compiling an optimized binary

As FDS is open source software, users can always download the latest version of
FDS source code and compile it by themselves using a Fortran 90 and C compiler.
Direct compilation is often applied to obtain an FDS binary that is optimized for
the specific hardware and platform and to fully take advantage of its speed.
Compilation is a complex task and is out of the scope of the present manual.
3.9 Performing a calculation

The typical procedure for using FDS and Smokeview is to:
1. Set up an FDS input file, as mycase.fds, and put it in a folder, as mycase

folder. See following chapters to learn how to do it.
2. Run FDS on the input files. FDS starts and creates many output files in
the mycase folder.
3. While FDS is running, monitor the development of the calculation.
4. Analyze the generated output files with Smokeview.
3.9.1 Running serial FDS on Windows XP
After having set up an input file, open up a command prompt window: select
Start . Run menu, then type cmd. Move into the mycase folder, where the input
file for the case is located, with the cd command.
Then run the code by typing the following command:
3.9. PERFORMING A CALCULATION 21
Figure 3.2: Starting a serial calculation on Windows XP and on Linux Ubuntu
fds5 mycase.fds
where fds5 is the name of FDS binary and mycase.fds is the input file name.
A serial calculation starts and its progress is indicated by diagnostic output that
is written out onto the screen.
3.9.2 Running serial FDS on Ubuntu Linux

On an Ubuntu Linux computer select Applications . Accessories . Terminal
menu to open the command prompt. Move into the mycase folder, where the
input file for the case is located, with the cd command.
Then execute one of the following commands:
On Ubuntu Linux 32 bit: fds5_intel_linux_32 mycase.fds
On Ubuntu Linux 64 bit: fds5_intel_linux_64 mycase.fds
If unsure, just look inside FDS/FDS5/bin folder to discover the right name for
FDS binaries.
Then the simulation starts and its progress is indicated by diagnostic output that
is written out onto the screen.
3.9.3 Running parallel FDS on Ubuntu Linux

FDS uses the Message Passing Library (MPI) for parallel computing.
Figure 3.3: Running a parallel calculation and monitoring the system on Ubuntu
Linux
MPI is a language-independent communications protocol used to program paral-

lel computers. Both point-to-point and collective communication are supported.
MPI’s goals are high performance, scalability, and portability. MPI is the domi-
nant model used in high-performance computing today.
The input file for both single and parallel versions of FDS are the same. In fact,
it is recommended that before embarking on parallel processing, you should run
your input file in serial mode to ensure that it is properly set up.
To run FDS in parallel, you must break up the computational domain into multiple
meshes so that the workload can be divided among the available processors.
For the parallel version to work well, there has to be a comparable number of
cells in each mesh, or otherwise most of the computers will sit idle waiting for
the one with the largest mesh to finish processing each time step.
On an Ubuntu Linux computer as configured before, type the following commands
to perform a parallel calculation:
On Ubuntu Linux 32 bit:
lamboot -v
mpirun -np 4 fds5_mpi_intel_linux_32 mycase.fds
lamhalt -v
On Ubuntu Linux 64 bit:
lamboot -v
mpirun -np 4 fds5_mpi_intel_linux_64 mycase.fds
lamhalt -v
3.10. MONITORING PROGRESS 23
The lamboot command starts the MPI environment.

The mpirun command starts an MPI application, in our case fds5_mpi_intel_linux_32
or fds5_mpi_intel_linux_64, where -np 4 is the number of started processes.
The number of processes must match the number of meshes that span the com-
putational domain of the input case.
At the end of the calculation, the MPI server is safely stopped with lamhalt
command.
3.10 Monitoring progress

Diagnostics for a given calculation are written into a text file called mycase.out,
contained in the case folder mycase. The CPU usage and simulation time are
written here, so you can monitor it to see how far along the program has pro-
gressed.
The application System . Administration . Gnome System Monitor is a pro-
cess viewer that provides a dynamic real-time view of a running system.
3.11 Stop a calculation

To stop a calculation before its scheduled time, create an empty file in the
mycase folder called mycase.stop. The mere existence of this file stops the
program gracefully, causing it to dump out the latest flow variables for viewing
in Smokeview.
Since calculations can be hours or days long, FDS has a restart feature. See
[FDS5 user’s guide] for broader details.
3.12 Visualizing results

Smokeview is used before, during and after model runs:
• before, to check the input data;
• during a calculation, to monitor a simulation’s progress;
• in a post-processing step, to visualize FDS data after a calculation has

been completed.
Figure 3.4: Running Smokeview on Windows XP and on Ubuntu Linux
On Windows XP, Smokeview may be started by double-clicking on the file named

mycase.smv, contained in the case folder.
On Ubuntu Linux, Smokeview is run from the command prompt by typing:
On Ubuntu Linux 32 bit: smv5_linux_32 mycase.smv

On Ubuntu Linux 64 bit: smv5_linux_64 mycase.smv
If unsure, just look inside FDS/FDS5/bin folder to discover the right name for
Smokeview binary.
Inside Smokeview, menus are accessed by clicking on the graphical window with
the right mouse button. The Load/Unload menu may be used to read in the
data files to be visualized. The Show/Hide menu may be used to change how
the visualizations are presented.
For the most part, the menu choices are self explanatory. In case of need, help
on using Smokeview can be found on [Smokeview user’s guide].
3.13 Output files

FDS writes out many output files in the mycase folder:
Diagnostic output: the file mycase.out consists of a list of input parameters,

and an accounting of various important quantities, including CPU usage.
Heat release rate and related quantities: the HRR of the fire, plus other global
energy-related quantities, are automatically written into a text file called
mycase_hrr.csv
3.13. OUTPUT FILES 25
Device output data: data associated with particular devices (link tempera-
tures, smoke obscuration, thermocouples, etc.) is output in comma de-
limited format in a file called mycase_devc.csv
and many other types of files, used by Smokeview for visualisation.
The comma delimited format files can easily be imported into Openoffice.org
Calc or Microsoft Excel for further analysis.
Chapter 4
Input file basics
This chapter teaches the logic of FDS input file, its organization and
its grammar. Then the standard reference system is explained and
some tips and tricks are exposed.
4.1 Syntax of the input file

All the necessary information to perform an FDS simulation has to be contained
in a single text file. The input file is saved with a name such as mycase.fds.
There should be no blank spaces in the job name.
Data is specified within the input file by using namelist groups. Each namelist Namelist groups
group record occupies a line of text and begins with the & character. The & must
be the first character of the line of text and should be followed by the name
of the namelist group. Then a comma-delimited list of the input parameters is
inserted. Finally a forward slash / character closes the namelist group, as shown
in Figure 4.1.
Figure 4.1: The structure of an FDS namelist group
Spaces and new lines can be freely inserted to visually format the namelist group.
FDS uses the information contained between the & / delimiters, the rest is
27
28 CHAPTER 4. INPUT FILE BASICS
ignored. Thus, comments and notes can be written outside the & / delimiters. Comments
For example:
&OBST XB=0.5,1.1,0.5,1.1,0.0,0.1 / A comment

Another comment
It is recommended that each namelist group be clearly commented to justify the

choice of its parameters and to link it to literature references or direct experi-
mentation. For example, comments like these:
&REAC ID=’polyurethane’, SOOT_YIELD=0.1875, CO_YIELD=0.02775,

C=1.0, H=1.75, O=0.25, N=0.065,
HEAT_OF_COMBUSTION=25300., IDEAL=.TRUE. /
Gas phase reaction: polyurethane flexible foam (means)
from Tewarson SFPE Handbook 3rd ed,
SFPE handbook table 3-4.14, p. 3-112.
help the reviewer keeping track of the sources of information employed by the
user.
By deeply commenting the code, the input file becomes the complete and only
source of information about the simulated case.
Parameter values The parameter values can be of the following types:
Integers, as in T_END=5400
Real numbers, as in CO_YIELD=0.008
Groups of real numbers, as in XYZ=6.04,0.28,3.65
Groups of integers, as in IJK=90,36,38
Character strings, as in CHID=’this_is_a_string’
Groups of character strings, as in SURF_IDS=’burner’,’steel’
Logical parameters, as in POROUS_FLOOR=.FALSE. or POROUS_FLOOR=.TRUE.

The periods must be included.
Parameter arrays Sometimes the parameters are multidimensional arrays. For example:
4.2. WRITING AN INPUT FILE 29
MATL_ID(2,3)=’brick’
indicates that the third material component of the second layer is brick.
To speed up data input, you can use this notation:
MATL_ID(1:3,1)=’plastic’,’insulation’,’steel’
which means that the surface is composed by three different layers made re-
spectively of plastic, insulation and steel. The notation 1:3 means array
element 1 through 3, inclusive.
A simplified notation is accepted, too:
MATL_ID=’plastic’,’steel’
is equivalent to:
MATL_ID(1:2,1)=’plastic’,’steel’
These last surfaces are composed by two different layers made respectively of
plastic and steel.
The code is case sensitive: my_burner is not the same as MY_BURNER. Case sensitivity
To ensure that FDS reads the entire input file, add &TAIL / or a comment as TAIL
the last line at the end of the input file.
4.2 Writing an input file

When looking at a new scenario, first select a pre-written input file that resem-
bles the case, make the necessary changes, then run the case at fairly low grid
resolution to determine if the geometry is set up correctly.
The following file is a slightly modified and simplified version of pplume5.fds,
generally included in FDS software distribution:
!!! General configuration
&HEAD CHID=’pplume5’, TITLE=’Plume case’ /

name of the case and a brief explanation
&TIME T_END=10.0 /
the simulation will end at 10 seconds
&MISC SURF_DEFAULT=’wall’, TMPA=25. /
all bounding surfaces have
a ’wall’ boundary condition
unless otherwise specified,
the ambient temperature is set to 25°C.
&REAC ID=’polyurethane’, SOOT_YIELD=0.10,
N=1.0, C=6.3, H=7.1, O=2.1 /
predominant fuel gas for the mixture fraction model
of gas phase combustion
!!! Computational domain
&MESH IJK=32,32,16, XB=0.0,1.6,0.0,1.6,0.0,0.8 /

&MESH IJK=32,32,16, XB=0.0,1.6,0.0,1.6,0.8,1.6 /
&MESH IJK=32,32,16, XB=0.0,1.6,0.0,1.6,1.6,2.4 /
&MESH IJK=32,32,16, XB=0.0,1.6,0.0,1.6,2.4,3.2 /
four connected calculation meshes
and their cell numbers
!!! Properties
&MATL ID=’gypsum_plaster’, CONDUCTIVITY=0.48,

SPECIFIC_HEAT=0.84, DENSITY=1440. /
thermophysical properties of ’gypsum plaster’ material
&PART ID=’tracers’, MASSLESS=.TRUE., SAMPLING_FACTOR=1 /
a type of Lagrangian particles
&SURF ID=’burner’, HRRPUA=600.,
PART_ID=’tracers’, COLOR=’RASPBERRY’ /
a type of boundary conditions named ’burner’
&SURF ID=’wall’, RGB=200,200,200, MATL_ID=’gypsum_plaster’,
THICKNESS=0.012 /
a type of boundary conditions named ’wall’
!!! Solid geometry
&VENT XB=0.5,1.1,0.5,1.1,0.1,0.1, SURF_ID=’burner’ /

the ’burner’ boundary condition
is imposed to a plane face
&OBST XB=0.5,1.1,0.5,1.1,0.0,0.1, SURF_ID=’wall’ /
4.3. THE LOGIC BEHIND MOST FDS INPUT FILES 31
a solid is created, ’wall’ boundary condition

is imposed to all its faces
&VENT XB=0.0,0.0,0.0,1.6,0.0,3.2, SURF_ID=’OPEN’/
the ’OPEN’ boundary condition is imposed to
the exterior boundaries of the computational domain
!!! Output
&DEVC XYZ=1.2,1.2,2.9, QUANTITY=’THERMOCOUPLE’, ID=’tc1’ /

send to output: the data collected by a thermocouple
&ISOF QUANTITY=’TEMPERATURE’, VALUE(1)=100.0 /
3D contours of temperature at 100°C
&SLCF PBX=0.8, QUANTITY=’TEMPERATURE’, VECTOR=.TRUE. /
vector slices colored by temperature
&BNDF QUANTITY=’WALL TEMPERATURE’ /
surface ’WALL_TEMPERATURE’ at all solid obstructions
&TAIL / end of file
Not all kinds of FDS namelist groups are listed in this input files. In fact,
another general rule of thumb when writing input files is to only add to the file
parameters that are to change from their default value. That way, you can more
easily distinguish between what you impose and FDS defaults.
In general, the namelist records can be entered in any order in the input file, but
it is a good idea to organize them in some systematic way.
Be aware that the order of identical namelist groups can be significant. When Order convention
properties overlap the general rule is first-come, first-served.
For the sake of clarity, users often group similar namelists in homogeneous sec-
tions identified by heading comments, as shown in the former example input
file.
4.3 The logic behind most FDS input files

This section presents the logic behind most FDS input files; this same logic is
used for the organization of this manual:
• First, general configuration is performed.
– The case receives a name via the HEAD namelist group, the simula-
tion time is set via the TIME namelist group. Other miscellaneous
parameters are prescribed via the MISC namelist group.
– Then gas phase combustion reaction is set up via the REAC namelist
group, the radiation model is configured with RADI.
• Second, the computational domain is defined via the MESH namelist group.
All FDS calculations must be performed within a domain that is made up
of rectilinear volumes called meshes. Each mesh is divided into rectangular
cells, the number of which depends on the desired resolution of the flow
dynamics.
Some initial conditions are prescribed for the flow domain via the INIT
namelist group.
• Third, some properties are set up:
– the properties of each material (MATL),

– the properties of extra gas species (SPEC),
– the properties of Lagrangian particles (PART),
– and the types of boundary conditions (SURF).
This is the most challenging part of setting up the simulation: first, for both
real and simulated fires, the growth of the fire is very sensitive to the thermal
properties of the surrounding materials. Second, even if all the material proper-
ties are known to some degree, the physical phenomena of interest may not be
simulated properly due to limitations in the model algorithms or resolution of the
numerical mesh.
It is your responsibility to supply the thermal properties of the materials, and then
assess the performance of the model to ensure that the phenomena of interest
are being captured.
• Fourth, the solid geometry is entered via OBST, VENT, HOLE namelist
groups.
– A considerable amount of work in setting up a calculation lies in

specifying the geometry of the space to be modeled and applying
boundary conditions to these objects. The geometry is described in
terms of obstructions to the gas phase flow.
4.3. THE LOGIC BEHIND MOST FDS INPUT FILES 33
– A boundary condition needs to be assigned to each bounding surface

of the gas phase domain describing its thermal properties. Both solid
obstruction faces and the exterior boundaries of the computational
domain need a boundary condition assigned. A fire is just one type
of boundary condition.
• Fifth, some control logic and automation is introduced via PROP, DEVC,
CTRL namelist groups: devices can be used to control various actions, like
creating and removing obstructions, or activating and deactivating fans
and vents.
• Finally, the user prescribes the output quantities (DEVC, SLCF, BNDF, ISOF).
All output quantities must be specified at the start of the calculation. In
most cases, there is no way to retrieve information after the calculation
ends if it was not specified from the start. Much like in an actual experi-
ment, the user must decide before the calculation begins what information
to save.
The table summarizes this logic and shows a proposed systematic organization
of an input file in sections:
Table 4.1: Systematic organisation of the input file
Section Content Namelist groups
General configuration General information required to HEAD, TIME, MISC

perform a simulation, as its name,
duration and other miscellaneous
parameters.
Main gas phase combustion reaction REAC, RADI

and radiation model.
Computational domain Computational domain: MESH

dimensions and grid.
Initial conditions of the INIT

computational domain.
Properties Materials, temperature dependent MATL, RAMP

thermophysical properties. (temperature)
Extra gas species properties. SPEC

continued on next page
from previous page

Lagrangian particles properties. PART
Boundary conditions, time dependent SURF, RAMP (time)

boundary conditions.
Solid geometry Description of solid geometry, OBST, HOLE, VENT

assignment of boundary conditions
to bounding surfaces.
Control logic General properties of devices, devices PROP, DEVC, CTRL

and control functions used to control
various actions, like creating and
removing solid obstructions or
activating and deactivating boundary
conditions.
Output List of calculated quantities to DUMP, DEVC, SLCF,

output. BNDF, ISOF
4.4 Keep it simple

Novice users tend to forget that FDS is not a Computer Aided Design (CAD)
tool, but a CFD code.
First, not all geometrical details, all physical and chemical properties of all in-
volved objects need to be entered in the input file.
Looking at the example proposed in Figure 4.2 on the facing page, chair and table
frame effect on the fluid flow can be considered negligible. On the contrary, the
influences to fluid flow of the separating wall, the table top and seats can become
important, depending on the objective of the analysis.
So, the first step of the analysis process is to formulate the problem by seeking
answers to the following questions:
• What is the objective of the analysis?

• What is the easiest way to obtain that objective?
• What input data needs to be included?
Approximations of the geometry and simplifications of the properties are always

required to allow an analysis with reasonable effort.
4.5. EACH MODEL, ITS INPUT DATA 35
Figure 4.2: Modeling reality in FDS
It is better to start off with a relatively simple file that captures the main features
of the problem without getting tied down with too much detail that might mask
a fundamental flaw in the calculation.
Initial calculations ought to be meshed coarsely so that the run times are less
than an hour and corrections can easily be made without wasting too much time.
As you learn how to write input files, you will continually run and re-run your
case as you add in complexity.
4.5 Each model, its input data

When entering data into the input file, it is suggested to always consider how
models inside FDS will use that data.
For example:
• The hydrodynamic model needs to know which cells of the computational

domain are open to fluid flow and which are instead occupied by solid
obstructions. The geometry is discretized and the maximum resolution is
the grid cell size.
• The heat transfer model needs the characteristics and the thicknesses of the
bounding surfaces of the flow domain to perform heat transfer calculation.
Imagine that the wall separating room 1 and room 2 of Figure 4.2 on the previous
page is 0.19 m thick. Thus, during the calculation:
• Taken the cell size equal to 0.30 m, the hydrodynamic model considers that
wall as if it was 0.30 m thick, because the geometry must conform to the
underlying grid. That information is used to obstacle the fluid flow.
• The heat transfer model performs a one-dimensional heat transfer calcula-

tion of the wall using the real 0.19 m thickness and the material properties.
It may sound strange to novice users, but that wall is. . . both 0.30 m and 0.19 m
thick for FDS.
4.6 Units of measurement
FDS employs the units of measurement from the International System (SI).
Lengths are expressed in m, time in s, mass in kg, temperature in °C, pressure
in Pa, heat in kJ, power in kW, conductivity in W/m/K, heat flux in kW/m2 ,
molecular weight in g/mol. . .
This manual contains a comprehensive list of frequent namelist parameters and
their units. For a complete list consult the [FDS5 user’s guide].
4.7 Reference coordinate system
FDS coordinate system conforms to the right hand rule. By default, the z axis
is considered the vertical.
For computational reasons, it is always preferable for the longest horizontal di-
mension of the model be aligned with the x axis. This often shortens the calcu-
lation time.
4.8. PRESCRIBING GEOMETRIC ENTITIES 37
Figure 4.3: The reference system, a volume, a face, a segment, a point, and a
plane
4.8 Prescribing geometric entities

Many namelist groups extend their action to volumes, faces, segments, points or
planes. As shown in Figure 4.3, FDS geometrical entities are always described
using some conventional rules.
A volume is always represented by a single right parallelepiped with edges parallel Volumes
to the axis. Its position and dimensions are described by the coordinates of two
opposite vertices: if point A = (xA , yA , zA ) and point B = (xB , yB , zB ) are
the opposite vertices, its coordinates are entered as xA , xB , yA , yB , zA , zB . For
example,
&OBST XB=0.5,1.5,2.0,3.5,-2.0,0., SURF_ID=’wall’ /
uses the parameter XB to define a solid obstacle that spans the volume starting
at the origin (0.5, 2.0, −2.0) and extending 1 m in the positive x direction, 1.5 m
in the positive y direction, and 2 m in the positive z direction.
A face is represented by a right plane face with edges parallel to the axis. Its Faces
position and dimensions are described by the coordinates of two opposite vertices,
that must lie on the same plane. For example:
&VENT XB=0.5,1.1,2.0,3.1,-2.0,-2.0, SURF_ID=’fire’ /
uses the parameter XB to define a flat face perpendicular to the z axis imposing
a particular boundary condition over a solid. Two of the six coordinates are the
same, denoting a flat face as opposed to a solid.
A segment is bounded by two end points. If point A = (xA , yA , zA ) and point Segments
B = (xB , yB , zB ) are the end points, its coordinates are entered following the
same convection valid for volumes. For example,
&DEVC XB=0.5,1.5,2.0,3.5,-2.0,0., QUANTITY=’PATH OBSCURATION’,

ID=’beam1’, SETPOINT=0.33 /
is a beam smoke detector between (0.5, 2.0, −2.0) and (1.5, 3.5, 0.) end points.
Points A point is simply identified by its 3 coordinates. For example, the line:
&DEVC XYZ=2.,3.,4., QUANTITY=’THERMOCOUPLE’, ID=’termo1’ /
uses the parameter XYZ to insert a thermocouple at the point of coordinates

(2., 3., 4.).
Planes A plane is represented by a right plane perpendicular to one of the reference axis.
For example, these lines:
&SLCF PBX=0.5, QUANTITY=’TEMPERATURE’ /
is a plane perpendicular to the x axis and intersecting its point (.5, 0., 0.).
&SLCF PBY=1.5, QUANTITY=’TEMPERATURE’ /
is a plane perpendicular to the y axis and intersecting its point (0., 1.5, 0.).
&SLCF PBZ=-.5, QUANTITY=’TEMPERATURE’ /
is a plane perpendicular to the z axis and intersecting its point (0., 0., −.5).
All use the parameters PBX, PBY, PBZ to specify the coordinate in the direction
of the perpendicular axis.
4.9 Prescribing orientations

Some FDS entities need the prescription of a particular orientation. This is done
with one of the following parameters: IOR or ORIENTATION.
IOR The parameter IOR, index of orientation, is used to prescribe one of the six
possible orientations parallel to axis: if the orientation is in the positive x direction
set IOR=1, negative x direction IOR=-1, positive y IOR=2, negative y IOR=-2,
positive z IOR=3, negative z IOR=-3.
For example, the line:
4.10. PRESCRIBING COLORS AND ASPECT 39
&DEVC XYZ=0.7,0.9,2.1, QUANTITY=’WALL TEMPERATURE’,

IOR=-2, ID=’ST-1’ /
designates the surface temperature of a wall facing the negative y direction.

The parameter ORIENTATION is used for entities that require a free directional ORIENTATION
specification, like a sprinkler. ORIENTATION is specified with a triplet of real
number values that indicate the components of the direction vector. The default
value of ORIENTATION is (0, 0, −1).
&DEVC XYZ=23.91,21.28,0.50, PROP_ID=’nozzle’,

ORIENTATION=1.,1.,0., ID=’noz_1’ /
designates a nozzle oriented towards the (1, 1, 0) vector.
4.10 Prescribing colors and aspect

Colors of objects can be prescribed with two parameters: RGB and COLOR.
The RGB parameter is followed by a triplet of integer numbers in the range from RGB
0 to 255, indicating the amount of red, green and blue that make up the color.
The COLOR parameter calls the name of a predefined color that must be entered COLOR
exactly as it is listed in the color table:
Table 4.2: COLOR values
ACQUAMARINE, BANANA, BEIGE, BLACK, BLUE, BRICK, BROWN, CADMIUM

ORANGE, CARROT, COBALT, CORAL, CRIMSON, CYAN, FIREBRICK, FLESH,
GOLD, GRAY, GREEN, INDIGO, MAGENTA, MAROON, MELON, MINT, NAVY,
OLIVE, ORANGE, ORCHID, PINK, PURPLE, RASPBERRY, RED, SALMON,
SEPIA, SIENNA, SILVER, TAN, TEAL, TOMATO, TURQUOISE, VIOLET,
WHITE, YELLOW, ...
You can rapidly find the whole color table of more than 500 colors by googling
for FDS COLOR TABLE on the Internet.
For example, both the parameter RGB=0,0,255 and the parameter COLOR=’BLUE’
can be used to obtain a blue object.
TRANSPARENCY Objects can be made semi-transparent by assigning a TRANSPARENCY parameter.

The parameter value is a real ranging from 0 to 1, with 0 being fully transparent.
The parameter should always be set along with RGB or COLOR.
Using COLOR=’INVISIBLE’ causes the object not to be drawn in Smokeview.
The parameter OUTLINE=.TRUE. causes the object to be drawn as an outline.
Chapter 5
General configuration
First, general configuration is performed.

The case receives a name via the HEAD namelist group, the simula-
tion time is set via the TIME namelist group. Other miscellaneous
parameters are prescribed via the MISC namelist group.
5.1 Naming the job, HEAD

The first thing to do when setting up an input file is to give the job a name. The
name of the job is important because often a project involves numerous simula-
tions in which case the names of the individual simulations can help organize the
effort. The namelist group HEAD contains two parameters, as in this example:
&HEAD CHID=’mycase’, TITLE=’This is a short description’ /
CHID is a string of 30 characters or less used to name the output files created
by FDS. No periods or spaces are allowed. TITLE is a string of 60 characters or
less that describes the simulation. It is simply a descriptive text that is passed
to various output files.
It is always convenient to exactly use the same string for the name of the input
file and the CHID. For example, if you name mycase.fds the input file, then set
CHID=’mycase’ in the HEAD namelist group.
Only one HEAD line can be entered in the input file. The following table summa-
rizes some HEAD parameters:
41
42 CHAPTER 5. GENERAL CONFIGURATION
Table 5.1: HEAD parameters
Parameter Type Description Unit Default
CHID String Job identifier ’output’
TITLE String Short description of the job
5.2 Simulation time, TIME

TIME is the namelist group that define the time duration of the simulation.
Usually, only the duration of the simulation is required on this line, via the
parameter T_END. The default is 1 s.
For example, the following line will instruct FDS to run the simulation for 5400 s:
&TIME T_END=5400. /
If T_END is set to zero, only the set-up work is performed, allowing you to quickly
check the geometry in Smokeview.
Only one TIME line can be entered in the input file. The following table summa-
rizes some TIME parameters:
Table 5.2: TIME parameters
T_BEGIN Real Starting time for calculation s 0.
T_END Real Ending time for calculation s 1.
5.3 Miscellaneous, MISC

MISC is the namelist group of global miscellaneous input parameters. Many
parameters for MISC exist, some of them are explained later in this manual.
For example:
&MISC SURF_DEFAULT=’steel’ /
5.3. MISCELLANEOUS, MISC 43
establishes that all bounding surfaces are to be made of steel unless otherwise
specified.
Only one MISC line can be entered in the input file. The following table summa-
rizes some MISC parameters:
Table 5.3: MISC parameters
SURF_DEFAULT String Default boundary condition SURF for ’INERT’

surfaces
TMPA Real Ambient temperature °C 20.
U0,V0,W0 Real Initial prevailing velocity field m/s 0.
GVEC(3) Real Gravity vector m/s2 0,0,-9.81
HUMIDITY Real Relative Humidity % 40.
CO_PRODUCTION Logical Start three-parameters mixture .FALSE.

fraction model
RESTART Logical Restart previous calculation .FALSE.

44 CHAPTER 5. GENERAL CONFIGURATION
Chapter 6
Combustion and radiation
. . . then gas phase combustion reaction is set up via the REAC namelist
group, the radiation model is configured with RADI.
6.1 Combustion is not pyrolysis

A common source of confusion in FDS is the distinction between gas phase
combustion and solid phase pyrolysis.
Pyrolysis is the decomposition or transformation of a compound caused by heat

that produce the gaseous fuel. It is the first chemical reaction that occurs
in the burning of many solid fuels, like wood, cloth, paper, and plastic.
Gas phase combustion refers to the exothermic chemical reactions between

the gaseous fuel and oxygen accompanied by the production of heat and
light in the form of flames.
So solid phase pyrolysis refers to the generation of fuel vapor at a solid or liquid
surface, while the visible flames are not due to combustion of the solid fuel itself,
but rather of the gases released by its pyrolysis.
6.2 Prescribing a fire

In FDS, a fire is a particular boundary condition applied to a surface bounding
the flow field. There are two ways of designating a fire:
45
46 CHAPTER 6. COMBUSTION AND RADIATION
Figure 6.1: Combustion is not pyrolysis
• The first is to specify an heat release rate on a surface; this is the same as
prescribing a well defined burner. How to do this is described in detail in
Section 11.4.6 on page 84.
• The other is to specify thermophysical properties of fuel materials and

to let them pyrolyze. In this case the burning rate of the fuel depends
on the net heat feedback to the surface. This approach is explained in
Section 8.3.1 on page 65 for solid fuels and in Section 8.3.2 on page 66
for liquids.
Both burners and pyrolyzing materials inject the calculated quantities of gaseous
fuels in the flow field. In a realistic fire scenario, there may be various types of
gaseous fuels originating from the various burning objects in the building and
injected into the flow field.
6.3 Modeling gas phase combustion, REAC
6.3.1 Ignition
Once injected into the flow field, the gaseous fuels mix with air and burn. There
is no need to prescribe an ignition source: the combustion model assumes that
6.3. MODELING GAS PHASE COMBUSTION, REAC 47
Figure 6.2: Combustion and pyrolysis in a flaming match
fuel gas and oxygen burn on contact. We can imagine that every grid cell hosts
a virtual spark plug, that initiates combustion when temperature and local ratio
of fuel gas and oxygen are appropriate (See Figure 6.3 on page 52).
6.3.2 Burning
The burning process releases heat and smoke.

Whereas there can be many types of combustibles in an FDS fire simulation, one
only gaseous fuel can be simulated by FDS. In general, you should set the chem-
istry of the modeled burning gaseous fuel to coincide with the actual predominant
burning gaseous fuel.
This model simplification is due to computational cost: it is expensive to solve
transport equations for multiple gaseous fuels.
FDS adjusts automatically the burning rates of solids and liquids to account for
the difference in the heats of combustion of the various combustibles. If the
stoichiometry of the burning material differs from the global reaction, the heat
of combustion of each burning material is used to ensure that an equivalent
amount of fuel is injected into the flow domain from the burning object.
FDS can describe the gas phase reaction in two ways.
By default, a so-called mixture fraction model is used to account for the evolution Mixture fraction
of the fuel gas from its surface of origin through the combustion process. model
The alternative is what is referred to as the finite-rate approach, where all of the Finite-rate approac
individual gas species involved in the combustion process are defined and tracked
individually. This is a costlier and more complicated approach than the mixture
fraction model.
This manual covers the mixture fraction model only, as it is simpler and commonly
employed for engineering level problems.
When the mixture fraction model is applied, a set of scalar variables, Zi , represent
the state of the combustion process from pure fuel ( Zi = 1) to pure air
P
( Zi = 0).
P
FDS provides two types of mixture fraction model:
Two-parameter mixture fraction model: the first parameter (Z1 ) is the mass
fraction of unburned fuel and the second (Z2 ) is the mass fraction of burned
fuel, as for example the mass of the combustion products that originated
as fuel. FDS uses the two-parameter model by default.
Three-parameter mixture fraction model: this combustion model simulates

a two-step chemical reaction with three parameters. The first step of the
reaction is the oxidation of fuel to carbon monoxide and the second step
the oxidation of carbon monoxide to carbon dioxide. The three mixture
fraction components for the two step reaction are unburned fuel (Z1 ), mass
of fuel that has completed the first reaction step (Z2 ), and the mass of
fuel that has completed the second reaction step (Z3 ). See Section 6.4 on
page 51 to understand why and how to use the three-parameter model.
The mass fractions of all of the major reactants and products of combustion – as
fuel, O2 , CO2 , H2 O, N2 , CO and soot – can be derived from the mixture fraction
parameters by means of state relations: a set of pre-tabulated functions of the
mixture fraction parameters, Zi . In other words, the values of Zi in any given
mesh cell determines the mass fraction of all the gases listed.
The stoichiometry of the predominant gas phase combustion reaction is pre-
scribed in the input file by one only REAC namelist group: the specified parame-
ters are used to generate the table associating the mass fractions with Zi . FDS
defaults to propane combustion if no REAC line is entered.
In the mixture fraction model, each reaction is assumed to be of the form:
Cx Hy Oz Nv Otherw + νO2 O2 →
→ νCO2 CO2 + νH2 O H2 O + νCO CO + νsoot Soot + νN2 N2 + νH2 H2 + νother Other
6.3. MODELING GAS PHASE COMBUSTION, REAC 49
You need only specify the chemical formula of the fuel along with the yields of CO,
soot, and H2 , and the amount of hydrogen in the soot, Hf rac . For completeness
you can specify the N2 content of the fuel and the presence of other species.
FDS will use that information internally to determine the amount of combustion
products that are formed.
The species implicitly defined by FDS when doing a mixture fraction calculation
for gas phase combustion are as follows:
Table 6.1: Mixture fraction species
fuel, oxygen, nitrogen, water vapor, carbon dioxide, carbon

monoxide, hydrogen, soot, other
Note that these species are identified by a lowercase name, and are not to be
confused with the species identified by uppercase names defined by the SPEC
namelist groups. See Section 9.2 on page 70 for further discussion.
The Table 6.2 lists some of the parameters that may be prescribed on the REAC
line. Note that the various *YIELD are for well-ventilated, post-flame conditions.
There are options to predict various species yields in under-ventilated fire scenar-
ios, but these special models still require the post-flame yields for CO, soot and
any other species listed in the table.
Table 6.2: REAC parameters
ID String Identifier
C Real Number of carbon atoms in the fuel 3
H Real Number of hydrogen atoms in the 8

fuel
O Real Number of oxygen atoms in the fuel 0
N Real Number of nitrogen atoms in the fuel 0
OTHER Real Number of other atoms in the fuel 0
MW_OTHER Real Average molecular weight of OTHER, g/mol 28

defaults to N2
CO_YIELD Real The fraction of fuel mass converted kg/kg 0

into carbon monoxide.
from previous page
H2_YIELD Real The fraction of fuel mass converted kg/kg 0

into hydrogen.
SOOT_YIELD Real Fraction of soot from the fuel. The kg/kg 0.01
fraction of fuel mass converted into
smoke particulate.
SOOT_H_FRACTION Real Atom fraction of hydrogen in soot 0.1
HEAT_OF_COMBUSTION Real The amount of energy released per kJ/kg

unit mass of fuel consumed
EPUMO2 Real Energy per unit mass oxygen. If the kJ/kg 13100
heat of combustion is not explicitly
specified, it is calculated as:
consumed O2 ×EPUMO2
IDEAL Logical Adjust for minor product yields .FALSE.
VISIBILITY_FACTOR Real Visibility parameter (see Section 14.9 3

on page 122)
MASS_EXTINCTION_COEFFICIENT Real Visibility parameter (see Section 14.9 m2 /kg 8700

on page 122)
IDEAL is a logical value indicating whether or not the EPUMO2 or HEAT_OF_COMBUSTION

values represent values for complete combustion (.TRUE.) or for incomplete com-
bustion (.FALSE.). If IDEAL=.TRUE., then FDS internally adjusts the resulting
heat of combustion to account for products of incomplete combustion specified
in CO_YIELD, H2_YIELD, and SOOT_YIELD.
A few sample REAC lines are given here, the values are for demonstration only:
&REAC ID=’methane’, C=1., H=4. /

&REAC ID=’ethylene’, C=2., H=4., SOOT_YIELD=0.05 /
&REAC ID=’propane’, SOOT_YIELD=0.01, C=3., H=8.,
&REAC ID=’propane’, SOOT_YIELD=0.01, C=3., H=8.,
HEAT_OF_COMBUSTION=46124., IDEAL=.FALSE. /
&REAC ID=’wood’, SOOT_YIELD=0.02, O=2.5, C=3.4, H=6.2,
HEAT_OF_COMBUSTION=17700 /
Ritchie, et al., 5th IAFSS
6.4. CO PRODUCTION IN UNDER-VENTILATED FIRES 51
C=1.0, H=1.75, O=0.25, N=0.065, OTHER=0.002427, MW=27.,

Polyurethane flexible foam (means) from
Tewarson SFPE Handbook 3rd ed,
6.4 CO production in under-ventilated fires

An algorithm has been implemented that computes the gas phase combustion as
a two step reaction and that predicts the formation and destruction of CO. This
algorithm is used when the parameter CO_PRODUCTION is set to .TRUE. on the
MISC line:
&MISC CO_PRODUCTION=.TRUE. /
Even though the algorithm predicts CO formation and its eventual oxidation at
elevated temperature, it cannot predict the post-flame yield of CO. For example,
within a flashed over compartment, the algorithm predicts the elevated CO levels,
but it cannot predict the CO concentration of the exhaust gases that exit the
flaming region. Thus, even if using this model, you must specify the CO_YIELD
that is expected of a well-ventilated fire.
Note that when active, this algorithm requires the use of three parameters for
the mixture fraction instead of the two parameters used when it is disabled and
will therefore increase run times and memory usage accordingly. If the simulation
you are performing will not result in an under-ventilated fire, then there will be
little if any benefit to enabling the CO production algorithm.
6.5 Flame extinction

Modeling suppression of a fire due to the introduction of a suppression agent like
CO2 or water mist, or due to the exhaustion of oxygen within a compartment
is challenging because the relevant physical mechanisms occur at length scales
smaller than a single mesh cell.
Flames are extinguished due to lowered temperatures and dilution of the oxy-
gen supply. A simple suppression algorithm has been implemented in FDS that
attempts to gauge whether or not a flame is viable at the fuel-oxygen interface.
Figure 6.3: Flame extinction criteria
The default values for the the limiting oxygen index and the critical flame temper-
ature are 15% (volume fraction) and 1427°C, respectively as shown in Figure 6.3
on the following page.
6.6 Radiation transport, RADI

For most FDS simulations, thermal radiation transport is computed by default
and you need not set any parameters to make this happen. However, there are
situations where it is important to be aware of issues related to the radiative
transport solver.
The most important issue involves the fraction of energy released from the fire
as thermal radiation, commonly referred to as the radiative fraction. It is a func-
tion of both the flame temperature (T4 dependence) and chemical composition,
neither of which are reliably calculated in a large scale fire calculation. In fact,
because of the size of the mesh cells, the flame sheet is not well-resolved.
To compensate the underestimation of the fire radiation, the RADIATIVE_FRACTION
is not calculated and is set to 35% by default: every mesh cell cut by the flame
radiates that fraction of the chemical energy being released into it. Some of
that energy may be reabsorbed elsewhere, yielding a net radiative loss that is less
than RADIATIVE_FRACTION, depending mainly on the size of the fire and the
soot loading.
For example:
&RADI RADIATIVE_FRACTION=0.45 /
sets the fraction of energy released from the fire as thermal radiation to 45%.
The following table summarizes some RADI parameters:
6.6. RADIATION TRANSPORT, RADI 53
Table 6.3: RADI parameters
NUMBER_RADIATION_ANGLES Integer Number of solid angles 104
RADIATIVE_FRACTION Real Radiative Loss Fraction 0.35

Chapter 7
Computational domain
Second, the computational domain is defined via the MESH namelist

group.
All FDS calculations must be performed within a domain that is made
up of rectilinear volumes called meshes. Each mesh is divided into
rectangular cells, the number of which depends on the desired res-
olution of the flow dynamics. Some initial conditions are prescribed
for the flow domain via the INIT namelist group.
7.1 Defining a mesh, MESH

MESH is the namelist group that defines the volume of the computational domain.
For example,
&MESH IJK=10,20,30, XB=0.0,1.0,0.0,2.0,0.0,3.0 /
defines a mesh that spans the volume starting at the origin (0., 0., 0.) and
extending 1 m in the positive x direction, 2 m in the positive y direction, and 3 m
in the positive z direction.
The mesh is subdivided into uniform cells via the parameter IJK. In this example,
the mesh is divided into 10 cm cubes: 10 cubes in x direction, 20 cubes in y
direction, and 30 cubes in z direction.
Any obstructions or vents that extend beyond the boundary of the mesh are cut
off at the boundary. There is no penalty for defining objects outside of the mesh,
and these objects will not appear in Smokeview either.
55
56 CHAPTER 7. COMPUTATIONAL DOMAIN
Note that it is best if the mesh cells resemble cubes, that is, the length, width
and height of the cells ought to be roughly the same.
Keep in mind that the Large Eddy Simulation technique (LES) is based on the
assumption that the numerical mesh should be fine enough to allow the formation
of eddies that are responsible for the mixing. In general, eddy formation is limited
by the largest dimension of a mesh cell, thus shrinking the mesh resolution in
one or two directions may not necessarily lead to a better simulation if the third
dimension is large.
Because an important part of the calculation uses a Poisson solver based on
Fast Fourier Transforms (FFTs) in the y and z directions, the second and third
dimensions of the mesh should each be of the form 2k × 3m × 5n , where k, m
and n are integers. For example, 64 = 26 , 72 = 23 · 32 and 108 = 22 · 33 are
good mesh cell divisions, but 37, 99 and 109 are not.
The first number of mesh cell divisions (the I in IJK) does not use FFTs and
need not be given as a product of small numbers.
Here is a list of numbers between 1 and 1024 that can be factored down to 2’s,
3’s and 5’s:
Table 7.1: IJK values
2, 3, 4, 5, 6, 8, 9, 10, 12, 15, 16, 18, 20, 24, 25, 27, 30, 32, 36, 40, 45,
48, 50, 54, 60, 64, 72, 75, 80, 81, 90, 96, 100, 108, 120, 125, 128, 135,
144, 150, 160, 162, 180, 192, 200, 216, 225, 240, 243, 250, 256, 270,
288, 300, 320, 324, 360, 375, 384, 400, 405, 432, 450, 480, 486, 500,
512, 540, 576, 600, 625, 640, 648, 675, 720, 729, 750, 768, 800, 810,
864, 900, 960, 972, 1000, 1024. . .
The following table summarizes some MESH parameters:
Table 7.2: MESH parameters
IJK(3) Integer Number of cells in x, y, and z 10

directions
XB(6) Real Volume m

7.2. MULTIPLE MESHES 57
Figure 7.1: The computational domain composed by four meshes
7.2 Multiple meshes

The computational domain can consist of many connected mesh. Each mesh
must have its MESH namelist group.
For example,
&MESH IJK=32,32,16, XB=0.0,1.6,0.0,1.6,0.0,0.8 /

&MESH IJK=32,32,16, XB=0.0,1.6,0.0,1.6,0.8,1.6 /
&MESH IJK=32,32,16, XB=0.0,1.6,0.0,1.6,1.6,2.4 /
&MESH IJK=32,32,16, XB=0.0,1.6,0.0,1.6,2.4,3.2 /
describes a domain composed of four connected meshes, as in Figure 7.1.

The connections must always follow a simple rule of mesh alignment depicted in Mesh alignment
Figure 7.2 on the following page: an integer (1, 2, 3. . . ) number of fine cells
exactly abuts each coarse cell.
The following rules of thumb should also be followed when setting up a multiple
mesh calculation:
• Avoid putting mesh boundaries where critical action is expected, especially

fire. Sometimes fire spread from mesh to mesh cannot be avoided, but
Figure 7.2: Mesh connections: (a) ideal, (b) allowed, and (c) forbidden
Figure 7.3: Geometric object: before and after automatic shifting
if at all possible try to keep mesh interfaces relatively free of complicated

phenomena since the exchange of information across mesh boundaries is
not yet as accurate as cell to cell exchanges within one mesh.
• If a planar obstruction is close to where two meshes abut, make sure that
each mesh sees the obstruction. If the obstruction is even a millimeter
outside of one of the meshes, that mesh does not account for it, in which
case information is not transferred properly between meshes.
• Experiment with different mesh configurations using relatively coarse mesh

cells to ensure that information is being transferred properly from mesh
to mesh. There are two issues of concern. First, does it appear that the
flow is being badly affected by the mesh boundary? If so, try to move the
mesh boundaries away from areas of activity. Second, is there too much
of a jump in cell size from one mesh to another? If so, consider whether
the loss of information moving from a fine to a coarse mesh is tolerable.
7.3 Conformity to the mesh

All geometric objects must conform to the rectangular mesh. If you create
geometrical objects that do not precisely conform to the underlying mesh, FDS
shifts them to the closest mesh cell as shown in Figure 7.3.
7.4. CHOOSING THE RIGHT MESH DIMENSION:A SENSITIVITY STUDY59
7.4 Choosing the right mesh dimension:

a sensitivity study
The most important numerical parameter in FDS is the grid cell size. CFD models
solve an approximate form of the conservation equations of mass, momentum,
and energy on a numerical grid. The error associated with the discretization of
the partial derivatives is a function of the size of the grid cells and the type of
differencing used. FDS uses second-order accurate approximations of both the
temporal and spatial derivatives of the Navier-Stokes equations, meaning that
the discretization error is proportional to the square of the time step or cell size.
In theory, reducing the grid cell size by a factor of 2 reduces the discretization
error by a factor of 4. However, it also increases the computing time by a factor
of 16 (a factor of 2 for the temporal and each spatial dimension). Clearly, there
is a point of diminishing returns as one refines the numerical mesh. Determining
what size grid cell to use in any given calculation is known as a grid sensitivity
study.
In general, you should build an FDS input file using a relatively coarse mesh,
and then gradually refine the mesh until you do not see appreciable differences
in your results.
A point of diminishing returns is reached when the improvement in the quality
of the results is outweighed by the cost of the computation. When this point is
reached depends on the application. It also depends on the quantities that are
of interest. Some quantities, like hot gas layer temperature or height, do not
typically require as fine a numerical grid as quantities such as the heat flux to
targets near the fire.
For simulations involving buoyant plumes, a measure of how well the flow field
is resolved is given by the non-dimensional expression D∗ /δx, where D∗ is a
characteristic fire diameter and δx is the nominal size of a mesh cell. D∗ is
defined as:
!2
5
Q̇
∗
D = √ (7.1)
ρ∞ cp T∞ g
where Q̇ is the heat release rate of the fire in kW, ρ∞ air density (∼1.2 mkg3 ),
cp air thermal capacity (∼1 kgkJK ), T∞ ambient air temperature (∼293 K), g
gravitational acceleration (∼9.81 sm2 ).
The quantity D∗ /δx can be thought of as the number of computational cells
spanning the characteristic (not necessarily the physical) diameter of the fire.
The more cells spanning the fire, the better the resolution of the calculation.
It is better to assess the quality of the mesh in terms of this non-dimensional
parameter, rather than an absolute mesh cell size. For example, a cell size of
10 cm may be adequate, in some sense, for evaluating the spread of smoke and
heat through a building from a sizable fire, but may not be appropriate to study
a very small, smoldering source.
As an example, in the mesh sensitivity study for [NUREG 1824], the D∗ /δx
values ranged from 4 to 16. These values were used to adequately resolve plume
dynamics, along with other geometrical characteristics of the models as well.
This range does not indicate what values to use for all models, only what values
worked well for that particular set of models.
7.5 Initial conditions of the computational do-

main, INIT
At the start of any calculation, the temperature is ambient everywhere, the flow
velocity is zero everywhere, nothing is burning, and the mass fractions of all
species are uniform.
To change the starting ambient conditions within some volumetric region of the
flow domain add lines of the form:
&INIT XB=0.5,0.8,2.1,3.4,2.5,3.6, TEMPERATURE=30. /
the initial temperature of the gas phase shall be 30°C instead of the ambient
within the prescribed volume. This construct can also be used for DENSITY or
MASS_FRACTION(n).
The INIT construct may be useful in examining the influence of stack effect in
a building, where the temperature is different inside and out.
For setting initial temperature of a solid obstruction see Subsection 11.6.2.
Also the MISC namelist group can be used to set a variety of initial conditions.
An initial velocity on the domain can be prescribed via U0, V0, and W0 parameters.
Normally, the initial values of the gas velocity in each of the coordinate directions
are all 0 m/s, but there are a few applications where it is convenient to start the
flow immediately, like in an outdoor simulation involving wind.
A different ambient temperature of the domain can be prescribed via the TMPA
parameter.
7.5. INITIAL CONDITIONS OF THE COMPUTATIONAL DOMAIN, INIT 61
To model a sloping roof or tunnel you can change the direction of the gravity
vector. The GVEC parameter contains the 3 components of gravity, in m/s2 . The
default is GVEC=0,0,-9.81
For example,
&MISC U0=2., TMPA=25., GVEC=-0.114377,0.,-9.809333 /
generates an initial wind speed to 2 m/s in +x direction, sets ambient tempera-

ture to 25°C, and bends the gravity vector in −x direction.
The following table summarizes some INIT parameters:
Table 7.3: INIT parameters
DENSITY Real Initial value of density kg/m3 Ambient
MASS_FRACTION(n) Real Initial value of specie n kg/kg Ambient
TEMPERATURE Real Initial value of temperature ◦

C TMPA
XB(6) Real Volume m

Chapter 8
Materials
Third, some properties are set up, as the properties of each material
(MATL). This chapter covers RAMP (temperature dependent) namelist
group, too.
8.1 Defining a material, MATL

The properties of each material used in the model are designated via the MATL
namelist group. These properties indicate how rapidly the materials heat up, and
how they burn. Each MATL entry in the input file must have an ID that can be
referred by other namelist groups.
The following table summarizes some MATL parameters:
Table 8.1: MATL parameters
DENSITY Real Solid mass per unit volume kg/m3 0.
EMISSIVITY Real Emissivity 0.9
CONDUCTIVITY Real Thermal conductivity W/m/K 0.
CONDUCTIVITY_RAMP String Ramp ID for conductivity
SPECIFIC_HEAT Real Specific heat kJ/kg/K 0.

63
64 CHAPTER 8. MATERIALS
from previous page

SPECIFIC_HEAT_RAMP String Ramp ID for specific heat
HEAT_OF_COMBUSTION Real Heat of combustion kJ/kg 0.
HEAT_OF_REACTION Real Heat of reaction kJ/kg 0.
ABSORPTION_COEFFICIENT Real Absorption Coefficient 1/m 50 000.
BOILING_TEMPERATURE Real Boiling temperature ◦

C 5000.
8.2 Thermal properties

The MATL namelist group can be used to specify thermal CONDUCTIVITY ( mWK ),
DENSITY ( mkg3 ), SPECIFIC_HEAT ( kgkJK ), and EMISSIVITY (0.9 by default) of
materials, for example:
&MATL ID=’steel’, EMISSIVITY=.95, DENSITY=7850.,

CONDUCTIVITY=45.8, SPECIFIC_HEAT=0.46, /
&MATL ID=’concrete’, DENSITY=2200.,
&MATL ID=’copper’, SPECIFIC_HEAT=0.38,
CONDUCTIVITY=387., DENSITY=8940. /
&MATL ID=’gypsum plaster’, CONDUCTIVITY=0.48,
Thermal properties like conductivity and specific heat can vary significantly with
temperature. In such cases, use the RAMP function like this:
&MATL ID=’steel’, SPECIFIC_HEAT_RAMP=’c_steel’,

CONDUCTIVITY_RAMP=’k_steel’, DENSITY=7850. /
&RAMP ID=’c_steel’, T=20., F=0.45 /
&RAMP ID=’c_steel’, T=377., F=0.60 /
&RAMP ID=’c_steel’, T=677., F=0.85 /
&RAMP ID=’k_steel’, T=20., F=48. /
&RAMP ID=’k_steel’, T=677., F=30. /
&MATL ID=’calcium silicate’,

CONDUCTIVITY_RAMP=’k_casi’, DENSITY=770.,
SPECIFIC_HEAT=0.96 /
8.3. BURNING PROPERTIES 65
&RAMP ID=’k_casi’, T= 25., F=0.18 /

&RAMP ID=’k_casi’, T=200., F=0.19 /
&RAMP ID=’k_casi’, T=500., F=0.20 /
For this kind of ramps the parameter F is the value of the actual physical quantity.
If CONDUCTIVITY_RAMP is used, there should be no value of CONDUCTIVITY
given. Note also that for values of temperature, T, below and above the given
range, FDS will assume a constant value equal to the first or last F specified.
Each set of RAMP lines must be listed with monotonically increasing T. The
following table summarizes some RAMP (temperature) parameters:
Table 8.2: RAMP (temperature) parameters
T Real Temperature °C
F Real Function value
8.3 Burning properties
8.3.1 Solids
The MATL namelist group can be used to specify the parameters employed in
the solid phase pyrolysis process. As already explained in Chapter 6 on page 45,
pyrolysis is the decomposition or transformation of a compound caused by heat
that produce the gaseous fuel, that is burned during gas phase combustion.
FDS contains a fairly general description of multi-layered, multi-component,
multi-reaction solid: while burning, each material can undergo several reactions
that may occur at different temperatures and consume different amounts of heat.
Each individual reaction can produce a single solid residue, water vapor, or fuel
gas.
Here is an example of a material that burns in the neighborhood of 350°C,
converting all its mass to fuel gases with NU_FUEL(1)=1.:
&MATL ID=’my fuel’, SPECIFIC_HEAT=1.0, CONDUCTIVITY=0.1,

DENSITY=100.0, HEAT_OF_COMBUSTION=15000., N_REACTIONS=1,
NU_FUEL(1)=1., REFERENCE_TEMPERATURE(1)=350.,
HEAT_OF_REACTION(1)=3000. /
See next Sections and [FDS5 user’s guide] for broader description of the problem
and its complexity.
8.3.2 Liquids
The MATL namelist group is also used to specify the parameters for burning
liquids.
For a liquid fuel, the thermal properties are similar to those of a solid material,
with a few exceptions. The evaporation rate of the fuel is governed by the
Clausius-Clapeyron equation. The only drawback of this approach is that the fuel
gases burn regardless of any ignition source. Thus, if a liquid fuel is specified,
the fuel begins burning at once.
As an example:
&MATL ID=’ethanol’, EMISSIVITY=1.0, NU_FUEL=0.97,

HEAT_OF_REACTION=880.,
CONDUCTIVITY=0.17, SPECIFIC_HEAT=2.45, DENSITY=787.,
ABSORPTION_COEFFICIENT=40., BOILING_TEMPERATURE=76. /
The inclusion of BOILING_TEMPERATURE on the MATL line tells FDS to use its
liquid pyrolysis model.
It also automatically sets N_REACTIONS=1: the only reaction is the phase change
from liquid to gaseous fuel. Thus, HEAT_OF_REACTION in this case is the latent
heat of vaporization. The gaseous fuel yield, NU_FUEL, is 0.97 instead of 1 to
account for impurities in the liquid that do not take part in the combustion
process.
The thermal conductivity, density and specific heat are used to compute the
loss of heat into the liquid via conduction using the same one-dimensional heat
transfer equation that is used for solids. Obviously, the convection of the liquid
is important, but is not considered in the model.
Note also the ABSORPTION_COEFFICIENT for the liquid. This denotes the ab-
sorption in depth of thermal radiation. Liquids do not just absorb radiation at
the surface, but rather over a thin layer near the surface. Its effect on the burning
rate is significant.
8.4. PROPERTIES HELL 67
8.3.3 HEAT_OF_COMBUSTION in a MATL line?
The HEAT_OF_COMBUSTION is the energy released per unit mass of fuel gas that
mixes with oxygen and burns. This has nothing to do with the pyrolysis process.
This parameter would better be used in gas phase combustion!
If you remember what was said in Chapter 6 on page 45, whereas there can be
many types of combustibles in an FDS fire simulation, only one gaseous fuel can
be simulated by FDS. The stoichiometry of the predominant reaction is specified
via the REAC namelist group.
In fact, the HEAT_OF_COMBUSTION specified on the REAC line pertains to the only
gaseous fuel modeled in gas phase combustion.
The HEAT_OF_COMBUSTION specified on the MATL line is that specific to gaseous
fuel produced by pyrolysis.
If the HEAT_OF_COMBUSTION is specified on the MATL line, FDS automatically
adjust the mass loss rate of the gaseous fuel injected by the pyrolyzing material,
so that the corrected mass loss rate multiplied by the single, global, gas phase
heat of combustion produces the expected heat release rate.
If, for example, the HEAT_OF_COMBUSTION specified on the REAC line is twice
that specified on the MATL line, the mass of pyrolyzing material contained within
wall cell will be decremented by that determined by the pyrolysis model, but the
mass of fuel gas added to gas phase would be reduced by 50%.
8.4 Properties hell
The scientific community agrees that there is no standardized way of obtaining

all of the parameters needed to run FDS. This is especially true of materials that
burn. There are various devices used to measure various properties, but there is
no consensus on the exact physical and mathematical description of these, and
thus, no standard way of taking bench-scale data and converting it into an FDS
input file.
Recently Nick Dempsey of WPI, Marc Janssens of Southwest Research,
and Morgan Hurley of the SFPE were awarded a three year grant to develop
an engineering guide that will document the standard test methods used to
obtain material properties, and more importantly the physical and mathematical
interpretation of these methods that will enable us all to understand what to do
with measurements made in the various bench scale devices.
A prediction is called blind, if the results are not compared to experimental mea-
sures. Grid sensitivity and uncertain material properties make blind predictions
of fire growth on real materials beyond the reach of the current version of the
model.
However, the model can still be used for a qualitative assessment of fire behavior
as long as the uncertainty in the flame spread rate is recognized.
For engineering level applications, it’s strongly advised to recur to simplified fire
modeling, directly prescribing the HRR of the fire scenario taken from literature
or direct experimentation, as shown in Section 11.4.6 on page 84.
8.5 Resources for material property data

Here are some web resources for material property data; a broader list of links is
maintained on FDS web site:
• NIST Chemistry Webbook:

http://webbook.nist.gov/chemistry/
• ChemFinder:
http://chemfinder.cambridgesoft.com/
• Parital INSC Material Properties Database:

http://www.insc.anl.gov/matprop/thermo.php
• Cone calorimeter data from Worcester Polytechnic Institute:

http://www.wpi.edu/Academics/Depts/Fire/Lab/Cone/Data
• MatWeb:
http://matweb.com
• Engineering Toolbox:
http://engineeringtoolbox.com
Chapter 9
Extra gas species
Third, some properties are set up, as the properties of extra gas
species (SPEC).
9.1 Defining extra gas species, SPEC

Gases that are introduced into the domain that are neither reactants nor products
of combustion, like carbon dioxide from an extinguisher, are tracked separately
from the mixture fraction model for gas phase combustion via an additional scalar
transport equation. In fact, there does not need to be any fire at all, as FDS can
be used to transport a mixture of non-reacting ideal gases.
The namelist group SPEC is used to specify each additional species. Each SPEC
line should include at the very least the name of the species via a character string
called ID.
The following gases are predefined in FDS and do not need any property to be
set up:
Table 9.1: Predefined extra species
AIR, ARGON, CARBON DIOXIDE, CARBON MONOXIDE, HELIUM, HYDROGEN,

METHANE, NITROGEN, OXYGEN, PROPANE, WATER VAPOR.
For example:
&SPEC ID=’HELIUM’ /
69
70 CHAPTER 9. EXTRA GAS SPECIES
adds the predefined HELIUM gas as an additional specie that can be injected in
the domain.
To specify a gas not included in the list, the user should input several chemical
properties. See [FDS5 user’s guide] for broader description.
If the ambient initial mass fraction of an extra gas specie is something other than
0, then the parameter MASS_FRACTION_0 is used to specify it. For example, the
line:
&SPEC ID=’ARGON’, MASS_FRACTION_0=0.1 /
specifies that 10% in mass of ARGON is to be included in the calculation, in

addition to the 90% unlisted default ambient specie named AIR.
The following table summarizes some SPEC parameters:
Table 9.2: SPEC parameters
MASS_FRACTION_0 Real Initial mass fraction 0
9.2 CARBON DIOXIDE and carbon dioxide

These extra gas species are identified by an uppercase name, and are not to be
confused with the lowercase species implicitly defined by FDS when doing a mix-
ture fraction calculation for gas phase combustion, as fuel, oxygen, nitrogen,
water vapor, carbon dioxide. . . See Section 6.3 on page 46 for reference.
If the user introduces an extra gas in the calculation that is the same as a product
of combustion, as in:
&SPEC ID=’CARBON DIOXIDE’ /
FDS will take into account two different gases: the implicitly defined carbon
dioxide and the extra gas species CARBON DIOXIDE, injected for example to
simulate a CO2 extinguisher.
9.2. CARBON DIOXIDE AND CARBON DIOXIDE 71
The first is a product of combustion, while the second is just another gas: it
does not participate to combustion, but it can dilute oxygen and contribute to
fire suppression.
The two gases are tracked separately: carbon dioxide is tracked via the mix-
ture fraction variable and CARBON DIOXIDE is tracked via its own transport
equation.
72 CHAPTER 9. EXTRA GAS SPECIES
Chapter 10
Lagrangian particles
Third, some properties are set up, as the properties of Lagrangian

particles (PART).
10.1 Defining Lagrangian particles, PART

Lagrangian particles are used in FDS as water or liquid fuel droplets, flow tracers,
and various other objects that are not defined or confined by the numerical mesh.
Sometimes the particles have mass, sometimes they do not. Some evaporate,
absorb radiation, etc. PART is the namelist group that is used to prescribe
parameters associated with Lagrangian particles.
All Lagrangian particles must be explicitly defined via the PART namelist group.
Once a particular type of particle or droplet has been described using a PART
line, then the name of that particle or droplet type is invoked elsewhere in the
input file via the parameter PART_ID.
There are no reserved PART_ID, all must be defined. For example, an input
file may have several PART lines that include the properties of different types of
Lagrangian particles:
&PART ID=’my tracer’, MASSLESS=.TRUE. /
Then these Lagrangian particles can be introduced in the fluid flow from a solid
surface via a boundary condition as explained in Section 11.8 on page 91.
The following table summarizes some PART parameters:
73
74 CHAPTER 10. LAGRANGIAN PARTICLES
Table 10.1: PART parameters
MASSLESS Logical Massless particles .FALSE.
WATER Logical Water droplets .FALSE.
AGE Real Droplet lifetime s 100000.
COLOR String Color
RGB(3) Integer Color
DT_INSERT Real Time between insertions s 0.01
XB(6) Real Volume, initial particle location m
10.2 Massless particles

The simplest use of Lagrangian particles is for visualization, in which case the
particles are considered massless tracers. In this case, the particles are defined
via the line:
10.3 Water droplets

WATER=.TRUE. declares that the liquid droplets evaporate into WATER VAPOR,
a separate gas phase specie that is automatically added to the calculation by
this command. By default, WATER=.FALSE., even though the default properties
of droplets are that of water. Setting WATER=.TRUE. instructs FDS to add
WATER VAPOR as an explicitly defined specie, and it also invokes appropriate
constants related to the absorption of thermal radiation by the water droplets.
It also causes the droplets to be colored blue in Smokeview.
For example:
&PART ID=’droplets’, WATER=.TRUE. /

10.3. WATER DROPLETS 75
When a droplet strikes a solid surface, it sticks and is reassigned a new speed
and direction. If the surface is horizontal, the direction is randomly chosen. If
vertical, the direction is downwards.
76 CHAPTER 10. LAGRANGIAN PARTICLES
Chapter 11
Boundary conditions
Third, some properties are set up, as the types of boundary conditions
(SURF).
This is the most challenging part of setting up the simulation: first,
for both real and simulated fires, the growth of the fire is very sensi-
tive to the thermal properties of the surrounding materials. Second,
even if all the material properties are known to some degree, the
physical phenomena of interest may not be simulated properly due
to limitations in the model algorithms or resolution of the numerical
mesh.
It is your responsibility to supply the thermal properties of the ma-
terials, and then assess the performance of the model to ensure that
the phenomena of interest are being captured.
This chapter covers RAMP (time dependent) namelist group, too.
11.1 Defining boundary conditions, SURF

This chapter describes how to specify the properties of the bounding surfaces
of the flow domain. The namelist group that defines the types of boundary
conditions is SURF. For example,
&SURF ID=’warm_surface’, TMP_FRONT=25. /
defines a surface named warm_surface. Its temperature is fixed to 25°C.
77
78 CHAPTER 11. BOUNDARY CONDITIONS
While building the solid geometry, the types of boundary conditions will be applied
to each of the bounding surfaces of the flow domain: the faces of the solid
obstructions and the exterior boundaries of the computational domain.
The following table summarizes some SURF parameters:
Table 11.1: SURF parameters
ADIABATIC Logical Adiabatic thermal boundary .FALSE.

condition
EMISSIVITY Real Emissivity 0.9
HRRPUA Real HRR per unit area kW/m2 0.
MLRPUA Real Mass loss rate per unit area kg/m2 /s 0.
HEAT_OF_VAPORIZATION Real Heat of vaporisation for kJ/kg 0.

specified HRR only
IGNITION_TEMPERATURE Real Ignition temperature ◦

C 5000.
MATL_ID(i,j) String Material name (Layer,

Component)
MATL_MASS_FRACTION(i,j) Real Mass fraction of

components (Layer,
Component)
THICKNESS(i) Real Thickness of layers (Layer) m 0.
BACKING String Back boundary condition ’VOID’
TMP_BACK Real Back surface temperature ◦

C 20.
TMP_FRONT Real Front surface temperature ◦

C 20.
TMP_INNER Real Initial solid temperature ◦

C 20.
BURN_AWAY Logical Burn away solid .FALSE.
NET_HEAT_FLUX Real Net heat flux at surface kW/m2 0.
CONVECTIVE_HEAT_FLUX Real Convective heat flux at kW/m2 0.

surface
11.2. PREDEFINED BOUNDARY CONDITIONS 79
from previous page

EXTERNAL_FLUX Real External heat flux to kW/m2 0.
surface
MASS_FLUX_TOTAL Real Total mass flux kg/m2 /s
MASS_FLUX(n) Real Mass flux for specie n kg/m2 /s 0.
MASS_FRACTION(n) Real Mass fraction for specie n
VEL Real Normal velocity m/s 0.
VEL_T(2) Real Tangential velocity m/s 0.,0.

components
VOLUME_FLUX Real Normal velocity × area m3 /s 0.
POROUS Logical Porous boundary condition .FALSE.
TAU_MF(n) Real Ramp time for specie n s 1.
TAU_Q Real Ramp time for HRR s 1.
TAU_T Real Ramp time for temperature s 1.
TAU_V Real Ramp time for velocity s 1.
RAMP_MF(n) String Ramp ID for specie n
RAMP_Q String Ramp ID for HRR
RAMP_T String Ramp ID for temperature
RAMP_V String Ramp ID for velocity
COLOR String Color
RGB(3) Integer Color 255,204,102
TRANSPARENCY Real Transparency 1
PART_ID String Lagrangian particle ID
11.2 Predefined boundary conditions

FDS contains some predefined boundary conditions that do not need to be set
within a SURF namelist group: INERT, OPEN, and MIRROR.
An INERT boundary condition represents an isothermal wall with the temperature INERT
fixed at ambient temperature. INERT allows for heat loss and is not the same
Figure 11.1: Extending the computational domain beyond the vent
as an adiabatic surface. An INERT solid is something that never heats up, like a
piece of steel that has cold water constantly flowing across its back side.
In general, this boundary condition should not be used, as it is better to assign
actual material properties to everything.
OPEN An OPEN boundary condition assumes that ambient conditions exist beyond that
VENT. OPEN can only be prescribed at an exterior boundary of the computational
domain.
If you are concerned about the flow through a particular vent, do not use an OPEN
boundary because the constant pressure assumption is just an approximation.
You should extend your computational domain beyond the vent and build it out
of obstructions, as shown in Figure 11.1. The flow in and out will then be treated
naturally as part of the solution of the governing equations.
MIRROR A MIRROR boundary condition denotes a symmetry plane. A MIRROR should span
an entire face of the computational domain, essentially doubling the size of the
domain. The flow on the opposite side of the MIRROR is exactly reversed. From
a numerical point of view, a MIRROR is a no-flux, free-slip boundary.
MIRROR can only be prescribed at an exterior boundary of the computational
domain.
11.3 Coloring boundary conditions

As explained in Section 4.10 on page 39:
&SURF ID=’upholstery’, RGB=0,255,0 /

&SURF ID=’carpet’, COLOR=’VIOLET RED’ /
will cause objects with a boundary condition of type upholstery to be colored

green and the objects of type carpet to be violet red.
11.4. EXAMPLES OF BOUNDARY CONDITIONS 81
It is highly recommended that colors be assigned to solid obstructions via the

SURF line because, as the geometries of FDS simulations become more complex,
it is very useful to use color as a spot check to determine if the desired surface
properties have been assigned throughout the room or building under study.
Another example:
&SURF ID=’glass’, RGB=0,255,0, TRANSPARENCY=.3 /
will cause objects with a boundary condition of type glass to be colored green
and to be partially transparent.
11.4 Examples of boundary conditions

In the following Sections a list of simple boundary conditions are presented. More
complex examples can be found in Chapter 16 on page 133.
11.4.1 Adiabatic surface

For some special applications, it is often desired that a solid surface be adiabatic,
that is, there is no net heat transfer (radiative and convective) from the gas to
the solid. The line:
&SURF ID=’adiabatic_surface’, ADIABATIC=.TRUE. /
defines an adiabatic surface named adiabatic_surface. FDS will compute a

wall temperature so that the sum of the convective and radiative fluxes to the
wall is zero.
11.4.2 Fixed temperature and heat flux

The line:
&SURF ID=’warm_surface’, TMP_FRONT=25. /
fixes the surface temperature to 25°C.

The following line specifies a NET_HEAT_FLUX in units of kW/m2 :
&SURF ID=’warm_surface’, NET_HEAT_FLUX=25. /
FDS will compute the surface temperature required to ensure that the combined
radiative and convective heat flux from the surface is equal to the prescribed flux.
The following line specifies separately the CONVECTIVE_HEAT_FLUX, in units of
kW/m2 and the radiative heat flux using TMP_FRONT temperature in °C and
EMISSIVITY:
&SURF ID=’warm_surface’, CONVECTIVE_HEAT_FLUX=25.,

TMP_FRONT=150., EMISSIVITY=.9 /
Sign convention The sign convention is that positive heat flux from a surface heats up the gas.
11.4.3 Fans
For most applications, the ventilation system of a building is described in FDS
using velocity boundary conditions. For example, fresh air can be blown into, and
smoke can be drawn from a compartment by specifying a velocity in the normal
direction to a solid surface. However, there are various other facets of velocity
boundary conditions that are described below.
&SURF ID=’supply’, VEL=-1.2, TMP_FRONT=50. /
defines a surface supplying hot air to the domain at a velocity of 1.2 m/s and
temperature of 50°C. The volume flux depends on the prescribed area and its
alignment with the computational mesh.
The line:
&SURF ID=’supply’, VOLUME_FLUX=1.2 /
defines a surface extracting air from the domain at a volume flow of 1.2 m3 /s. The
velocity depends on the prescribed area and its alignment with the computational
mesh.
This line:
&SURF ID=’supply’, MASS_FLUX_TOTAL=-1.2 /

11.4. EXAMPLES OF BOUNDARY CONDITIONS 83
supplies air to the domain at a mass flow rate of 1.2 kg/s. The MASS_FLUX_TOTAL
is converted internally into a velocity boundary condition whose value for an
outflow is adjusted based on the local density.
The line:
&SURF ID=’louver’, VEL=-1.2, VEL_T=0.5,-0.3 /
represents a boundary condition for a louvered vent that pushes air into the space
with a normal velocity of 1.2 m/s and a tangential velocity of 0.5 m/s in either
the x or y direction and -0.3 m/s in either the y or z direction, depending on
what the normal direction is.
In cases of limited mesh resolution, it may not be possible to describe a louvered
vent or slot diffuser using VEL_T because there may not be enough mesh cells
spanning the opening. In these cases, you might consider simply specifying a flat
plate obstruction in front of the VENT with an offset of one mesh cell. The plate
will simply redirect the air flow in all lateral directions.
Note that either VEL, VOLUME_FLUX, or MASS_FLUX_TOTAL should be prescribed,
not both. The choice depends on whether an exact velocity is desired at a given
vent, or whether the given volume flux or mass flux is desired.
The sign convention is that positive volume or mass flux is drawn out of the Sign convention
domain.
11.4.4 Fans injecting extra gas species

There are two species boundary conditions that can be specified: MASS_FLUX(n)
and MASS_FRACTION(n) where n refers to a given specie SPEC via its place in
the input file.
If the mass fraction of the n specie is to be some value at a forced flow boundary
(VEL or MASS_FLUX_TOTAL) set MASS_FRACTION(n) equal to the desired mass
fraction on the appropriate SURF line.
If the mass flux of the n specie is desired, set MASS_FLUX(n) instead of MASS_FRACTION(n).
If MASS_FLUX(n) is set, no VEL should be set. It is automatically calculated based
on the mass flux.
The inputs MASS_FLUX(n) and MASS_FRACTION(n) should only be used for
inflow boundary conditions. MASS_FLUX(n) should always be positive with units
of kg/m2 /s.
For example, the lines:
&SPEC ID=’ARGON’, MASS_FRACTION_0=0.1 /

&SPEC ID=’HELIUM’ /
&SURF ID=’inlet’, MASS_FRACTION(2)=0.2, VEL=-0.3 /
specify that ARGON and HELIUM are to be included in the calculation in addition
to the unlisted default AIR. At the inlet, a mixture of helium (20% by mass),
argon (10% by mass because nothing different is specified), and air (70% by mass
making up the rest) flows out at a velocity of 0.3 m/s into the flow domain.
11.4.5 Dynamic pressure at an open boundary

In some situations, it is more convenient to specify a dynamic pressure, rather
than a velocity, at a boundary.
Suppose that you are modeling the interior of a tunnel, and a wind is blowing
at one of the portals that affects the overall flow within the tunnel. If (and only
if) the portal is defined using an OPEN vent, then the dynamic pressure at the
boundary can be specified like this:
&VENT XB=0.,0.,0.,4.,0.,3., SURF_ID=’OPEN’,

DYNAMIC_PRESSURE=2.4 /
A dynamic pressure of 2.4 Pa is applied to the specified face. See Section 12.3
on page 97 for a description of the VENT namelist group.
11.4.6 Prescribing an heat release rate

Solids and liquid fuels can be modeled by specifying their relevant properties via
the MATL namelist group. However, if you simply want to specify a fire of a
given Heat Release Rate (HRR), you need not specify any material properties.
A specified fire is basically modeled as the ejection of gaseous fuel from a solid
surface or vent. This is essentially a burner, with a specified heat release rate
per unit area, HRRPUA, in units of kW/m2 . For example, the line:
&SURF ID=’burner’, HRRPUA=500. /
defines a surface that injects a flow of fuel gas that, when properly mixed with
ambient air, burns and produces 500 kW per m2 of emitting surface.
11.5. GEOMETRIC CONFORMITY AND RATES 85
An alternative to HRRPUA with the exact same functionality is MLRPUA, except

this parameter specifies the mass loss rate of fuel gas per unit area in kg/m2 /s.
Do not specify both HRRPUA and MLRPUA on the same SURF line.
For example:
&SURF ID=’burner’, MRLPUA=5. /
specifies the a mass loss rate of fuel gas per unit area of 5 kg/m2 /s.
By specifying HRRPUA or MRLPUA, you are controlling the burning rate rather
than letting the material pyrolyze based on the conditions of the surrounding
environment.
11.5 Geometric conformity and rates

Be aware that, whenever geometric objects are transformed to become conform
to the underlying mesh, their face areas can change. FDS adjusts the value of
HRRPUA, MRLPUA, and of other mass fluxes to guarantee the user prescribed rates.
11.6 Boundary conditions for solids

The thermal and burning properties of each material are specified via the MATL
namelist group. Then materials are invoked by the SURF namelist group to define
boundary conditions for solids.
FDS performs a one-dimensional heat transfer calculation at each surface of the
solid to provide a reasonable bounding surface temperature for the gas phase
calculation.
A solid boundary can consist of one or multiple layers of different materials, and
each layer can consist of multiple material components.
These combinations of layers and material components are specified on the SURF
line via the array parameter called MATL_ID(i,j). The argument i is an integer
indicating the layer index, starting at 1, the layer at the exterior boundary. The ar-
gument j is an integer indicating the component index. MATL_ID(2,3)=’brick’
indicates that the third material component of the second layer is brick.
The components of the solid mixtures are treated as pure substances with no
voids.
The following is an example of a multi-layer, multi-component surface:
Figure 11.2: brick wall: multiple layers of different materials
&MATL ID=’water’, CONDUCTIVITY=0.60, SPECIFIC_HEAT=4.19,

DENSITY=1000. / material
&MATL ID=’brick’, CONDUCTIVITY=0.69, SPECIFIC_HEAT=0.84,
&MATL ID=’insulator’, CONDUCTIVITY=0.041, SPECIFIC_HEAT=2.09,
&SURF ID=’brick wall’, MATL_ID(1,1:2)=’brick’,’water’,
MATL_MASS_FRACTION(1,1:2) = 0.95,0.05,
MATL_ID(2,1)=’insulator’,
THICKNESS(1:2)=0.1,0.2 / boundary condition
First, materials are defined, then a boundary condition brick wall is prescribed.
In brick wall surface (see Figure 11.2), the first layer is composed of a mix-
ture of brick and water. This is given by the MATL_ID array which spec-
ifies component 1 of layer 1 to be of brick material, and component 2 of
layer 1 to be of water material. The mass fraction of each is specified via
MATL_MASS_FRACTION: brick is 95% by mass and water is 5%. The first layer
is 0.1 m thick.
The innermost layer is made of one only component, insulator, and is 0.2 m
thick.
11.6.1 Backing
The heat transfer condition of the innermost layer of a wall is set using the
BACKING parameter. This parameter can be set to VOID, INSULATED, or EXPOSED.
11.6. BOUNDARY CONDITIONS FOR SOLIDS 87
For example: VOID
&SURF ID=’double_layer’, MATL_ID(1:2,1)=’plastic’,’steel’,

THICKNESS(1:2)=0.1,0.2, BACKING=’VOID’, TMP_BACK=30. /
defines a two layers surface. The external layer is made of one only component,
plastic, and is 0.1 m thick. The innermost layer is made of one only component,
steel, and is 0.2 m thick. The innermost layer backs up to an air gap. The air
gap is at a TMP_BACK temperature of 30°C. If TMP_BACK is not set, the air gap
defaults to ambient temperature. BACKING=’VOID’ can be safely omitted as it
is the default value.
A second example: INSULATED

THICKNESS(1:2)=0.1,0.2, BACKING=’INSULATED’ /
defines the same two layers surface. In this second case, the innermost layer
backs up to an insulating (adiabatic) material, so that no heat is lost to the
backing material.
As a last example: EXPOSED

THICKNESS(1:2)=0.1,0.2, BACKING=’EXPOSED’ /
defines the same two layers surface. In this third case, the innermost layer backs
up to the room on the other side of the wall. EXPOSED only works if the wall
is less than or equal to one mesh cell thick, and if there is a non-zero volume
of computational domain on the other side of the wall. FDS calculates the heat
conduction through the entire THICKNESS and uses the gas phase temperature
and heat flux on the front and back sides for boundary conditions.
A redundant calculation is performed on the opposite side of the obstruction, so
be careful how you specify multiple layers: if the layering is symmetric, the same
SURF line can be applied to both sides; however, if the layering is not symmetric,
you must create two separate SURF lines and apply one to each side.
For example, a asymmetric layered hollow box column that is made of steel and
covered on the outside by a layer of insulation material and a layer of plastic on
top of the insulation material, would have to be described with two SURF lines
like the following:
&SURF ID=’column exterior’, BACKING=’EXPOSED’,

MATL_ID(1:3,1)=’plastic’,’insulation’,’steel’,
THICKNESS(1:3)=0.002,0.036,0.0063 /
&SURF ID=’column interior’, BACKING=’EXPOSED’,
MATL_ID(1:3,1)=’steel’,’insulation’,’plastic’,
THICKNESS(1:3)=0.0063,0.036,0.002 /
11.6.2 Setting an initial temperature

A solid obstruction can be given an initial temperature via the parameter TMP_INNER
on the SURF line:
&SURF ID=’stuff’, MATL_ID=’steel’, THICKNESS=.1, TMP_INNER=30. /
the initial temperature shall be 30°C within the concerned face, instead of the
ambient.
11.7 Time dependent boundary conditions

When solid obstacles are activated (See Section 12.7 on page 102), the prescribed
boundary conditions for their faces begin to come into effect.
After activation, temperatures, velocities, burning rates, etc., are ramped-up
from their initial values to their prescribed values in roughly 1 s, because nothing
can happen instantaneously.
This default 1 s ramp can be modified by the user: many SURF parameters can
become time dependent and follow a different trend after the activation instant.
11.7.1 Simplified ramps

The parameters TAU_Q, TAU_T, TAU_V, TAU_MF(n) indicate that the heat re-
lease rate (HRRPUA), surface temperature (TMP_FRONT), normal velocity (VEL,
VOLUME_FLUX) or MASS_FLUX_TOTAL, mass fraction or mass flux of specie n are
to ramp up to their prescribed values in TAU_* seconds after SURF activation and
remain there.
Sign convention If TAU_* is positive, then the related quantity ramps up like tanh(t/τ ). If
11.7. TIME DEPENDENT BOUNDARY CONDITIONS 89
Figure 11.3: HRRPUA as function of time after SURF activation
negative, then it ramps up like (t/τ )2 . As stated before, the default value for all
TAU_* is 1 s.
For example, this line:
&SURF ID=’burner’, HRRPUA=4000., TAU_Q=-120 /
specifies a boundary condition for a burner that activates when the calculation
starts at t=0 s, ramps up like HRRPUA=4000. (t/120)2 while t<120 s and remains
at 4000 kW/m2 after 120 s, as shown in Figure 11.3.
11.7.2 User defined ramps

If something other than a tanh or t2 ramp up is desired, then a user-defined
function must be input. To do this, set RAMP_Q, RAMP_T, RAMP_V or RAMP_MF(n)
equal to a character string designating the ramp function to use for that particular
surface type, then somewhere in the input file generate lines of the form:
&RAMP ID=’rampname1’, T= 0.0, F=0.0 /

&RAMP ID=’rampname1’, T= 5.0, F=0.5 /
&RAMP ID=’rampname1’, T=10.0, F=0.7 /
For this kind of ramp, T is the time passed from activation, and F indicates the
fraction of the heat release rate, wall temperature, velocity, mass fraction, etc.,
to apply. Linear interpolation is used to fill in intermediate time points.
Note that each set of RAMP lines must be listed with monotonically increasing T.
For example, a simple blowing fan can be controlled via the lines:
Figure 11.4: VEL and TMP_FRONT as function of time after SURF activation
&SURF ID=’blower’, VEL=-2., TMP_FRONT=50.,

RAMP_V=’blower_v’, RAMP_T=’blower_t’ /
&RAMP ID=’blower_v’, T=20.0, F=1.0 /
&RAMP ID=’blower_v’, T=30.0, F=0.5 /
&RAMP ID=’blower_v’, T=60.0, F=0. /
&RAMP ID=’blower_t’, T=40.0, F=1.0 /
that produce the time trend shown in Figure 11.4 for SURF parameters.
The following table summarizes some RAMP (time) parameters:
Table 11.2: RAMP (time) parameters
T Real Time s
F Real Function value

11.8. INJECTING LAGRANGIAN PARTICLES 91
11.8 Injecting Lagrangian particles

Lagrangian particles can be introduced into the fluid flow from a solid surface
via boundary conditions.
For example, the following line defines a type of Lagrangian particles:
These Lagrangian particles are then introduced into the fluid flow from a solid
surface that has the following boundary condition prescribed:
&SURF PART_ID=’my tracer’ /
Note that a surface on which particles are specified must have a non-zero normal
velocity directed into the computational domain. This happens automatically if
the surface is burning, hence injecting fuel gas into the flow domain, but must
be specified if it is not.
Chapter 12
Solid geometry
Fourth, the solid geometry is entered via OBST, VENT, HOLE namelist
groups.
A considerable amount of work in setting up a calculation lies in
specifying the geometry of the space to be modeled and applying
boundary conditions to these objects. The geometry is described in
terms of obstructions to the gas phase flow. A boundary condition
needs to be assigned to each bounding surface of the gas phase do-
main describing its thermal properties. Both solid obstruction faces
and the exterior boundaries of the computational domain need a
boundary condition assigned. A fire is just one type of boundary
condition.
12.1 Defining solid obstructions, OBST

The namelist group OBST contains parameters used to define obstructions. Each
OBST line define a solid volume within the computational domain.
The boundary condition for whole faces of the obstruction can be easily speci-
fied prescribing one of the following three parameters: SURF_ID, SURF_IDS, or
SURF_ID6.
The parameter SURF_ID designates one SURF boundary condition to apply to all
the faces of the obstruction. For example:
&OBST XB=2.3,4.5,1.3,4.8,0.0,9.2, SURF_ID=’brick wall’ /
93
94 CHAPTER 12. SOLID GEOMETRY
builds a solid obstruction and apply the brick wall surface type to all its six
faces.
If the obstruction has different properties for its top, sides and bottom, use in-
stead the parameter SURF_IDS, an array of three character strings specifying the
boundary condition for the top, sides and bottom of the obstruction, respectively.
For example:
&OBST XB=2.3,4.5,1.3,4.8,0.0,9.2,
SURF_IDS=’burner’,’brick wall’,’INERT’ /
builds a solid obstruction and applies the burner surface type to the top face
(+z direction), brick wall surface type to sides, and INERT surface type to
the bottom face (−z direction).
If the obstruction has different properties for all its faces, use instead the parame-
ter SURF_ID6, an array of six character strings specifying the boundary condition
for each face. For example:
&OBST XB=2.3,4.5,1.3,4.8,0.0,9.2,
SURF_ID6=’bc-x’,’bc+x’,’bc-y’,’bc+y’,’bc-z’,’bc+z’ /
builds a solid obstruction and applies:
• the bc-x surface type to the x = 2.3 face (face in −x direction),
• the bc+x surface type to the x = 4.5 face (face in +x direction),
• the bc-y surface type to the y = 1.3 face (face in −y direction),
• the bc+y surface type to the y = 4.8 face (face in +y direction),
• the bc-z surface type to the z = 0.0 face (face in −z direction),
• the bc+z surface type to the z = 9.2 face (face in +z direction).
Note that SURF_ID6 complies to the same convention as the XB parameter.

The following table summarizes some OBST parameters:
12.1. DEFINING SOLID OBSTRUCTIONS, OBST 95
Figure 12.1: Boundary conditions prescribed with SURF_ID, SURF_IDS, and

SURF_ID6
Table 12.1: OBST parameters
XB(6) Real Volume m
SAWTOOTH Logical Sawtooth .TRUE.
THICKEN Logical Force at least one cell thick .FALSE.
SURF_ID String Set boundary condition (all faces) ’INERT’
SURF_IDS(3) String Set boundary conditions (top, side, ’INERT’

bottom faces)
SURF_ID6(6) String Set boundary conditions (each of six ’INERT’

faces)
ALLOW_VENT Logical Allow VENT on OBST .TRUE.
PERMIT_HOLE Logical Allow OBST to be carved by a HOLE .TRUE.
COLOR String Color
RGB(3) Integer Color 255,204,102
TRANSPARENCY Real Transparency 1
OUTLINE Logical Draw as outline in Smokeview .TRUE.
DEVC_ID String ID of DEVC that controls OBST’s

existence
CTRL_ID String ID of CTRL that controls OBST’s

existence
12.2 Creating voids inside obstructions, HOLE

The HOLE namelist group is used to carve a hole out of an existing obstruction
or set of obstructions. To do this, add lines of the form:
&HOLE XB=2.0,4.5,1.9,4.8,0.0,9.2 /
Any solid mesh cells within the volume 2.0 < x < 4.5, 1.9 < y < 4.8, 0.0 <
z < 9.2 are removed. Obstructions intersecting the volume are broken up into
smaller blocks.
If the hole represents a door or window, a good rule of thumb is to punch more
than enough to create the hole. This ensures that the hole is created through
the entire obstruction. For example:
&OBST XB=1.0,1.1,0.0,5.0,0.0,3.0 /
&HOLE XB=0.99,1.11,2.0,3.0,0.0,2.0 /
the OBST line denotes a wall 0.1 m thick; the HOLE line creates a door. The extra
centimeter added to the x coordinates of the hole make it clear that the hole is
to punch through the entire obstruction.
If an obstruction is not to be punctured by a HOLE, add the parameter PERMIT_HOLE=.FALSE.
to the OBST line.
Note that a HOLE has no effect on a VENT or a mesh boundary. It only applies
to obstructions.
The following table summarizes some HOLE parameters:
Table 12.2: HOLE parameters
XB(6) Real Volume, cutout m
COLOR String Color for resulting obstruction
RGB(3) Integer Color for resulting obstruction
TRANSPARENCY Real Transparency of resulting obstruction
DEVC_ID String ID of DEVC that controls HOLE’s

existence
CTRL_ID String ID of CTRL that controls HOLE’s

existence
12.3. PRESCRIBING A DIFFERENT BOUNDARY CONDITION, VENT 97
Figure 12.2: OBST, HOLE and VENT
12.3 Prescribing a different boundary condition,

VENT
OBST namelist group can easily prescribe boundary conditions of entire faces of
obstacles. But very often you will need to apply a particular boundary condition
to a rectangular patch of an entire face or to the exterior boundaries of the
computational domain.
The VENT namelist group is used to prescribe these particular boundary condi-
tions:
• on flat faces adjacent to obstructions,

• or exterior boundaries of the computational domain.
&VENT XB=1.0,2.0,2.0,2.0,1.0,3.0, SURF_ID=’burner’ /

&OBST XB=0.0,5.0,2.0,3.0,0.0,4.0, SURF_ID=’brick wall’ /
build a solid obstacle made of brick wall and apply a burner boundary condition
to a rectangular patch on the solid face in −y direction.
To set boundary conditions to exterior boundaries of the computational domain
proceed as in the following example:
Figure 12.3: Setting boundary conditions to exterior boundaries of the compu-

tational domain

&MESH IJK=32,32,16, XB=0.0,1.6,0.0,1.6,0.0,0.8 /
&MESH IJK=32,32,16, XB=0.0,1.6,0.0,1.6,0.8,1.6 /
!!! Properties
&SURF ID=’brick wall’, COLOR=’BROWN’ /
&SURF ID=’floor’, COLOR=’SILVER’ /
&SURF ID=’ceiling’, COLOR=’SLATE GRAY’ /
!!! Solid geometry
&VENT XB=0.0,0.0,0.0,1.6,0.0,1.4, SURF_ID=’brick wall’ /
lower part of -x exterior boundary
&VENT XB=0.0,0.0,0.0,1.6,1.4,1.6, SURF_ID=’OPEN’ /
upper part of -x exterior boundary
+x exterior boundary
&VENT XB=0.0,1.6,0.0,0.0,0.0,1.6, SURF_ID=’brick wall’ /
-y exterior boundary
+y exterior boundary
&VENT XB=0.0,1.6,0.0,1.6,0.0,0.0, SURF_ID=’floor’ /
-z exterior boundary
&VENT XB=0.0,1.6,0.0,1.6,1.6,1.6, SURF_ID=’ceiling’ /
+z exterior boundary
The result is shown in Figure 12.3.

A shortcut exists to select mesh boundaries: the MB parameter. This manual will
not cover it because it leads to error and confusion when employed with multiple
meshes.
12.4. DEFAULT BOUNDARY CONDITION 99
Note that:
• Only one VENT may be specified for any given wall cell. If additional VENT
lines are specified for a given wall cell, FDS will output a warning message
and ignore the subsequent lines. The first defined VENT will be applied:
first-come, first-served.
• VENT overrides the boundary condition defined by the underlying obstruc-

tion: VENT boundary condition wins on OBST boundary condition.
• A VENT must always be attached to a solid obstruction or exterior bound-

aries of the computational domain: a flying VENT is not allowed.
• If FDS outputs an error message requesting that the orientation of a VENT

be specified, check to make sure that the VENT is a plane and that it is
not buried within a solid obstruction.
The following table summarizes some VENT parameters:
Table 12.3: VENT parameters
XB(6) Real Face m
PBX, PBY, PBZ Real Plane m
IOR Integer Index of orientation
SURF_ID String Set boundary condition ’INERT’
DEVC_ID String ID of DEVC that controls VENT’s

existence
CTRL_ID String ID of CTRL that controls VENT’s

existence
12.4 Default boundary condition

INERT is the default SURF boundary condition for all solid surfaces and the
exterior boundary of the computational domain, if not otherwise specified.
If you want to change the default boundary condition, set SURF_DEFAULT pa-
rameter on the MISC line. For example:
&MISC SURF_DEFAULT=’steel’ /
If the default boundary condition is desired for the faces of an obstruction, then
SURF_ID* need not be set. For example:
&OBST XB=2.3,4.5,1.3,4.8,0.0,9.2 /
builds a solid obstruction and apply the default surface type to all its faces.
The same is true for a VENT:
&VENT XB=2.3,4.5,1.3,4.8,0.0,0,0 /
12.5 How thick is a wall?

The lines:
&MATL ID=’brick’, CONDUCTIVITY=0.69, SPECIFIC_HEAT=0.84,

&SURF ID=’brick wall’, MATL_ID(1,1)= ’brick’, THICKNESS= 0.1 /
boundary condition
&OBST XB=0.,10.,0.,.2,0.0,2.7, SURF_ID=’brick wall’ /
solid obstruction
first define a brick material and describe a brick wall boundary condition,
then build a solid obstruction applying the brick wall surface type to all its
faces.
If you carefully examine the prescriptions:
• The OBST object is 10 m long, 2.7 m high, and 0.2 m thick in the y direction.
• The brick wall boundary condition (SURF line) prescribe a 0.1 m thick-
nesses for the same wall.
12.6. THIN SHEET OBSTRUCTIONS 101
At first sight, these two parameters seem in contradiction.

But, if you remember what was anticipated in Section 4.5 on page 35, the
THICKNESS parameter indicated by the SURF line, does not need to match the
XB dimensions of the solid obstruction prescribed by OBST.
In fact, the two parameters are independent from each other:
• The OBST line describes the overall geometric structure of a solid that
obstacles the gas phase flow: it provides data to the hydrodynamic model.
• The SURF line describes the characteristics of the surfaces of the solid, used
to provide a reasonable bounding surface temperature for the gas phase
calculation: it provides data to the solid heat transfer model.
When a SURF boundary condition is applied to the faces of a solid obstruction,

FDS performs a separate one-dimensional heat transfer calculation at each face
of the solid, using the THICKNESS parameter. There is no communication among
the faces.
Obviously, this is not an ideal way to perform solid phase heat transfer, but that’s
currently beyond FDS scope!
12.6 Thin sheet obstructions

Obstructions can be flat. Often, thin sheets, like a window, form a barrier,
but if the numerical mesh is coarse relative to the thickness of the barrier, the
obstruction might be unnecessarily large if it is assumed to be one layer of mesh
cells thick.
All faces of an obstruction are shifted to the closest mesh cell. If the obstruction
is very thin, the two faces may be approximated on the same cell face.
FDS and Smokeview render this obstruction as a thin sheet, but it is allowed to
have thermally thick boundary conditions, in other words a not null THICKNESS
of the applied SURF.
A thin sheet obstruction can only have one velocity vector on its face, thus a gas
cannot be injected reliably from a thin obstruction because whatever is pushed
from one side is necessarily pulled from the other. For full functionality, the
obstruction should be specified to be at least one mesh cell thick.
Thin sheet obstructions work fine as flow barriers, but other features are fragile
and should be used with caution.
To prevent FDS from allowing thin sheet obstructions, set THICKEN_OBSTRUCTIONS=.TRUE.

on the MISC line, or THICKEN=.TRUE. on each OBST line for which the thin sheet
assumption is not allowed.
12.7 Activating and deactivating objects

By default the objects and their prescribed boundary conditions are activated
and come to existence when the calculation starts, then they are deactivated and
disappear when the calculation ends.
If needed, activation and deactivation times of single OBST, VENT and HOLE can
be prescribed by a control logic, as explained in Chapter 13 on page 105.
12.8 Stair stepping complex geometries

The efficiency of FDS is due to the simplicity of its numerical mesh. However,
there are situations in which certain geometric features do not conform to the
rectangular mesh, such as a sloped ceiling or roof. In these cases, construct the
curved geometry using rectangular obstructions, a process sometimes called stair
stepping.
A concern is that the stair stepping changes the flow pattern near the wall.
To lessen the impact of stair stepping on the flow field near the wall, prescribe
the parameter SAWTOOTH=.FALSE. on each OBST line that makes up the stair
stepped obstruction. The effect of this parameter is to prevent vorticity from
being generated at sharp corners, in effect smoothing out the jagged steps that
make up the obstruction.
&OBST XB=0.00, 0.05,-0.01, 0.01, 0.00, 0.05,

SAWTOOTH=.FALSE., COLOR=’GREEN’ /
&OBST XB=0.05, 0.10,-0.01, 0.01, 0.00, 0.10,
&OBST XB= 0.10, 0.15,-0.01, 0.01, 0.05, 0.15,
...
&OBST XB=0.00, 0.05,-0.01, 0.01, 0.05, 0.10,
SAWTOOTH=.TRUE., COLOR=’TEAL’ /
12.9. COLORING INDIVIDUAL OBJECTS 103
Figure 12.4: Flow velocity on two sides of an oblique wall. Lower side has
SAWTOOTH=.FALSE. set.
&OBST XB=0.05, 0.10,-0.01, 0.01, 0.10, 0.15,

&OBST XB=0.10, 0.15,-0.01, 0.01, 0.15, 0.20,
...
create a two sided oblique wall. The resulting flow is shown in Figure 12.4.
This is not a complete solution of the problem, but it does provide a simple
way of ensuring that the flow field around a non-rectangular obstruction is not
inhibited by extra drag created at sharp corners.
12.9 Coloring individual objects

Objects may be colored individually, overriding SURF prescription, by specifying
a COLOR or RGB value on the respective OBST or VENT line:
&OBST XB=..., SURF_ID=’carpet’, COLOR=’INDIGO’ /
This is not recommended. As explained in Section 11.3 on page 80, it is much

better to assign a color to each boundary condition.
12.10 Making burning solids disappear

If a burning object is to disappear from the calculation once it is consumed, set
BURN_AWAY=.TRUE. on the corresponding SURF line. The solid object disappears
from the calculation cell by cell, as the mass contained by each mesh cells is
consumed either by the pyrolysis reactions or by the prescribed HRR. The mass
of each mesh cell is the cell face area multiplied by the surface density of the
SURF type.
An example:
&SURF ID=’stuff’, MATL_ID(1:2,1)=’fabric’,’foam’,

THICKNESS(1:2)=0.01,0.1, BURN_AWAY=.TRUE. /
Keep in mind the following issues:
• For reacting surfaces, the surface density is computed as a sum of the layer
densities multiplied by the layer thicknesses. This value can be overridden
by setting SURFACE_DENSITY on the SURF line.
• For surfaces with prescribed HRRPUA, add SURFACE_DENSITY parameter as

this is the only way of defining the mass of the object.
• Use BURN_AWAY parameter cautiously. If an object has the potential of

burning away, a significant amount of extra memory has to be set aside to
store additional surface information as the rectangular block is eaten away.
• If BURN_AWAY is prescribed, the SURF should be applied to the entire object,

not just to a face of the object, because it would be unclear how to handle
edges of solid obstructions that have different SURF_IDs on different faces.
See [FDS5 user’s guide] for broader discussion on the topic.

Chapter 13
Devices and control logic
Fifth, some control logic and automation is introduced via PROP,

DEVC, CTRL namelist groups.
Devices can be used to control various actions, like creating and
removing obstructions, or activating and deactivating fans and vents.
13.1 Devices, DEVC and PROP

From the point of view of FDS, sprinklers, smoke detectors, heat flux gauges,
timers, thermocouples, etc., are devices that operate in specific ways depending
on the properties assigned to them.
All devices are designated via the DEVC namelist group. The various parameters
associated to devices can be grouped and entered in a PROP namelist group.
Each PROP line is identified by a unique ID, and it is invoked by the DEVC lines
that share the same properties. For example, these lines:
&PROP ID=’acme heat detector’, QUANTITY=’LINK TEMPERATURE’,

ACTIVATION_TEMPERATURE=74. /
&DEVC ID=’heat detector 1’, XYZ=22.88,19.76,7.46,
PROP_ID=’acme heat detector’ /
105
106 CHAPTER 13. DEVICES AND CONTROL LOGIC
define a group of heat detectors of the same model.

Every device has an associated QUANTITY. When the QUANTITY value passes
above, or below, a prescribed threshold the device is activated or deactivated,
and changes its state from .FALSE. to .TRUE. or the other way back.
The threshold can be as simple as a numeric SETPOINT or can be the result of an
activation algorithm. For example, an activation algorithm is used for sprinklers,
heat and smoke detectors. . .
The following table summarizes some DEVC parameters:
Table 13.1: DEVC parameters
QUANTITY String Name of quantity to output. See

Table 14.7 on page 125.
XB(6) Real Volume, face or segment of m

measurement
XYZ(3) Real Point of measurement m
IOR Integer Index of orientation
ORIENTATION(3) Real Direction vector 0,0,-1
PROP_ID String Associated PROP line
SETPOINT Real Value at which device changes state
TRIP_DIRECTION Integer Sign of derivative at first state 1

change
INITIAL_STATE Logical Initial state of device .FALSE.
LATCH Logical Device cannot change state multiple .TRUE.

times
See [FDS5 user’s guide] for a detailed description of PROP parameters.

13.2. EXAMPLES OF DEVICES 107
13.2 Examples of devices

In the following paragraphs some sample devices are listed.
13.2.1 Timer
The simplest example of device is just a timer:
&DEVC XYZ=1.2,3.4,5.6, ID=’my timer’,

QUANTITY=’TIME’, SETPOINT=30. /
It changes its state from .FALSE. to .TRUE. when the simulation time increases
past 30 s.
13.2.2 Thermometer
The following is a thermometer:
&DEVC XYZ=1.2,3.4,5.6, ID=’my thermometer’,

QUANTITY=’TEMPERATURE’, SETPOINT=60. /
It changes its state when the temperature at point (1.2, 3.4, 5.6) increases past
60°C.
13.2.3 Smoke detector

A smoke detector is defined in the input file with an entry similar to:
&PROP ID=’acme smoke detector’, QUANTITY=’CHAMBER OBSCURATION’,

LENGTH=1.8, ACTIVATION_OBSCURATION=3.28 /
&DEVC ID=’SD_29’, PROP_ID=’acme smoke detector’, XYZ=2.3,4.6,3.4 /
The SD_29 smoke detector has the following properties:

• LENGHT is the characteristic length for the single parameter Heskestad
model and defaults to 1.8 m.
• ACTIVATION_OBSCURATION threshold can be set according to the value
provided by the manufacturer. The default setting is 3.28%/m.
The smoke detector changes its state following the specific activation algorithm.
13.2.4 Beam smoke detector
A beam detector is defined by:
&PROP ID=’acme beam’, QUANTITY=’PATH OBSCURATION’,

SETPOINT=0.33 /
&DEVC ID=’B_4’, PROP_ID=’acme beam’,
XB=1.0,1.1,0.0,5.0,0.0,3.0 /
The B_4 beam detector has the following properties:
• SETPOINT is the total % obscuration at which the detector activates.
• XB specifies the segment covered by the beam. The two endpoints must
lie in the same mesh.
The beam detector changes its state following the specific activation algorithm.
13.2.5 Sprinkler and heat detector
Here is a very simple example of a sprinkler:
&PART ID=’water drops’, WATER=.TRUE. /

&PROP ID=’acme spk’, QUANTITY=’SPRINKLER LINK TEMPERATURE’,
RTI=148., ACTIVATION_TEMPERATURE=74.,
PART_ID=’water drops’, FLOW_RATE=189.3 /
&DEVC ID=’S_60’, XYZ=22.88,19.76,7.46, PROP_ID=’acme spk’ /
A sprinkler, known as S_60, is located at a point in space given by XYZ. It is an

acme spk type sprinkler, whose properties are given on the PROP line:
√
• RTI is the Response Time Index in units of m · s.
• ACTIVATION_TEMPERATURE is the link activation temperature in °C.
• FLOW_RATE is the flow rate of released water expressed in units of l/min.
• PART_ID refers the properties of the droplets water drops, defined by a

PART namelist group.
13.3. BASIC CONTROL LOGIC 109
This example defines a heat detector, which uses essentially the same activation
algorithm as a sprinkler, without the water spray:
&PROP ID=’acme heat’, QUANTITY=’LINK TEMPERATURE’, RTI=132.,

ACTIVATION_TEMPERATURE=74. /
&DEVC ID=’HD_66’, PROP_ID=’acme heat’, XYZ=2.3,4.6,3.4 /
13.3 Basic control logic

In many fire scenarios, the opening or closing of a door or window can lead to
dramatic changes in the course of the fire. Sometimes these actions are taken
intentionally, sometimes as a result of the fire. Within the framework of an FDS
calculation, these actions are represented by the creation or removal of solid
obstacles, or the opening or closing of vents.
The change of state of a device can be used to trigger an action to occur, like
activating and deactivating obstructions, boundary conditions and holes. For
example, devices change of state can create or remove obstructions, switch on
or off burners, ventilators and fans.
For example, in the lines:
&DEVC XYZ=1.2,3.4,5.6, ID=’my timer’, QUANTITY=’TIME’,

SETPOINT=30. /
&OBST XB=2.3,4.5,1.3,4.8,0.0,9.2, SURF_ID=’brick wall’,
DEVC_ID=’my timer’ /
the DEVC creates a timer named my timer. The OBST existence depends on
the DEVC, thanks to the DEVC_ID=’my timer’ parameter. When the simulation
starts the timer has a .FALSE. initial state, thus the OBST is not activated and
does not obstacle the flow domain. Then at 30 seconds the timer changes its
state to .TRUE., the OBST is activated and comes to life.
The following parameters dictate how a device will control something:
• SETPOINT is the value of the device at which its state changes. For a
detection type of device (heat or smoke detectors) this value is calculated
from the device’s activation algorithm and need not be specified on the
DEVC line.
• TRIP_DIRECTION, a positive integer means the device will change state

when its value increases past the SETPOINT and a negative integer means
the device will change state when its value decreases past the SETPOINT.
• LATCH, if this logical value is set to .TRUE. the device will only change
state once. Otherwise it can change its state several times.
• INITIAL_STATE, this logical value is the initial state of the device.
To remove and then re-create an obstruction in the same place, use two lines
since the code simply sees this as two different obstructions:
&DEVC XYZ=1.2,3.4,5.6, ID=’timer1’, QUANTITY=’TIME’,

SETPOINT=30., INITIAL_STATE=.TRUE. /
&DEVC XYZ=1.2,3.4,5.6, ID=’timer2’, QUANTITY=’TIME’,
SETPOINT=60., INITIAL_STATE=.FALSE. /
&OBST XB=2.3,4.5,1.3,4.8,0.0,9.2,
SURF_ID=’brick wall’, DEVC_ID=’timer1’ /
&OBST XB=2.3,4.5,1.3,4.8,0.0,9.2,
SURF_ID=’brick wall’, DEVC_ID=’timer2’ /
A last example:
&PROP ID=’acme heat’, QUANTITY=’LINK TEMPERATURE’,

RTI=132., ACTIVATION_TEMPERATURE=74. /
&DEVC ID=’HD_66’, PROP_ID=’acme heat’, XYZ=2.3,4.6,3.4 /
&HOLE XB=2.3,4.5,1.3,4.8,0.0,9.2, DEVC_ID=’HD_66’ /
the hole is created when the activation algorithm of the heat detector gives the
consensus. Note that a DEVC that is being used for a HOLE should not be used
for anything else other than additional HOLE lines.
When a HOLE is deactivated, the obstruction to be cut out can have a different
color and transparency than the original obstruction: just set the COLOR and a
TRANSPARENCY value on the HOLE line. When the HOLE becomes activated, the
void is created and the prescribed color disappears.
Also VENT activation can be controlled by DEVC state. For example, to control a
burner with the device my timer, do the following:
13.4. ADVANCED CONTROL LOGIC 111
&DEVC XYZ=1.2,3.4,5.6, ID=’my timer’,

QUANTITY=’TIME’, SETPOINT=30. /
&SURF ID=’burner’, HRRPUA=4000., TAU_Q=-120 /
&VENT XB=0.6,1.0,0.3,0.7,0.0,0.0,
SURF_ID=’burner’, DEVC_ID=’my timer’ /
Note that at 30 s, the VENT is activated and the burner boundary condition
turns on. The prescribed t2 ramp begins at 30 s and ends at 150 s, when HRRPUA
reaches its maximum of 4000 kW/m2 .
Note that a MIRROR or OPEN VENT should not be activated or deactivated. The
reason for this restriction is that abrupt changes in pressure can cause numerical
instabilities.
13.4 Advanced control logic

If you desire to control FDS objects using more complex logic than can be pro-
vided by the use of a single device and its SETPOINT, control functions can be
specified using the CTRL namelist group.
A control function take as input the outputs of one or more devices and control
functions. In this manner, complicated behaviors can be simulated by making
functions of other functions. For most of the control function types, the logical
value output of the devices and control functions and the time they last changed
state are used as the inputs.
For any object that a DEVC_ID can be specified for (such as OBST or VENT), a
CTRL_ID can be specified instead.
See [FDS5 user’s guide] for broader discussion of the topic.
Chapter 14
Output
Finally, the user prescribes the output quantities (DEVC, SLCF, BNDF,
ISOF).
All output quantities must be specified at the start of the calcula-
tion. In most cases, there is no way to retrieve information after the
calculation ends if it was not specified from the start.
14.1 Prescribing output

FDS computes the temperature, density, pressure, velocity and chemical com-
position within each numerical grid cell at each discrete time step. There are
typically hundreds of thousands to millions of grid cells and thousands to hun-
dreds of thousands of time steps. In addition, FDS computes at solid surfaces
the temperature, heat flux, mass loss rate, and various other quantities.
So the user must carefully select what data to save, much like one would do
in designing an actual experiment. Even though only a small fraction of the
computed information can be saved, the output typically consists of fairly large
data files (it can be many GBytes!).
Remember that all output quantities must be specified at the start of the calcu-
lation. Before a calculation is started, carefully consider what information should
be saved.
Typical output quantities for the gas phase include:
• Gas temperature;
• Gas velocity;
113
114 CHAPTER 14. OUTPUT
• Gas species concentration (water vapor, CO2 , CO, N2 );
• Smoke concentration and visibility estimates;
• Pressure;
• Heat release rate per unit volume;
• Mixture fraction (or air/fuel ratio);
• Gas density;
• Water droplet mass per unit volume.
On solid surfaces, FDS predicts additional quantities associated with the energy
balance between gas and solid phase, including:
• Surface and interior temperature;
• Heat flux, both radiative and convective;
• Burning rate;
• Water droplet mass per unit area.
Global quantities recorded by the program include:
• Total Heat Release Rate (HRR);
• Sprinkler and detector activation times;
• Mass and energy fluxes through openings or solids.
Time histories of various quantities at a single point in space or global quantities

like the fire’s heat release rate (HRR) are saved in simple, comma-delimited text
files that can be plotted using a spreadsheet program, like Openoffice.org Calc
or Microsoft Excel.
Most field or surface data are visualized with Smokeview. FDS and Smokeview
are used in concert to model and visualize fire phenomena. Smokeview performs
this visualization by presenting animated tracer particle flow, animated contour
slices of computed gas variables and animated surface data. Smokeview also
presents contours and vector plots of static data anywhere within a scene at a
fixed time.
14.3. POINT MEASUREMENT DEVICES, DEVC 115
14.2 Output control parameters, DUMP

The namelist group DUMP contains parameters that control the rate at which
output files are written, and various other global parameters associated with
output files.
For example, NFRAMES parameter is the number of output dumps per calculation.
The default is 1000. Device data, slice data, particle data, isosurface data, 3D
smoke data, boundary data, solid phase profile data, and control function data are
saved every (T_END - T_BEGIN) / NFRAMES seconds unless otherwise specified.
The following table summarizes some DUMP parameters:
Table 14.1: DUMP parameters
NFRAMES Integer Number of output dumps per 1000

calculation
14.3 Point measurement devices, DEVC

The same devices DEVC used for control logic (see Chapter 13 on page 105)
are employed to save a given quantity at a single point in space so that this
quantity can be plotted as a function of time, like for example a thermocouple
temperature measurement.
The prescribed QUANTITY is recorded as a column in an output file named
mycase_devc.csv. This type of file can be imported into any spreadsheet pro-
gram.
An example:
Table 14.2: Output of devices in mycase_devc.csv file
s °C °C
FDS Time TC_A01 TC_A02
0.00E+000 2.00E+001 2.00E+001

from previous page

5.00E+000 2.98E+001 2.77E+001
1.00E+001 2.35E+001 2.26E+001
14.3.1 Record a gas phase quantity
For example, if you just want to record the time history of the temperature at a
given point, add:
&DEVC XYZ=6.7,2.9,2.1, QUANTITY=’TEMPERATURE’, ID=’T-1’ /
and a column will be added to the output file mycase_devc.csv under the label
T-1.
FDS reports the value of the QUANTITY calculated in the cell where the point
XYZ is located.
14.3.2 Record a solid phase quantity
When prescribing a solid phase quantity, be sure to position the probe at a solid
surface. It is not always obvious where the solid surface is since the mesh does
not always align with the input obstruction locations.
To help FDS locate the appropriate surface, suggest the right orientation of the
face using the parameter IOR (index of orientation).
There are still instances where FDS cannot determine which solid surface is being
designated, in which case an error message appears in the diagnostic output file.
Re-position the probe and try again. For example, the line
&DEVC XYZ=0.7,0.9,2.1, QUANTITY=’WALL TEMPERATURE’,

IOR=-2, ID=’wt1’ /
designates the surface temperature of a wall facing the negative y direction.

14.4. ANIMATED PLANAR SLICES, SLCF 117
Figure 14.1: Output of animated planar slices SLCF as viewed in Smokeview
14.3.3 Record integrated quantities

In addition to point measurements, the DEVC group can be used to report inte-
grated quantities. For example, you may want to know the mass flow out of a
door or window. To report this, add the line:
&DEVC XB=0.3,0.5,2.1,2.5,3.0,3.0,
QUANTITY=’MASS FLOW’, ID=’mf1’ /
Note that in this case, a face is specified rather than a point.

QUANTITY=’HRR’ can be used to compute the total heat release rate within a
subset of the domain. In this case, the sextuplet XB ought to define a volume
rather than a face.
Remember to avoid faces or volumes that cross multiple mesh boundaries: FDS
has to decide which mesh to use in the integration.
14.4 Animated planar slices, SLCF

The SLCF namelist group parameters allows you to record various gas phase
quantities at more than a single point. A slice refers to a subset of the whole
domain. It can be a line, face, or volume, depending on the values of XB.
Animated vectors can be created in Smokeview if a given SLCF line has the
attribute VECTOR=.TRUE. If two SLCF entries are in the same plane, then only
one of the lines needs to have VECTOR=.TRUE. Otherwise, a redundant set of
velocity component slices will be created.
&SLCF PBX=0.8, QUANTITY=’TEMPERATURE’, VECTOR=.TRUE. /
records the temperature and animated velocity vectors on the plane x = 0.8
The following table summarizes some SLCF parameters:
Table 14.3: SLCF parameters

VECTOR Logical Include flow vectors .FALSE.
XB(6) Real Face m
PBX, PBY, PBZ Real Plane m
14.5 Animated boundary quantities, BNDF

The BNDF namelist group parameters allows you to record surface quantities at
all solid obstructions. As with the SLCF group, each quantity is prescribed with
a separate BNDF line. No physical coordinates need be specified, however, just
QUANTITY.
&BNDF QUANTITY=’WALL_TEMPERATURE’ /
records WALL_TEMPERATURE for all solid obstructions faces.

For certain output quantities, additional parameters need to be specified via the
PROP namelist group. In such cases, add the character string, PROP_ID, to the
BNDF line to tell FDS where to find the necessary extra information.
Note that BNDF files can become very large, so be careful in prescribing the time
interval.
One way to reduce the size of the output file is to turn off the recording
of boundary information on desired obstructions. On any given OBST line,
14.5. ANIMATED BOUNDARY QUANTITIES, BNDF 119
Figure 14.2: Output of animated boundary quantities, BNDF as viewed in Smoke-

view
if the string BNDF_OBST=.FALSE. is included, the obstruction is not consid-

ered for boundary quantities output. To turn off all boundary recording, set
BNDF_DEFAULT=.FALSE. on the MISC line. Then individual obstructions can be
turned back on with BNDF_OBST=.TRUE. on the appropriate OBST line. Individ-
ual faces of a given obstruction can be controlled via BNDF_FACE(IOR)=.TRUE.,
where IOR is the index of orientation.
The following table summarizes some BNDF parameters:
Table 14.4: BNDF parameters

Figure 14.3: Output of animated isosurfaces, ISOF as viewed in Smokeview
14.6 Animated isosurfaces, ISOF

The ISOF namelist group is used to specify the output of gas phase scalar quanti-
ties, as three dimensional animated contours. For example, a 300°C temperature
isosurface shows where the gas temperature is 300°C. Three different values of
the temperature can be saved via the line:
&ISOF QUANTITY=’TEMPERATURE’,
VALUE(1)=50., VALUE(2)=200., VALUE(3)=500. /
where the values are in °C.

Any gas phase quantity can animated via isosurfaces, but use caution. To render
an isosurface, the desired quantity must be computed in every mesh cell at every
output time step. For quantities like TEMPERATURE, this is not a problem, as
FDS computes it and saves it anyway. However, soot density or oxygen demand
substantial amounts of time to compute at each mesh cell.
The following table summarizes some ISOF parameters:
14.7. REALISTIC SMOKE AND FIRE 121
Table 14.5: ISOF parameters

VALUE(3) Real Contour values
14.7 Realistic smoke and fire
When you do a fire simulation using the default mixture fraction combustion
model, FDS automatically creates two output files that are rendered by Smoke-
view as realistic looking smoke and fire.
Figure 14.4: Output of soot MASS FRACTION and HRRPUV as viewed in Smoke-
view
By default, the output quantities MASS FRACTION of soot and HRRPUV (heat
release rate per unit volume) are used in the visualization.
14.8 Heat release rate

Quantities associated with the overall energy budget are reported in the comma
delimited file mycase_hrr.csv. This file is automatically generated.
The file consists of six columns. The first column contains the time in seconds.
The second through fifth columns contain integrated energy gains and losses, all
in units of kW. The second column contains the total heat release rate, the third
contains the radiative heat loss to all the boundaries (solid and open), the fourth
contains the convective and radiative heat loss to the boundaries (i.e. the energy
flowing out of or into the domain), and the fifth contains the energy conducted
into the solid surfaces. The sixth column contains the total burning rate of fuel,
in units of kg/s. It is included merely as a check of the total heat release rate.
An example:
Table 14.6: Output of HRR in mycase_hrr.csv file
s kW
FDS_HRR_Time HRR
0.00E+000 0.00E+000
5.00E+000 2.04E+002
1.00E+001 2.16E+002
14.9 Visibility
If you are performing a fire calculation using the mixture fraction approach, the
smoke is tracked along with all other major products of combustion.
The intensity of monochromatic light I passing a distance L through smoke is
attenuated according to:
I/I0 = e−KL (14.1)
The light extinction coefficient K, is a product of the density of smoke particulate,

ρYS , and a mass specific extinction coefficient Km that is fuel dependent:
K = Km ρYS (14.2)
14.10. UPPER AND LOWER LAYERS 123
As showed by [Mulholland 2002], an estimate of visibility through smoke can be

made by using the equation:
S = C/K (14.3)
where C is a non-dimensional constant characteristic of the type of object being

viewed through the smoke.
Since K varies from point to point in the domain, as it depends on smoke density,
the visibility S does as well.
Keep in mind that FDS can only track smoke whose production rate and com-
position are specified. Predicting either is beyond the capability of the present
version of the model. Three parameter control smoke production and visibility;
each parameter is input on the REAC line:
• SOOT_YIELD is the fraction of fuel mass that is converted to soot.
• MASS_EXTINCTION_COEFFICIENT, the Km of Equation 14.2 on the preced-

ing page. The default value is 8700 m2 /kg, a value suggested for flaming
combustion of wood and plastics.
• VISIBILITY_FACTOR, the C of Equation 14.3. C = 8 for a light-emitting

sign and C = 3 for a light-reflecting sign. C is 3 by default.
The visibility S is output via the QUANTITY keyword VISIBILITY.
14.10 Upper and lower layers

Fire protection engineers often need to estimate the location of the interface
between the hot, smoke-laden upper layer and the cooler lower layer in a burn-
ing compartment. Relatively simple fire models, often referred to as two-zone
models, compute this quantity directly, along with the average temperature of
the upper and lower layers. In a computational fluid dynamics (CFD) model
like FDS, there are not two distinct zones, but rather a continuous profile of
temperature. Nevertheless, there are methods that have been developed to es-
timate layer height and average temperatures from a continuous vertical profile
of temperature.
The quantities LAYER HEIGHT, UPPER TEMPERATURE and LOWER TEMPERATURE
can be designated via DEVC lines in the input file. For example, the entry:
&DEVC XB=2.0,2.0,3.0,3.0,0.0,3.0,
QUANTITY=’LAYER HEIGHT’, ID=’whatever’ /
produces a time history of the smoke layer height at x = 2 and y = 3 between

z = 0 and z = 3. If multiple meshes are being used, the vertical path cannot
cross mesh boundaries.
14.11 Heat fluxes and thermal radiation

There are various ways of recording the heat flux at a solid boundary. If you
want to record the net heat flux to the surface, qconvective + qradiative , use the
QUANTITY=’HEAT FLUX’. The individual components, the net convective and
radiative fluxes, are CONVECTIVE HEAT FLUX and RADIATIVE HEAT FLUX, re-
spectively.
If you want to compare predicted heat flux with a measurement, you often need
to use GAUGE HEAT FLUX. The difference between NET HEAT FLUX and GAUGE
HEAT FLUX is that the former is the rate at which energy is absorbed by the solid
surface; the latter is the amount of energy that would be absorbed if the surface
were cold or some temperature specified with GAUGE_TEMPERATURE.
All of the above heat flux output quantities are defined at a solid surface.
14.12 Interfacing with structural models

FDS solves a one-dimensional heat conduction equation for each boundary cell
marking the interface between gas and solid, assuming that material properties for
the material layers are provided. The results can be transferred (via either DEVC or
BNDF output) to other models that predict the mechanical response of the walls
or structure. For many applications, the one-dimensional solution of the heat
conduction equation is adequate, but in situations where lateral heat conduction
within the solid is significant, another approach can be followed. FDS includes
a calculation of the Adiabatic Surface Temperature (AST), a quantity that is
representative of the heat flux to a solid surface, following the idea proposed by
[Wickstrom 2007].
Obviously, the objective in passing information to a more detailed model is to
get a better prediction of the solid temperature (and ultimately its mechanical
response) than FDS can provide.
14.13. VISUALIZING LAGRANGIAN PARTICLES 125
14.13 Visualizing Lagrangian particles

Tracer particles can be injected into the flow field from vents or obstacles, as
shown in Section 11.8 on page 91, and then observed in Smokeview. Streak lines
can be drawn, too.
14.14 Frequently used output quantities

The following table shows an organized list of frequently used output quantities.
The column “Namelist” details where the concerned QUANTITY can be specified:
B boundary file (BNDF), D device (DEVC), I isosurface file (ISOF), S slice file
(SLCF).
Table 14.7: Frequently used output quantities
QUANTITY Description Unit Namelist
NET HEAT FLUX Sum of radiative heat flux and kW/m2 B,D
convective heat flux at a solid
boundary
RADIATIVE HEAT FLUX Radiative heat flux at a solid kW/m2 B,D

boundary
CONVECTIVE HEAT FLUX Convective heat flux at a solid kW/m2 B,D

boundary
MASS FLUX∗ Mass flux at solid surface of the kg/m2 /s B,D

specified specie
MASS FRACTION∗ Mass fraction of the specified specie kg/kg D,I,S
VOLUME FRACTION∗ Volume fraction for the specified mol/mol D,I,S

specie
LAYER HEIGHT Estimate height of the interface m D

between the hot, smoke-laden upper
layer and the cooler lower layer in a
burning compartment
UPPER TEMPERATURE Upper layer temperature °C D
LOWER TEMPERATURE Lower layer temperature °C D

from previous page

MASS FLOW Calculate integrated mass flow kg/s D
through a given planar area.
HEAT FLOW Calculate integrated heat flow kJ/s D

VOLUME FLOW Calculate integrated volume flow m3 /s D

VISIBILITY Visibility length through smoke m D,I,S
SOOT VOLUME FRACTION Soot volume fraction mol/mol D,I,S
FED Fractional effective dose based on D

CO, CO2 , and O2 as proposed by
[Purser 2002]
TEMPERATURE Gas temperature. °C D,I,S
THERMOCOUPLE Temperature of a simulated °C D

thermocouple, usually close to the
gas temperature.
WALL TEMPERATURE Solid interface temperature. °C B,D
ADIABATIC SURFACE TEMPERATURE See Section 14.12 on page 124. °C B,D
VELOCITY Gas phase velocity. m/s D,I,S
NORMAL VELOCITY Gas phase wall normal velocity. m/s D,B
WALL CLOCK TIME Elapsed wall clock time s D

∗
These quantities require the specification of a gas specie using SPEC_ID.
Here are some examples of output quantities:

&DEVC XYZ=0.1,0,2.39, QUANTITY=’THERMOCOUPLE’,
ID=’2.4’ /
&DEVC XB=0.1,0.1,0,0,0.0,2.4,
QUANTITY=’LAYER HEIGHT’, ID=’layer_h’ /
&SLCF PBY= -3., QUANTITY=’TEMPERATURE’,
VECTOR=.TRUE. /
&BNDF QUANTITY=’ADIABATIC SURFACE TEMPERATURE’ /
There are some output quantities that require a specie name via SPEC_ID, as
for example the MASS FRACTION quantity. The SPEC_ID can select one of
14.14. FREQUENTLY USED OUTPUT QUANTITIES 127
the species implicitly defined when doing a mixture fraction calculation (fuel,
oxygen, nitrogen, water vapor, carbon dioxide, carbon monoxide, hydrogen,
soot, other), or an extra gas specie from those defined via a SPEC line:
&SLCF PBX= 0.1, QUANTITY=’VOLUME FRACTION’,

SPEC_ID=’carbon dioxide’ /
volume fraction of carbon dioxide
issued from mixture fraction model
gas phase combustion model

SPEC_ID=’CARBON DIOXIDE’ /
volume fraction of carbon dioxide
defined in a SPEC namelist group
and injected separately in the flow domain
Chapter 15
Using BlenderFDS
This chapter introduces the powerful BlenderFDS, the open source

graphical interface for FDS.
15.1 A faster way to writing input files
Have you ever passed long hours calculating and typing geometric coordinates of
FDS objects by hand? That is a really slow, tedious and error prone procedure.
BlenderFDS is the open source graphical interface for FDS that assists the user
during the input file preparation. BlenderFDS tool tries to be as flexible as
possible, and is intended for those users that already have a basic knowledge on
how FDS works, because it does not check the syntax of the data you enter.
The user retains full control over the FDS input file
Geometry and thermophysical properties are modeled in a graphical environment.

Pre-existing 2D and 3D data of buildings can be imported from many CAD tools.
BlenderFDS effort is completely unrelated and independent from FDS develop-

ment performed at NIST and other organizations. None of these organizations
finance, support, endorse, or otherwise recommend BlenderFDS.
129
130 CHAPTER 15. USING BLENDERFDS
Figure 15.1: A BlenderFDS session
BlenderFDS is free and open source. Developed in Python, BlenderFDS is avail-

able on Linux, MS Windows, MacOS X platforms.
BlenderFDS is based on Blender (http://www.blender.org), an open source 3D
content creation suite. Blender is a complex platform: as with all 3D packages,
the learning curve is steep and the average user needs some time to become
productive. You do not need to be a Blender power user to use BlenderFDS, but
it is much better if you are already familiar with its particular interface and able
to build simple architectural models.
BlenderFDS is currently based on Blender 2.5x series. Blender 2.5x was chosen
because it dramatically improves the user and developer experience over Blender
2.4x series. Blender 2.5x is quite stable now, but its developers state that it is
alpha quality software and the documentation is still scarce. An officially stable
version is expected around the end of 2010.
15.2 From the Community, to the Community

The first version of BlenderFDS was publicly released in May 2010.
BlenderFDS development was started by Emanuele Gissi on September 2009.
A blueprint was written and shared with the FDS and Blender worldwide com-
munities. Many users from both communities, and from several universities of-
fered their help and now contribute to the effort: Kristopher Overholt, Johannes
Dimyadi, Roberto Bartola, Nicola De Santis, Fabrizio Valpreda, Gianluca Faletti,
Roberto Orvieto.
15.3. ONLINE RESOURCES 131
BlenderFDS development is public and open. If you wish to become a contributor,

please contact us for inclusion. Don’t be afraid, there is plenty of work available
for non-developers, too: documentation, support, translation...
BlenderFDS is provided as it is, and support is community-based. If you need
commercial grade support, please refer to good commercial alternatives, as Py-
rosim (http://www.thunderheadeng.com/pyrosim/).
Figure 15.2: A BlenderFDS property panel
15.3 Online resources

BlenderFDS development is web based. You can browse to its main site is at the
following address:
• http://www.blenderfds.org/
The whole user and technical documentation is updated very often and is main-
tained as wiki pages at:
• http://code.google.com/p/blenderfds/wiki/Home?tm=6
Install instructions are explained at:
• http://code.google.com/p/blenderfds/wiki/InstallingBlenderFDS
132 CHAPTER 15. USING BLENDERFDS
There is an active discussion group, where project members offer support to new
users on a voluntary basis:
• http://groups.google.com/group/blenderfds
Every users can speed up the development by reporting BlenderFDS issues at:
• http://code.google.com/p/blenderfds/issues/list
Figure 15.3: Exporting a BlenderFDS model to an FDS input file

Chapter 16
Real world examples
This chapter shows some real world examples.
16.1 Building a ventilator

If you just want to blow gases in a particular direction, create a thin (zero
cells thick) OBST and apply to it, via SURF_ID only, a SURF line that has the
parameter POROUS=.TRUE. along with the other velocity parameters described
above. This allows hot, smokey gases to pass through the obstruction, much like
a free-standing fan. These obstructions are merely flat plates, by necessity. For
example:
&SURF ID=’blow’, POROUS=.TRUE., VEL=5.0 /

pushes towards +x direction
&OBST XB=4.0,5.0,-0.2,-0.2,1.4,1.8 /
The velocity VEL associated with a POROUS surface represents the velocity in the
positive or negative coordinate direction, as indicated by its sign. Sign convention
16.2 Prescribing a simplified burning material

Real objects are often difficult to describe via the SURF and MATL parameters. So
simplified descriptions of burning solid fuels are possible. If ignition temperature
and burning rate as a function of time from ignition are known, add lines similar
to the following:
133
134 CHAPTER 16. REAL WORLD EXAMPLES
&MATL ID=’stuff’, CONDUCTIVITY=0.1,

SPECIFIC_HEAT=1.0, DENSITY=900.0 /
&SURF ID=’my_surf’, MATL_ID=’stuff’, HRRPUA=1000.,
IGNITION_TEMPERATURE=500., HEAT_OF_VAPORIZATION=1000.,
RAMP_Q=’fire_ramp’, THICKNESS=0.01 /
&VENT XB=0.6,1.0,0.3,0.7,0.0,0.0, SURF_ID=’my_surf’ /
&RAMP ID=’fire_ramp’, T=0.0, F=0.0 /
&RAMP ID=’fire_ramp’, T=10.0, F=1.0 /
• IGNITION_TEMPERATURE delays the emission of fuel gas until the specified

temperature is reached: when the surface temperature reaches 500°C, the
object starts emitting fuel gas.
• HEAT_OF_VAPORIZATION tells FDS to account for the energy used to va-

porize the fuel; in the example, the net heat flux at the material surface is
reduced by a factor 1000 kJ/kg times the instantaneous burning rate.
If a MATL line is invoked by a SURF line containing a specified HRRPUA, then that
MATL ought to have only thermal properties and no reaction parameters, product
yields. . .
By specifying HRRPUA, you are controlling the burning rate rather than letting
the material pyrolyze based on the conditions of the surrounding environment.
16.3 Simulation and revelation of smoke of a

smoldering fire
By default, FDS assumes that the smoke from a fire is generated in direct pro-
portion to the heat release rate. A value of SOOT_YIELD=0.01 on the REAC
line means that the smoke generation rate is 1% of the fuel burning rate. The
smoke in this case is not explicitly tracked by FDS, but rather is assumed to be
a function of the mixture fraction variables that are explicitly tracked.
Suppose, however, that you want to define your own smoke and that you want
to specify its production rate independently of the HRR (or even instead of an
actual fire, like a smoldering source). You also want to define a mass extinction
coefficient for the smoke and an assumed molecular weight (as it will be tracked
like a gas specie). Finally, you also want to visualize the smoke using the SMOKE3D
feature in Smokeview.
Use the following lines:
16.4. A PAN FILLED OF ETHANOL 135
&SPEC ID=’my smoke’, MW=29.,

MASS_EXTINCTION_COEFFICIENT=8700. /
&SURF ID=’smolder’, TMP_FRONT=1000., MASS_FLUX(1)=0.0001,
COLOR=’RED’ /
&VENT XB=0.6,1.0,0.3,0.7,0.0,0.0, SURF_ID=’smolder’ /
&PROP ID=’Acme Smoke’, QUANTITY=’CHAMBER OBSCURATION’,
SPEC_ID=’my smoke’ /
&DEVC XYZ=1.00,0.50,0.95, PROP_ID=’Acme Smoke’, ID=’smoke_1’ /
&DUMP SMOKE3D_QUANTITY=’my smoke’, DT_PL3D=30. /
16.4 A pan filled of ethanol

Here is an example of a steel pan filled with a thin layer of ethanol:
&MATL ID=’ethanol’, EMISSIVITY=1.0, NU_FUEL=0.97,

HEAT_OF_REACTION=880.,
CONDUCTIVITY=0.17, SPECIFIC_HEAT=2.45, DENSITY=787.,
ABSORPTION_COEFFICIENT=40., BOILING_TEMPERATURE=76. /
&MATL ID=’steel’, EMISSIVITY=.95, DENSITY=7850.,
&MATL ID=’concrete’, DENSITY=2200.,
&SURF ID=’pool’, MATL_ID=’ethanol’,’steel’,’concrete’,
THICKNESS=0.01,0.001,0.05 /
&VENT XB=0.,1.,0.,1.,0.,0., SURF_ID=’pool’ /
16.5 A simple car parking
16.5.1 Description
In Figure 16.1 on the next page a simple case of a fire in a car parking is proposed.
The data are for demonstration only, and the proposed solution is only one of
the many possible solutions.
The objectives of the analysis are:
• Study the critical times for evacuation and rescue operations from fire
brigade of the car parking.
Figure 16.1: Car parking plan

16.5. A SIMPLE CAR PARKING 137
• Obtain adiabatic surface temperature to predict the mechanical response

of the structure.
The following input file is called car_parking.fds, and it is deeply commented.
16.5.2 Input file and results

&HEAD CHID=’car_parking’,
TITLE=’Covered car parking (10 cars)’ /
Name of the case and a brief explanation.
&TIME T_END=3600.0 /
The simulation ends at 3600 seconds.
&MISC SURF_DEFAULT=’wall’, CO_PRODUCTION=.TRUE. /
All bounding surfaces have a ’wall’ boundary condition
unless otherwise specified.
Calculation of formation and destruction of CO at elevated
temperatures activated.
C=1.0, H=1.75, O=0.25, N=0.065,
Gas phase reaction: polyurethane flexible foam (means) from
Tewarson SFPE Handbook 3rd ed,
&MESH IJK=32,30,10, XB= 0.0, 8.5, 0.5, 8.5, 0.0,2.4 /

&MESH IJK=32,30,10, XB=-8.5, 0.0, 0.5, 8.5, 0.0,2.4 /
&MESH IJK=32,30,10, XB= 0.0, 8.5,-7.5, 0.5, 0.0,2.4 /
&MESH IJK=32,30,10, XB=-8.5, 0.0,-7.5, 0.5, 0.0,2.4 /
Four connected calculation meshes and their cells numbers,
total 38400 cells.
!!! Properties
! Walls
&MATL ID=’gypsum plaster’, CONDUCTIVITY=0.48,
Thermo-physical properties of gypsum plaster.
&SURF ID=’wall’, COLOR=’BRICK’, MATL_ID=’gypsum plaster’,
THICKNESS=0.03 /
Type of boundary condition for walls.
! Cars
Burning surface of the car: (4 + 2 + 4 + 2) * 1.3 + 4 * 2 = 23.6 m2
HRR max for a car: 5000 kW, HRR ramps up in 600 s
HRRPUA: 5000 / 23.6 = 211.86 kW/m2 (approx: whole car burns)
&SURF ID=’first_car’, HRRPUA=211.86, TAU_Q=-600, COLOR=’FLESH’ /
Type of boundary conditions for the first burning car, a burner.
&MATL ID=’car_mat’, CONDUCTIVITY=54.0,
SPECIFIC_HEAT=0.465, DENSITY=7850.0 /
Properties for steel taken from NUREG-1805 pg. 2-11
&SURF ID=’car’, MATL_ID=’car_mat’, HRRPUA=211.86, TAU_Q=-600,
IGNITION_TEMPERATURE=250., THICKNESS=0.005,
BACKING=’INSULATED’, COLOR=’DARK OLIVE GREEN 1’ /
Type of boundary conditions for other cars.
!!! Solid geometry
&OBST XB= 7.5 , 7.75,-7.5, 7.5 ,0.0, 2.4 / E wall

&OBST XB= -7.5 ,-7.75,-7.5, 7.5 ,0.0, 2.4 / W wall
&OBST XB= -7.75, 7.75, 7.5, 7.75,0.0, 2.4 / N wall
&HOLE XB= -1.5 , 1.5 , 7.0, 8.0 ,0.0, 2.0 / N entrance
The entrance is open since the beginning.
&HOLE XB= 7.0 , 8.0 , 2.0, 7.0 ,2.0, 2.2, COLOR=’PALE GREEN’,
DEVC_ID=’NE_broke’, TRANSPARENCY=.6 / NE window
&HOLE XB= -7.0 ,-8.0 , 2.0, 7.0 ,2.0, 2.2, COLOR=’PALE GREEN’,
DEVC_ID=’NW_broke’, TRANSPARENCY=.6 / NW window
&HOLE XB= 7.0 , 8.0 ,-2.0,-7.0 ,2.0, 2.2, COLOR=’PALE GREEN’,
DEVC_ID=’SE_broke’, TRANSPARENCY=.6 / SE window
&HOLE XB= -7.0 ,-8.0 ,-2.0,-7.0 ,2.0, 2.2, COLOR=’PALE GREEN’,
DEVC_ID=’SW_broke’, TRANSPARENCY=.6 / SW window
Window panes are broken by temperature.
&VENT XB= -7.5 , 7.5 ,-7.5, 7.5 ,2.4, 2.4, SURF_ID=’wall’ / soffit
&VENT PBX= 8.5 , SURF_ID=’OPEN’ / E opening
&VENT PBX=-8.5 , SURF_ID=’OPEN’ / W opening
&VENT PBY= 8.5 , SURF_ID=’OPEN’ / N opening
&VENT PBZ= 2.4 , SURF_ID=’OPEN’ / top opening
Domain borders are open.
&OBST XB= 3.0 , 7.0 , 5.0, 7.0 ,0.2, 1.5, SURF_ID=’car’ / +E2 car
&OBST XB= 3.0 , 7.0 , 2.0, 4.0 ,0.2, 1.5, SURF_ID=’car’ / +E1 car
&OBST XB= 3.0 , 7.0 , -1.6, 0.4 ,0.2, 1.5, SURF_ID=’car’ / E0 car,
Asymmetric parking
&OBST XB= 3.0 , 7.0 , -2.0,-4.0 ,0.2, 1.5,

SURF_IDS=’first_car’,’first_car’,’car’ / -E1 car
&OBST XB= 3.0 , 7.0 , -5.0,-7.0 ,0.2, 1.5, SURF_ID=’car’ / -E2 car
&OBST XB=-3.0 ,-7.0 , 5.0, 7.0 ,0.2, 1.5, SURF_ID=’car’ / +W2 car
&OBST XB=-3.0 ,-7.0 , 2.0, 4.0 ,0.2, 1.5, SURF_ID=’car’ / +W1 car
&OBST XB=-3.0 ,-7.0 , -1.0, 1.0 ,0.2, 1.5, SURF_ID=’car’ / W0 car
&OBST XB=-3.0 ,-7.0 , -2.0,-4.0 ,0.2, 1.5, SURF_ID=’car’ / -W1 car
&OBST XB=-3.0 ,-7.0 , -5.0,-7.0 ,0.2, 1.5, SURF_ID=’car’ / -W2 car
!!! Control logic
&DEVC ID=’NE_broke’, XYZ= 7.0, 4.5, 2.1,

&DEVC ID=’NW_broke’, XYZ=-7.0, 4.5, 2.1,
&DEVC ID=’SE_broke’, XYZ= 7.0,-4.5, 2.1,
&DEVC ID=’SW_broke’, XYZ=-7.0,-4.5, 2.1,
These devices effectively break window panes at 300°C.
!!! Output
&DEVC XYZ=0.1,0,2.39, QUANTITY=’THERMOCOUPLE’, ID=’2.4’ /

&DEVC XYZ=0.1,0,2.0 , QUANTITY=’THERMOCOUPLE’, ID=’2.0’ /
&DEVC XYZ=0.1,0, .8 , QUANTITY=’THERMOCOUPLE’, ID=’0.8’ /
&DEVC XYZ=0.1,0, .4 , QUANTITY=’THERMOCOUPLE’, ID=’0.4’ /
Thermocouples.
&DEVC XYZ=0.1,0,2.0 , QUANTITY=’FED’, ID=’FED’ /
FED calculation.
&DEVC XB=0.1,0.1,0,0,0.0,2.4,
QUANTITY=’LAYER HEIGHT’, ID=’layer_h’ /
Layer height calculation.
3D contours of temperature at 60°C.
&ISOF QUANTITY=’VISIBILITY’, VALUE(1)=10.0 /
3D contours of VISIBILITY 10 m.
&SLCF PBX= 0.1, QUANTITY=’TEMPERATURE’, VECTOR=.TRUE. /
&SLCF PBY= -3., QUANTITY=’TEMPERATURE’, VECTOR=.TRUE. /
Vector slices colored by temperature.
&SLCF PBX= 0.1, QUANTITY=’VISIBILITY’ /
&SLCF PBZ= 2.0, QUANTITY=’VISIBILITY’ /

Visibility slices.
SPEC_ID=’carbon monoxide’ /
SPEC_ID=’carbon dioxide’ /
SPEC_ID=’oxygen’ /
species slices.
&BNDF QUANTITY=’WALL TEMPERATURE’ /
&BNDF QUANTITY=’NET HEAT FLUX’ /
Quantities at all solid obstructions.
&TAIL / end of file

Figure 16.2: The entered geometry
Figure 16.3: Heat release rate curve

Figure 16.4: Temperatures measured by the thermocouples at the center of the

car parking area. The effect on temperatures of the glazing breaking is noticeable.
Figure 16.5: Gas temperatures measured in front of the window panes vs time.
It is prescribed that the glazing breaks effectively at 300°C. The SE glass is the
nearest to the fire and breaks at about 370 s; the NE glass breaks at about 612 s.
The others follow later.
Figure 16.6: FED vs time is shown here. At FED=.3 an occupant standing at

the center of the car parking is incapacitated by toxic gases.
Figure 16.7: Layer height vs time is shown. The smoke evacuation is not enough
to keep the smoke layer near the ceiling.
Figure 16.8: AST (Adiabatic Surface Temperature) boundary file at 1200 s.
Figure 16.9: Visibility slice file at 120 s.

Figure 16.10: Visibility (10 m) isosurface at 300 s.
Figure 16.11: Net heat flux on boundary surfaces at 1200 s.

16.6 An university building

A more complex example is included within BlenderFDS distribution.
A three-floors university building is modeled. A 1500 kW fast fire is positioned
at ground floor near the main entrance. The calculation domain is divided into
three MESHs for parallel calculation. Round geometries are exported to FDS
notation.
Figure 16.12: The university building as modeled in BlenderFDS
Figure 16.13: The exported FDS input file, as shown by Smokeview
The following text is the first part of the generated FDS input file:
! Generated by BlenderFDS (Version: 0.44 2010/05/05)

! Fri, 28 May 2010 09:22:16
16.6. AN UNIVERSITY BUILDING 147
! Voxel Size: 0.125, 0.124, 0.120

&HEAD CHID=’uni-build-s1’,
TITLE=’University building, scenario 1’ /
! Start of header file

&TIME T_END=900.0 /
&REAC ID=’polyurethane’, SOOT_YIELD=0.1875,
CO_YIELD=0.02775, C=1.0, H=1.75, O=0.25, N=0.065,
&MATL ID=’Gypsum plaster’, CONDUCTIVITY=0.48,
&PROP ID=’acme smoke detector’, QUANTITY=’CHAMBER OBSCURATION’,
LENGTH=1.8, ACTIVATION_OBSCURATION=3.28 /
&ISOF QUANTITY=’TEMPERATURE’, VALUE(1)=60. /
&ISOF QUANTITY=’VISIBILITY’, VALUE(1)=10. /
! End of header file
!!! Boundary conditions defs
&SURF ID=’Burner’, RGB=204,0,3, HRRPUA=300.00,

TAU_Q=-230.63, FYI=’1500 kW on 5 m2, fast fire’ /
&SURF ID=’Gypsum wall’, RGB=184,187,137,
MATL_ID=’Gypsum plaster’, THICKNESS=0.03 /
&SURF ID=’Glass pane’, RGB=0,204,201, TRANSPARENCY=0.200 /
! IJK=84,125,54 (567000 cells, actual size 0.250, 0.248, 0.240)

&MESH ID=’Domain +1’, XB=10.500,31.500,-14.817,16.183,0.000,12.968,
IJK=84,125,54 /
&MESH ID=’Domain 0’, XB=-10.500,10.500,-14.817,16.183,0.000,12.968,
IJK=84,125,54 /
&MESH ID=’Domain -1’, XB=-31.500,-10.500,-14.817,16.183,0.000,12.968,
IJK=84,125,54 /
!!! Geometry
! Start object &VENT ID=’External BC’, PBX=-31.500, SURF_ID=’OPEN’ /

&VENT ID=’External BC_1’, PBX=31.500, SURF_ID=’OPEN’ /
&VENT ID=’External BC_2’, PBY=-14.817, SURF_ID=’OPEN’ /
&VENT ID=’External BC_3’, PBY=16.183, SURF_ID=’OPEN’ /
...
...
...
&TAIL / ! Generated in 144.747 sec
Bibliography
[Hottel 1984] H C Hottel. Stimulation of Fire Research in the United States

After 1940 (A Historical Account). Combustion Science and
Technology, 39:1–10, 1984.
[FDS5 user’s guide] McGrattan K, Hostikka S, Floyd J, “Fire dynamics simulator

(version 5) User guide”, NIST Special Publication 1019-5,
2008.
[FDS5 technical reference] McGrattan K, Bryan K, Hostikka S, Floyd J, “Fire

dynamics simulator (version 5) Technical guide”, NIST Spe-
cial Publication 1019-5, 2008.
[Smokeview user’s guide] Forney G P, “User’s Guide for Smokeview Version 5 -

A Tool for Visualizing Fire Dynamics Simulation Data”, NIST
Special Publication 1017-1, 2007.
[FDS5+EVAC 2008] Korhonen T, Hostikka S, “Fire dynamics simulator with

evacuation, version 5”, VTT Research notes, Espo (Finland),
2008.
[Rehm 1978] R.G. Rehm and H.R. Baum. The Equations of Motion for
Thermally Driven, Buoyant Flows. Journal of Research of the
NBS, 83:297–308, 1978.
[NUREG 1824] Verification and Validation of Selected Fire Models for Nu-
clear Power Plant Applications. NUREG 1824, United States
Nuclear Regulatory Commission, Washington, DC, 2007.
[Grosshandler 1993] W. L. Grosshandler. “RADCAL: A Narrow-Band Model for

Radiation Calculations in a Combustion Environment”, NIST
TN 1402; 52 p. April 1993.
149
150 BIBLIOGRAPHY
[Wickstrom 2007] U. Wickstrom, D. Duthinh, and K.B. McGrattan. Adiabatic

Surface Temperature for Calculating Heat Transfer to Fire
Exposed Structures. In Proceedings of the Eleventh Inter-
national Interflam Conference. Interscience Communications,
London, 2007.
[Purser 2002] D.A. Purser. SFPE Handbook of Fire Protection Engineer-

ing, chapter Toxicity Assessment of Combustion Products.
National Fire Protection Association, Quincy, Massachusetts,
3rd edition, 2002.
[Mulholland 2002] G.W. Mulholland. SFPE Handbook of Fire Protection Engi-

neering, chapter Smoke Production and Properties. National
Fire Protection Association, Quincy, Massachusetts, 3rd edi-
tion, 2002.
Index
Adiabatic Surface Temperature (AST),

124
BURN_AWAY, 104
Direct Numerical Simulation (DNS), 4
EXPOSED, 87
Finite-rate approach, 48
Fire Dynamics Simulator, version 5 (FDS),
7
Heat Release Rate (HRR), 12, 24, 68,
84, 114, 117, 122
INERT, 79
INSULATED, 87
Large Eddy Simulation (LES), 3
Light extinction coefficient, 122
Mass extinction coefficient, 122
Message Passing Library (MPI), 21
MIRROR, 80
Mixture fraction model, 47
OPEN, 80
Reynolds-averaged form of the Navier-
Stokes equations (RANS), 3
SAWTOOTH, 102
Sign convention, 82, 83, 88, 133
Smokeview, 7
Visibility factor, 123
VOID, 87
Zone models, 2, 123
151

An Introduction To: Fire Simulation

Uploaded by

Copyright:

Available Formats

An Introduction To: Fire Simulation

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

An Introduction To: Fire Simulation

Uploaded by

Copyright:

Available Formats

An introduction to

Updated to FDS 5.5.1 and BlenderFDS

You can participate in the development of this document. Please, contact me

Emanuele Gissi ([email protected]) is a fire officer since 2002, serving

4 Input file basics 27

6 Combustion and radiation 45

9 Extra gas species 69

13 Devices and control logic 105

14.4 Animated planar slices, SLCF . . . . . . . . . . . . . . . . . . . 117

15 Using BlenderFDS 129

16 Real world examples 133

3.1 A cluster of Linux computers . . . . . . . . . . . . . . . . . . . 18

4.1 The structure of an FDS namelist group . . . . . . . . . . . . . 27

6.1 Combustion is not pyrolysis . . . . . . . . . . . . . . . . . . . . 46

7.1 The computational domain composed by four meshes . . . . . . 57

11.1 Extending the computational domain beyond the vent . . . . . . 80

12.1 Boundary conditions prescribed with SURF_ID, SURF_IDS, and

12.2 OBST, HOLE and VENT . . . . . . . . . . . . . . . . . . . . . . . 97

14.1 Output of animated planar slices SLCF as viewed in Smokeview . 117

15.1 A BlenderFDS session . . . . . . . . . . . . . . . . . . . . . . . 130

16.1 Car parking plan . . . . . . . . . . . . . . . . . . . . . . . . . . 136

4.1 Systematic organisation of the input file . . . . . . . . . . . . . . 33

5.1 HEAD parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.1 Mixture fraction species . . . . . . . . . . . . . . . . . . . . . . 49

7.1 IJK values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

8.1 MATL parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 63

9.1 Predefined extra species . . . . . . . . . . . . . . . . . . . . . . 69

10.1 PART parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 74

11.1 SURF parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 78

12.1 OBST parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 95

13.1 DEVC parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 106

14.1 DUMP parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 115

This chapter presents the problems embedded in fire simulation. The

1.1 Complexity of fire phenomena

The difficulties revolve about three issues:

• First, there are an enormous number of possible fire scenarios to consider

body aerodynamics, multi-phase flow, turbulent mixing and combustion,

1.2 Approaches to fire simulation

This chapter gives a concise insight on how Fire Dynamics Simula-

2.1 What are FDS ans Smokeview?

2.2 Engineering applications

2.3 Who develops FDS?

2.4 Who uses FDS?

2.5 How much does it cost?

2.6 How does FDS work?

2.6.1 Hydrodynamic model

2.6.2 Combustion model

2.6.3 Radiation transport

2.6.4 Geometry and multiple meshes

FDS approximates the governing equations on a rectilinear mesh. Rectangular

2.6.5 Parallel processing

2.6.6 Boundary conditions

2.7 Limitations of FDS

2.7.1 Low speed flow assumption

2.7.2 Rectilinear geometry

2.7.3 Fire growth and spread

For large-scale, well-ventilated fires, this is a good assumption. However, if a fire

• Second, the radiation transport is discretized via approximately 100 solid

3.1 Online resources and user support