June 11, 2025

205 - FDS maintenance and development with Randy McDermott

205 - FDS maintenance and development with Randy McDermott
The player is loading ...
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 prac...

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.

00:00 - Introduction to FDS and Randy McDermott

08:44 - FDS Development Process and Roadmap

14:20 - Validation Guide and Application Scope

22:12 - Battery Fires and New Applications

29:10 - Fire Prediction vs. Specification Challenges

38:50 - Mass Timber and Pyrolysis Modeling

45:24 - External Models and Integration

51:55 - Chemistry Implementation and Computational Cost

56:44 - GPU Computing and Future Efficiency

WEBVTT

00:00:00.261 --> 00:00:02.125
Hello everybody, welcome to the Fire Science Show.

00:00:02.125 --> 00:00:23.730
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.

00:00:23.730 --> 00:00:32.848
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.

00:00:32.848 --> 00:00:35.128
I had great episodes with Jason Floyd.

00:00:35.128 --> 00:00:39.271
I had Kevin McGrath talking about the history of FDS, how it came to life.

00:00:39.271 --> 00:00:43.527
If you're interested and have not heard them, I highly recommend you to do that.

00:00:43.527 --> 00:00:51.890
And today we're more discussing the future of FDS or more just what's happening with it right now.

00:00:52.219 --> 00:01:09.593
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.

00:01:09.593 --> 00:01:21.051
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.

00:01:21.051 --> 00:01:22.094
To some extent.

00:01:22.094 --> 00:01:24.081
I think that's a very interesting concept.

00:01:24.081 --> 00:01:26.950
That's a very rich literature piece.

00:01:26.950 --> 00:01:28.224
The validation guide of FDS.

00:01:28.224 --> 00:01:35.468
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.

00:01:35.468 --> 00:01:45.129
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.

00:01:45.129 --> 00:01:47.808
I have not known them for sure and I've learned them here.

00:01:47.808 --> 00:01:54.513
So episode's packed with information, new information and Randy's just a great guy to talk.

00:01:54.513 --> 00:02:00.893
There's not that many people getting so excited talking about physics and I really love this vibe.

00:02:00.893 --> 00:02:03.200
So let's not prolong this anymore.

00:02:03.200 --> 00:02:05.808
Let's spin the intro and jump into the episode.

00:02:10.400 --> 00:02:12.020
Welcome to the Firesize Show.

00:02:12.020 --> 00:02:15.484
My name is Wojciech Wigrzyński and I will be your host.

00:02:15.484 --> 00:02:45.009
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.

00:02:45.009 --> 00:02:58.728
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.

00:02:58.728 --> 00:03:14.829
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.

00:03:14.829 --> 00:03:23.405
If you're keen to find out more or join OFR Consultants during this exciting period of growth, visit their website at ofrconsultantscom.

00:03:23.405 --> 00:03:25.509
And now back to the episode.

00:03:25.509 --> 00:03:26.412
Hello everybody.

00:03:26.412 --> 00:03:29.907
I am joined here today by Randy McDermott from NIST.

00:03:29.907 --> 00:03:30.949
Hey, randy, hey.

00:03:31.170 --> 00:03:32.133
Hey, wojciech, good to see you.

00:03:32.681 --> 00:03:34.268
Mr Randy, good to have you in the podcast.

00:03:34.268 --> 00:03:35.763
I'm ashamed.

00:03:35.763 --> 00:03:39.032
It took over 200 episodes to get you in the podcast.

00:03:39.379 --> 00:03:40.241
Oh, no way, man.

00:03:40.241 --> 00:03:45.673
I'm a big fan of the show and I'm very happy to be asked and to be here.

00:03:52.139 --> 00:03:53.362
Yeah, I know you are and I'm ashamed I didn't ask you earlier.

00:03:53.383 --> 00:03:56.491
but well, some things are worth waiting for and I still have to keep some big names for upcoming episodes.

00:03:56.491 --> 00:03:58.721
I cannot shoot all the stars in like first 20.

00:03:58.721 --> 00:04:00.163
So here we are.

00:04:00.163 --> 00:04:13.575
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.

00:04:13.575 --> 00:04:22.254
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.

00:04:23.141 --> 00:04:27.952
So we can recreate this atmosphere in the podcast, so good.

00:04:27.952 --> 00:04:34.947
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.

00:04:34.947 --> 00:04:40.879
But one thing I don't know about you what was your pre-FDS background?

00:04:40.879 --> 00:04:48.970
How did you come to the world of fire science and developing the most critical piece of intellectual property we have in this?

00:04:49.331 --> 00:04:49.973
in this space.

00:04:50.435 --> 00:04:52.761
So my background is chemical engineering.

00:04:53.002 --> 00:05:41.190
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.

00:05:41.319 --> 00:05:50.853
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.

00:05:50.853 --> 00:05:55.232
So that's kind of where I got started and it was very fire-related.

00:05:55.232 --> 00:06:17.146
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.

00:06:17.980 --> 00:06:20.826
Yeah, yeah, it was, that's right.

00:06:20.826 --> 00:06:26.781
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.

00:06:26.781 --> 00:06:30.345
There was a material point methods and a lot of solid phase.

00:06:31.425 --> 00:07:05.471
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.

00:07:06.701 --> 00:07:08.586
And well, that's like 2013,.

00:07:08.586 --> 00:07:08.930
I think that was.

00:07:08.930 --> 00:07:11.043
2013 is when I think we released that.

00:07:11.365 --> 00:07:14.742
Also, there's like a hundred versions of FDS 6 ago.

00:07:14.783 --> 00:07:15.726
Yeah, yeah.

