Fire Science Show
Fire Science Show
205 - FDS maintenance and development with Randy McDermott
Dr Randy McDermott takes us behind the scenes of fire science's most critical software tool in this conversation about the Fire Dynamic Simulator (FDS) developed at NIST. As one of the developers, Randy offers valuable insights into how this essential modelling tool is maintained, improved, and adapted to meet the evolving challenges of the fire safety community.
The conversation begins with a look at the development process itself, based on a greater picture roadmap and also addressing practical issues reported by users. This balance between vision and responsiveness has helped FDS maintain its position as the gold standard in fire modelling. Randy unpacks the massive validation guide (over 1,200 pages) and explains how users should approach it to understand model capabilities and uncertainties.
The guide, along with all the validation cases, is available at Github repository here: https://github.com/firemodels/fds
Rather than blindly applying FDS to any problem, he emphasises the importance of identifying similar validated cases and understanding the limitations of the software for specific applications. The discussion tackles emerging challenges like battery fires and mass timber construction – areas where traditional fire modelling approaches face significant hurdles. Randy addresses the limitations of current models while outlining pathways for future development, including potential integration with external specialised models and improvements in chemistry modelling.
Finally, we also get to talk about computational costs and efficiency. As Randy explains the implementation of GPU acceleration and the challenges of incorporating detailed chemistry, listeners gain a deeper appreciation of the tradeoffs involved in advanced fire modelling.
Whether you're an FDS user, fire safety engineer, or simply curious about computational modelling, this episode offers valuable perspectives on the past, present and future of the tool that underpins modern fire safety science.
Oh, and Randy is not just an FDS developer - he is also a prolific researcher. You can find more about his scientific works here: https://www.nist.gov/people/randall-j-mcdermott
As always, MASSIVE THANKS TO THE NIST GROUP AND THEIR COLLABORATORS FOR BUILDING AND MAINTAINING THE SINGLE MOST IMPORTANT PIECE OF SOFTWARE WE HAVE!!! You guys are not thanked enough!
----
The Fire Science Show is produced by the Fire Science Media in collaboration with OFR Consultants. Thank you to the podcast sponsor for their continuous support towards our mission.
Hello everybody, welcome to the Fire Science Show. In today's episode we're going to talk about the fundamental number one tool used by the fire safety, science and engineering communities, and that is the fire dynamic simulator, the FDS, the inclusive D-model that we all use, and if you don't use it well, then you are exposed to it in some way, one way or another. It's just so prevalent in the discipline and I've had episodes with the creators of the FDS, some of the people from the group that creates FDS. I had great episodes with Jason Floyd. I had Kevin McGrath talking about the history of FDS, how it came to life. If you're interested and have not heard them, I highly recommend you to do that. And today we're more discussing the future of FDS or more just what's happening with it right now.
Speaker 1:I've invited to the podcast Dr Randy McDermott from NIST, and he's one of the main developers of the software, and Randy was kind enough to answer a lot of difficult questions about the current state of the models and the problems that the FDS development team is facing and some ideas for solutions for the future. So in this podcast episode we will cover some of the models of FDS, where they are and where they are heading, we will discuss the validation guide and how to use it. To some extent. I think that's a very interesting concept. That's a very rich literature piece. The validation guide of FDS. It's enormous, it's beautiful, and Randy tells me how he sees people using that and how he would like people to use that. So I think that's a very practical take out of this podcast episode and besides that, you will learn a lot of things about the inside of the FDS that you perhaps have not known. I have not known them for sure and I've learned them here. So episode's packed with information, new information and Randy's just a great guy to talk. There's not that many people getting so excited talking about physics and I really love this vibe. So let's not prolong this anymore. Let's spin the intro and jump into the episode.
Speaker 1:Welcome to the Firesize Show. My name is Wojciech Wigrzyński and I will be your host. The FireSense Show is into its third year of continued support from its sponsor, ofr Consultants, who are an independent, multi-award-winning fire engineering consultancy with a reputation for delivering innovative safety-driven solutions. As the UK leading independent fire risk consultancy, ofr's globally established team have developed a reputation for preeminent fire engineering expertise, with colleagues working across the world to help protect people, property and the plant. Established in the UK in 2016 as a startup business by two highly experienced fire engineering consultants, the business continues to grow at a phenomenal rate, with offices across the country in eight locations, from Edinburgh to Bath, and plans for future expansions. If you're keen to find out more or join OFR Consultants during this exciting period of growth, visit their website at ofrconsultantscom. And now back to the episode. Hello everybody. I am joined here today by Randy McDermott from NIST. Hey, randy, hey.
Speaker 2:Hey, wojciech, good to see you.
Speaker 1:Mr Randy, good to have you in the podcast. I'm ashamed. It took over 200 episodes to get you in the podcast.
Speaker 2:Oh, no way, man. I'm a big fan of the show and I'm very happy to be asked and to be here.
Speaker 1:Yeah, I know you are and I'm ashamed I didn't ask you earlier.
Speaker 1:but well, some things are worth waiting for and I still have to keep some big names for upcoming episodes. I cannot shoot all the stars in like first 20. So here we are. When I started the podcast, I said the reason is I want to preserve some of the fun conversations happening in pubs and informal settings where scientists open up, talk freely. You know, and what I have in front of my eyes is Yulisha, summer school and the times we spend in pubs talking about CFD.
Speaker 1:So we can recreate this atmosphere in the podcast, so good. Anyway, randy, we're going to talk about some CFD, we're going to talk about combustion, we're going to talk some hardcore fire science. But one thing I don't know about you what was your pre-FDS background? How did you come to the world of fire science and developing the most critical piece of intellectual property we have in this?
Speaker 2:in this space.
Speaker 2:So my background is chemical engineering.
Speaker 2:Okay, I went to a university of Tulsa in Tulsa, oklahoma, which if you know Oklahoma, it's got a long history in the petrochemical industry, and I worked at a company called John Zink that makes process burners for the petrochemical industry and worked at a company called John Zinc that makes process burners for the petrochemical industry and I was a project engineer and test engineer out there for several years and we ended up hiring a couple of people who had close connections with the University of Utah, which is how I managed to go out there for grad school to work with Phil Smith, who's in chemical engineering, and he was one of the, I think, first CFD people for coal combustion and this sort of thing.
Speaker 2:So he had a very good CFD group and they were just starting to get into developing a code for a large eddy simulation when I got there. So that's kind of where I got started and it was very fire-related. They were part of the Department of Energy's ASCII project, this Accelerated Strategic Computing Initiative, and their grand challenge problem was to predict the time to explosion of a plastic-bonded explosive bathed in a pool fire a large like gasoline or jet A pool fire Sounds like a battery fire.
Speaker 2:Yeah, yeah, it was, that's right. I mean, I think a lot of the stuff that ended up getting developed for that would be very interesting to apply it to batteries. There was a material point methods and a lot of solid phase.
Speaker 1:interesting solid phase structural were well into five um by the time I arrived in 2000 end of 2006, beginning of 07, I would say for me, fds5 is is the first one I can say I I knew like that was probably the version I've started learning and, and when I uh transitioned into professional career fds6, I was just delivered back then.
Speaker 2:And well, that's like 2013,. I think that was. 2013 is when I think we released that.
Speaker 1:Also, there's like a hundred versions of FDS 6 ago.
Speaker 2:Yeah, yeah.
Speaker 1:Okay, so you seem to update the software very often and now I have some questions about how you do it. Not in terms of programming you can tell me a bit more if you like it but I really wonder, like, how do you choose the pathway of development of FDS? Is there like a blackboard in Kevin's office where like a pathway till FDS 10 is already outlined? Is it problem by problem issue tracker thing?
Speaker 2:It's a little bit of both of those things I would say there is I'm looking at a whiteboard I have in my office of things that I'm working on. We do have on our GitHub wiki page a research roadmap which many people have probably looked at. We try to keep that as up to date as we can. That's also in place. Hopefully, if someone's doing graduate school research or something and they're interested in a topic, we might collaborate or something like that to kind of give an idea.
Speaker 1:Okay, that's a good call to action. So, github Wikipage, there's a development roadmap and if you're running a project you probably would like to align it a little bit with the the roadmap.
Speaker 2:then there's a chance it's going to get sure, and you know, and just you know, there may be things that need to be on the roadmap that aren't, you know, and so always feel free to connect with us. Um, there, you know the, the discussion forum and, uh, the issues page. I think people are. We've we've transitioned now over the last year over to purely using github instead of google groups. You probably know that. I think that that seems to be up and running.
Speaker 1:It's certainly keeping us busy, so I think that people have gotten used to that, that switch at this point and like, if you had to give me like a percentage, how much of your time is this uh big roadmap development and how much is patching the, the stuff that comes like your way every day on the?
Speaker 2:issue tracker yeah, I mean, it's probably 90 issue tracker, I would say, and hopefully you know some of those things. We try to manage them in a way where, okay, we see 10 issues come in and and maybe all 10 of them have some relation to extinction or some other problem that's somehow related, the headaches that get created in these very complex geometries with hundreds of unintended pressure zones that are pressurizing and blowing up and so on. When we can, whenever we can find a common thread and we can knock out, you know, several problems at once, then we obviously try to do that.
Speaker 1:Do you do some kind of triage? Okay, this problem seems super like burning, super urgent. This one looks like okay, it's like a very narrow. How do you evaluate them? Which one's next to take?
Speaker 2:yeah, I mean, you know there are some. Somebody demonstrates an energy conservation problem, for example, that gets our attention.
Speaker 1:Um okay that's a way to get your attention back.
Speaker 2:For example, that's the famous Borschtok verification case that came in, and similarly I'm thinking of Dan Swenson sent in a case a few years back maybe several years back at this point where he showed that there was some violation of realizability in the composition of species under certain situations and that led to basically a complete overhaul of the way we transport, so that you always have some error in the nth species right and you have to somehow absorb the error into the species.
Speaker 2:Usually it's nitrogen or something like that that's in abundance and you can afford it. But Dan showed that even in those situations you can get violations, and so that that led us to and jason and I public ended up publishing a paper, I think, related to that, that overhaul. So those are the kinds of things that definitely get to the top of the of the issue list very quickly when we see those, those problems I ask those questions because you know you are keeping up the critical piece of software for this branch of science, really, like I don't know.
Speaker 1:there are those memes in the internet like with, like some enormous system and all of it is standing on a little wooden leg which is like an open-source piece within the 90s. You know, I have a feeling a lot of fire science is standing on the shoulders of FDS and FDS development. So this definitely is critically interesting to me. How does this software grow and mature and develop? Especially that you know when I look how people use FDS it's absolutely crazy, like I mean, the variety of things people apply FDS to. A normal thing for me would be smoke control in buildings. You know there are those. I think in Handbook version three there were already those beautiful renderings of buildings and Kevin in the podcast said that he was surprised when people started applying FDS to smoke control in buildings and they were starting getting great, great outcomes. And I also did that.
Speaker 1:This is for me the normal use of FDS. Let's say, a compartment fire, that's for me a normal use of FDS. I see a program which is a buoyancy-driven flow solver for fires, compartment fire. Here we go right. But then I see like microgravity fires Okay, that's like one variable less, but still like a little quite interesting variable to play with. Then I see some applications like cone calorimetry. People simulate cone calorimetry and extremely difficult material properties change with FDS. I saw people do quite complicated heat transfer problems in FDS. I've seen people do firebrand transport. I've been a part of a group that was doing firebrand transport in FDS. I see people applying that to batteries, electric vehicles, suppression. There is such an endless number of uses of this single code and yet it works on one kind of default set of of physical models that you've picked I.
Speaker 2:I find it like difficult to grasp that this one set works for, for everything so well, I mean, do you, do you really think it works for everything, right? I mean I mean it's I.
Speaker 1:I find it unreasonable to to think that they're perhaps I'll rephrase it like I always seen fds as like this brilliantly curated list of physical models which are best for fire problems. Like you go into three-star Michelin restaurant and you tell chef, just give me the best what you have. And this like you guys curated, this beautiful list of models that are fine-tuned to fire problems and get applied. But again, it's hard for me to imagine the same solver can handle chemistry of a battery and fire on a space station. It's just like for someone who works with modeling it's hard for me to grasp.
Speaker 2:Well, I mean, I don't know that we've yet nailed chemistry in a battery.
Speaker 2:But you could try I mean that's something where you know chemistry just at least gas phase chemistry is something that we're very new to. A new member of our team, chandan Paul, has been working closely with Jason and Marcos to implement chemistry and he's made a lot of progress over the last year. But we're starting to run into the same headaches that everybody who's done chemistry runs into, which is that it can be very expensive and just getting the fluid mechanics and everything right with it. It's very interesting. You start to see like why the sort of eddy dissipation models work well in fire, because you've got to get the fluid mechanics, the buoyancy and the mixing and everything right first before you apply any chemistry to it. And it's tricky. I'll leave it at that for now, but it's not an easy problem.
Speaker 1:If there is, let's say this, infinite number of problems that FDS can be and is applied to, do you have, like your core set of problems for which it has to work the best, and then whatever else it works for is an addition, or yeah, I mean I guess I should have continued on with from your previous question, just saying, you know I'm bringing in the whole idea of the validation guide.
Speaker 2:I mean that is to me the glue that allows this sort of like one set of parameters, or these default parameters, to work well across a large set of problems. Right, and it's somewhat of, I mean, I guess you could kind of try to think of it as like of an optimization problem and maybe, yeah, maybe someday an AI will come in and, you know, optimize all these parameters in the best way, given, you know, a set of validation targets. Maybe that's ultimately where things will be headed. And you know, I would say that what we've done since I've, you know, been around the team is we try to do this somewhat manually and in a way that we think makes sense.
Speaker 2:But it's an art. You know that part of it. You know there are choices to be made. They may not be optimal in every situation, you know, especially when you're trying to meld. You know these Lagrangian methods that, as you know, you mentioned firebrands and things like that, and of course these things are getting used, you know, for wildland fire modeling and to represent geometries that can be resolved and these sorts of things, and so you know what sort of parameters you use and what correlations you end up using to account for heat and mass transfer, and these sorts of things are all part of the sauce, as you say, for what the default results of FDS will be.
Speaker 1:I have the validation guide in front of my eyes. I just downloaded it freshly.
Speaker 2:I probably better get that up if you're going to start peppering me, I'm just going to drop.
Speaker 1:You know random chapters and you have to tell me what it is about and how it's relevant. No, just kidding. I'm looking at it. It has 1,200 pages, so it's a third of the handbook. In scale. It's massive.
Speaker 2:I think we're up to 8,000 plots that get made, or something like that as part of the Congratulations.
Speaker 1:That's a sensible achievement, congratulations. I just like, like now, go for 10,000,. I guess it's a good job to create this insane body of reference material. How do you, as a developer, how would you like people use this body of literature? Because I will be a voice of the industry or no, I'm going to be the voice hated by the industry because I see how industry uses it. A lot of people in the industry would be using. They just download Fds. It. It's well accepted. Everyone knows fds in this space. Like you don't really have to prove fds works. Also, you know I'm I publish a lot of answers, fire simulations. I always have to justify why I've used answers randy. I always have to justify. But uh, half of the papers I publish with fds I usually just write it's a state-of-the-art software for fire and that's it which is fine, which is fine yeah, I mean I'm with you on in that, in the sense that that shouldn't be.
Speaker 2:It shouldn't be. You know, I don't think it's a good, it's a healthy statement to to just take fds uh to be, to be okay for for any specific problem. I do think that there are classes of problems that we have enough confidence in our because we've done. We have several examples of them in the validation guide. Uh, you know they span the. You know the range of the parameter spaces that that are are relevant to to fire protection engineering and when, when that is the case, for example, upper layer temperatures and so on in compartments. I have a lot of confidence that we're going to do that right. You know, again, when you have a specified fire size and so on. We've talked about that offline a little bit. But, yeah, that to me is how I would like people to use the guide is to look for classes of problems, and we do have a range of I think we spell out in the guide.
Speaker 2:Here are certain types of problems, whether they're compartment fires, fire spread and so on. Some of the things we obviously do better than others. If you go look at CO prediction in a compartment, for example, example, your uncertainties are going to be much higher than than if you're looking at upper layer temperatures, for example, or doorway velocities or or, um, you know, pressurization and and things like this. So hopefully those scatter plots give some sense of where the uncertainties are when they're tight. Then I would say you know, we're those classes of problems we're doing pretty well, but there are, especially anything involving fire growth and flame spread tend to have uncertainties that are, you know, much, much higher than so.
Speaker 1:So it would be something like I have a problem. My first look, there's chapter two which summarizes stuff that has been done. I'm probably would like to find a case similar to mine in the validation guide, at least in the scope. Then I see what kind of range of variables. So let's say I want to simulate wind and I look into your wind cases. So if I want to simulate a tornado I probably will not find a reference case.
Speaker 2:You will not find a tornado. You do not find an example.
Speaker 1:I mean, it's fit to do wind, but perhaps not this type of specific atmospheric phenomenon. I don't see that specific like go deeper, find a specific phenomenon or specific thing you're investigating, find the reference case. Look at the range of uncertainties. Also, like if there's a validation guide about this case but it's from one to five kilowatts, it would be not very advisable to do a 10 megawatt fire, for example, like something completely out of range with it.
Speaker 1:That's right, or at least to find a different reference. Or perhaps you just have to do a reference experiments right.
Speaker 2:Exactly Like. I mean definitely. You know experiments are the key right to having confidence in the models and you know I've had a lot of discussions some of our favorite researchers about. You know it's okay, given that you have to have experiments to validate everything. Like what good are the models really? To validate everything? Like what good are the models really? And, um, you know, I I look at it and and, from the standpoint of the, the models do provide some more interrogation of the, of all the fields that you that you get in the particular application species compositions, you know, heat fluxes and and so on and in the ideal world, the experiments and the models are sort of corroborating one another. You know, in terms of okay, I think this happened in the experiment, I see that in the model. Okay, I think that are my physical understanding of why this was happening in the real world and that's also showing up in the model. Then that makes me feel like I understand the phenomenon. If those two things are wildly different, then I need to maybe rethink what's going on.
Speaker 1:And the reason I'm bringing this discussion into development is that I simply observe a really unprecedented, I think, growth of the discipline in terms of topics that we're covering. The times are so exciting, really, like with all the battery, battery stuff, the must timber stuff, the wildfire stuff, that's that's happening.
Speaker 1:I mean, I lived in the world of you know simple compartment fires and shopping malls and smoke control for a long long time and now I I see all those interesting, you know directions in which the whole discipline is moving forward right and definitely you, you are a battery researchers, you researcher, you know fds. You probably would like to do some simulations related to battery fires, like you probably have not thought about battery problems 10-15 years. If you did, I congratulate you for being visionary. But mean, I have not thought about lithium-ion battery problem 10 years ago, right, mass timber I have not thought in 2010 about mass timber before the age of CLT in buildings. So it's just some things that the industry is moving into and needs answers fast. So I wonder about the applicability of FTS to those new problems and also your response as the FTS development team to those new problems. Kind of trends, you know you can consider them trends in science, because today there's probably more people doing battery fires than I don't know compartment fires at this point of time.
Speaker 2:Right, yeah, so it's a great question and a good topic. I mean the old note, since you have the validation guide in front of you. There is not a chapter on battery fires.
Speaker 1:Yeah.
Speaker 2:There's not a chapter on battery fires. Yeah, there's not a chapter on mass timber, right. So these are definitely challenges for us and I take those two applications to be somewhat different in the sense that I mean. So we were talking about this before like with batteries, what I've noticed is and I'm not an expert on batteries at all, so I'm coming, I'm sort of just brand new to to all of that, but we, you know, we try to look at you know what parts of the code, where are there gaps? And you know, from the problem that I've always had with the, with trying to, you know, quote, unquote, you know, model a battery fire in FDS is. I want to try to press people on. What do they mean by that? Cause it's quite that's a big statement. You know, can you model? Can you model battery fires?
Speaker 1:It's like I do computer simulations Like what exactly do you mean by computer?
Speaker 2:simulations, Right, so math. So let's like right, let's write the problem down, Like, let's formulate it in a way that you can solve it on a computer. And what do you mean? And when sometimes people say, oh well, this thing is going to be venting, you know this much gas at this rate, and I just want to see what the fire plume looks like.
Speaker 2:And I say, okay, well, fts can do that right. I mean, that's kind of a trivial application depending on the speed of the jet and so on. Of course, yeah, low on and and of course, but low my assumption, yeah, I mean. But then some people, oh, you know, you know we need to do the, you know the, the structural deformation of the battery and the thermal runaway, and and then you know the subsequent off-gassing and the kinetics of the chemistry and basically like the full, the full.
Speaker 2:You know principles, thermal runaway problem, and I think quite obviously that's way, way more than FDS can handle at the moment. I think you know there may be cases when we finally wrap our arms around it, where we we can do the pressurization stuff, but I don't know that that's necessarily the main problem that people have.
Speaker 1:Can I ask you a follow-up question on that? Sure, I'm pretty certain about capability of FDS to model a building. I know there has been a lot of validation regarding cargo spaces in airplanes, also related to pressurization and fires in confined spaces. But what if you use the same set of models to simulate a battery that can fit on a desk like 20 by 20 centimeter by 10 centimeter size pack? Can you use the same software and everything to simulate it at that scale? Just use some millimeter mesh? Would that work? I have not tried.
Speaker 2:I mean, again it comes back to whether or not you're predicting the, the, you know the mass increase, um of the gas phase in that small compartment. To the extent that that is just a pressurization problem we should be able to handle that. But again you're in research territory.
Speaker 2:I would say um either way you go, I don't know larger compartments where. Again, where you, where you have specified um, mass losses, I think there are enough experiments out there that we've compared to that. We can say that we get the pressure losses and and even you know a lot of Jason's HVAC uh stuff does a good job of of you know connecting pressure zones and so on once the losses are known and all that kind of thing, I do have confidence. It may be difficult to get all those losses right and so on, but if you do know them then I think the pressures are pretty well.
Speaker 1:I have confidence in anything Jason does me too. I wonder if he, when he was building the hvac solver, I wonder if if he had a glimpse of idea what kind of crazy stuff where people will use that solver for, because it allows you to do some really funny things that work uh, I think probably, because I think he was probably developing the controls in parallel with it and thinking that those two together were going to be a lot of fun.
Speaker 1:I need to bring him back to the podcast so we can discuss all the fun things you can do with HVAC solver. You mentioned chemistry so I guess for the chemistry of the batteries the same thing. If you are interested only in the products, you have your custom reaction. You can spec the yields of products, put it directly to your uh reaction, or or perhaps just vent the gases directly from the the same mass source along with with your fuel, and you're good. And if you want to simulate like complex chemistry of a battery, then this is not the territory you are able to apply this software.
Speaker 1:Yeah, I mean you're talking about, like the solid phase kinetics of the I'm talking about all the things that are happening inside the cell from electrolyte decomposition.
Speaker 2:Yeah, we don't do any of that.
Speaker 1:I don't think so. But if you know the yields, you can put them in and have a fairly representative source and you're back to the region of simple right, Right.
Speaker 2:Yeah, it's like. Yeah, it's like. It's like predicting these things versus knowing the yields, as are two different worlds, right.
Speaker 1:When we were prepping, you said something similar about fires, like if you specify a fire, that's a completely different set of challenges when you want to predict a fire, and for me it's, I guess, a pet peeve or something that triggers me a lot when I see people oh yeah, I used a computer simulation to predict the fire and I'm always oh really did you?
Speaker 2:That's funny.
Speaker 1:And I've never seen anyone did, perhaps a few times. I've seen a really good attempts at, but not yet there. Can you elaborate on?
Speaker 2:that.
Speaker 2:Sure, I mean I think you know when we talk, when I'm talking specified, I think you know we're talking about a sand burner with a prescribed heat release rate and we generally, you know, kind of falls into the category of of, like the compartment fires that we have in validation guide.
Speaker 2:I mean these are, or the, you know, the McCaffrey plumes, or the Heskestead plumes and so on.
Speaker 2:I mean we think we have a reasonable handle on that. You know it's not perfect for sure, but I mean, when you get into the world of, of trying to, you know, predict the mass loss rates of fuel, I mean the solid phase in and of itself has its own challenges and, you know, providing the right heat flux to a surface has its own challenges. And I think that there are a lot of uncertainties in when these two systems get coupled. And I think this is one of the the reasons why the whole um, you know, mac, fp measurement and computation of fire phenomena working group, you know, really took off is because it is to me one of the the first efforts to to try to bring together the people that are working in the solid phase and the gas phase and to, you know, force them into the same working on the same set of problems and you start to see where these uncertainties are and how hard these, this coupled set of problems, is for fire growth and flame spread.
Speaker 1:It's kind of funny in fire because if you just have a compartment fire and you have a megawatt-ish size of a fire, you simulate that it's very easy to get like pretty close results. You know, in a very general case I would say it's not hard. But if you try to predict like exact value of convective heat transfer to a thin wall from a flame or, you know, heat transfer towards the surface of solid objects on which the fire is spreading, especially if you have a more complicated material underneath, those problems become quite crazy in terms of how hard it is actually to narrow the uncertainties to a level where the simulation is accurate. Perhaps the dishes are within the uncertainties. I don't.
Speaker 2:Yeah, I mean you said it all exactly right. I mean that's the challenge. I mean there's the. You know large-eddy simulation is quite a powerful technique. But you know, if you go back and you ask anybody, they don't even have to be from the FHIR community. You know what is the most challenging thing to do with large eddy simulation. They will tell you the boundary layer right. That's why there's a difference between so-called large eddy simulation with near-wall modeling and large eddy simulation with near-wall resolution. And in FHIR, as practiced currently, we always do near-wall modeling modeling and that means that you have a subgrid model near the wall and these are.
Speaker 2:This is an unsolved problem, you know. It's like what is the best near wall model and a lot of what we have used in fire protection engineering focuses more on the global sort of like integral scale results of the large eddy simulation. You know, do you get the flame height Correct, okay, you know if you've got. If you're prescribing a radiant fraction, are you getting? You know the your, your radiation heat flux to the target right, and so on.
Speaker 2:But when we're doing fire growth, it's it's a matter of getting things correct locally right, and we don't have that much in flame fire data to validate these models. There are very few experiments, right? I mean, if you look at, just even if you look at heat, what we call, you know flame structure. In other words, if you just look at the heat release rate, like, say, the center line heat release rate in a in a fire plume, you know the data that the only validation case we have for that in our guide um are franco tamarini's experiments okay right and we are not grid converged on in that particular validation target, right.
Speaker 2:So grid from converge, meaning like what people typically use for engineering you know level gr and then so if you don't, if you don't have the heat release rate as a function of height above the burner to be grid converged, okay then like that, local heat release rate is what is radiating or you know, transferring heat to a surface, and so now locally, you know you have uncertainties there and I think these things compound these uncertainties. It's a nonlinear system. These things errors on one side of the model, whether it's gas phase or solid phase, I think feed back and it makes it a very much harder problem.
Speaker 1:I don't think people are correctly doing mesh convergence in engineering. Really, I think what's happening is people just, you know, because it's expected, they just use two, three different mesh sizes, which are, let's say, 5, 10, and 20 centimeters, and you end up with not big difference between them. So you pick the 10 because 5 calculates too long and you just go with it. And I see that not just in engineering, in engineering.
Speaker 1:In engineering is a blessing if there's any sort of mesh convergence study I see that in research papers, whereas this falls into this kind of false assumption that the convergence is linear in the across the size scale, like if you haven't went to a millimeter, how can you know? I mesh convergence starts to make sense if you start to directly resolve more and more phenomena at the scale at which they happen. I don't see a big difference between 5 and 10 centimeter mesh really, but that's an off topic.
Speaker 2:Perhaps we'll it depends on the problem, right?
Speaker 1:Of course, yeah, of course.
Speaker 2:Because it's got to be relative to what is the link scale you're trying to resolve.
Speaker 1:Exactly exactly. Yeah, that's exactly what I meant. I mean, if you're resolving a fire plume at the scale of a compartment fire, it doesn't really make that much difference because you already get plume ride in the 10, 20 centimeter region. I mean you don't need to go to a millimeter. But if you are investigating a heat transfer to a specific item which is very small, therefore you have very high convective heat transfer, Like we were simulating, for example, fiber heat detectors recently, which is extremely thin object in your smoke layer and that gives crazy values of convective heat transfer coefficients. So if I just stopped my grid convergence study at 10 centimeters, yeah, well, that's not really the scale at which I'm trying to resolve the object, but again, that's a different conversation. I've also brought mass timber to the mix of topics that we had. So I'm wondering about the state and future of pyrolysis modeling in general, heat transfer to to solid and what's happening with the solid, because I I think it's also extremely interesting to people to capture timber fires yeah, I'll try to to give my impression upon this.
Speaker 2:I mean, I'm I am not the pyrolysis expert on the team um for sure, but and in this, but when it comes to timber and, for example, char oxidation, I think you know you've had Eric Mueller on the show and I think Eric is doing probably is most closely connected with maybe CMO's group as well, looking at char oxidation and wood pyrolysis, char oxidation and wood pyrolysis. So Eric has recently introduced what we think is a better approach to doing the oxidation step, oxidation profile, prescribed oxidation profile. But maybe where you're going with the question is you know there are other pyrolysis models like G pyro that do gas phase transport or solid phase transport of the gaseous species and I was mentioned. You know there are a couple of groups that are interested in connecting uh g pyro um with fds. I know chris laubenberger had done that. It's one version of fds. I think he's got it in his repository in the g pyro um repo and I know Guillermo's group with Alexander Castagna has looked at sort of maybe reviving the GPyro-FDS connection. So we've been talking with them.
Speaker 1:It's like introducing an external model to work along with FDS right.
Speaker 2:Right, we're getting a little better at. You know, this becomes a software engineering issue, right? Who's going to maintain the code? Um, we're not. Our group is at the moment probably not in a position to maintain g pyro. Yeah, of course, right, but you know we're it's, you know we're supportive of, of the idea of making this, this connection, and then it becomes a matter of like how do we, you know, create a reasonable api for g pyro to connect into fds, right, and? And so we've got, we're getting a little bit better at using libraries. We do that, for example, now with our pressure solver and the chemistry solvers, their external libraries developed at Lawrence Livermore National Labs, and Chandan has figured out ways to make that fairly painless, to hook these things up.
Speaker 1:I mean that's a potential future for the software I mean with all, let's say, battery models. I would not expect you guys now drop everything and start developing a battery model because so many people want that. Or I can see a group in the world somewhere emerging that wants to create a, let's say, sub model for a module fire that doesn't do cfd but gives you a prediction of of this off-gassing species that you can then implement into FTS. Are you creating bridges that would allow such developments to be introduced to FTS? If I would like to start something like that tomorrow. Would that be possible?
Speaker 2:We don't have the concept of like ANSYS, of like a user-defined function.
Speaker 1:if that's where you're going, Well user-defined function is something else, because it gives the user freedom. But I would think about there's a group that has resources that can build a model and, let's say, maintain it for five years. Could you make a system in such a way that the user can link this model with FDS, have it working? One day the model dies because they lose the attraction to keep it up, but FDS goes on and that model is vanity, whatever. So you don't gain, you don't lose anything in FDS, but someone can plug in something into the code. Is there a path?
Speaker 2:Well, it's a great question. So I guess the only way I can answer that is to look through history and also maybe look to the future. So to start with the future, you know, we hope that this connection with GPyro is an example of what you're talking about, right? So it's pretty clear that there's needs. There's some work that they need to do on their end to make GPyro sort of portable and able to connect, and then there's probably some work that we need to do on fds's end to allow that to more seamlessly happen so that we can make it sort of you know, you turn on model a, you turn on model b, because it's true that within fds there are a lot of things that get hardwired, um, and it's not as easy to always plug and play these things now. Historically, you know, an example where that did happen was like evac yeah, I loved evac.
Speaker 1:Okay, why did you kill an evac?
Speaker 2:I love that maybe, maybe that was a it was awesome tactical error bringing that up. Evac. Evac is awesome, but it was also. It became very impossible for us to maintain without you know, know, without Timo, you know at the ready and able to deal with it. So you know this.
Speaker 1:A huge effort to keep it up yeah.
Speaker 2:Because this tentacles were just everywhere and so every time we would need to, we started off talking about the program. Somebody has an issue, and we see these 10 issues all with the same problem, and we make the decision that we've got to overhaul, you know, this component of the code and all of a sudden you know we can't get in there and do it because everything else breaks. Um, because if it's tied to something that that somebody is not maintaining, so maintenance is long-term, maintenance is a real is a real trick. Anyway, there is no simple answer, I guess, to that. It needs to be sort of a tight collaboration at this point to have a module. But a battery module, you know, if such a thing existed, is something that we could discuss.
Speaker 1:I would say, though you already made some improvements in FTS that allow users to change stuff while the simulation is running right.
Speaker 2:Maybe you'd like to talk about those developments, sure, so and again I guess you get to talk about everybody else's stuff.
Speaker 1:So this is, I believe this is Give me a list of your stuff, Show me the blackboard, the whiteboard.
Speaker 2:Yeah the whiteboard, yeah the whiteboard. Pressure and turbulence, oh no. So, yeah, so there's a next and again, this is Jason's work with you know, with Julio, and they're doing this external control feature which allows you to read, for FDS to read and write files, and sort of stop and wait for some other while running.
Speaker 2:So, for example, julio does this with, you know, with a finite element model that he's running and FTS will generate, you know, heat fluxes that he reads as a boundary condition for his finite element model. Fts marches forward to a certain point that it stops and waits to get an output from the finite element model, and so on. So there's a two-way, a two-way coupling. I mean, I'd say that's fairly new if it's in quote unquote beta testing at the current time. So that's another thing. That is, a lot of these things can stay in beta if they don't get used a lot.
Speaker 1:Okay, you need a critical mass of testers of tests.
Speaker 2:Exactly. Yeah, it's a bit of a chicken and egg problem because I know a lot of people who are doing real life projects can't use something that's in beta officially. So until you know. But until we have real life projects, then it becomes harder for us to like really have confidence that that things are going to get out of the simple unit test phase.
Speaker 1:When you were talking about chemistry, you brought something up and I want to come back to that. You said that detailed chemistry can be very expensive, and I would like to put you on that word expensive. As a developer, I know NIST has pretty fancy computers so I guess you have access to a lot of computational power. But also whenever I review a paper. Coming back to the mesh convergence, the reason why they chose 10 centimeter mesh over five is that, due to computational resources, we had to choose the medium mesh. That's a sentence I see a lot. So undoubtedly that's something that a lot of users consider when choosing their models, their resolutions, basically building their cases. How important is computation efficiency and this expensiveness of simulations from perspective of a developer?
Speaker 2:Yeah, I mean we don't like to increase the cost of anything and probably I'm more guilty than anybody else with FDS-6 for increasing costs over 5. But that was an example where it sort of had to be done because the transport that was going on in FDS-5 with central differencing just led to a lot of spurious behavior for the temperature field and so we couldn't really tolerate that. And so that was an example where you know, increasing costs, you know, was we try to only do it if there's like a real physical reason. So similarly with chemistry we've run into problems like we're trying to do extinction, for example. I've always challenged. You know we've had into problems like we're trying to do extinction, for example. I've always challenged. You know we've had, and a lot of our colleagues we've always. You know we have these sort of like everybody's got their own extinction model and everybody's arguing for their own extinction model and a lot of times I would, you know, for the problems that we were throwing at the models. You know the critical flame temperature model was able to handle it one way or another, okay, in some reasonable way. And I said, you know, as soon as we have an example where this critical flame temperature model like physically cannot do the job. We'll start looking at chemical suppression and these sorts of things.
Speaker 2:And we ran into that, jason and I, when working with Paul Pappas and his team looking at sodium bicarbonate suppression. Because the mechanism there is a radical scavenging mechanism and you first have to get you know, first have to generate these radicals by decomposition of the bicarbonate, and then it's a chemical suppression mechanism. It's not a thermal suppression mechanism. After that we tried everything we could think of to try and trick the FDS model into doing a sort of trick, it into a thermal suppression situation, and it never, it never worked. So we said, ok, let's, let's get the chemistry off the ground. And so we're getting close on that.
Speaker 2:But that's been, you know, a year's effort, um or more to to just to get the verification step of the chemical mechanisms working. And, and that's that's even before we get into doing large eddy simulations where we don't really resolve temperatures, uh, on the, on the, on the grid, right? So anyway, that that gets beyond your question about efficiency. I mean the chemistry at the moment is super expensive relative to infinitely fast chemistry which is free, right, you can't beat that for cost. But if there's a problem that you physically cannot do, then the cost becomes somewhat justified. Right Now we have a plan for making it more efficient down the road, but you have to do things sort of one, one thing at a time. First step is to get get everything up and running and verified so that you you have you're doing things physically correctly. Then, once that's working, then we'll worry about the efficiency.
Speaker 1:Do you measure the efficiency when you do changes to the code, because you must be doing changes all the time.
Speaker 2:Oh yeah, I mean, we mean we have, you know, we have a continuous integration system where, as you mentioned earlier in the podcast, where we we have, you know, thousands of cases that get run, and each night we're running, you know almost a thousand cases, um, and we time that every night, and so if somebody introduced something that made that double in time that night, we would notice. First of all, it wouldn't finish when we think it should finish.
Speaker 2:uh, we wake up every morning, do an email from, from firebot is the name of our uh continuous integration system, and you know, if it's taken too long then then we'll look and and what happened Do you keep those results or you delete them.
Speaker 1:It must be a hell amount of data.
Speaker 2:They get overwritten every night for the nightly runs. The validation runs are. The outputs for validation are kept under version control.
Speaker 1:So there's a repository for. So there's a set of the reference cases and the bot runs new simulations every night to see if something changed, correct? So a lot of the cases have analytical solutions or and the bot runs new simulations every night to see if something changed, correct?
Speaker 2:Yeah. So a lot of the cases have analytical solutions or known solutions, and we have a system. That system in and of itself has become its own sort of behemoth of a code. So that's something we also have to maintain, and you mentioned about developments for using larger computational powers.
Speaker 1:We're definitely moving towards the era of GPU computations. It's inevitable that, well inevitable. It's something that we probably would like to have because of how efficient those systems are, and I've heard rumors about FDS development towards those GPU computations. Can you shed some light on that?
Speaker 2:Yeah, sure so, marcos, and Marcos Vanela, and.
Speaker 1:Again, I'm asking questions outside of your.
Speaker 2:Well, this I know a little bit about, just because, I mean, I've at least been involved in the planning of this, although the strategy has been because, you know, recoding everything in GPU is a, is a is tricky, you know you've, you're not as, you're just not as general general and it's not as portable. Um, you know, you pick up a certain GPU that you're programming for and you know all the promise of, of there's going to be some universal language that we can that will apply to all the GPUs hasn't panned out.
Speaker 1:I can only see this from the perspective of Ansys user and we're like third year of implementation of GPU solvers into Ansys and it's really slow in terms of how new models are implemented. And we're talking about billion dollar company which has, let's say, all the resources and thousands of engineers working on the problem. So I can imagine how big challenge it must be for a relatively small team that you guys have.
Speaker 2:So our strategy has been to not attack the problem directly ourselves but to leverage these libraries, that where other people are experts in doing this development. And so far we've landed on using the Lawrence Livermore libraries of HYPR for linear solvers and Sundials for ordinary differential equation solvers. So basically, the HYPR solver gets used for the pressure equation and the sundials CVODE solver, which is the backbone on GPUs, and so far we've done that with the pressure solver and Marcos has managed to get you know, I don't think I'm misquoting this factor of two or three speed up a lot of work on the oversubscription of the cpu side in order to make make that work. So it's it's definitely not not trivial on our end, but it's doable and it does show that that, like there is some, some benefit to be gained and to me that I mean that's to me that's the real hope of for chemistry is that we'll be able to you know, when we need to do chemistry, that we'll be able to offload it to a gpu, and that's we're getting close to testing that we'll be able to you know, when we need to do chemistry, that we'll be able to offload it to a GPU, and that's we're getting close to testing that. We've got some.
Speaker 2:The stage that Chandon's at with the chemistry at the moment is again. We've got it sort of working on the DNS side of things, direct numerical simulation, in other words it's like highly resolved, where you, you know, you know the temperatures are well resolved and we're trying to scale that formulation up so that it can be run with les and still give, you know, good fluid mechanics for the, for the flame and plume. So that's where that and we, you know we're not, like I said, when we're as we're doing this we're definitely running into this challenge of of computational efficiency. I mean it takes it's just so much slower than you know. Basically you go from something that was chemistry, was free, and now now it's taking 95 of your cpu time is it that much?
Speaker 2:okay, well yeah, it's bad. I mean it's, it's the chemistry is can be horrendous. If you're doing this is like real mechanism, if you're doing real mechanisms, this isn't not. This is not westbrook dryer, one-step chemistry. This is utilizing, I don't know, I think SMUC mechanism or something like 30 species, 100 reactions, that kind of stuff.
Speaker 1:Soot formation as well.
Speaker 2:Not yet. Soot formation Okay, that's yet another issue. So we're collaborating a bit with David Lignel at BYU. He sits in on our development meetings and then Chandan also has a good background in formation. So that's, yeah, another step. But again, until you have the sort of the larger scale case working right where you're able to get decent chemistry without resolving the flame temperatures, in other words, you have to have some kind of subgrid model for the, the temperature distribution and species distributions, um and that's where things are awesome man I.
Speaker 1:I have a long list of questions to ask, but we've already are past, uh, one hour mark, so perhaps, instead of asking you them now, I'll probably like to invite you for another episode. So I also have this Fire Fundamentals series in the podcast, where we talk about fundamental stuff in fire science, and I think it could be a material for a Turbulent Combustion episode Perhaps. Finally, I would take some items from your whiteboard.
Speaker 2:if we talk about turbulence and combustion, yeah, get me in my comfort zone a little more.
Speaker 1:Oh my God. It's like oh yeah, turbulent combustion, that's my comfort zone. That's like first time in my life I hear this sentence in this logical order.
Speaker 2:Yeah, pyrolysis is not my comfort zone.
Speaker 1:But I know what I think. I did not expect you to explain to me the models. What I want to and to deliver in this interview is that our listeners grasp a little bit how developing the most important piece of software we have looks like and hearing it firsthand from you one. It should boost their confidence in the software and how much effort goes into building and maintaining it, but also lower their confidence of applying it blindly. I really hope people take more intentional efforts to apply this software, understanding the uncertainties they introduce into their own models. And there's like 1,200 pages of validation guide to help you. There's the technical reference guide, there are brilliant documents available in the FDS repository, and I also have a feeling that if someone runs into an issue and shoots you an email, you'll probably respond. We do our best. Kevin always responds in like five minutes. It's kind of ridiculous.
Speaker 2:He's superhuman.
Speaker 1:He's probably some kind of AI model at this point.
Speaker 2:He is yeah. Okay, randy, thank you so much for joining me in the Fire Science Show in this episode and sharing the background of FTS development.
Speaker 1:Yeah, it's a pleasure, always good to see you and we'll see each other very soon, and that's it. Thank you for listening. I've tried to pull Randy on some more specific cases, but indeed we've just talked about the general developments and I think that's fine. It's interesting how they respond to what the scientific community needs. I mean, I've been really curious, attempting this interview about what do they do about batteries? How do they respond to mastimber? Because neither of those, if you really think about solving the fundamental problems of both areas of fire safety, neither of those, can be directly solved.
Speaker 1:In FTS you can electrolyze and cathodes burning and changing their state, you know, breaking down etc. It's irresponsible to expect that from a fluid solver. And also in terms of timber, it's very difficult to get real combustion. Also, in terms of timber, it's very difficult to get real combustion if you just cover your room with burners and start emitting some heat imitating the fire of timber. Yeah sure, you can model that. But to predict the rate at which the ceiling will ignite, how will it spread through the ceiling? How will it spread to the walls? How will that influence the fuel package inside your room? That's a hell of a challenge and I'm really reassured that they are looking into those things.
Speaker 1:They're developing models, they are improving the chemistry, they're improving the flows and everything in the software. They're thinking strongly about the computational efficiency of the software package. They're monitoring it. That's the thing. And when they meet problems that cannot be resolved with the current solver, it's time to migrate to a new one. So I hope this was interesting to you. If you are an FDS user or if you're simply a 5-6 engineer, you have been and will be in some ways exposed to a dynamicodynamic simulator one way or another, so better to know how it works and how it's developed. I hope it was interesting to you. Thanks for being here with me this week and see you here for more Fire Science and Engineering next Wednesday. Cheers, bye, thank you.