minor edits

Author: mcgratta

mcgrattan/document/McGrattan_FEMTC/McGrattan_FEMTC/McGrattan_FEMTC.mdk

@@ -0,0 +1,62 @@
+
+[INCLUDE=style/lncs]
+
+Title       : The Challenge in Maintaining FDS and CFAST
+Author      : Kevin McGrattan
+address     : National Institute of Standards and Technology, Gaithersburg, Maryland, USA
+
+Bibliography  : references.bib
+Logo          : False
+Tex Header    :
+  \def\refname{&name-references;}
+name-references : REFERENCES
+
+[TITLE]
+
+~ Begin Abstract 
+The paper presents the day to day challenges of maintaining and developing complex open source software.
+~ End Abstract
+
+
+The Fire Dynamics Simulator (FDS) has been in the public domain for 16 years, and the zone fire model CFAST (Consolidated Fire and Smoke Transport) has been around, in one form or another, for nearly twice that long. While both are widely used and well regarded within the fire protection community, it may come as a surprise to many to learn what goes into their development and upkeep and what motivates the organization, NIST, to continue supporting this activity. This is true of most of the free and very useful publicly available open source software that we have come to rely on. Indeed, I am composing this paper using a new document preparation software tool named Madoko that I just discovered yesterday. I had a similar experience 26 years ago when I wrote my doctoral thesis using TeX, even before LaTeX became popular outside the mathematics community.
+
+I must confess that I do not know much about the organizations or people who create the wonderful free software tools that I use everyday for both work and home life. I assume that there is some financial motivation, like selling advertising space or user data or a not-free "premium" version of the software. This isn't a new idea – we've been watching and listening to "free" TV and radio programs for a century for the price of being subjected to advertisements. But what I hope to convey in this presentation is that FDS and CFAST are quite different from other open-source software development projects. These software packages are the primary means of transferring basic research results in fire into practice. In fact, most of us developers are essentially applied mathematics and computer scientists, whether or not our college degrees actually state it. This presents two fundamental challenges. First, researchers have historically viewed archival journals as the primary means of communicating their findings. Second, end users often regard these models as black boxes that spit out results and require little in the way of understanding basic fire phenomena. These two challenges have forced the model developers to do far more than just numerically solve the ordinary and partial differential equations that describe basic fire behavior. The long term viability of software like FDS and CFAST will require a considerable change in attitude of both researchers and end users because it is becoming increasingly difficult for the model developers to play all three roles – researcher, software developer, end user. No doubt, we cannot avoid completely all three, but if the perception in the community that NIST or similar organization can do it all, then the effort will certainly fail.
+
+<!--% ------------------------------------------------------------------>
+# 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 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 &ndash; 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.
+
+And so I was confronted with two very difficult challenges &ndash; 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 
+
+
+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. 
+
+# A Path Forward 
+
+
+
+For those of you who are interested in fire research, and you want to improve these fire modeling programs, do the following:
+
+
+1. Identify a problem in the existing models. There are already some listed in the FDS Road Map, but you need only simulate some fire scenario to discover that there's undoubtedly numerical or physical assumptions that can be improved. Each and every time I try FDS on a new fire scenario, I compile a list of very interesting masters or PhD theses that I could write if only there were time.
+
+* Contact the developers to make sure that your idea fits in with our current development plans. Do not wait until your paper or thesis is written and then present it to us as a finished work. We simply do not have enough hands to make the changes to the code or documents ourselves.
+
+* Learn Git, LaTeX, Matlab, Fortran, and whatever other software we use to maintain the codes and supplemental materials. 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, which in most cases it inevitably will. These are the tools that we use in our virtual laboratory, and much like a real lab, you simply cannot work without knowing how to use the tools. After working with these tools for a while, you will find that the basic Microsoft Office Suite is not particularly useful for doing serious technical work. 
+
+* If you want to publish your work in a journal, work within the FDS or CFAST GitHub repositories to document your contribution. Consider this activity to be of mutual benefit &ndash; you can share your work with a larger audience through the journal, and have a direct impact on the model users and developers. Much of the push back that we get from professors is that the students must write a thesis and follow-up paper(s), and that they see documenting the work in the FDS or CFAST repository is extra work. In fact, it need not be extra work at all, save for perhaps a bit of cutting and pasting from the model documents into the thesis. LaTeX or a markdown language such as the one used to create this paper help considerably in this effort.
+
+For those of you who use our models for day to day fire protection engineering, be a smart user. When something doesn't seem quite right in one of your calculations, spend some time and put together a simple test case for us to debug. Yes, this will cost you precious time, but it will lead to better understanding of the model and help you in the long run. Consider it an investment that is well worth it.
+