00:07:16.341 --> 00:07:23.305
Okay, so you seem to update the software very often and now I have some questions about how you do it.

00:07:23.305 --> 00:07:34.374
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?

00:07:34.374 --> 00:07:41.533
Is there like a blackboard in Kevin's office where like a pathway till FDS 10 is already outlined?

00:07:41.533 --> 00:07:44.629
Is it problem by problem issue tracker thing?

00:07:45.480 --> 00:07:53.206
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.

00:07:53.206 --> 00:08:01.531
We do have on our GitHub wiki page a research roadmap which many people have probably looked at.

00:08:01.531 --> 00:08:04.389
We try to keep that as up to date as we can.

00:08:04.389 --> 00:08:06.324
That's also in place.

00:08:06.324 --> 00:08:16.286
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.

00:08:16.439 --> 00:08:18.220
Okay, that's a good call to action.

00:08:18.220 --> 00:08:26.668
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.

00:08:26.687 --> 00:08:35.566
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.

00:08:35.566 --> 00:08:40.842
Um, there, you know the, the discussion forum and, uh, the issues page.

00:08:40.842 --> 00:08:42.067
I think people are.

00:08:42.067 --> 00:08:48.145
We've we've transitioned now over the last year over to purely using github instead of google groups.

00:08:48.145 --> 00:08:49.889
You probably know that.

00:08:49.889 --> 00:08:51.541
I think that that seems to be up and running.

00:08:51.581 --> 00:09:08.947
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?

00:09:08.967 --> 00:09:15.849
issue tracker yeah, I mean, it's probably 90 issue tracker, I would say, and hopefully you know some of those things.

00:09:15.849 --> 00:09:50.629
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.

00:09:50.629 --> 00:09:59.042
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.

00:09:59.322 --> 00:10:00.645
Do you do some kind of triage?

00:10:00.645 --> 00:10:04.486
Okay, this problem seems super like burning, super urgent.

00:10:04.486 --> 00:10:07.243
This one looks like okay, it's like a very narrow.

00:10:07.243 --> 00:10:08.947
How do you evaluate them?

00:10:08.947 --> 00:10:10.629
Which one's next to take?

00:10:11.312 --> 00:10:13.001
yeah, I mean, you know there are some.

00:10:13.001 --> 00:10:18.181
Somebody demonstrates an energy conservation problem, for example, that gets our attention.

00:10:18.541 --> 00:10:21.745
Um okay that's a way to get your attention back.

00:10:23.148 --> 00:10:59.011
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.

00:10:59.561 --> 00:11:03.071
Usually it's nitrogen or something like that that's in abundance and you can afford it.

00:11:03.071 --> 00:11:14.494
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.

00:11:14.494 --> 00:11:31.346
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.

00:11:31.649 --> 00:11:40.347
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.

00:11:40.347 --> 00:11:46.270
You know, I have a feeling a lot of fire science is standing on the shoulders of FDS and FDS development.

00:11:46.270 --> 00:11:49.424
So this definitely is critically interesting to me.

00:11:49.424 --> 00:11:55.311
How does this software grow and mature and develop?

00:11:55.311 --> 00:12:06.802
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.

00:12:06.802 --> 00:12:10.164
A normal thing for me would be smoke control in buildings.

00:12:10.164 --> 00:12:12.546
You know there are those.

00:12:12.546 --> 00:12:27.518
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.

00:12:27.518 --> 00:12:29.046
And I also did that.

00:12:29.620 --> 00:12:31.488
This is for me the normal use of FDS.

00:12:31.488 --> 00:12:35.119
Let's say, a compartment fire, that's for me a normal use of FDS.

00:12:35.119 --> 00:12:43.062
I see a program which is a buoyancy-driven flow solver for fires, compartment fire.

00:12:43.062 --> 00:12:43.846
Here we go right.

00:12:43.846 --> 00:12:54.212
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.

00:12:54.212 --> 00:12:58.652
Then I see some applications like cone calorimetry.

00:12:58.652 --> 00:13:04.231
People simulate cone calorimetry and extremely difficult material properties change with FDS.

00:13:04.231 --> 00:13:08.250
I saw people do quite complicated heat transfer problems in FDS.

00:13:08.250 --> 00:13:11.789
I've seen people do firebrand transport.

00:13:11.789 --> 00:13:14.269
I've been a part of a group that was doing firebrand transport in FDS.

00:13:14.269 --> 00:13:20.178
I see people applying that to batteries, electric vehicles, suppression.

00:13:20.178 --> 00:13:37.255
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.

00:13:37.376 --> 00:13:47.681
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?

00:13:47.681 --> 00:13:49.464
I mean I mean it's I.

00:13:49.705 --> 00:14:04.601
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.

00:14:04.601 --> 00:14:11.014
Like you go into three-star Michelin restaurant and you tell chef, just give me the best what you have.

00:14:11.014 --> 00:14:18.687
And this like you guys curated, this beautiful list of models that are fine-tuned to fire problems and get applied.

00:14:18.687 --> 00:14:26.748
But again, it's hard for me to imagine the same solver can handle chemistry of a battery and fire on a space station.

00:14:26.748 --> 00:14:31.251
It's just like for someone who works with modeling it's hard for me to grasp.

00:14:31.480 --> 00:14:34.869
Well, I mean, I don't know that we've yet nailed chemistry in a battery.

00:14:35.070 --> 00:14:44.874
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.

00:14:44.874 --> 00:14:55.368
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.

00:14:55.368 --> 00:15:08.750
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.

00:15:08.750 --> 00:15:09.932
It's very interesting.

00:15:09.932 --> 00:15:22.308
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.

