periodic update

Author: mcgratta

mcgrattan/document/document.mdk

@@ -29,22 +29,21 @@ This presents two fundamental challenges. First, researchers have historically v
 # A Brief History of FDS 
 
 
-I jointed the staff of the Fire Research Division of the National Institute of Standards and Technology in 1992, after working for about a year as a post-doctoral fellow in the Computing and Applied Mathematics Laboratory of NIST. The year before, I had graduated from the Courant Institute of New York University with a doctorate in mathematics. I assumed that I would eventually make my way to a teaching position at a university. However, teaching jobs were not easy to come by, and when offered a job in the fire research division, I jumped at the chance. I knew nothing about fire, but it sounded interesting. At that age, everything sounds interesting. For the next few years, I worked three very different projects: (1) CFD calculations with Ron Rehm and Howard Baum, (2) microgravity flame spread calculations with Takashi Kashiwagi, and (3) mesoscale oil fire plume dispersion with Dave Evans and Doug Walton. On any given day, I worked on three separate simulation programs, with length scales ranging from millimeters to kilometers.
+I jointed the staff of the Fire Research Division of the National Institute of Standards and Technology in 1992, after working for about a year as a post-doctoral fellow in the Computing and Applied Mathematics Laboratory of NIST. The year before, I had graduated from the Courant Institute of New York University with a doctorate in mathematics. I assumed that I would eventually make my way to a teaching position at a university. However, teaching jobs were not easy to come by, and when offered a job in the fire research division, I jumped at the chance. I knew nothing about fire, but it sounded interesting. At that age, everything sounds interesting. For the next few years, I worked three very different projects: (1) CFD fire calculations with Ron Rehm and Howard Baum, (2) microgravity flame spread calculations with Takashi Kashiwagi, and (3) mesoscale oil fire plume dispersion with Dave Evans and Doug Walton. On any given day, I worked on three separate simulation programs, with length scales ranging from millimeters to kilometers.
 
 I soon discovered that my supervisors lived in completely different worlds. Ron, Howard and Takashi would go to Combustion Institute meetings and interact with chemists, physicists and applied mathematicians in a very academic environment. Evans and Walton would go to meetings held by their sponsors at the U.S. Minerals Management Service and U.S. Coast Guard. These meetings were anything but academic. Within a few years, I grew fairly comfortable with both sets of "stakeholders", but it was clear that these groups just did not interact. Through the 1990s, I continued to work in these very different worlds, but by the end of the decade, I started to wonder about my future in fire. I was also starting to wonder about the impact of our work. The work on the large oil fires led to the development of a program called ALOFT (A Large Outdoor Fire plume Trajectory model), and the establishment of air quality guidelines for controlled burns of spilled crude oil. My more academic research, on the other hand, really hadn't led to anything but a lot of papers and conferences. Seeing how these CFD calculations could actually be useful led me towards the development of FDS.
 
 FDS was really just an amalgamation of those codes that I worked with throughout the 1990s. It became very tedious maintaining all of them, and so I combined the best of each and started working on just one code base. This seems perfectly obvious, but at the time, it was not. Fire models proliferated throughout the 1980s and 1990s. In fact, according to a survey done by Combustion Science and Engineering, over 50 zone fire models and 10 CFD fire models were developed at some point. 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. It's a lot of fun to write a new program, but no so much fun to keep it working year after year.
 
-This discussion rarely arises in academic settings because it is assumed by most researchers that their job is research, not development, and certainly not maintenance. Universities and research labs are supposed to do "fundamental" research and publish their findings in archival journals. This basic research then forms the backbone of commercial products and services. But for the field of fire protection engineering, and I suspect similar niche disciplines, there's a problem – and of course the problem has to do with money. There is just not a big enough customer base to support fire models like FDS and CFAST.
+This discussion rarely arises in academic settings because it is assumed by most researchers that their job is research, not development, and certainly not maintenance. Universities and research labs are supposed to do "fundamental" research and publish their findings in archival journals. This basic research then forms the backbone of commercial products and services. But for the field of fire protection engineering, and I suspect similar niche disciplines, there's a problem -- and of course the problem has to do with money. There is just not a big enough customer base to support fire models like FDS and CFAST. There might be a market for modeling and computing services, and handy tools such as PyroSim, but there is not a large enough market, in my opinion, to support the research behind the models.
 
