Has it ever crossed your mind how would our discipline look like, if we did not have Fire Dynamics Simulator? Maybe you had an opportunity to discuss CFD with colleagues from other disciplines, to find their faces in shock and awe that the fire community actually has its own, FREE AND OPEN SOURCE, validated and fully recognized solver? A testimony to the impact of FDS may be the citation count on its user guide, which has recently exceeded 5.000 citations! The FDS code is something special and our little scientific community can feel proud that a tool of this magnitude was built just for us!
But it did not build itself. There is a history of giants paving the route with their low-Mach number approximation of Navier-Stokes. There is my today's guest - Dr Kevin McGrattan who saw the need and built the first iteration of FDS (and still leads its development 20 years later). And there is a team of brilliant scientists at NIST, VTT and other parts of the world, who shared this dream of a robust, open-access fire simulator, and volunteered their hard work into making this dream a reality.
In this podcast episode, we focus on the very early days of FDS (or even before it came to life). My mission was to learn how FDS was built, what the landscape looked like back then and how it was growing. When particular important sub-models came into existence and what triggered that. We also learn what were the goals for the tool development and how did they evolve over the years as the project got more and more serious. You may be surprised by some very simple explanations beyond some very tough design decisions!
I hope you enjoy this episode. Please appreciate dr Kevin McGrattan and the hard work done at NIST, VTT and other places, that enabled us to have something really special. Our solver. Fine tuned for fire and open to all.
Learn more about FDS at the project website at NIST or the GitHub repository.
Wojciech Wegrzynski:
Hello, everybody and welcome to what seems to be a holiday special episode of the Fire Science Show. And the episodes is definitely special because it seems to be one of the most requested interviews to be done on the podcast. So I'm super happy. I finally arranged that. Today I have the pleasure to interview Dr. Kevin McGrattan from NIST who's, better known as the creator of FDS fire dynamic simulator, a tool that. I guess every fire engineering their career has used at least once That's my belief, maybe not true, but. I think everyone, Of us has is. And I, I guess I could just stop the. The introduction at this point and just jump into the interview, but, uh, I still have some stuff to tell you before we do that. So, I'm super excited, not only because of the fantastic guest I'm having today, but also. Because the podcast has just breached another milestone that is 50,000. Individual podcast listens. Uh, thank you so much for, for being here. Thank you so much for listening to the show. I'm super happy to be a part of your professional life. And I'm super grateful that you choose to spend your time with the Fire Science Show and. It has been a challenging journey to reach this point. But, today the podcast is better than ever before. I have. All the things set up in place. All the automations set up in place. All the routine going. It's a pure pleasure to create a podcast nowadays. I get to interview magnificent people. I get to share with you. I get to interact with my audience. I'm talking to you through my newsletter. If you haven't signed up for that. You can through the websites and, I try to use more and more ways to listen to you more and produce the show that you want. Uh, so I hope there's some good times ahead for the podcast. I'm very sure about that. And, yeah, Eleni. Early next year, some more interesting and big updates coming your way. Well for now, let's, let's focus on. What's here now. And, uh, what's here now is it's a great episode of the show where you will learn. A lot of stuff where FDS came from, what was the rational behind building this. A set of tools. How did the landscape look when Kevin did build it up? How did the team look up in the early days? How did the solver look up in the early days? Oh man. It's so fantastic. to discover the. Fairly recent but very important. Part of the history of. Of the fire science. And I would also like to encourage you. If you have some great memories from the early days of FDS development, I don't know if you use version 1, 2, 3, 4, 5. Or started with version six doesn't matter, share it with others. Let's see how the. path to using the more or less of this today look like. And, uh, maybe we'll, have some fun sharing. And collecting experiences the fire science, your audience. And yeah, I won't take more of your time because you're waiting to, to hear Kevin and, you're right. you should thank you for being here with me and now enjoy your episodes. Hello everybody. I'm here today with an episode everyone was asking for. I have invited Dr. Kevin McGrattan from NIST hey, Kevin.
Kevin McGrattan:
Hey, how are you?
Wojciech Wegrzynski:
I'm super good. Thank you very much. And we are gonna talk fire dynamic simulator development. Man, that's a, that's a topic that's a. many times I, I've said fds is among, maybe three best, uh, or most impactful things that, happen to fire science. I, I would put it on par with SFPE handbook and, and Oxygen calorimetry I'm not sure , if that's where you would place it as well, but, there's not many things that would have such an impact over the, the whole discipline. So first of all, Kevin, Thank you so much for building and managing that you and this team. That is amazing effort.
Kevin McGrattan:
Yep. Well, it's interesting and fun to work every day and enjoy what you're doing. that's a plus.
Wojciech Wegrzynski:
Yeah, for sure. That makes sense when you say that because I, don't know how you manage all of this looking through the issue tracker and stuff like that. Uh, I, I don't know how much I would handle,
Kevin McGrattan:
Well, you know, one of the, fun parts about the job is that every day there's something new. and sometimes it's some, some issue having to do with, you know, computer science, some, some fire that occurred somewhere that's of interest. Some little bit of science that I know very little about, and I learn something about. I mean, every day there's something new and you just come in in the morning and you look at that issue tracker in the discussion group and, I didn't know that's
Wojciech Wegrzynski:
That's so cool. So, uh, Kevin, as far as I know, you are a mathematician.
Kevin McGrattan:
am.
Wojciech Wegrzynski:
How, how does a mathematician end up working in a fire laboratory
Kevin McGrattan:
Uh, so I studied mathematics in graduate school at New York University. it was called the Courant Institute. And after I graduated, I found a post-doc position, a post-doctoral fellowship down here at NIST and my advisor was named, uh, Ron Rehm and he was in the applied math lab. So I came down and I found out that Ron Rehm was, uh, working with a fellow named Howard Baum and Howard Baum was doing, uh, model calculations. And so I started doing fire model calculations after all that was a postdoc. And I found it pretty interesting. when I was in graduate school, I worked on high speed flow, you know, flow at supersonic speeds, and then I came down here. Completely turned the tables and started looking at low speed flow. Believe it or not, fire, fire in the realm of speeds is, is relatively low speed, low mock number.
Wojciech Wegrzynski:
Nice.
Kevin McGrattan:
in fact, that's, what Ron and Howard really pioneered where this was this idea of the low mach number approximation of the narrative stokes equations. So, that was a refreshing change for me because up to that point in. My education, I've been looking at shockwaves and high speed flow and now something completely different. So, um, you know, that's how I, that's how I got into it. My other, connection to fire though is that my uncle's name is Bernie McCaffrey. So of you who are familiar with, fire science would, would recognize the name McCaffrey. Um, he did a lot of work, experimental work plume correlations. He develop. the bidirectional probe or one type of bidirectional probe. And just by coincidence, you know, he is my mother's brother, and I always, I always wondered, know, what was fire science? I would go to my grandmother's house when I was growing up and she would have a, there was a picture of him from one of these meetings and he won the, you know, Fire Scientist of the year award or something like that. . What is fire science? Well, I got a good education when I came down, uh, here to NIST after graduating from graduate school. So that's how I got started. There was no, no other reason other than that's just happened to be what my advisor was doing. So
Wojciech Wegrzynski:
Wow.
Kevin McGrattan:
I started doing it too.
Wojciech Wegrzynski:
I gu I, I guess we should be grateful then. And institute, like the Courant number. Huh?
Kevin McGrattan:
Yes. exactly, exactly.
Wojciech Wegrzynski:
interesting.
Kevin McGrattan:
Richard a German mathematician who fled the Nazis in the 1930s and he started up the program at New York University and, know, he and his other, cohorts. Yeah, we're famous for that car number. So that's, that's something that was, uh, tattooed onto my brain when I was in school. The importance of the.
Wojciech Wegrzynski:
Fantastic. And now, now, when I was going through some files, I saw, uh, in one of them that the, the FDS was in development since 1978. Well, I guess this would, uh, trace back all the way to these, uh, Low mach number Howards approximation times
Kevin McGrattan:
Yes, exactly.
Wojciech Wegrzynski:
became like reality that are going to build a three-dimensional model that's, uh, supposed to, to simulate fire environment because I should actually ask like, how, how did the playing field look at that point? That's the, time of CFAST and stuff like that. Right?
Kevin McGrattan:
Yeah. So what, what Ron and Howard were doing was, uh, was somewhat, ahead of its time and whole concept of the low MAch number and their, and their approximation that they made to the equation. That was absolutely necessary because if you wanna run these CFD calculations for long periods of time, I mean like when we do fire simulations, sometimes we're simulating hours worth of time.
Wojciech Wegrzynski:
Hmm.
Kevin McGrattan:
you've gotta make some approximations and not having to track these pressure waves they bounce around your domain is a huge advantage. That's what allows us. To run FDS relatively fast. Now, a lot of people do complain that it takes forever to run your FDS calculation, but if you actually look at other, CFD packages or other CFD techniques, it, it's actually relatively fast. What we're doing and, and a lot of it is, is due to the low MAch number approximation. Ron and Howard actually had a background in meteorology. . Um, Ron went to m mit, uh, the Massachusetts Institute of Technology, and Howard went to Harvard and they were working with, uh, some of the pioneers of, you know, meteorology and, um, meteorological CFD. So a lot of the techniques that went into, their model was borrowed. You know, the weather people, not the, not the people who were designing missiles and rockets. A lot of CFD at that time was all about, shooting intercontinental ballistic missiles, and landing men on the moon and high speed flow and all of that. But, you, and you need certain approximations in the equation to handle those kinds of flows. But, uh, Ron and Howard looked to the meteorologist and they said, you know, what do we have here? We have buoyant thermal. So not, we're not talking about, you know, rockets reentering the earth's atmosphere you know, Mach 10. Uh, we're talking about, weekly buoyant, know, thermal plumes, and that's, that's how the equation is developed.
Wojciech Wegrzynski:
And the most, uh, fundamental tool you would use at for modeling at that time would be the zone model, I guess.
Kevin McGrattan:
Yep. Yep.
Wojciech Wegrzynski:
so can you tell me about the moment where you started to think that, okay, uh, zone model is great, but it would be greater to, to go 3D dimensional and use
Kevin McGrattan:
Yes.
Wojciech Wegrzynski:
tools
Kevin McGrattan:
Right. So when I first started working with Ron and Howard in the early nineties, we developed a couple of different of software to handle different problems. So I worked with one group and they were looking at Big oil, plume fire, big oil fires that created, big plumes, in the outdoors. And we're talking about, tens of kilometers into the atmosphere.
Wojciech Wegrzynski:
Hmm.
Kevin McGrattan:
And then I was working with another group and we were doing these little tiny spread calculations of flames and outer space. So we had some money from NASA to look at the spread of fire on the space shuttle or the space station. So we were doing these tiny fundamental little flame spread calculations. then I was just doing some simple, calculations within simple compartments. So I had a whole series of different codes that I was working. And I was kind of slamming these different algorithms together for each one, for each different application. And it's, that's not unusual. And CFD oftentimes you find that someone takes, a bunch kind bits and pieces, core solvers, if you will, and. Puts them together for, for each application. Well, I found after a couple of years of this that I was getting stretched way too thin, so I had too many codes to keep care, take care of, and I needed to consolidate. So the idea was that, you know, I should be able to combine all these different bits and pieces into one. that can handle this range of different applications. And it's, that's a bit of a stretch going from these tiny little, know, flames and outer space to, you know, gigantic oil fires. But if you look at just the core solver, the Naver Stokes equation, it's common to all of these things. In fact, I mean, all CFD codes at the end of the day have some kind basic transport equations. And so I combine that all into. Code and then we started applying it to some applications that, were on our plate at the time. The, one of the first applications was we got involved with the, N F P A Research Foundation, and they were looking at this issue that involved sprinklers, vents, and draft curtains in, uh, warehouses. So that was, that was a bit of a controversy at that time. . in the nineties, at least here in the United States, we started to see all of these, what we call big box stores. I don't know what you call 'em in Europe, but uh, think like the IKEA warehouse, right? Okay. You know what that is?
Wojciech Wegrzynski:
Yeah.
Kevin McGrattan:
So that was somewhat new in the nineties, and the new concept there was that we were combining, what would you wanna call it? Like, industrial fire protection with, the type of life safety, fire protection you would find in a small store. Okay, so now you basically have people in a large industrial facility, and so there was on controversy as to, you know, how do we protect both property and life safety at the. Okay, so that's where this, this problem of, uh, sprinklers, vents, and draft curtains came up. Cause, in these stores, you would've sprinklers. But then they also wanted to keep the vents and the draft curtains, which was a sort of an earlier technology. And make a long story short, some people complain that these three, fire did not work well.
Wojciech Wegrzynski:
They, they still do, Kevin, they that that discussion has not ended.
Kevin McGrattan:
Right, right, right.
Wojciech Wegrzynski:
interesting that you say, um, it was multiple codes, applied together. I, heard different versions of this story said by different people. Like some people were saying, oh, there was this industrial. Fire model, uh, that, that originated. Someone was saying No, no, there was like ALOFT for, uh, external plumes. They, they used ALOFT
Kevin McGrattan:
Yep.
Wojciech Wegrzynski:
And I, I, I see all of them have, bits of truth and, the truth, truth is that, uh, you are done with this with writing, model for every application,
Kevin McGrattan:
right. That's right. We had, there was something called Aloft, which we used for these big oil plume fires. And um, then there was something called the industrial fire simulator or ifs. and that's just typical of the way things were, where you would put together a special code for each special application. But it's a nightmare in terms of maintenance. I mean, it's just, it's impossible. So I just combined everything into, into fds and it's been that way ever since. And it makes my life a lot easier to just try to keep track of one code
Wojciech Wegrzynski:
It's,
Kevin McGrattan:
not three, or.
Wojciech Wegrzynski:
it, it sounds like the best investment in your life, I guess
Kevin McGrattan:
Yes. right. But there's also something, there's a bit of like, sort of academic politics involved, and that is oftentimes people rename or rebrand research that they're doing, because then it sounds like it's something new. And, and even today, sometimes, you know, when I talk to my managers, they say, you know, this FDS thing, it's been great, but what's next? What are we doing next? I know we're just trying to make it better. We're not necessarily gonna rebrand it.
Wojciech Wegrzynski:
like iPhone. You can make FDS 6S now or, or something. now I need to ask you like, When you were merging these models, you must have done some choices. And, now, 20 something years later, are all, uh, doomed with, uh, with your choices. So I, would love to, I would love to understand, especially the, the first and most, impactful one, I guess. Uh, LES model. So, uh, for the listeners, f d s, uh, works turbulence model, the way, how you model the turbulent, part of the flow of, of the air called Large Eddy Simulation, uh, Smagorinsky version of it. would say, um, even today, If I, if I was making a proposal to write a new code and said, and I would like to make it LES code may, maybe today it would not be very odd, but
Kevin McGrattan:
Yes. Right.
Wojciech Wegrzynski:
some years ago, I guess that was, that was a bold decision. Like,
Kevin McGrattan:
Right, Well, well remember I said that we had our start in meteorology and Smagorinsky was a meteorologist, I believe. I think Google search on it, but I believe. Gregsky was, was developing algorithms from meteorological models. So it was natural for us. And the other thing too was that we, we did some, have some experience with, RANS codes. Uh, Reynolds averaged Navor Stokes, but I found Rand's codes to be so uninteresting. So for example, , When, when we do a fire simulation and you see the, the buoyant plume and you see the smoke behaving the way smoke really behaves, and if you've had experience working in a lab as I have had, it gives me great satisfaction to see on the computer screen exactly what I see in the laboratory, or at least something fairly close to it. But when you run a a rans model, I mean, you may get a reason. Result or answer. But I just find it to be so unsatisfying to see that, you know, time average portrayal of the of the smoke movement. And so for me it was more of academic interest. We weren't, at that time when we chose LES, we were thinking that this was just gonna be an academic exercise. We didn't realize that people were gonna actually use it to shopping mall. thought we were just gonna, run calculations, go to meetings, you know, live the academic life. Um, and it wasn't until, you know, around the year 2000 or approaching the year 2000, I started to give the code out just to some, you know, friends in the area who wanted to play around with it. And I was startled when they came back with these, you know, fairly sophisticated. , renditions of buildings. Some of these buildings were in the Washington DC area and I thought, wow, I mean, this is fantastic. And I found that the engineers who were doing these calculations, they really enjoyed it. I mean, almost like a little kid playing with Lego Box. I mean, we all enjoyed that. We still do building up, you know, complicated geometries and then looking at the smoke move. I just found it was interesting and I think that the engineers who were doing the work also found it interesting. so don't discount that, you know, work should be fun, . And I know, and I know it's, it's, it's somewhat difficult to say that, you know, fire is not always fun. Sometimes fire is not very fun. You know, setting up these calculations, it's challenging, it's fun, it's rewarding, and I think that, you know, I was having a good time and I think that the engineers who were using the model were having a good time. I thought, you know, if they're interested in it and they put that extra bit of effort into doing these calculations, why not?
Wojciech Wegrzynski:
Now,
Kevin McGrattan:
mean, that's gonna advance the field.
Wojciech Wegrzynski:
I've read in one of your papers or maybe in an interview with you that, you chose LES because it was interesting. So again, this one is, this one is, is confirmed. It's
Kevin McGrattan:
Right,
Wojciech Wegrzynski:
is like MythBusters in here.
Kevin McGrattan:
right, right. Well, I mean, could, I could spend an hour arguing as to why l e s is technically superior and we can go into turbulence models and closure methods and all of that. But, you know, for me, at the end of the day, I just was much more satisfied running these, you know, realistic looking. fire simulations, and then when we, you know, when we discovered that we could actually do these calculations on desktop, personal computers, I mean, that was a win-win. We said, all right, you know, if we can do l a s on a manageable platform, why not do l a s.
Wojciech Wegrzynski:
I find it also fascinating that you've built this as a, a tool for science, not imagining the, um, impact it would have over the engineering discipline that you were discovering that as the tool was, was given. That that must have been very rewarding to see how. Creatively people use it maybe sometimes even too creatively but, reach that point for sure.
Kevin McGrattan:
right. But, again, that's part of the fund because you develop a technology and then you see that technology grow in ways you never imagined. I mean, that could be said of so many things that have happened in the past 30 years with, the boom and computing and information technology. I mean, a lot of the things that we take for granted were develop. know, just out of the blue and the developers themselves never had a clue that it would take off the way it.
Wojciech Wegrzynski:
so if, if, we think fds version one, what was it like compared to the modern fds? Like, what are the things that we would take for granted that, they were not even, uh, in, in inception at that point? Like, how, how, how, how did it look? Did it, had he transferred to the surfaces? Uh,
Kevin McGrattan:
it, it really didn't. So it, one of the things that FDS one lack was radiation. we had a very, very crude rendition of radiation and where we, we literally assumed that the fire were, were just a bunch of burning, like little particles, little burning ping pong balls. And each ping pong ball would radiate a certain amount of energy in all directions. And we just used a, like a simple, , Montecarlo type algorithm that just randomly shot the energy out in different directions. And at about that time when we were developing fds one, Simo Hostikka from Finland came to visit us for a year. And remember when I, when I first met him and he said, you gotta put in a new radiation solver. This one you have is terrible. So I said, okay, cmo, if you think it's so terrible, then you put a new one in it, come at it. and I'll tell you, within a month he had essentially what is still in the code today. I mean, he, he developed something within a month, um, that is still a workhorse. and quite frankly, we've never really improved on it. It's, it's that,
Wojciech Wegrzynski:
Yeah.
Kevin McGrattan:
and that's where FDS one went, to FDS two and so forth.
Wojciech Wegrzynski:
Uh, next combustion model. Like
Kevin McGrattan:
Yeah,
Wojciech Wegrzynski:
at the beginning or also you used some clever approximations.
Kevin McGrattan:
no, it didn't really have combustion. All it, all it had were, again, these ping pong balls each ping pong ball you could think of as representing a certain amount of fuel and the energy would be deposited Onto the grid, in a certain amount of time. So in some sense the, the most basic type of, you know, aian model where we just, we had a, a, a burnout time for these particles that was just fixed. So it wasn't tied to any turbulence or anything else. It just wants the ping pong ball. And in half a second, say, um, its energy is deposited onto the.
Wojciech Wegrzynski:
Okay.
Kevin McGrattan:
and we adjusted that burning time based on the flame heights. So if, if the fire was too short, then we just extended time
Wojciech Wegrzynski:
Okay,
Kevin McGrattan:
a little taller. So there really was no combustion in it at all. It was just really a way to, to deposit a fixed amount of energy onto the grid.
Wojciech Wegrzynski:
but.
Kevin McGrattan:
mean, it's, it's almost like what you, what you do now, sometimes you have these volumetric. Heat sources where the fire is really just like a cone and you deposit the energy in a, like a shape on your grid. It was about that level of complexity.
Wojciech Wegrzynski:
so at that point, it was mostly the, the flow solver. So you, you had the flow, you had the turbulent flow with l e s,
Kevin McGrattan:
Mm-hmm.
Wojciech Wegrzynski:
you, you have created this ping pong, ping pong balls to basically release the energy to capture the, the buoy flows and, and
Kevin McGrattan:
Mm-hmm.
Wojciech Wegrzynski:
you just used the, the mixture fraction model.
Kevin McGrattan:
that didn't, that, that came later fds one, there was no mixture fraction. we just used these ping pong balls to visualize the smoke, and so also that's when smoke view was born.
Wojciech Wegrzynski:
Okay.
Kevin McGrattan:
Smoke View was originally just a simple visualization tool that allowed us to visualize the particles.
Wojciech Wegrzynski:
Okay.
Kevin McGrattan:
So the particles were colored orange when they were burning and they were colored black when they weren't. And so , so you have the fire and then you have the smoke, that was the original smoke view. And then, Glenn Forney who, who develop. Um, you know, as time went on, he, he started studying all sorts of other techniques to visualize the smoke. I mean, a lot of his inspiration comes from the movies. So he reads, he reads a lot of books about how, computer graphics are used in, in the film industry. And so some of what you see in smokeview now are simple renditions of what, the Pixar people are doing.
Wojciech Wegrzynski:
you, you have, I must say fairly advanced camera operations within smoeview that is misaligned with, uh, with the needs. Uh, I guess, uh, that explains why, if, if someone with, uh, would love to film in this stream made it, that it makes actually. and also not no heat transfer. Okay. You didn't have heat transfer to solids. um, okay, so, so you had the solver. How did you choose, like, okay, now, now let's add the heat transfer. Now let's add the combustion. Was it because of certain cases or was there, um, like a grant plan for the next, uh, 10 years?
Kevin McGrattan:
Uh, no, there's not. I'd like, I'd love to think that there was a grand plan, but it usually came case by case. and so the heat transfer came about because, you know, again, our original problem with these. Storage fires, right? So you've got boxes piled up in a warehouse, and we would start the fire at the base of the boxes, and obviously we needed to heat up the surfaces of those boxes until we got to some, you know, quote unquote ignition temperature, and then the boxes would start burning. So in order to do this sort of simple fire spread, we had to have, you know, a relatively simple, you know, heat transfer algorithm into the box.
Wojciech Wegrzynski:
and combustion, like, when did you figure out, okay, I, I want to see the flames
Kevin McGrattan:
Yeah. Yeah, so, so combustion came about like an FDS two. I started working with Jason Floyd. So Jason Floyd was my postdoc, and he had graduated from the University of Maryland. You know, with a PhD in, I think it's nuclear engineering, but , he's a clever guy and he, he figured out how fire works and he was doing work as a postdoc, looking at unventilated fires. And so we knew that in order to do unventilated fires, we couldn't just continue, you know, with this burning ping pong ball, idea that wasn't gonna do it. So, so Jason and I developed the, you know, the mixture fraction approach and a, as sort of a first way to look at combustion more realistically, and also to look at combustion in an unventilated environment. Now we, have to then, you know, evolve beyond the mixture fraction approach, to what we do today. Which is where we have these so-called lump species, you know, fuel plus air goes to products. but FDS two sort of introduced the concept of the mixture fraction. And then, you know, Jason's been working with us ever since. And you know, over time he has evolved, the combustion model to what it is today.
Wojciech Wegrzynski:
Uh, j Jason's a star. He, he was also at the podcast
Kevin McGrattan:
Yeah. Yeah. I listen to podcast
Wojciech Wegrzynski:
the best to Jason. so, okay, now you have mixture, fraction approach and, capability to do under ventilated fires. I think now this point, F Ds gains, that highly. Go above what we could do as, uh, as a fire modelers like, balances of heat, uh, small compartment fires, stuff like that you could do with CFAs. But once you solve, oxygen and you know how much oxygen is in your room, you
Kevin McGrattan:
Right,
Wojciech Wegrzynski:
next to your doors and how much is in the back of the room, you create very like environment in your compartment.
Kevin McGrattan:
Yes.
Wojciech Wegrzynski:
and this is when you start to see inside the fire, like no one ever, uh, done. So, so, when did you start like doing, I dunno, back drafts or, or smoke explosions with it? I guess, I guess you, you probably immediately went for that when you gained these capabilities.
Kevin McGrattan:
Yeah. well, I think we were, again, Jason was doing his, post-doc, uh, research. down at Virginia Tech and he was working with another fellow named Chris Wieczorek who's now at Factory Mutual. And they were, you know, they had a, a reduced scale enclosure and they were, putting big fires in the reduced scale enclosure and measuring, uh, soot and co and, and other gases within the box. And so we were trying to model that. And our, you know, our big goal was to try to predict the co. , that would build up in the upper layer of this, flashed over compartment. you know, that kept pushing the combustion modeling. Because if you wanna actually predict co as opposed to just specifying it, you know, then you've gotta now have something a little bit more sophisticated than fuel plus oxygen goes to products. Now we have to have something like fuel plus oxygen goes to you. Some initial set of products and then those initial set of products have to then, know, combine with oxygen and, and to form the final set of products. That is the CO has to oxidize and form co2. And that's where the lump species approach, um, came into play because we needed some way to account for all of these major and minor species without breaking the. because in fds, if you track all of these different species, fuel, oxygen, nitrogen, soot, co, co2, water vapor, blah, blah, blah, blah, blah, you know, each of these is his own transport equation and the cost of the calculations would get higher and higher and higher. So Jason was really the, the one who, worked out, you know, the simplification of, of the kinetics to the point where you would. The minimum number of species that you would need to track. But once you get into under ventilated combustion and you form CO and that sort of thing, you know, basically now you have four species to track rather than three, right? You've got these two sets of, of products. the initial set, you know, has the CO in it, and then the, uh, the secondary set has the, the CO2.
Wojciech Wegrzynski:
by like developing, you mean like literally solving the equations on, on the blackboard then figuring out how to transfer that into a code. Like how did you even write it?
Kevin McGrattan:
well, well, Jason's very good with algebra , so
Wojciech Wegrzynski:
and you're a mathematician?
Kevin McGrattan:
I'm supposed to be the mathematician, but Jason actually is, is really clever. And, and what this involves is, you, you, you write down your basic. equations where you have, okay, the fuel molecule plus oxygen plus nitrogen goes to, know, X, Y, and Z. Well, now you have to lump these things together and there's just a lot of, a lot of algebra. And then when you start to code it up, you know, you have to make sure that you know all the, all the atoms balance. Um, and, and you've probably heard from people who try to run FDS in sort of primitive species mode. It's tricky. Just figure out, okay, you know, what are my tric coefficients for this, you know, complicated set of set of equations.
Wojciech Wegrzynski:
I, I find it fascinating, you know, because I, I really like to put it in the, um, timeline. You know, was time when people listened to Britney Spears and NSync. I guess this is, this is times where you, you surely could not go stuck overflow and just, okay, give me like nice this particular problem. You have to figure it out.
Kevin McGrattan:
Yeah. Well, yeah, for us,
Wojciech Wegrzynski:
because there was no YouTube.
Kevin McGrattan:
I think the problem was is that a lot of, I mean, there's certainly a lot of people doing CFD related to combustion. But a lot of them are doing these fundamental calculations where they don't have these lump species. They just literally, you know, track all of the major and minor species directly. And it's computationally expensive, but it's a little bit easier in terms of the formulation. for us, often the difficulty in programming FDS is we have to make these approximations to get things to work in a reasonable amount of. Whereas sometimes someone, if we just talk to combustion people, they'll say, well, why don't you just solve for everything explicitly and don't worry about, the lump species. And we say, well, you know, we have to get our calculations done in a day or two, not a week or two, or a month or two. Sometimes in, in the academic world, if it, if your calculation takes a month
Wojciech Wegrzynski:
It's,
Kevin McGrattan:
Well, so what
Wojciech Wegrzynski:
and what, what came next? Pyrolysis suppression.
Kevin McGrattan:
Let's see. so Pyrolysis came about, I'd say next because again, Simo Hostikka um, who had returned to Finland at that point was starting to get interested in pyrolysis. And wood. Wood in particular. I think in Finland, they , they're very interested in wood. It's an important part of their economy. and so he started to know, put the basic pyrosis equation. Into fds and I also became quite interested in it. So he and I both started to, to work out, the detailed kinetics models that one can choose to use in FDS today. But it was, it was Simo who really, who really pioneered that. And he was again, just interested in doing, um, simulations involving wood. He, and he got a number. Of coworkers. Anna Matala, was one who I remember. and she was also very interested in this. So, I decided as long as Simo was interested in coding it up, I was more than happy to work with him.
Wojciech Wegrzynski:
Fantastic.
Kevin McGrattan:
Yeah.
Wojciech Wegrzynski:
suppression. How, how did you end up putting lagrangian aggression particles, water, and uh, and all the suppression
Kevin McGrattan:
Well, well, the, all the suppression stuff was around from the very beginning, even before we released fds we were doing these warehouse fires. So we had, we had the sprinkler model in place. But one of the things that we really wanted to do, after we released FDS officially, is. We wanted to do more with droplet sizes and distributions and, and that sort of thing. And there's a fellow named Dave Shepherd who, for his graduate work, know, developed a, a fairly sophisticated treatment of water droplets that we built into fds. The problem there though, is, For any given sprinkler, it's very difficult to get the data that we would need for this sophisticated model. So, I mean, if you go into any building and look up and look at the sprinkler, there are, you know, an infinite number of different types of sprinklers. Each one has its own sort of characteristic, spray pattern and, and droplet distribution. . And so we got to a point where we had to kind of keep in place the relatively simple model that we still use today, simply because we don't have, the details of any given sprinkler. I know it can be measured. I mean, one can go to a testing lab measure these things, but that's a very expensive thing to do. And I've, I've found by talking to a lot of the fire protection engineers who use fds, they're quite happy to. Have fds predict when the sprinklers are gonna activate and they wanna have a, a reasonable idea of where the water is gonna go. But in terms of suppression, in terms of actually predicting, if you know a pile of commodity that's burning is gonna go out, that's still something that I don't think we can, we can.
Wojciech Wegrzynski:
Yeah.
Kevin McGrattan:
mean, we have rough empirical models in FDS to make some approximation as to how much the heat release rate will decrease when you throw water on something. But that's never really been something that we're gonna be able to do, like reliably. Like we'll never be able to replace a full scale test in terms of predicting whether or not, you know, that burning pile of boxes is gonna. Put out by, sprinkler X, Y, or Z.
, Wojciech Wegrzynski:
now, I, I'm, I'm switching to the difficult question spot the list. I remember there a thing around FDS four. It was the, material database. then when, when you move to FDS five, the material database has disappeared, uh, causing, uh, causing almost a collapse to a whole industry of fire safety engineering. So I would love to ask you like, uh, first, uh, about the development and the destruction of the material database and the world of default values in, in modeling, because the, these, these two things connect.
Kevin McGrattan:
Right. the original idea behind that database was just to put in, you know, some K - rho - C for some basic materials, brick gypsum board. But over time it started to creep and we, we started to develop much more sophisticated, property data that we put into that data. and then we just started adding numbers that, you know, came out of this paper or that paper or this handbook or, or wherever it, the, the database started getting filled up with a lot of numbers that we really couldn't validate or verify,
Wojciech Wegrzynski:
Hmm.
Kevin McGrattan:
and at this time we were doing more and more work with regulatory authorities, like in this country, the Nuclear Regulatory Commission. And they were all very interested in validating these models. I mean, they're essentially the authorities having jurisdiction and they wanna have some idea as to how accurate these models are. And know, the question arose when we were starting to do the validation work is, okay, well what do we do about these material properties? How do we quote unquote validate them? And I looked through the database and I found that, you know, I really couldn't rigorously justify. Some of these numbers, I mean, some of 'em were just, you know, ballpark order of magnitude guesses. some of, and we, we started to notice that they were being used inappropriately.
Wojciech Wegrzynski:
They, they, were cited like to
Kevin McGrattan:
were being cited sort of standard reference materials, and that's a problem here at N I S T. We do have, as an agency, we have what are known as standard reference materials and standard reference data. and our materials database was not that
Wojciech Wegrzynski:
Okay.
Kevin McGrattan:
It's a big deal when you, when you stamp, you know, standard reference data onto something. I mean, the funniest thing that we, we, we sell peanut butter here. Did you ever hear that story about peanut butter? so nist, you can buy for about $500 a jar, peanut butter from nist, and it's a standard reference material and it's used by, food producers for measuring caloric content. So if you have an apparatus for measuring the caloric content of food, you can use the NIST peanut butter. As a standard to make sure that your apparatus for measuring the calorie content of the food is okay. so the long, so the long story short is we were not going through all of the necessary, hoops to call our database standard reference. So when we went to FDS five, we just decided. This was too much of a burden for us to take on. It's hard enough to maintain the code. We really weren't comfortable maintaining this database of material properties, especially when we were just pulling these, these numbers from just a whole variety of different sources. It's almost like, you know, going onto the web these days and just Google searching on something and putting the number, I mean, that's really all our database. And so I'd rather have the end user pick a number off the web rather than us
Wojciech Wegrzynski:
and justify ma'am.
Kevin McGrattan:
justify it. And that's, and that's what the authorities said to us. They said, look, when someone runs an FDS calculation and we review it, we will ask them where they came up with all these properties. And we don't want to hear from them that it's just comes from this database. I agree. I don't wanna hear that either.
Wojciech Wegrzynski:
question. it taste good? Like, is, is it better taste?
Kevin McGrattan:
Terrible
Wojciech Wegrzynski:
Well,
Kevin McGrattan:
have the sugar. It doesn't have, it's just like peanut and.
Wojciech Wegrzynski:
okay. Okay. as, as we discussed this, this material database, I had this discussion with Wolfram Jahn a long, long time ago in the podcast um, users using default values without giving, without giving it a serious thought. and you, you had to use some defaults in, in FDS there's, there's many defaults. There's, uh, smoke extinction, specific smoke extinction, coefficient default. There's, suit default. I think there, no, now you have to specify your reaction because you, you, you have taken away that from
Kevin McGrattan:
Yeah, we even, we even took that away cause that was problematic too. We didn't, we dunno. The smoke yield of your burning couch. I mean, that's something I want you to
Wojciech Wegrzynski:
Actually, actually, actually that's a great example because half of the world was burning pole urethane because that was their default reaction.
Kevin McGrattan:
I forget what the default re I think the default reaction was.
Wojciech Wegrzynski:
yeah, yeah. Sorry. Yeah. Prop point. But that was like
Kevin McGrattan:
But there was, but there was polyurethane in this database that we had just pieced together from some experiments that were done here at nist. And I can't even tell you, you know, in detail what that polyurethane consisted of, what kind of fabric was in it. It was just like a one off from one test and we just, were not comfortable, declaring that to be, standard reference data.
Wojciech Wegrzynski:
now, okay, now, there are still some defaults, I guess they are like, you probably put a lot more attention into, into having them. But what, what, how do you feel about this, uh, user responsibility? Like from from a developer perspective,
Kevin McGrattan:
Mm-hmm.
Wojciech Wegrzynski:
from your point of view? Like the, the user is fully, uh, Responsible for, for choosing the numbers, whether they, they leave default or, or pick one.
Kevin McGrattan:
right.
Wojciech Wegrzynski:
you have the impression that they actually do that?
Kevin McGrattan:
well, we, they have to cause we force them , for example, I was talking to someone the other day who was doing an analysis of a fire in, in some building, and he kept talking about the, the visibility. And I asked him, I said, well, what have you specified for the so yield?
Wojciech Wegrzynski:
Hm.
Kevin McGrattan:
And he didn. No, what he was specifying for the soot yield, and I'm guessing if he didn't specify anything, then there's no soot at all, which means that the visibility is always going to be, you know, at it's maximum. And so, so we decided that it was much better to sort of force the user to think about these things rather than to specify it. Because, I mean, let's face it, when I run a computer program, and I'm not talking about fds, but some other, you know, program. , I generally go with the default. If I don't go any better, I'm just gonna go with the default unless the program forces me to make a decision. And so we, We often argue amongst ourselves, to what extent do we wanna force the users to make these decisions, or do we wanna provide them with a default? Over the years, we've kind of come to this compromise. Like for example, 35% is our default, radi theft fraction. but that's, I mean, I'm trying to think of what other, what other defaults do we have in there that the user doesn't have to really specify? I mean, that,
Wojciech Wegrzynski:
my Extinction Co. Is, is
Kevin McGrattan:
that's another one. Okay.
Wojciech Wegrzynski:
that's
Kevin McGrattan:
Yes.
Wojciech Wegrzynski:
Mulholland's Research that, that
Kevin McGrattan:
Right, And that's a number that, I mean, we haven't seen anything better than that. So we heard, let's at least provide the best data that's out there. And, but then for, for other things the soot yield, co yield, know, those are things that we really think the user has to think, especially if they're doing a life safety.
Wojciech Wegrzynski:
So, we, we've covered, I, I hope, quite torr the, the first 10 years of fds FDS five came, what, 2008, nine.
Kevin McGrattan:
Something like that. Yep. Mm-hmm.
Wojciech Wegrzynski:
six came 2013, 14, around that time,
Kevin McGrattan:
Yes.
Wojciech Wegrzynski:
I, I guess some people were lucky to get into better version for, and, and I, that that was quite a long one as well.
Kevin McGrattan:
Right. Great.
Wojciech Wegrzynski:
how did the development of the modern versions look like? Because you had now combustion model, you had a radiation model, you had model, you had the pressure model.
Kevin McGrattan:
Yep.
Wojciech Wegrzynski:
point, was it like improving the models, a changes
Kevin McGrattan:
so as we went from FDS five to FDS six, we were joined by Randy McDermott. and he. , you know, he actually has a formal CFD background. you know, Jason, CMO and I who kind learned it as we went along. Randy actually had, a very, extensive background in cfd and you know, one of the things we asked him to do when he first came on board was just to look at everything in the code and. Start running, you know, verification tests, and we started running more validation tests and we started to get a little bit, more strict with the way we handled a lot of things. I mean, it's hard to go, I mean, there'd be a laundry list of different things,
Wojciech Wegrzynski:
Hmm.
Kevin McGrattan:
but, but Randy started to really apply a lot more rigor, to what we were doing. up to that point. Up to that point, you know, sometimes we were, we were being a little bit fast and loose with some of the, know, the turbulence models, boundary layer correlations. And, and Randy brought some discipline to that and introduced the, the whole concept of running verification cases.
Wojciech Wegrzynski:
Okay.
Kevin McGrattan:
And so that's, a lot of that went into fds. you know, one of the major problems that we had with FDS five is that the, the algorithm at the time that we were using, which was the simplest form of, of the transport algorithm, would allow temperatures to drop down to extremely low values right around the fire. And, you know, to make a long story short, you have a situation where you go from like a really high temperature in the fire, and then in just one or two grid cells you're down to ambient temperature. So the temperature kind of goes through this dip, and it's purely numerical. There's nothing physical about this at all. It's just a, it's a numerical artifact. It's just part of that particular algorithm that we were using. But it really, you know, got a lot of people bent outta shape. A lot of our users. Did not like to see, you know, minus 10 degrees Celsius right next to a big fire. And we tried to explain that this was, you know, purely a numerical artifact. It doesn't affect the overall accuracy of the calculation, but still, you know, it was a, it was a thorn in our side. And so we said to Randy, I said, Randy, what can we do about this? And he knew of more sophisticated transport algorithms. Would eliminate this spurious, flow temperature. So those are the, those are the kinds of things that, that Randy brought to the table. A lot of it is under the hood, know, you don't notice a lot of this stuff, but it was absolutely necessary in order for us to continue. Because as we start using, you know, near flame temperatures for extinction and suppression and those sorts of things, you know, if you have these fictitious values, You can't do anything. So we really needed to tighten up the basic algorithm before we could move onto to other things. So, so we needed someone, we needed like a, a real cfd.
Wojciech Wegrzynski:
you, you needed Randy. It's great you got him. Fantastic. I remember from those times, a lot of, discussion on Jet fans and, how the core is solved. you, I think you went to like two or three durations of the l e s model at the.
Kevin McGrattan:
Yes. Yeah.
Wojciech Wegrzynski:
case of, having to put a pressure inlet every mesh to, to keep the background pressure. I, I mean, of course, a of things, but,
Kevin McGrattan:
another thing that Randy did is that he coded up into fds all of. Like most popular turbulence models. So when we say l e s, there are about half a dozen different ways of representing the viscosity of the gas. Okay. And you, you've heard like s gorinsky, that's one type and then there's a, there a variety of others. And Randy coded up every single one. And then we ran all of our test cases with all of these different turbulence. And the one that we came to, which is known as the Deardorff model, is the one we're using now simply because over the wide range of our applications, this one performed the best.
Wojciech Wegrzynski:
And, and now having this, massive, uh, library of, of reference cases,
Kevin McGrattan:
Yes,
Wojciech Wegrzynski:
in such a better position to understand and it changed to the code. You do
Kevin McGrattan:
yes, yes.
Wojciech Wegrzynski:
understood, every night you run the simulations again and again and again
Kevin McGrattan:
Right,
Wojciech Wegrzynski:
for errors, right.
Kevin McGrattan:
right, right. And we also, we run these validation cases. So if, if we introduce some new, variant of a, of our extinction model, we can run half a dozen different test series and see, okay, are, is, are we improving or are we getting worse?
Wojciech Wegrzynski:
That's,
Kevin McGrattan:
and we can do that literally within a few days, whereas before. Something like this would be, you know, something a graduate student would spend two years doing. Now we can do it in a couple of days just because we have all of this stuff at the push of a button. So we, we just simply make the change in a test version of the code. We push the button a couple days later, we look at the results and we can tell whether or not, you know, things are getting better or things are getting worse.
Wojciech Wegrzynski:
how big is the team nowadays?
Kevin McGrattan:
So, the core people, it's, it's basically myself, Jason Floyd, Randy McDermott, a fellow named Marcus Vanella who's, who's working on the, non rectangular geometry,
Wojciech Wegrzynski:
Hmm.
Kevin McGrattan:
Simo And, and his students, uh, help out. Um, Glen Forney is doing smoke view plus a lot of the, um, the IT support. and then we have, we have various other people, um, Susan Killian from Germany, for example, you know, sometimes works on the pressure solving features. but the day-to-day, maintenance is myself, Jason, Floyd, Randy and Marcos we're the ones when you, when you send in an issue tracker, it's gonna be one us who takes it.
Wojciech Wegrzynski:
such a big, How to even say it. I mean, uh, is, this is not important for fire science. This is fundamental for fire science. You know, this, I, tomorrow F ds disappeared, would be like a stock market crash in the world of fire science and engineering. So,
Kevin McGrattan:
Well, we, one of the reasons why we've put together this kind of elaborate, set of online tools like, you know, the Gith. is that if we were all hit by a bus tomorrow,
Wojciech Wegrzynski:
Hmm.
Kevin McGrattan:
someone could step in and, and take over. I mean, that's the beauty of open source software.
Wojciech Wegrzynski:
Hmm.
Kevin McGrattan:
I mean, we do the day-to-day maintenance, but there are others who are kind of following us in a way
Wojciech Wegrzynski:
Hm.
Kevin McGrattan:
who if we went away, they could step in and, and take it over. So we wanna make sure that this thing lasts longer than just.
Wojciech Wegrzynski:
I I think the, and I think the impact, uh, of the tool is tremendous. Okay. Kevin, that, that was fascinating to go, uh, through the development of fds. I I think you've cleared a lot about, the origins and, and the solver and how it was built. It's, it's a fantastic so story. I was told It's a good story and, and it truly is. um, yeah. Thank you very much for coming to the
Kevin McGrattan:
You're welcome.
Wojciech Wegrzynski:
Thank you very much for, uh, building this for us.
Kevin McGrattan:
Okay. I enjoyed it.
Wojciech Wegrzynski:
And that's it. Oh man. so good. It was on the podcast bucket list. We have Kevin talk about FDS on, on the air. And it finally happened and I'm super happy to have conducted this interview. So many golden nuggets from the early days of FDS development. So many interesting insights. How the model grew. What's Power to this growth and, how it changed over the years? the most astonishing part I think is, uh, how it was built as an academic tool. And then it quickly was rediscovered as a commercial powerhouse. Now. It's fueling so many companies around the world. So many people are basically FDS engineers nowadays. And that's great. That's great that the tool. Uh, developed by scientists. Powered by fire science has found away. To fire engineering, what's the better testament or for fire science and the need of. Development of fundamental stuff in this field. What's a better example of how great investment fundamental fire science can be. If you really enjoyed this episode and you would love to. hear Kevin, once again. Uh, I have. Nice for you. So there's no, the only Christmas special episode, but there's also, let's say new year's special episode coming your way next Wednesday. And that's Kevin McGrattan and again, And we're going to talk about experiment that has certainly changed the fire science. And this experiment was the investigation after the World Trade Center collapse, which is also heavily tied into the developing the fDS and, uh, How the software had to be changed to. Um, make. This investigation, the possibility. So I hope you will enjoy it as much as this episode. And for now. thank you very much for being here with me. Thank you for sharing your listener experience with me, I've received so much feedback through the listener experience survey. Uh, I'm very, very happy with that. And very glad you did. Share that with me, I'm going to dedicate a half of the Q and a episode in early January answering some of the stuff. I cannot just reply you with an email because it was kind of anonymous. But, uh, I'm going to reflect on what feedback I've received in the QA. And I'm going to tell you what I'm going to do with it. What's the outcome of the survey and what I have processed out of that. Um, one of the Fitbit was to make this outros shorter. I seem to just fail, incorporating that one, but I'll improve. I'll make this thing more concise in the future. Anyway, thank you very much for being here with me. Christmas coming soon. So if you celebrate Christmas or Christmas to you and your family, I hope you have a lovely time. If you don't celebrate Christmas, just have a great time around there. And, uh, I hope you will find some joy in the calmness and, escape from the mad world that surrounds us. In this special time. this year not taking any Christmas break. I have a podcasts prepared all the way into the new year. So next Wednesday, I see you here again. Thank you. Bye.