00:15:22.308 --> 00:15:23.644
And it's tricky.

00:15:23.644 --> 00:15:28.285
I'll leave it at that for now, but it's not an easy problem.

00:15:29.408 --> 00:15:55.687
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.

00:15:55.727 --> 00:16:06.375
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.

00:16:06.375 --> 00:16:24.211
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.

00:16:24.211 --> 00:16:28.144
Maybe that's ultimately where things will be headed.

00:16:28.144 --> 00:16:38.500
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.

00:16:38.981 --> 00:16:40.225
But it's an art.

00:16:40.225 --> 00:16:41.288
You know that part of it.

00:16:41.288 --> 00:16:43.572
You know there are choices to be made.

00:16:43.572 --> 00:16:48.456
They may not be optimal in every situation, you know, especially when you're trying to meld.

00:16:48.456 --> 00:17:19.692
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.

00:17:20.440 --> 00:17:23.130
I have the validation guide in front of my eyes.

00:17:23.130 --> 00:17:24.666
I just downloaded it freshly.

00:17:24.819 --> 00:17:29.723
I probably better get that up if you're going to start peppering me, I'm just going to drop.

00:17:29.743 --> 00:17:33.392
You know random chapters and you have to tell me what it is about and how it's relevant.

00:17:33.392 --> 00:17:35.019
No, just kidding.

00:17:35.019 --> 00:17:36.686
I'm looking at it.

00:17:36.686 --> 00:17:40.505
It has 1,200 pages, so it's a third of the handbook.

00:17:40.505 --> 00:17:41.866
In scale.

00:17:41.866 --> 00:17:42.948
It's massive.

00:17:44.210 --> 00:17:48.875
I think we're up to 8,000 plots that get made, or something like that as part of the Congratulations.

00:17:50.582 --> 00:17:52.440
That's a sensible achievement, congratulations.

00:17:52.440 --> 00:17:55.930
I just like, like now, go for 10,000,.

00:17:55.930 --> 00:18:02.472
I guess it's a good job to create this insane body of reference material.

00:18:02.472 --> 00:18:08.613
How do you, as a developer, how would you like people use this body of literature?

00:18:08.613 --> 00:18:19.728
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.

00:18:19.728 --> 00:18:23.608
A lot of people in the industry would be using.

00:18:23.608 --> 00:18:25.724
They just download Fds.

00:18:25.724 --> 00:18:26.808
It.

00:18:26.808 --> 00:18:28.742
It's well accepted.

00:18:28.742 --> 00:18:30.445
Everyone knows fds in this space.

00:18:30.445 --> 00:18:33.472
Like you don't really have to prove fds works.

00:18:33.472 --> 00:18:38.549
Also, you know I'm I publish a lot of answers, fire simulations.

00:18:38.549 --> 00:18:41.723
I always have to justify why I've used answers randy.

00:18:41.723 --> 00:18:43.670
I always have to justify.

00:18:43.670 --> 00:18:57.271
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.

00:18:57.332 --> 00:18:58.040
It shouldn't be.

00:18:58.040 --> 00:19:07.441
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.

00:19:07.441 --> 00:19:12.942
I do think that there are classes of problems that we have enough confidence in our because we've done.

00:19:12.942 --> 00:19:15.914
We have several examples of them in the validation guide.

00:19:15.914 --> 00:19:18.261
Uh, you know they span the.

00:19:18.261 --> 00:19:28.573
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.

00:19:28.573 --> 00:19:32.931
I have a lot of confidence that we're going to do that right.

00:19:32.931 --> 00:19:36.711
You know, again, when you have a specified fire size and so on.

00:19:36.711 --> 00:19:38.768
We've talked about that offline a little bit.

00:19:38.768 --> 00:19:50.685
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.

00:19:50.746 --> 00:19:55.335
Here are certain types of problems, whether they're compartment fires, fire spread and so on.

00:19:55.335 --> 00:19:58.548
Some of the things we obviously do better than others.

00:19:58.548 --> 00:20:14.814
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.

00:20:14.814 --> 00:20:21.150
So hopefully those scatter plots give some sense of where the uncertainties are when they're tight.

00:20:21.150 --> 00:20:36.510
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.

00:20:36.571 --> 00:20:38.923
So it would be something like I have a problem.

00:20:38.923 --> 00:20:42.592
My first look, there's chapter two which summarizes stuff that has been done.

00:20:42.592 --> 00:20:49.420
I'm probably would like to find a case similar to mine in the validation guide, at least in the scope.

00:20:49.420 --> 00:20:52.190
Then I see what kind of range of variables.

00:20:52.190 --> 00:20:57.708
So let's say I want to simulate wind and I look into your wind cases.

00:20:57.708 --> 00:21:04.339
So if I want to simulate a tornado I probably will not find a reference case.

00:21:04.339 --> 00:21:05.444
You will not find a tornado.

00:21:05.444 --> 00:21:07.287
You do not find an example.

00:21:08.200 --> 00:21:12.892
I mean, it's fit to do wind, but perhaps not this type of specific atmospheric phenomenon.

00:21:12.892 --> 00:21:21.049
I don't see that specific like go deeper, find a specific phenomenon or specific thing you're investigating, find the reference case.

00:21:21.049 --> 00:21:23.180
Look at the range of uncertainties.

00:21:23.180 --> 00:21:36.148
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.

00:21:36.871 --> 00:21:39.519
That's right, or at least to find a different reference.

00:21:39.519 --> 00:21:44.090
Or perhaps you just have to do a reference experiments right.

00:21:44.711 --> 00:21:45.200
Exactly Like.

00:21:45.200 --> 00:21:46.222
I mean definitely.

