By Kevin McGrattan
Note: A longer version of this article was originally published in the Proceedings of the Fire and Evacuation Modelling Technical Conference, held in Torremolinos, Spain, in November 2016, and published by Thunderhead Engineering.
The Fire Dynamics Simulator (FDS) has been in the public domain for 17 years, and the zone fire Consolidated Fire and Smoke Transport (CFAST ) model for nearly twice that long. While both are widely used within the fire safety community, most end users do not fully appreciate the challenge of their maintenance and upkeep. Most of the developers are neither fire safety engineers nor combustion researchers, because software development requires a considerably different skill set. In fact, most developers are essentially applied mathematicians and computer scientists.
Our job is to translate fundamental combustion research into differential equations whose solution is of value to practicing engineers. Thus, the model developers interact with two very different communities: basic combustion research and fire safety engineering. These two groups live in very different spheres; they have different degrees, work for different organizations, and attend different kinds of conferences. The models try to bridge the gap.
A Brief History of FDS
I joined the staff of the Fire Research Division of the National Institute of Standards and Technology (NIST) in 1992, after receiving a PhD in mathematics. For the next few years, I worked on three very different projects involving compartment fire calculations, microgravity flame spread calculations, and mesoscale oil fire plume dispersion calculations. On any given day, I worked on three separate simulation programs, with length scales ranging from millimeters to kilometers.
FDS is an amalgamation of those codes. Maintaining all of them became very tedious, so I combined the best of each and started working on just one code base. This seems perfectly obvious now, but at the time, it was not. Fire models proliferated throughout the 1980s and 1990s, but most died as soon as the funding did, and only a handful are left today.
There are several reasons for this, but the simplest is that software maintenance is a thankless task. This discussion rarely arises in academic settings because it is assumed by most researchers that their job is to do research, not code development, and certainly not code maintenance. Universities and research labs are supposed to do “fundamental” research and publish their findings in archival journals.
The Lesson of CFAST
FDS and other CFD models of fire did not evolve naturally within fire science, but zone models did. If you have a degree in fire safety engineering, you have undoubtedly sat through many lectures where the professor drew a simple compartment on the chalk board, showing just one door on one side, and sketched the fire, plume, ceiling jet, neutral plane, Bernoulli flow in and out of the door. This is “classic” fire science, with the familiar ṁ, Q̇*, and so on. It was a great advancement, and according to a survey performed by the firm Combustion Science and Engineering (CSE) of Columbia, Maryland, USA (http://www.firemodelsurvey.com/), led to the development of roughly 50 programs to solve the set of ordinary differential equations for the layer temperatures, height, and compartment pressure.
Writing the computer program is the easy part. What about verification and validation? What about all those uncertainties in the assumptions that underlie each and every subroutine? The vast majority of the now-defunct zone models on the CSE website were written with none of this in mind. Most were developed by a few students who wrote a few papers, graduated, and moved on.
Thus, the lesson to be learned from CFAST is that it is fairly easy to develop a fire model, but it is not so easy to make it usable, verified, validated, and so on. This is not an appealing job for a young researcher, even though a wealth of interesting problems, unique to zone models, have never really been solved satisfactorily. Yes, a lot of work was done in the past, looking at buoyant flows through ceiling vents and spill plumes and so on, but somehow much of the basic research never made it into CFAST and lies scattered throughout the literature.
Many of the routines in CFAST were never formally verified and validated. CFAST is an ideal topic of study because it is much more aligned with the curricula of fire safety engineering programs than FDS is. To work with the FDS source code, you need a graduate-level understanding of partial differential equations and CFD. To work with CFAST, however, the bar is not as high, and there are plenty of interesting topics for master’s-degree students. The challenge for us is convincing these students and their advisors to get that basic research into usable form and help to keep it that way.
The Problem with Papers
A major problem in maintaining models like CFAST and FDS is that many see the work as completely separate from research, the goal of which is to publish archival journal papers. For centuries, progress in science and engineering has been promulgated by peer-reviewed publications in archival journals. Any aspiring researcher knows that the pathway to success in academia is a long list of papers. Indeed, many of the numerical techniques in our models were obtained from the general-purpose CFD literature, and sometimes more-specialized journals in combustion, fluid flow, and meteorology.
These papers illustrate basic finite differencing techniques, much like a textbook would. However, archival journals are not a particularly effective means of describing models like FDS because it is impossible to include all of the relevant details in a 10-page paper.
Some CFD modelers publish descriptions of their algorithms in various journals, creating a form of documentation via a list of references. This may be an effective way of advertising one’s research work, but it is a terrible way of documenting a CFD model. I learned this lesson the hard way after releasing the first version of FDS in 2000. I assumed that my and others’ papers in the journals would supplement the fairly sparse description of the model that I included in the manuals. What resulted was chaos: random snapshots of different versions of the code applied to various fire scenarios by dozens of students who were just learning about fire and CFD.
The quality of these papers was, in general, poor, and they led to misconceptions about the basic model that still remain today. It was not until 2007 that FDS and CFAST were put under version control (Sourceforge, then GoogleCode, now GitHub). At the same time, verification and validation guides were published, which now collectively document thousands of test cases that are run on a regular basis.
Much of this work is laborious and somewhat tedious, but it is an essential part of our model development strategy because when dealing with hundreds of thousands of lines of source code, mistakes are inevitably made that can be caught and corrected within a day. Contrast this with journal publications on a roughly three-year cycle commensurate with the duration of a typical graduate student's research work.
A Path Forward
While this article presents a somewhat pessimistic outlook for continued fire model development, aspiring researchers and model users can take steps to improve the current situation:
- Identify a problem in the existing models. One need only simulate a challenging new fire scenario to discover that numerous numerical or physical assumptions can be improved.
- Contact one of the model developers to ensure that a potential improvement is compatible with current development plans. This should be done well before writing the paper or thesis.
- Be open to learning Git, LaTeX, Matlab, Fortran, and whatever other software packages are typically used to maintain the codes and manuals. You need not be an expert in any of these, but you will benefit tremendously from the investment, even if your career path veers away from fire.
- Beyond the academic arena, for those who use fire models for day-to-day fire safety engineering, be a smart user. When something does not seem quite right in a simulation, spend some time and put together a simple test case for debugging. Yes, this will cost a bit of time, but it will lead to a better understanding of the model. Consider it an investment that is well worth the time and a small cost to pay to keep these models in the public domain.
Kevin McGrattan with National Institute of Standards and Technology, Gaithersburg, Maryland, USA