-And so I was confronted with two very difficult challenges – the very large gap between academic fire research and the practicing engineers, and the thankless task of software maintenance. A solution to both problems, or so I thought, was to release FDS as an open source application that would draw academics to do their research, and engineers to design their sprinkler systems. It just seemed to make so much sense, until I remembered back in college when I took a course in Marxist economics. It all makes sense unless you actually have to make a living.
+And so I was confronted with two very difficult challenges -- the very large gap between academic fire research and the practicing engineers, and the thankless task of software maintenance. A solution to both problems, or so I thought, was to release FDS as an open source application that would draw academics to do their research, and engineers to design their sprinkler systems. It just seemed to make so much sense, until I remembered back in college when I took a course in Marxist economics. It all makes sense unless you actually have to make a living.
 
 # The Lesson of CFAST 
 
+FDS and other CFD models of fire did not naturally evolve in fire science -- zone models did. If you flip through a text book on fire science, you'll see a steady progression of empirical correlations leading towards the two-zone compartment model. If you have a degree in fire protection engineering, you have undoubtedly sat through many lectures where the professor draws a little dog house on the chalk board, with just one door on one side, and sketches the fire, the plume, the ceiling jet, the neutral plane, the Bernoulli flow in and out of the door. This is "classic" fire science, with the so familiar $\dot{m}$, $\dot{Q}^*$, and so on. I've seen this lecture a hundred times. It was a great advancement, and it led to the development of roughly 50 programs to solve the set of ordinary differential equations for the layer temperatures, height, and compartment pressure. Anyone with some background in numerical methods could write a very basic zone model in a few hours, and if you add in multiple compartments and a host of other bells and whistles, maybe a few weeks. And so it hasn't really dawned on many that there may come a time when you can't just download one of the models onto your computer. But writing the computer program is the easy part. What about verification and validation? What about all those uncertainties in the assumptions that underly each and every subroutine? How do you explain to the authority having jurisdiction that the calculation is valid? The vast majority of the now defunct zone models on the CSE web site were written with none of this in mind. Most were developed by a few students, who wrote a few papers, graduated, and left the program to rot on some old computer at the back of the fire lab.
 
-If you flip through a text book on fire science, you see a steady progression of empirical correlations leading towards the two-zone compartment model. CFD models like FDS actually come out of the blue, in that they did not evolve within the fire science community like zone models did. If you have a degree in fire protection engineering, you have undoubtedly sat through many lectures where the professor draws a little dog house on the chalk board, with just one door on one side, and sketches the fire, the plume, the ceiling jet, the neutral plane, the Bernoulli flow in and out of the door. This is "classic" fire science, with the so familiar $\dot{Q}$, $\dot{Q}^*$, and so on. I've seen this lecture a hundred times. It was a great advancement, and it led to the development of roughly 50 programs to solve the set of ordinary differential equations for the layer temperatures, height, and compartment pressure. Anyone with some background in numerical methods could write a very basic zone model in a few hours, and if you add in multiple compartments and a host of other bells and whistles, maybe a few weeks. And so it hasn't really dawned on many that there may come a time when you can't just download one of the models onto your computer. But writing the computer program is the easy part. What about verification and validation? What about all those uncertainties in the assumptions that underly each and every subroutine? How do you explain to the authority having jurisdiction that the calculation is valid? The vast majority of the now defunct zone models on the CSE web site were written with none of this in mind. Most were developed by a few students, who wrote a few papers, graduated, and left the program to rot on some old computer at the back of the fire lab.
-
-Rick Peacock, the primary caretaker of CFAST, has announced his retirement in 2017. There are no immediate plans to replace him. 
+So the lesson to be learned from CFAST is that it's fairly easy to develop a fire model, of one sort or another, but it's quite another to make it usable, verified, validated, etc., and keep it that way year after year. Rick Peacock, the primary caretaker of CFAST, has announced his retirement in 2017. There are no immediate plans to replace him. The reason is that it's not an appealing job for a young researcher, or so it would seem. However, I spent some time last year working with Rick to streamline the core solver, eliminate routines that were not being used or that were never verified and validated, simplify the documentation and graphical user interface, and update its maintenance process to conform to that which we use for FDS. In doing this, I found that there are a wealth of interesting problems, unique to zone models, that 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. The work that did make it was never formally verified and validated. CFAST is an ideal topic of study because it is much more aligned with the curricula of fire protection engineering programs than FDS is. To really work with FDS, you need a graduate level understanding of partial differential equations and CFD. To work with CFAST, the bar is not so high, and there are plenty of interesting topics for masters degree students. The challenge for us, however, is convincing these students and their advisors to work with us to get that basic research into usable form.
 
 # A Path Forward