00:21:46.222 --> 00:21:56.705
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.

00:21:56.705 --> 00:22:01.133
You know it's okay, given that you have to have experiments to validate everything.

00:22:01.133 --> 00:22:02.755
Like what good are the models really?

00:22:02.755 --> 00:22:07.382
To validate everything?

00:22:07.382 --> 00:22:08.304
Like what good are the models really?

00:22:08.304 --> 00:22:25.809
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.

00:22:25.809 --> 00:22:30.215
You know, in terms of okay, I think this happened in the experiment, I see that in the model.

00:22:30.215 --> 00:22:36.886
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.

00:22:36.886 --> 00:22:41.852
Then that makes me feel like I understand the phenomenon.

00:22:41.852 --> 00:22:47.989
If those two things are wildly different, then I need to maybe rethink what's going on.

00:22:48.502 --> 00:23:00.049
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.

00:23:00.049 --> 00:23:09.830
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.

00:23:10.070 --> 00:23:30.951
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.

00:23:30.951 --> 00:23:40.074
You probably would like to do some simulations related to battery fires, like you probably have not thought about battery problems 10-15 years.

00:23:40.074 --> 00:23:42.805
If you did, I congratulate you for being visionary.

00:23:42.805 --> 00:23:55.354
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.

00:23:55.354 --> 00:24:02.730
So it's just some things that the industry is moving into and needs answers fast.

00:24:02.730 --> 00:24:13.248
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.

00:24:13.248 --> 00:24:25.022
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.

00:24:25.269 --> 00:24:30.623
Right, yeah, so it's a great question and a good topic.

00:24:30.623 --> 00:24:33.397
I mean the old note, since you have the validation guide in front of you.

00:24:33.397 --> 00:24:35.403
There is not a chapter on battery fires.

00:24:35.825 --> 00:24:36.145
Yeah.

00:24:38.211 --> 00:24:39.883
There's not a chapter on battery fires.

00:24:39.883 --> 00:24:40.930
Yeah, there's not a chapter on mass timber, right.

00:24:40.930 --> 00:24:53.230
So these are definitely challenges for us and I take those two applications to be somewhat different in the sense that I mean.

00:24:53.230 --> 00:25:09.799
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?

00:25:09.799 --> 00:25:20.192
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.

00:25:20.192 --> 00:25:20.913
I want to try to press people on.

00:25:20.913 --> 00:25:21.476
What do they mean by that?

00:25:21.476 --> 00:25:23.441
Cause it's quite that's a big statement.

00:25:23.441 --> 00:25:24.612
You know, can you model?

00:25:24.612 --> 00:25:25.895
Can you model battery fires?

00:25:26.297 --> 00:25:30.180
It's like I do computer simulations Like what exactly do you mean by computer?

00:25:30.200 --> 00:25:30.903
simulations, Right, so math.

00:25:30.903 --> 00:25:37.218
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.

00:25:37.218 --> 00:25:37.980
And what do you mean?

00:25:37.980 --> 00:25:46.078
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.

00:25:46.230 --> 00:25:48.739
And I say, okay, well, fts can do that right.

00:25:48.739 --> 00:25:53.836
I mean, that's kind of a trivial application depending on the speed of the jet and so on.

00:25:53.836 --> 00:26:01.433
Of course, yeah, low on and and of course, but low my assumption, yeah, I mean.

00:26:01.433 --> 00:26:14.751
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.

00:26:15.172 --> 00:26:23.376
You know principles, thermal runaway problem, and I think quite obviously that's way, way more than FDS can handle at the moment.

00:26:23.376 --> 00:26:43.861
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.

00:26:43.869 --> 00:26:45.256
Can I ask you a follow-up question on that?

00:26:45.256 --> 00:26:49.580
Sure, I'm pretty certain about capability of FDS to model a building.

00:26:49.580 --> 00:26:58.739
I know there has been a lot of validation regarding cargo spaces in airplanes, also related to pressurization and fires in confined spaces.

00:26:58.739 --> 00:27:09.395
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?

00:27:09.395 --> 00:27:14.392
Can you use the same software and everything to simulate it at that scale?

00:27:14.392 --> 00:27:15.778
Just use some millimeter mesh?

00:27:15.778 --> 00:27:16.933
Would that work?

00:27:16.933 --> 00:27:18.372
I have not tried.

00:27:18.732 --> 00:27:28.059
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.

00:27:28.059 --> 00:27:34.683
To the extent that that is just a pressurization problem we should be able to handle that.

00:27:34.683 --> 00:27:37.332
But again you're in research territory.

00:27:37.412 --> 00:27:41.054
I would say um either way you go, I don't know larger compartments where.

00:27:41.054 --> 00:27:48.260
Again, where you, where you have specified um, mass losses, I think there are enough experiments out there that we've compared to that.

00:27:48.260 --> 00:28:05.650
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.

00:28:05.650 --> 00:28:15.757
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.

00:28:16.171 --> 00:28:20.336
I have confidence in anything Jason does me too.

00:28:20.336 --> 00:28:43.239
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.

00:28:46.130 --> 00:28:52.263
I need to bring him back to the podcast so we can discuss all the fun things you can do with HVAC solver.

00:28:52.263 --> 00:28:57.199
You mentioned chemistry so I guess for the chemistry of the batteries the same thing.

00:28:57.199 --> 00:29:01.223
If you are interested only in the products, you have your custom reaction.

00:29:01.223 --> 00:29:13.397
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.

00:29:13.397 --> 00:29:21.722
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.

00:29:22.124 --> 00:29:31.482
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.

00:29:31.502 --> 00:29:32.834
Yeah, we don't do any of that.

00:29:32.974 --> 00:29:33.517
I don't think so.

00:29:33.517 --> 00:29:40.978
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.

00:29:41.378 --> 00:29:41.778
Yeah, it's like.

00:29:41.778 --> 00:29:42.779
Yeah, it's like.

00:29:42.779 --> 00:29:47.945
It's like predicting these things versus knowing the yields, as are two different worlds, right.

00:29:49.271 --> 00:30:14.798
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?

00:30:15.519 --> 00:30:16.101
That's funny.

00:30:16.990 --> 00:30:20.500
And I've never seen anyone did, perhaps a few times.

00:30:20.500 --> 00:30:23.657
I've seen a really good attempts at, but not yet there.

00:30:23.657 --> 00:30:24.961
Can you elaborate on?

00:30:24.981 --> 00:30:25.142
that.

00:30:25.410 --> 00:30:41.798
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.

00:30:41.818 --> 00:30:46.733
I mean these are, or the, you know, the McCaffrey plumes, or the Heskestead plumes and so on.

00:30:46.753 --> 00:30:50.122
I mean we think we have a reasonable handle on that.

00:30:50.122 --> 00:31:10.096
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.

00:31:10.096 --> 00:31:16.474
And I think that there are a lot of uncertainties in when these two systems get coupled.

00:31:16.474 --> 00:31:50.702
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.

00:31:51.270 --> 00:32:04.017
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.

00:32:04.017 --> 00:32:07.510
You know, in a very general case I would say it's not hard.

00:32:07.510 --> 00:32:36.858
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.

00:32:36.858 --> 00:32:40.118
Perhaps the dishes are within the uncertainties.

00:32:40.118 --> 00:32:41.191
I don't.

00:32:41.432 --> 00:32:44.320
Yeah, I mean you said it all exactly right.

00:32:44.320 --> 00:32:45.977
I mean that's the challenge.

00:32:45.977 --> 00:32:47.355
I mean there's the.

00:32:47.355 --> 00:32:51.980
You know large-eddy simulation is quite a powerful technique.

00:32:51.980 --> 00:32:57.798
But you know, if you go back and you ask anybody, they don't even have to be from the FHIR community.

00:32:57.798 --> 00:33:02.221
You know what is the most challenging thing to do with large eddy simulation.

00:33:02.221 --> 00:33:04.319
They will tell you the boundary layer right.

00:33:04.319 --> 00:33:11.021
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.

00:33:11.021 --> 00:33:22.715
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.

00:33:22.996 --> 00:33:24.961
This is an unsolved problem, you know.

00:33:24.961 --> 00:33:39.420
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.

00:33:39.420 --> 00:33:42.765
You know, do you get the flame height Correct, okay, you know if you've got.

00:33:42.765 --> 00:33:45.376
If you're prescribing a radiant fraction, are you getting?

00:33:45.376 --> 00:33:49.661
You know the your, your radiation heat flux to the target right, and so on.

00:33:49.789 --> 00:34:05.820
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.

00:34:05.820 --> 00:34:06.784
There are very few experiments, right?

00:34:06.784 --> 00:34:10.195
I mean, if you look at, just even if you look at heat, what we call, you know flame structure.

00:34:10.195 --> 00:34:29.659
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.

00:34:29.699 --> 00:35:00.704
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.

00:35:00.704 --> 00:35:03.639
It's a nonlinear system.

00:35:03.639 --> 00:35:13.150
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.

00:35:13.871 --> 00:35:18.862
I don't think people are correctly doing mesh convergence in engineering.

00:35:18.862 --> 00:35:34.099
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.

00:35:34.099 --> 00:35:37.840
So you pick the 10 because 5 calculates too long and you just go with it.

00:35:37.840 --> 00:35:40.034
And I see that not just in engineering, in engineering.

00:35:40.074 --> 00:35:56.614
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?

00:35:56.614 --> 00:36:04.036
I mesh convergence starts to make sense if you start to directly resolve more and more phenomena at the scale at which they happen.

00:36:04.036 --> 00:36:09.737
I don't see a big difference between 5 and 10 centimeter mesh really, but that's an off topic.

00:36:10.831 --> 00:36:14.036
Perhaps we'll it depends on the problem, right?

00:36:14.177 --> 00:36:15.340
Of course, yeah, of course.

00:36:16.253 --> 00:36:20.496
Because it's got to be relative to what is the link scale you're trying to resolve.

00:36:20.951 --> 00:36:21.793
Exactly exactly.

00:36:21.793 --> 00:36:23.777
Yeah, that's exactly what I meant.

00:36:23.777 --> 00:36:34.268
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.

00:36:34.268 --> 00:36:35.934
I mean you don't need to go to a millimeter.

00:36:35.934 --> 00:36:58.952
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.

00:36:58.952 --> 00:37:11.452
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.

00:37:11.452 --> 00:37:15.494
I've also brought mass timber to the mix of topics that we had.

00:37:15.494 --> 00:37:35.815
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.

00:37:35.896 --> 00:38:06.246
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.

00:38:06.246 --> 00:38:11.757
So Eric has recently introduced what we think is a better approach to doing the oxidation step, oxidation profile, prescribed oxidation profile.

00:38:11.757 --> 00:38:25.208
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.

00:38:25.208 --> 00:38:31.668
You know there are a couple of groups that are interested in connecting uh g pyro um with fds.

00:38:31.668 --> 00:38:33.972
I know chris laubenberger had done that.

00:38:33.972 --> 00:38:36.737
It's one version of fds.

00:38:36.737 --> 00:38:52.438
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.

00:38:52.438 --> 00:38:54.192
So we've been talking with them.

00:38:54.626 --> 00:38:58.817
It's like introducing an external model to work along with FDS right.

00:38:59.224 --> 00:39:01.693
Right, we're getting a little better at.

00:39:01.693 --> 00:39:05.248
You know, this becomes a software engineering issue, right?

00:39:05.248 --> 00:39:07.251
Who's going to maintain the code?

00:39:07.251 --> 00:39:08.634
Um, we're not.

00:39:08.634 --> 00:39:13.349
Our group is at the moment probably not in a position to maintain g pyro.

00:39:13.349 --> 00:39:30.777
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?

00:39:30.777 --> 00:39:35.932
And so we've got, we're getting a little bit better at using libraries.

00:39:35.932 --> 00:39:51.188
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.

00:39:51.429 --> 00:39:56.449
I mean that's a potential future for the software I mean with all, let's say, battery models.

00:39:56.449 --> 00:40:04.865
I would not expect you guys now drop everything and start developing a battery model because so many people want that.

00:40:04.865 --> 00:40:21.291
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.

00:40:21.291 --> 00:40:27.320
Are you creating bridges that would allow such developments to be introduced to FTS?

00:40:27.320 --> 00:40:30.793
If I would like to start something like that tomorrow.

00:40:30.793 --> 00:40:32.376
Would that be possible?

00:40:33.646 --> 00:40:38.023
We don't have the concept of like ANSYS, of like a user-defined function.

00:40:38.222 --> 00:40:44.235
if that's where you're going, Well user-defined function is something else, because it gives the user freedom.

00:40:44.235 --> 00:40:53.054
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.

00:40:53.054 --> 00:40:59.817
Could you make a system in such a way that the user can link this model with FDS, have it working?

00:40:59.817 --> 00:41:08.976
One day the model dies because they lose the attraction to keep it up, but FDS goes on and that model is vanity, whatever.

00:41:08.976 --> 00:41:16.072
So you don't gain, you don't lose anything in FDS, but someone can plug in something into the code.

00:41:16.072 --> 00:41:17.275
Is there a path?

00:41:17.295 --> 00:41:18.157
Well, it's a great question.

00:41:18.157 --> 00:41:25.869
So I guess the only way I can answer that is to look through history and also maybe look to the future.

00:41:25.869 --> 00:41:33.896
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?

00:41:33.896 --> 00:41:36.478
So it's pretty clear that there's needs.

00:41:36.478 --> 00:41:59.818
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.

00:41:59.818 --> 00:42:06.849
Historically, you know, an example where that did happen was like evac yeah, I loved evac.

00:42:07.309 --> 00:42:08.693
Okay, why did you kill an evac?

00:42:08.753 --> 00:42:15.614
I love that maybe, maybe that was a it was awesome tactical error bringing that up.

00:42:15.614 --> 00:42:17.057
Evac.

00:42:17.057 --> 00:42:19.043
Evac is awesome, but it was also.

00:42:19.043 --> 00:42:28.119
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.

00:42:28.119 --> 00:42:28.820
So you know this.

00:42:29.505 --> 00:42:31.233
A huge effort to keep it up yeah.

00:42:31.625 --> 00:42:38.197
Because this tentacles were just everywhere and so every time we would need to, we started off talking about the program.

00:42:38.197 --> 00:42:53.338
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.

00:42:53.338 --> 00:43:02.766
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.

00:43:02.766 --> 00:43:07.768
Anyway, there is no simple answer, I guess, to that.

00:43:07.768 --> 00:43:12.690
It needs to be sort of a tight collaboration at this point to have a module.

00:43:12.690 --> 00:43:17.454
But a battery module, you know, if such a thing existed, is something that we could discuss.

00:43:18.153 --> 00:43:24.677
I would say, though you already made some improvements in FTS that allow users to change stuff while the simulation is running right.

00:43:25.297 --> 00:43:34.483
Maybe you'd like to talk about those developments, sure, so and again I guess you get to talk about everybody else's stuff.

00:43:37.425 --> 00:43:42.175
So this is, I believe this is Give me a list of your stuff, Show me the blackboard, the whiteboard.

00:43:42.215 --> 00:43:43.963
Yeah the whiteboard, yeah the whiteboard.

00:43:43.963 --> 00:43:46.751
Pressure and turbulence, oh no.

00:43:46.751 --> 00:44:05.701
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.

00:44:07.425 --> 00:44:19.898
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.

00:44:19.898 --> 00:44:27.152
Fts marches forward to a certain point that it stops and waits to get an output from the finite element model, and so on.

00:44:27.152 --> 00:44:29.673
So there's a two-way, a two-way coupling.

00:44:29.673 --> 00:44:35.757
I mean, I'd say that's fairly new if it's in quote unquote beta testing at the current time.

00:44:35.757 --> 00:44:37.706
So that's another thing.

00:44:37.706 --> 00:44:41.251
That is, a lot of these things can stay in beta if they don't get used a lot.

00:44:41.572 --> 00:44:44.577
Okay, you need a critical mass of testers of tests.

00:44:44.978 --> 00:44:45.420
Exactly.

00:44:45.420 --> 00:44:53.335
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.

00:44:53.335 --> 00:44:55.068
So until you know.

00:44:55.068 --> 00:45:04.958
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.

00:45:06.806 --> 00:45:11.277
When you were talking about chemistry, you brought something up and I want to come back to that.

00:45:11.277 --> 00:45:18.414
You said that detailed chemistry can be very expensive, and I would like to put you on that word expensive.

00:45:18.414 --> 00:45:26.608
As a developer, I know NIST has pretty fancy computers so I guess you have access to a lot of computational power.

00:45:26.608 --> 00:45:30.235
But also whenever I review a paper.

00:45:30.235 --> 00:45:40.672
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.

00:45:40.672 --> 00:45:42.579
That's a sentence I see a lot.

00:45:42.579 --> 00:45:54.429
So undoubtedly that's something that a lot of users consider when choosing their models, their resolutions, basically building their cases.

00:45:54.429 --> 00:46:03.197
How important is computation efficiency and this expensiveness of simulations from perspective of a developer?

00:46:03.766 --> 00:46:14.438
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.

00:46:14.438 --> 00:46:29.036
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.

00:46:29.036 --> 00:46:36.586
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.

00:46:36.586 --> 00:46:43.456
So similarly with chemistry we've run into problems like we're trying to do extinction, for example.

00:46:43.456 --> 00:46:43.822
I've always challenged.

00:46:43.822 --> 00:46:44.050
You know we've had into problems like we're trying to do extinction, for example.

00:46:44.050 --> 00:46:45.427
I've always challenged.

00:46:45.427 --> 00:46:47.835
You know we've had, and a lot of our colleagues we've always.

00:46:47.835 --> 00:46:58.789
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.

00:46:58.789 --> 00:47:05.753
You know the critical flame temperature model was able to handle it one way or another, okay, in some reasonable way.

00:47:05.753 --> 00:47:13.320
And I said, you know, as soon as we have an example where this critical flame temperature model like physically cannot do the job.

00:47:13.320 --> 00:47:16.510
We'll start looking at chemical suppression and these sorts of things.

00:47:16.570 --> 00:47:25.286
And we ran into that, jason and I, when working with Paul Pappas and his team looking at sodium bicarbonate suppression.

00:47:25.286 --> 00:47:37.976
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.

00:47:37.976 --> 00:47:39.684
It's not a thermal suppression mechanism.

00:47:39.684 --> 00:47:51.213
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.

00:47:51.213 --> 00:47:55.836
So we said, ok, let's, let's get the chemistry off the ground.

00:47:55.836 --> 00:47:58.172
And so we're getting close on that.

00:47:58.224 --> 00:48:07.217
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.

00:48:07.217 --> 00:48:17.565
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?

00:48:17.565 --> 00:48:21.588
So anyway, that that gets beyond your question about efficiency.

00:48:21.588 --> 00:48:31.954
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.

00:48:31.954 --> 00:48:38.400
But if there's a problem that you physically cannot do, then the cost becomes somewhat justified.

00:48:38.400 --> 00:48:45.050
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.

00:48:45.050 --> 00:48:50.853
First step is to get get everything up and running and verified so that you you have you're doing things physically correctly.

00:48:50.853 --> 00:48:54.409
Then, once that's working, then we'll worry about the efficiency.

00:48:55.032 --> 00:48:59.612
Do you measure the efficiency when you do changes to the code, because you must be doing changes all the time.

00:49:00.034 --> 00:49:23.639
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.

00:49:23.639 --> 00:49:28.398
First of all, it wouldn't finish when we think it should finish.

00:49:29.041 --> 00:49:43.177
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.

00:49:43.277 --> 00:49:45.431
It must be a hell amount of data.

00:49:45.945 --> 00:49:50.034
They get overwritten every night for the nightly runs.

00:49:50.034 --> 00:49:51.530
The validation runs are.

00:49:51.530 --> 00:49:55.137
The outputs for validation are kept under version control.

00:49:55.157 --> 00:49:56.106
So there's a repository for.

00:49:56.106 --> 00:50:00.610
So there's a set of the reference cases and the bot runs new simulations every night to see if something changed, correct?

00:50:00.610 --> 00:50:03.264
So a lot of the cases have analytical solutions or and the bot runs new simulations every night to see if something changed, correct?

00:50:03.284 --> 00:50:03.364
Yeah.

00:50:03.364 --> 00:50:10.771
So a lot of the cases have analytical solutions or known solutions, and we have a system.

00:50:10.771 --> 00:50:16.295
That system in and of itself has become its own sort of behemoth of a code.

00:50:16.295 --> 00:50:24.773
So that's something we also have to maintain, and you mentioned about developments for using larger computational powers.

00:50:25.806 --> 00:50:30.557
We're definitely moving towards the era of GPU computations.

00:50:30.557 --> 00:50:34.831
It's inevitable that, well inevitable.

00:50:34.831 --> 00:50:47.835
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.

00:50:47.835 --> 00:50:49.690
Can you shed some light on that?

00:50:50.231 --> 00:50:53.393
Yeah, sure so, marcos, and Marcos Vanela, and.

00:50:54.184 --> 00:50:56.012
Again, I'm asking questions outside of your.

00:50:57.228 --> 00:51:15.157
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.

00:51:15.157 --> 00:51:28.041
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.

00:51:28.161 --> 00:51:40.385
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.

00:51:40.385 --> 00:51:48.485
And we're talking about billion dollar company which has, let's say, all the resources and thousands of engineers working on the problem.

00:51:48.485 --> 00:51:53.597
So I can imagine how big challenge it must be for a relatively small team that you guys have.

00:51:54.065 --> 00:52:05.177
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.

00:52:05.177 --> 00:52:18.076
And so far we've landed on using the Lawrence Livermore libraries of HYPR for linear solvers and Sundials for ordinary differential equation solvers.

00:52:18.076 --> 00:53:05.369
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.

00:53:05.369 --> 00:53:26.012
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.

00:53:26.012 --> 00:53:27.911
We've got some.

00:53:27.951 --> 00:53:31.927
The stage that Chandon's at with the chemistry at the moment is again.

00:53:31.927 --> 00:53:52.972
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.

00:53:52.972 --> 00:54:01.807
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.

00:54:01.807 --> 00:54:05.717
I mean it takes it's just so much slower than you know.

00:54:05.717 --> 00:54:13.474
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?

00:54:13.614 --> 00:54:14.717
okay, well yeah, it's bad.

00:54:14.717 --> 00:54:17.289
I mean it's, it's the chemistry is can be horrendous.

00:54:17.289 --> 00:54:21.128
If you're doing this is like real mechanism, if you're doing real mechanisms, this isn't not.

00:54:21.128 --> 00:54:24.257
This is not westbrook dryer, one-step chemistry.

00:54:24.257 --> 00:54:32.056
This is utilizing, I don't know, I think SMUC mechanism or something like 30 species, 100 reactions, that kind of stuff.

00:54:32.536 --> 00:54:33.458
Soot formation as well.

00:54:34.298 --> 00:54:34.559
Not yet.

00:54:34.559 --> 00:54:37.230
Soot formation Okay, that's yet another issue.

00:54:37.230 --> 00:54:44.458
So we're collaborating a bit with David Lignel at BYU.

00:54:44.458 --> 00:54:51.737
He sits in on our development meetings and then Chandan also has a good background in formation.

00:54:51.737 --> 00:54:54.253
So that's, yeah, another step.

00:54:54.253 --> 00:55:14.255
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.

00:55:14.376 --> 00:55:26.391
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.

00:55:26.391 --> 00:55:38.226
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.

00:55:38.226 --> 00:55:41.204
Finally, I would take some items from your whiteboard.

00:55:41.324 --> 00:55:46.894
if we talk about turbulence and combustion, yeah, get me in my comfort zone a little more.

00:55:47.688 --> 00:55:48.311
Oh my God.

00:55:48.311 --> 00:55:51.454
It's like oh yeah, turbulent combustion, that's my comfort zone.

00:55:51.454 --> 00:55:57.838
That's like first time in my life I hear this sentence in this logical order.

00:55:58.204 --> 00:56:00.012
Yeah, pyrolysis is not my comfort zone.

00:56:00.465 --> 00:56:02.012
But I know what I think.

00:56:02.012 --> 00:56:05.815
I did not expect you to explain to me the models.

00:56:05.815 --> 00:56:22.121
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.

00:56:22.121 --> 00:56:32.175
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.

00:56:32.175 --> 00:56:45.117
I really hope people take more intentional efforts to apply this software, understanding the uncertainties they introduce into their own models.

00:56:45.117 --> 00:56:49.936
And there's like 1,200 pages of validation guide to help you.

00:56:49.936 --> 00:57:06.409
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.

00:57:06.409 --> 00:57:07.032
We do our best.

00:57:07.032 --> 00:57:09.056
Kevin always responds in like five minutes.

00:57:09.056 --> 00:57:11.748
It's kind of ridiculous.

00:57:11.807 --> 00:57:12.548
He's superhuman.

00:57:12.889 --> 00:57:16.856
He's probably some kind of AI model at this point.

00:57:17.036 --> 00:57:18.018
He is yeah.

00:57:18.018 --> 00:57:30.000
Okay, randy, thank you so much for joining me in the Fire Science Show in this episode and sharing the background of FTS development.

00:57:30.181 --> 00:57:33.547
Yeah, it's a pleasure, always good to see you and we'll see each other very soon, and that's it.

00:57:33.547 --> 00:57:34.248
Thank you for listening.

00:57:34.248 --> 00:57:43.480
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.

00:57:43.480 --> 00:57:48.545
It's interesting how they respond to what the scientific community needs.

00:57:48.545 --> 00:57:54.375
I mean, I've been really curious, attempting this interview about what do they do about batteries?

00:57:54.375 --> 00:57:55.851
How do they respond to mastimber?

00:57:55.851 --> 00:58:06.452
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.

00:58:06.472 --> 00:58:13.012
In FTS you can electrolyze and cathodes burning and changing their state, you know, breaking down etc.

00:58:13.012 --> 00:58:17.360
It's irresponsible to expect that from a fluid solver.

00:58:17.360 --> 00:58:22.757
And also in terms of timber, it's very difficult to get real combustion.

00:58:22.757 --> 00:58:30.056
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.

00:58:30.056 --> 00:58:31.259
Yeah sure, you can model that.

00:58:31.259 --> 00:58:36.396
But to predict the rate at which the ceiling will ignite, how will it spread through the ceiling?

00:58:36.396 --> 00:58:37.547
How will it spread to the walls?

00:58:37.547 --> 00:58:40.476
How will that influence the fuel package inside your room?

00:58:40.476 --> 00:58:47.318
That's a hell of a challenge and I'm really reassured that they are looking into those things.

00:58:47.786 --> 00:58:55.155
They're developing models, they are improving the chemistry, they're improving the flows and everything in the software.

00:58:55.155 --> 00:59:00.097
They're thinking strongly about the computational efficiency of the software package.

00:59:00.097 --> 00:59:01.891
They're monitoring it.

00:59:01.891 --> 00:59:02.853
That's the thing.

00:59:02.853 --> 00:59:09.077
And when they meet problems that cannot be resolved with the current solver, it's time to migrate to a new one.

00:59:09.077 --> 00:59:11.990
So I hope this was interesting to you.

00:59:11.990 --> 00:59:27.295
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.

00:59:27.295 --> 00:59:28.751
I hope it was interesting to you.

00:59:28.751 --> 00:59:34.856
Thanks for being here with me this week and see you here for more Fire Science and Engineering next Wednesday.

00:59:34.856 --> 00:59:36.146
Cheers, bye, thank you.