039 - The (near) future of modelling with a tool developer Bryan Klein

Wojciech Wegrzynski: 0:01

Hello on the welcome to Fire Science Show session 39. Today, we're back to the world of fire modeling and I have invited Bryan Klein. Bryan is with that Thunderhead Engineering company, which is known for their landmark products. software models, Pathfinder and Pyrosim. And because I have a chance to talk with someone who's developing software to help engineers solve their issues. Let's try and ask him some tough questions about how the user issues are being solved. What are the most demands they meet? How users are using their software and how they are modifying their software to meet user the demands and also some. Tough questions. Like it's a simple model, better. Or easy to use, is that always beneficial? I had a lot of questions to Bryan and he was really kind answering. All of them. I really hope you will enjoy this one. he, it was huge fun to talk with Brian about how new tools are being delivered to the fire science community. And, uh, I'm really happy that they listen to the feedback they receive, actually from this talk. It's obvious that they're working on features that are most needed. So I can also recommend you, if you have something that you would need from your software. Well, The best way is to ask for it. And maybe it will be delivered. Though he mentioned that 400 long list of. ending issue as well, maybe. If, if you claimed it, you came from fire science show. Maybe it's going to get bumped up a little bit on the list. Anyway. it's a great one. So let's not prolong this anymore. Let's spin the intro and jump into the episode. Hello everybody. Welcome to Fire Science Show I'm today here with Brian Klein from Thunderhead Engineering, the developer of a Pyrosim and Pathfinder software Hi Bryan

Bryan Klein: 2:17

hi, Wojciech it's good to see you. Good to meet with you today.

Wojciech Wegrzynski: 2:19

thanks for coming. very happy to have you here. And, you probably create a software that most of us are familiar and, using. So I have some tough questions for you already. And I met your software when I was starting my career in CFD, like literally in my master curse. That was probably the first time I've been exposed to fire. CFD was true through PyroSim him. I, probably didn't even know that the FDS is the backbone and the solver of that. I wonder, do you, do you still get that? , people confuse a Pyrosim with FDS and, I see that in papers actually.

Bryan Klein: 2:59

Yeah. Yeah, we do. I would say it's not. As frequent confusion, but we definitely get questions, you know? So we'll get an email that's like, so tell me, what's the difference between PyroSim and FDS? That's it is FDS PyroSim, you know, a preprocessor to help you build the input file easily. And, as error-free as possible and error in quotes because the inputs could certainly be wrong, but the syntax should be correct. And then, a visualization or post-processing tool that we put together for visualizing the output of FDS. But under the hood, of course is the fire dynamics simulator. And we use The same binaries that we get from the NIST site. So we don't compile our own special version. We don't mess with that. And there's some advantages to that. Primarily in VNV, we don't have to rerun the suite to rebuild and make sure we're getting the same answers. We just use the exact same binary that's been run and tested and reported on from NIST but yeah, it is a confusion. And, even on our website, it's like right on the piracetam homepage, it says, you know, for fire dynamics, simulator, FDS, and we talk about that, but still it's, something that if you're not familiar, if you don't even know, FDS is a thing, first of all right.

Wojciech Wegrzynski: 4:08

I'll give credit where credit is due. FDS is an amazing piece of software. And for myself, I find it as one. Biggest achievements in the world of fire science, like there was handbook, there was CFast. Now there we'll see FDS these things that really gave a push and democratized access to powerful, tools.

Bryan Klein: 4:28

Yeah, and I think the story of FDS is pretty interesting and it's probably not for this episode, but you know that in summary there were all these sub models, there was like a radiation to target some model in there room. Heat transfer into a solid sub model. And they're all the chemical reaction in the gas phase sub model. So all these different algorithms that people have been developing in the seventies and eighties and stuff. And then, and it NIST, you know, each little, there was kind of a different research teams that were working on the new numerical model to do this, and they would publish it and whatever, and it took like a mathematician, an applied math guy to come in and go, I could put these together, you know, I could assemble all of these algorithms into a cohesive system that, could work together to solve like larger phenomenon in a more complex phenomena than any of the individual parts. And you almost see that in the source code, right? There's like a Rady dot F 90. There's the pressure solver. that's sort of reflected in that, decomposition into the models.

Wojciech Wegrzynski: 5:21

I was wanted to find out how they solve, emissivity for smoke for radiation model from the soot. And, it was like, okay, we use RadCal model of NIST I'm like , okay. What's RadCal model. And then there's like this hundred page long manual for a model to do that. And it's, it's one of hundreds underlying models in FDS.

Bryan Klein: 5:42

And each model comes with an assumption and there's, there's a whole technical document that NIS produces for that. When I joined NIST primarily, it was a little bit complaining to Kevin about how things were working, I need source control and I need I need to be able to look at differences between releases and where's your change log and, how do I report a problem and stuff? So, back in 2006, I was hired by NIST.

Wojciech Wegrzynski: 6:05

That's as a GIT

Bryan Klein: 6:07

yeah, yeah. Well, and you know, I was kind of complaining and Kevin was like, well, can you come help us fix it? We're not a software development project like that. We're a bunch of researchers trying to do something useful over here at NIST. And like we did producing software in our specialty and I had some familiarity with source control and software development and building. So I put together the original Google code project. got all the source online, got the discussion groups, started on Google groups.

Wojciech Wegrzynski: 6:34

this only good to

Bryan Klein: 6:35

Yeah. And then, yeah, that's my fault. And then,

Wojciech Wegrzynski: 6:38

Thank you

Bryan Klein: 6:39

uh, got that set up and then even like automating VNV and publishing some of that stuff. I worked a bit on the automation of the plotting and all of that stuff in the beginning. So I'm trying to make it something that had an outward face that could be, interacted with by the users. Cause it was, it was really like sending Kevin an email, right? That was the way you've. And if you wanted the source code, he could send you a zip file of the latest version of the files that he had compiled from everybody else sending him zip file. it was working, but it couldn't scale like that. So, and then we started all that and it's gone wild since then and a huge credit to smoke view as well. Like I don't think FDS would be as as well received if it wasn't for smoke, like that's just a huge compliment to FDS, to have that. That tool, that visualizes in 3d what's happening, which gives you such good qualitative insights. I think,

Wojciech Wegrzynski: 7:27

And when, when did you decide that the there's a, pre-processor missing two to fill out the complete, the puzzle?

Bryan Klein: 7:33

Yeah. So, that was before I joined Thunderheads there was a SBIR, these are the small business, innovative research grants that come out from the government periodically. And there was one for. preprocessor tool for FDS. and so Thunderhead had already had success with Petra SIM, uh, which was a pre-processor and post processor for a series of, of tools from Lawrence Livermore, National Labs. And so, they had already had a framework for like taking a solver and wrapping it with a pre-processor and post-process or toolkit. And so they made a bid on that and, was awarded that SBR and got that initial funding to, to develop PyroSim him as the wrapper for FDS. And so, and I remember when that, I actually remember when that happened, because I was still on the user side of things. When PyroSim released, I was still using FDS sitting down with the text editor and copy, pasting text and fussing over all of that. And I remember PyroSim came out and I was like, oh my gosh, this is. This is such a time-saver, this is so useful and, became a PyroSim user first as you know, trying to do my work. And I, started before NIST. I was working for a private research laboratory called the Western fire center in Washington state, in the U S and it was a private lab. So we did a lot of litigation support, doing reconstruction type work and fire modeling related to reconstruction and standardized testing for building code compliance was the other big, part of that. I was able to start my experience with FDS. I think it was just around when version three released. In a laboratory with the experimental resources. So, you know, if I ran a model of a room, I had data, real data that was from a burning room that I could compare my results to, and kind of almost do many validations using that experimental data, which I thought was really valuable for me to understand the connection between, I can make some inputs and get a result and it's nothing like what actually happened.

Wojciech Wegrzynski: 9:25

And as, as a user was, how big was it the jump for you to suddenly have a graphics interface on the software? Because I think many people today was starts with, they never go through the phase of writing their own FDS codes.

Bryan Klein: 9:40

Yeah, in fact it was, pretty great. So PyroSim what we had done, I feel like any level of complexity of a model. Once you get past just a couple of boxes and you need walls and doors, structure, it gets very difficult and the hardest thing. That in the text file, you don't see what you're doing. You can't, it's really difficult to visualize from a bunch of OBS T lines from a bunch of these obstructions where things are. If they're meeting up to each other, if there's gaps, you know, how things are positioned. So you had to go through this iterative cycle of adding a few input lines and then running a zero time simulation to open it in smoke view and look at the model, oh, I need to fix that and go back and fix. And, you know, you had to keep like this thing, whereas. These tools, the 3d preprocessor really just as you're creating it, you're seeing what you're doing. You get that immediate feedback and that really saves you time. So before PyroSim I was using a tool called Vectorworks, which is kind of a CAD package and actually we hired somebody. I had some initial scripts written, but we hired, a developer to write some more automation scripts to help they take like locus points and convert them into devices and take objects and decompose those into obstructions. And almost trying to make like a pirate SIM type tool, but in, in a CAD package. And I think other people did similar things.

Wojciech Wegrzynski: 10:51

I think now there is some other packages existing. I know my colleagues from Poland did, something called WizFDS. There's also a, I think it's online tool. I know there's like two or three different macro sets for all the cat that you can use to translate. Uh, so there definitely and blender at the S yeah, that th that was blender was, was, even when I started there was already blender and there was Emanuelle Gissi, very active in that, part,

Bryan Klein: 11:18

Yeah. So the thing we wrote for Vectorworks was a lot like blender FDS, where it was like you model in this modeling tool, and then you use this package to extract or export a bunch of things to FTS input, but having a dedicated tool like PyroSim that's like its focus is just building FDS and files it's not a, it's not a general CAD package with a lot of bells and whistles. It's very like narrowly focused on that I think is, was helpful because learning a whole CAD tool learning blender just to get FDS files is like a big leap. So,

Wojciech Wegrzynski: 11:45

I always had this with this tools, like for geometry is obvious. If you want to build a building model, it, it was obvious you needed to, because as you mentioned, you go above few obstacles. you either have to be a genius in, imagining three dimensional space with coordinates or I dunno, some sort of gift to be able project in your mind what these coordinates mean, with geometry is obvious. However, for like setting up the fire reactions, I, think, maybe the user interface is just a do easy way to, to do that. You know, you have a window with default options. I somehow always liked the magic of writing it as a code. having to think about what variables are looking, how they connect to each other, even today, when I'm, using, your, your software and, commercially where we're using ANSYS. So I'm not thinking actually that much FDS simulations, but for scientific research, we, use FDS a lot and even then I usually. Love to build the geometry, with the pre-processor, but then still a mess, a bit in a code. And that, you know, maybe it gives me this false feeling of have control over the simulation, maybe You just feel closer to what you're doing. it's not this magical box. And, it is dangerous to have boxes when you're dealing with such powerful pieces of software, right?

Bryan Klein: 13:05

Yeah. I agree with and that actually a goal. Like nothing should be a black box, and defaults, we've gone through various stages. Even the FDS projects come through various stages of providing defaults to people, you know, providing libraries and things like

Wojciech Wegrzynski: 13:17

Yeah. I remembered the material library that was there, then it disappeared. And I remember that discussion. It was interesting.

Bryan Klein: 13:24

Yeah. And, and so that's something that, there's this balance right. Between where helping somebody. Make the process more efficient, more effective, like if I have to define a reaction, I don't want to spend a bunch of time looking through the table of all of the input parameters and figure out which ones apply. you know, it's hard enough just figuring out what the input should be, let alone like the structure and all the possible parameters and everything, especially that's true with surfaces, right? Like the surface, the table of parameters for surf is like, I don't know, 40 different inputs or something possible for a surf nameless. So the UI for PyroSim has really been designed to help collect relevant parameters and show those in particular contexts to help sort of minimize the overhead of figuring out what you need to input and really focused user on the essentials that are required for that part of the definition of a surface or a reaction or whatever. and now. I would say there's a few defaults. Maybe that's just a requirement that the data model, you know, like, starting with the heat release rate per unit area of value and not zero. and maybe it would be better to just set it to zero instead of a thousand or whatever it's set to. But, there's, always warnings that come with, these are just a starting value. This is not what you use, right. This is just a number that's sitting in the box, but you need to type in what you're supposed to type in based on your vent area and your heat release rate and everything that you're supposed to do. and that could be confusing. I think, to new users. what is hard about this balance is we don't want to make it hard for advanced users to get their job done. But by not making it hard for advanced users and being really ergonomic and everything, it makes it easier for new users to get wrong things, too. Right. So, we have added a few things in like warnings. So if you don't define a reaction, but you create a burner, we don't create a reaction by default. We don't create propane or whatever. We don't write that in now. I think we used to, we used to have a propane or a default reaction or polyurethane or something like that, just so it something would work if you ran it. And then we decided actually is not very good idea, right. Because now people make a burner and they run and they get a fire and they're good. But like, they didn't define the reaction. Yeah. They see smoke and they see fire and everything looks good, but, we stepped away from that and now we just throw a warning. Like, Hey, you have something that's requiring combustion, but you haven't defined reactions. So you need to go do that. And then it puts it back on the user. Now they got to go into reactions. And now we do have a library of reactions that they could pull from a library. But again, those do come from sourced data. They come from some like this reaction was used in this literature. It's whatever. So it's a starting point to give somebody placeholders, but again, it's the sort of burden is on the user to make sure that those inputs that are in their library actually reflect the model that they're making. and it gives somebody a way that they can put their own reactions back into a library to reuse. So the mechanism is super useful, but it could be misused. And I, I sort of struggle where that should be caught, right? Should it be caught by the software, make it really hard to use. All right. And, or not help anybody make it easy or should it be caught on the review? if there's a new user, somebody should be looking at what they're doing right. There should be a knowledgeable engineer or a staff member, or even a third party review somewhere. Maybe the authority who's reviewing it. Somebody at somewhere has to go, why you use a thousand kilowatts per unit area, right? Like for your, he released rate per unit area. 500 or two 50 or 300, you just use the default. Right. And we have had conversations about building, like audit, auditing tools to look for defaults, right. To help an authority, like yeah, run the, put your FDS file in here and it'll flag, Hey, this is a default value, you know, and maybe there's some good tooling. We could do that in Pyre SIM okay. These are all still defaults. Do you want to run with these defaults? Okay, good. And

Wojciech Wegrzynski: 16:56

We have that in ANSYS. And it's super useful, and it's called the case check and you run it. And it says, okay, this model is chosen, is left in default. You've used this model, but have not defined a species is a re related to that. Or this numerical scheme is used with this turbulence model. And it may cause this and this and window by window gives you relevant information on, possible, threats related the quality of the simulation that that's actually quite useful. And the second check is related to mesh, and it gives you information about the mesh quality skewness,

Bryan Klein: 17:31

yeah. We've added some new mesh warnings. Like if things aren't open, like if you didn't open your boundaries or don't have any kind of connection to ambient, like there's a warning now, but this is probably not going to run well. and at least just get the user to reflect on the choices they've made without verifying every input, but say like, Hey, these are. Some known pitfalls and try to expose those early in the process. I don't necessarily think, we shouldn't make hammers harder to use just because somebody could like, not build a house. Right. You know, so knowing that the tool is not the given to give you the answer, but it's a data point in your rational analysis. You know, you have this, this one answer from one simulation. Maybe you need to do five or six more to get a little bit more data to increase your confidence. And I think that's a broader topic than just like how the tool

Wojciech Wegrzynski: 18:14

Yeah. But as, tool developer, you find out that someone is using a tool in a ridiculous way. based on, default values or using some misconceptions that you must have this urge to try and prohibit that, but, there must be limit. So you don't limit the advanced user who know what they're doing. So how we deal with that as a, developer, that always intrigued me.

Bryan Klein: 18:38

yeah. So I mean, that, that is a good point. That's why we backed away from default reactions. Because we noticed that people weren't being careful. So without increasing the burden too much, we just. made there be a small hurdle, right? Like you can't run because you don't have a reaction. So you got to go to find that. Right. And then not just that forces the user back into like, oh man, now I have to think about a reaction, which is critical. That's the whole foundation of it. They should have thought about a reaction already. They didn't, but it's just to help remind people to make better choices where we can in the tool. and looking at doing some things like that, even with, mesh sizes, for example, like with meshing, like, Hey, one goal of meshing is that each mesh should have approximately the same number of cells. Right? Well, if we have a situation where you have one with a million cells and one with 300,000 cells, you could say, Hey, this there's some imbalance in your meshing, right? Like you might want to go think about how you've balanced your load. you know? And you can make that choice, but you could, it could stop somebody from being inefficient with. There are computational work and go back to that. And we've even made some tools to help mesh, to say like decompose this mesh into some number of meshes that have an equal number of cells, right? Yeah,

Wojciech Wegrzynski: 19:45

I've heard about that. I haven't haven't used that one yet, but have heard about the plan and it's like, wow, that's so cool. I've used to do that on my own with a calculator in my hands, making sure that you can divide it by two, three or five. And that, that was quite a lot of fun. I appreciate if you do it automatically

Bryan Klein: 20:03

And we do even have warnings of that too. Like your cell scale, like, uh, it's good. If the cells are more cubic than more of a stretch rectangle, right? So it won't stop you, but it just flags it in the UI. Like, this is a one to one to four ratio. Might want to change this one and maybe even a suggested value to get it back to them. One-to-one right. I think that's the thing. It's a constant kind of feedback cycle with our users to see what they're doing, right. What they're doing wrong. And then using that information to try to tune the software to be better at the end goal, which is ultimately making the process of making accurate models as quickly and as easily as we can.

Wojciech Wegrzynski: 20:40

I really, wonder what type of issues people come to you like your customers. because I live in a silo, we all live in a silo. I talk with researchers and, we. Sometimes may discuss the amount of angles for radiation model. Sometimes mys may discuss a way, how to, I don't know, model all three modes of heat transfer for a plate thermocouple or something, but I really doubt this would be the issues, that the end-users have. I really wonder what what's like from the user perspective, your customer perspective, w what is the needed developments and where could we assist

Bryan Klein: 21:18

yeah. So one is just the computational load, how to, how to take a complex problem and run an accurate simulation in the shortest amount of time. what strategies do we use? How do we do that? Cause you can, really make a mess for yourself, you know, and if you're not being efficient, if you're not blocking out unnecessary cells, if you're, there's a lot of techniques that there's almost an art to it or currently. and so that could all kind of go away in some ways, if we had different ways of defining the mesh, which may be as. automatic, you could do some kind of like adaptive mesh refinement system where, you know, we use , some metrics within the simulation to drive the resolution at specific zones or areas. And that all happens automatically based on some quality thresholds or some something that the user defines.

Wojciech Wegrzynski: 22:03

We have that in ANSYS as well, scale scale adaptive simulation, but not, truly using that much, because it also brings a lot of challenges on its own.

Bryan Klein: 22:12

Yeah. And I think that's part of why we don't have it in FDS already, too. I know Randy worked on that a bit and just found like it became very difficult. So

Wojciech Wegrzynski: 22:20

But yeah, it will be magical if, this happened, regardless of you, if you could just define qualitative metric to do it for you and, It would also prevent you just stupid decisions. You, you will prevent you running a model with like half meter match because it runs faster.

Bryan Klein: 22:36

well, and especially, big problem with meshing now is that what you get at time, zero is what you get by the end of the simulation. And in an often, a lot of situations, the phenomena, the fire dynamics are transient in time and space. So, you know what you've meshed for the first 10, five minutes of the fire isn't necessarily what needs to be meshed for the last five minutes of the fire, right? So you're by having to mesh at zero, it never changing the mesh is it really is not optimal. But for shorter duration simulations, where everything's pretty much the same in time and space, , Then it's okay . And, and I think that that whole problem. that whole, like, how do I mesh this? What's the best mesh resolution mesh sensitivity studies. There's a lot of effort that goes into this, just the way we mesh. And if that changed, that could be a big benefit. So that's, but that's an area of research that, you know, that's a big project. Somebody wanted to try to add adaptive, mesh refinement into FDS, or have some ideas for that, how to do that. Like I know that's a significant undertaking, so, but it would be an area of work. Reactions. and I would say like solid phase reactions and just that whole material properties, how to get, how to get real objects converted into FDS input is always a struggle. And then testing that, you know, like just making sure that, for the heat in you get the reaction out, you get the decomposition step. Correct. You're getting the pyrolysis. Right. And you're getting the right fuels out of it that the energy balance is correct. And in depth and all of that, I think,

Wojciech Wegrzynski: 24:00

I was always scared of that, as, as a fire scientist, I have very, very little trust in my ability to really model that well, like I would consider myself somewhere around an advanced user and. I've done TGA uh, I hope I understand how it works, but it scares the hell out of me to model pyrolysis. And if it was that simple, advanced models like G-Pyro FDS would never exist, there would not be a neat if you could just, turn it into a simple Arrhenius reaction, give me two variables and we're done. It's not as simple. And yet I think there's a whole group of people who maybe even think that it's necessary for the simulation to be credible, because did I really simulate fire when I didn't have my solid face to gas face model? I mean, it's curious. And then again, I go back to my simulations and I define heat release rate. I define soot yields, heat of combustion. That's pretty good. It's and these are the things that will matter after all, no matter how complex the reaction was in between, if you force model to release two megawatts, it will release two megawatts, no matter how many steps the reaction has.

Bryan Klein: 25:16

Yep. Well then if you're using a burner, it's going to keep pumping that fuel mass out at whatever rate you specified, regardless of how much oxygen is available and the energy feedback and all of that, it just keeps pushing gas and

Wojciech Wegrzynski: 25:26

I was always scared of that. I was, I always went towards minimalization of the, inputs I do, and to cut as much out as possible. well, that, must be interesting struggle. The new users may have defining reactions and maybe even believing that it's so necessary to have that part. Correct.

Bryan Klein: 25:45

I think part of it is we are, we know how reality works, right. You know that you have something, you make it hot, it starts to burn then based on what it is, it's smoke comes out with certain chemistry and whatever, and you have an expectation that, well, if you have a fire simulator, then it's going to do the same thing, you

Wojciech Wegrzynski: 26:01

it's going to simulate fire, right?

Bryan Klein: 26:02

Yeah. That I, I have some things and I heat them up and they burn and like in a fire spreads around the room, over the carpet and everything just like it would do in reality. And, and FDS doesn't really have the physics of the same thing.

Wojciech Wegrzynski: 26:15

That's the story of my CFD start, man. I maybe I've told you the story, but the first time I've started like PyroSim. And I was like, okay, let's simulate something easy. Like, what's the easiest thing. Let's burn a log of wood. And I, I've built a model. I've put the piece of wood and the first one didn't ignite, the second one exploded. And I think that's actually an interesting field of science. This would to burn.

Bryan Klein: 26:40

Yeah. Yeah. I didn't like, and did you model the lignin and all the, like components of the material and all of the

Wojciech Wegrzynski: 26:46

was super, I was super, smart and sassy back then. And, I've done all the tricks in the SFP handbook and the got them hooked. It either kept exploding or didn't catch fire. So

Bryan Klein: 26:58

And you know, what's funny about that is that could have been just a mesh resolution issue too, right? Like completely unrelated, like, because you were averaging out the temperature on the surface too much, and it didn't get to the ignition point. Right. Like, there's, there's, a lot of complexity, and just that

Wojciech Wegrzynski: 27:10

but then again, I have never used the same model ever again in my professional career that was in a school, but in a professional career, you know, here's like design fire scenario that you need to model and it's alfa-t squared and you just put that hard as a hard boundary and that's it.

Bryan Klein: 27:25

Yeah. And I th I think that's a key point is that the majority of fire protection engineers, for example, they're using designed fire they're being more explicit about controlling what's happening in the environment. there may be using curb ramp curves instead of flame spread. Right. And, because their FDS is in this weird space where it's, it was designed to be a very practical tool for engineers to get a good enough answer in a reasonable amount of time. Right. And so it's sort of tuned for that workspace, but it has all of these more detailed capabilities, right. It can, you can go down to DNS mode and simulate the decomposition of a wick you know, of a candle flame and the, and all of that, like at a very small scale. So, and so you get this. Hybrid experience of, well, what's a very practical use of FDS in, to build a fire that's gives you enough information that you can make a rational decision about, or do I keep going deeper? Do I start getting into the research re research area of this, where I need sprinkler spray to presoak my materials and then, suppress my fire and, get the momentum transfer into the gas phase accurate, so, there's a lot of research in that area, to get all of that detail, but then. how much of that can be transferred back up to a practical level where, you know, I need to get a few answers in a week or so, and have a good sense of what's happening in this building. And if my smoke handling system will do the job or not. and I think there's all these little pit pitfalls where people like, oh, that's a feature. I should use that. And it's like, actually, that's kind of over in this research space that nobody really fully understands yet. There's not good models. Or we just know, we're not going to go down that path because there's other tools that are better at that. Right. another example I would say of common. Issues and frustration is the conversion of real geometry into this Lego block world. Right. And there's some problems that come from that and it's dependent on the mesh it's dependent on some other things, and how you model it. And so somebody will take an architectural model of a building and import it into PyroSim and make a mesh around the thing and expect it to be what they brought in. Right. And not this rasterized blocky, stair-step diversion of it.

Wojciech Wegrzynski: 29:29

there, there is a reason why it's "SAWTOOTH = FALSE" is a, there is such a line and it's you have

Bryan Klein: 29:35

that's gone away. That that went away. Yeah.

Wojciech Wegrzynski: 29:37

Oh, cool.

Bryan Klein: 29:38

But there is work going into what are, what is now called Geoms it's a new record set, um, where you can do this immersed boundary method or the IBM's method. And so now you can have this non-regular geometry in the Cartesian mesh and there's this cuts out method. That's applied to try to deal with that. with it comes with more computational costs. I won't expect people to model their whole building, in the immersed boundary method, but maybe critical geometry. That's like, you really want to get the in, in and out of them. So surfaces correct. And the flow around the object.

Wojciech Wegrzynski: 30:09

okay. I'm going to challenge you. I heard about this first time in a FMTC in Malaga I think it was, there was my Marcus Vanella presenting the first, approach with that. And, it was super impressive, the, this immerse boundary method, but he mentioned it increases the computational time, but by a factor of something, I don't remember the number, but it was a significant factor, like two, twice or three times. And that was like down. If that's the case, it's not going to be ever used. Like people would rather find lazy work around. Or, approximation rather than use a technique that increases computational time by a factor of two or three. And, I don't even have to go that far to future set of features. We are here today and we have the mesh resolution. You cut the mesh size by half. You, you increase the computational time 16 times.

Bryan Klein: 31:03

Well, I'd I'd rather have a two X increase than 16, right? Like, right. So, so that's, I think where that, value might be as like, if I have just one part of the model that I need some good resolution around that space or around that object or that surface, the rest of the model could still be blocked. So you, you don't need to write, use the whole thing, immersed boundary method. It's just certain objects within the scene that are really critical to, you know, maybe you feel like those are critical to the analysis, , or maybe smaller scale things. But, I mean, look at where computing has come computing power in the last two decades. The clusters I was building when I was working at Western fire center are like weaker than my cell phone now. Right. with GPU's and scaling. So I think that there's. Optimizations there's things that can happen that can improve our ability to solve harder problems at the same speed or faster. But, sometimes it just might be the question of time, cost and accuracy, right? Like, so maybe you don't need to spend the time it's a decision, that's an engineering choice, right. That's something a user has to go. Is it worth extra? Like how much more do I get out of this? And is it worth the cost? maybe it is, maybe it isn't. So I don't think it's going to be the default. Like everybody should just import their whole building, run it all immerse boundary and just, you know, pay the cost for the entire building.

Wojciech Wegrzynski: 32:18

and have amazing doorknob aerodynamics

Bryan Klein: 32:21

yeah, your inches, your engine, your trim, you know, you see the flow around your trim and your door frame and everything. Yeah. I don't see that as like that won't be How it will be,

Wojciech Wegrzynski: 32:31

let's hope for that. You you've touched the competitional power. there are funny ways you can spend your computational power, you know, not necessarily on the accuracy. It's very tempting to go into multiple scenarios or what if a analysis or parametric studies and. You see that in evacuation modeling where basically the calculation time, I wouldn't say it's irrelevant, but even very complex models you can get to under an hour. it is completely different timescale than CFD I would say it's not a part of the optimization equation and I wonder where it would go in, in CFD. And you sit here as a developer, you observe this growth of power every three years, it doubles or whatever, the Moore law says, how does the user change using your model? Do you see the staff using finer meshes or they just doubled their profits by running twice the projects.

Bryan Klein: 33:26

Yeah. I hadn't mentioned that yet, but that's also probably one of the more common support questions we get is, , so I started this model and it says, it's going to take, you know, six years to finish, you know, like how can I get it done? And it's like, okay, , my guess is your model is not well, defined in a way that. Computationally efficient. Let's just, we'll say it that way. Right. You have 200 million grid cells. You probably need like 3 million, right? Like, I mean, there's ways you can, you can optimize this stuff. , and I do, I have seen, I don't, I don't think Moore's law is holding, because we we've been all kind of around four gigahertz. Five years, six years, right? I mean like nothing, you don't have a 10 gigahertz chip, right. Or a 20. So we've hit this plateau around three to five and now you see more cores. so now the problem is like not clock speed, but parallelization. And how do we like spread this problem out over more cores? And there's been work. you know, Suzanne Kilian, has been working on new pressure solvers to help decouple the pressure solution to make it more parallel. so that we could take smaller parts of the model and distribute those calculations over multiple cores more easily without that direct coupling that happens in the global pressure

Wojciech Wegrzynski: 34:34

I think radiation is also perfect

Bryan Klein: 34:36

Very another one. Exactly. so some of those strategies I think can make that more efficient and may make up time and then we can scatter, we've added some cloud computing capability into PyroSim there's services like Sable core and CFD, FEA, and others out there that, you know, you can spin up these instances of virtual machines that have 96 cores and, terabytes of memory and everything, and you can run these calculations there. and I think that focusing on. effective ways to parallelize these calculations that take advantage of these computing platforms offers is going to be an important one moving forward. Especially if we start adding in more calculational load, computational requirement like with the immerse boundary method or other improvements in accuracy, we've got to spread that additional load in some way. And I don't think it's going to come in the form of faster clock speeds. At least in any future I can predict we're just gonna need to find ways to use more cores and, and you're right. there's another opportunity, which is. we've added like a scenario's feature into PyroSim and, we have some other work to help him make it easier to make like multi-variate equation or multi-variate calculations or test sets where you could take, like, let's say he released rate per unit area, for example, and you say, I want to test like a min-max bound on that. And it will automatically generate the cases for all of these bounding, which is something people do manually right now. A lot of times they'll, go 10% below, 10% above check, check the result and look at the phenomenon of interest, making tools to help people generate those test sets or those, you know, minimize the number and help them make a good set of scenarios that they can then run all at the same time on like maybe cloud computing or something. And in this case, day or two that it would normally take to get the answer to one question, you might get a hundred back right here. You might get 10 back because you ran all 10 at the same time.

Wojciech Wegrzynski: 36:20

You can run a hundred together. You can run a thousand together. if your wallet allows for that, which we, which isn't in a way, a beautiful, um, concept and, Opens a complete new array of possibilities. but it creates challenges. You know, it creates challenges with processing the data that will come back to you. So if you are working on a ways to allow people to do the simulations, are you working on ways to collect the data and reduce the the results in a way

Bryan Klein: 36:50

Yeah. That's another area of work that was actually a idea when I joined Thunderhead, it's like 11 years ago or whatever, it was like, we want this kind of risk analysis system where we can run lots of scenarios and reduce that down to statistical views on, what the probability of things are. You know, what's the probability of failure based on a set of runs that have explored all these different variables and the impact on the phenomenon of interest rates. and so that's, now that we've, kind of like, we've opened that box. Like now we're opening the box to the cloud computing, which immediately demands. Okay. Now I have 500 gigabytes of data sitting up in the cloud somewhere that I need to get an answer from. What do I do? Like do I download it all? And do I download it all to my computer and start running Python scripts to like, try to process all this stuff? Or is there some tooling that we can use maybe even cloud side, like services that can help collect the information and aggregate it and then process it and give you, you know, maybe a web view of your data we're exploring some like solutions to how to, deal with the big data problem, because now that hasn't really been a problem, right? More, more people were restricted computationally historically, you know, I only have so many cores or I only have two computers in my office that I can work with. The computational capabilities have expanded, which then has generated even more data that has to be reduced back to something reasonable that you can use to inform your analysis. So,

Wojciech Wegrzynski: 38:10

my dream would be to reduce the complex analysis to like a single number. You know, I've mentioned that in episode 13 with like when I do a pump, I want the pressure to flow chart. When I do a complex duct, I usually would like a pressure loss and that's, that's it. I don't care about the fancy vectors in sight. don't need that. I would know as much from my simulation seeing just this single number or a single chart, then going through, , hundreds of images

Bryan Klein: 38:40

Yeah. I've almost thought it would like imagine a probability curve and here's your threshold value? What's the probability of exceeding the threshold,

Wojciech Wegrzynski: 38:47

w we do that in risk. you go up on the curve, you have a risk threshold level, you have outcome of all of your scenarios, combined fatalities to probability, and you can compare that there was an excellent PhD in, Ghent Bart van Weyenberge. And he had some papers from it who did response surface modeling with FDS as well. And he was going very, very deep into that. And it would be really great if we could somehow move, people away from single point calculations into this approach, because it gives you so much broader view and understanding of what's happening in your model and understanding of the physics that's going around.

Bryan Klein: 39:24

And any consequence of uncertainty, right? Like like if I don't know exactly the density of the material. Tested sort of reasonable bounds and looked at the result of the heat transfer effect of that. then I get, it increases my confidence a little bit in that I know reasonably well what it is.

Wojciech Wegrzynski: 39:41

worst case you know, if it's important or not,

Bryan Klein: 39:43

Right. Exactly. How sensitive is. it? Exactly.

Wojciech Wegrzynski: 39:46

if it's important, then you can research it further. So, also gives you, another view on your simulation that I think the tools that we currently have do not really promote this

Bryan Klein: 39:56

No,

Wojciech Wegrzynski: 39:56

analysis, that

Bryan Klein: 39:57

It's hard enough to make one model and run it and get an answer. Right. Not run a hundred or run 50 or whatever number you need to run to get a more comprehensive view on the results. So yeah.

Wojciech Wegrzynski: 40:09

I also wondered. And that's a challenge to you as a developer. Maybe you will not like it. I can cut it out if you, if you hate it, can, do we have like a CFast with PyroSim you know or something like a zone model that would use the same sort of inputs I, I'm a huge fan of scissor zone

Bryan Klein: 40:26

Thank you for plus wanting my feature requests. So I already have, that's been a long time. Like we already have so much in PyroSim that to basically try to establish room volumes and connections. like you need for Cfast is not a lot more information, right? It's but it does add some complexity and, you know, it's, one of the. Cost benefit things, you know, that you have to make, you have to make these choices. We have limited the number of developers. We have a limited number of years. What's the most important spend on our side to get people the features they need and want are the tools they need. One. another example is, you know, people have come to us complaining about, CONTAM is great. I use it for every project and it's terrible to work with. Right. It's like so hard to use. It's just

Wojciech Wegrzynski: 41:07

it on my list just after the zone model.

Bryan Klein: 41:09

Yeah. And , so that's actually come to us way more often than Cfast. So we've taken that on. As you know, we're starting work on a CONTAM gui essential, you know, some tool set to help make modeling and content a lot easier. And what's really interesting about that is what people mostly complain about is the windows build of CONTAM that uses the little sketchpad and like trying to work with that. that's the hard part is the tool, and under the hood, there's, content mix, which is this real abstract, generic, you know, node network system, calculation tool. so we're, not really trying to recreate the windows thing, but really leverage that more abstract

Wojciech Wegrzynski: 41:45

And you just build on the network model that exists. That's cool. What's also on your magical list? Tell me,

Bryan Klein: 41:50

well, I can't give away all of our secrets, but, uh, yeah. those opportunities are what we look for for, you know, people who really find like this pain point, like, ah, we use it, we use this tool all the time and it's terrible. Or, we always spend way too much time like doing this kind of data processing or whatever. And if we, if we get enough of that, it inspires us to try to like find a way to solve that problem for people and make the tool that will make their job easier. and we're not in the business of competing, you know, Thunderhead doesn't do fire protection, engineering or analysis. We're really a, tool builder. So, come to us with your problems and your struggles and your pain, and we'll try to find ways to make it easier. And that's. Big effort, you know, so what we try to do but yeah, the few things I mentioned, those are probably the highlights. In the Pathfinder world, there's some work to help make like rail car simulation and stuff like that easier. And, you know, with like dynamic obstacles and things like that, that can happen during the simulation. There's always something we have, like I said, we have I think Pathfinder has something like 400 feature requests sitting in queue, waiting for somebody to work, you know, and, and, and we have scaled up development. I started with Thunderhead, there were five of us. , I was the fifth and now there's, I think 17 people and not all full-time, but seven with some interns and some full-time staff and stuff. And we've really grown. Our developer set our group. So we're now able to. Churn through these hopes and dreams that people come to us with and start producing something more quickly.

Wojciech Wegrzynski: 43:13

Okay. For the last question, let's go BIM integration. My, my colleagues in office say that, uh, I was not to listeners so I was not paid to say that at all, but it's an, as the opinion like that, your BIM importer is magical and it, it works For us, at

Bryan Klein: 43:29

for Pathfinder or

Wojciech Wegrzynski: 43:31

Pathfinder. yeah. It's magic. It works so well. And it's so, so useful. And, you know, BIM to CFD is this sort of, I don't know, dream for the engineers that you could just take and model in one computer plus press calculate. And you have CFD done. And agree. It would be fantastic, but in a way, we come back to the challenges of the beginning of the episode, where people not even knowing that the Pyrosim is not FDS would be running fire simulations because they have the button to do so. And there's nothing to stop them. And, the smoke will be there and the fire will be there. So I, I wonder, what's your take on BIM fire integration, and was the future for.

Bryan Klein: 44:15

so that's great. That's a great question. and it is an area of work, so we've even just recently with Pathfinder. there's some really good work happening with Lund within Enrico and, Nazim there. And, Pete Thompson at Autodesk there, we're all kind of working on, some new staff, new expanded parameters that can come in the BIM model that we can then in Pathfinder read in to use. even more efficiently build a model, like how many people are in the room, what kind of profiles are in the room that stuff could be

Wojciech Wegrzynski: 44:40

um, in BIM, that makes sense. That's what BIM is for.

Bryan Klein: 44:44

We'd use that as input, build the model, run it, right? Like that's. Yeah. And then the output of Pathfinder gets reimported back in and stored in the BIM model for like, what's the flow rate at the door. What's the time to leave the room, stuff like that. So you get this like full life cycle kind of a thing. So taking that idea, that concept, that we're doing pretty well in Pathfinder now, and are working to improve using as much information as we can from what's been defined in the BIM model, right? So if you've defined your material properties and you have a density set, for example, or you have some thermal physical data that is stored in the model, reading that in and using that to build a surface and materials that have the information. So we wouldn't be inventing a material for you. Like if it said it was covered with carpet, but didn't have any thermal physical properties. Define what carpet means for you, but we would step in a placeholder and say, you have a material here. It needs to be done. It's not fully defined yet, but be good because we already know this association with the material in the surface. Then it's, if you just fill in this information, then you'll have, Therma physical properties for this solid, and where there's a door, in Pathfinder regenerate a door element in the navigation mesh and PyroSim the equivalent would be maybe a, wall with a hole in it with an obstruction in the hole. That's already kind of set up as a door that you could open and close or whatever. So, same thing with windows. Like we, if we know there's glass and there's glazing, we HVAC exactly. Like where's the vent, what's the vent area. What does it connect to? We could reinterpret that stuff. Yeah. So there's a lot of room for improvement in that. and as we're continuing to work more in BIM and the IFC files, Being able to intelligently extract that data and use it to at least create a good starting point. That would be just a lot of busy work to build it. You've already defined it. So we're not inventing information. You've already defined this in a model somewhere. We're just converting it into the same definition of those things, but in a different context, which is sort of an FDS model version of that. So yeah, there's room for that, For sure. And it is one thing that's been on our, list now, like I said, I even gave the talk of the webinar recently about, BIM can be insane, right? Like you could have all your piping and plumbing and hinges and doorknobs and all that. Like there could be a lot of detail in there that you had to go through some reduction step to convert it into, more simplified fire models. So, that's also like how do we, without just bringing everything in, maybe we bring in the CAD just for visualization, but under the hood, we've really reduced this down to just what the wall, where the walls are in the floor slabs and kind of re. That detailed version of the building into a more simplified rendition. So

Wojciech Wegrzynski: 47:10

I honestly think that for many years I thought the way how meshing works in FDS is a disadvantage. You know, for, for many years, I thought that because it's, the way how condition mesh is built, that you have to build a mesh to incorporate your surroundings, then build your walls inside. It is sometimes annoying if you have troubles with shapes and so on, but now did we have to go into the world of BIM with our, software and I have to do a very complex unstructured mesh on this mess of door knobs, hinges, seven layers that define the pipes. I would love to have a model that just pops me a rectangular grid cell and doesn't care if there is 17 small cords going through it or not. So I think in a way as something, they felt that FDS is its weakness. It can actually be a huge favor

Bryan Klein: 48:08

strength. Yeah.

Wojciech Wegrzynski: 48:09

and

Bryan Klein: 48:10

And, and I think a lot of people they'll take in these complex geometries, they'll use it as really as a reference for using the really simple PyroSim like wall tool and slap to, and stuff to draw these simple objects. And use CAD their cat is like snap referencing. So they can say, oh, the wall goes from this corner to that corner. They don't care about all the detail and the trim and everything like that. They're kind of just reducing all of that out by redrawing, a wall object where those, you know, in those two points in 3d. So then you can kind of ignore the CAD version of that wall because you've recreated an equivalent essentially in 3d with a simple object in PyroSim and so those kinds of conversions people are doing manually. Like I've talked to quite a few people that, you know, they have this gigantic beautiful building and it's yeah, but if this is my FDS version of it, and it's just very simple walls and very simple floors and some big objects that are like the critical components of, that environment that the fire model needs to know about and not all the sub grid stuff for, or on essential characteristics.

Wojciech Wegrzynski: 49:10

Let's close on this one. Okay, Brian, that was great. Having you, I know that you have conference going on in my neighborhood, soon ish, so

Bryan Klein: 49:20

yeah,

Wojciech Wegrzynski: 49:21

let's advertise it. I want more people in it to have beer with.

Bryan Klein: 49:25

yeah, that would be awesome. Yeah. We're , so we're planning for the September, to do the sixth, fire and evacuation modeling technical conference, which is a mouthful. So we say FMTC or fem tech. I've heard it say all different ways. So if you go to femtc.com, that's the website for the event. And there's a way to pre-register that you're interested in, let us know if you'd want to be in person or virtual. It will be a hybrid event. So we will be in person and live streaming at the same time. that way, if I mean, COVID is thrown a wrench in everything. We ended up having to go virtual with 2020 for the same reason. And so we're really hoping that, you know, all the efforts we've done so far with vaccination and masking and all of the public health stuff that it's, paid off enough that by September, we'll be able to travel. People will travel easily and feel safe, to be there. So that's something we've considered, there's a backup plan to go. just pure virtual if we have to

Wojciech Wegrzynski: 50:18

nah, we need to go.

Bryan Klein: 50:19

hope to be in person. Yeah.

Wojciech Wegrzynski: 50:20

It needs to be in person.

Bryan Klein: 50:22

Yeah.

Wojciech Wegrzynski: 50:23

I didn't care about you. I'm going to know

Bryan Klein: 50:25

Yeah. Yeah.

Wojciech Wegrzynski: 50:26

if the conference is not happening there,

Bryan Klein: 50:28

So we've been working. Yeah,

Wojciech Wegrzynski: 50:30

Evans.

Bryan Klein: 50:32

I'll be there. Yeah. The, uh, we've been working with our, we have a distributor there over Recognity Tomas Apeltauer and he's been helping find great events, locations, things to do while we're in the city. And, uh, we're really looking forward to it. So call for papers is open. Now. It just opened up. you'll see that information on the website, on the event page. And, we're just a quick abstract, no more than 300 words, just a quick idea of what you would like to talk about and, Pick, hopefully we get enough, uh, you know, good ideas that we can put together a conference. this is not really like a revenue generator for us or anything. If we break, even, we feel like we we've done a good job. We try to keep costs low and, and maximize the value. We put all the talks and everything for free on the web. So you'll see, every past event has a YouTube video for the talk and the PDF of the paper. And, you know, we really try to spread this. This is part of our, I would say advocacy mission where we're trying to really promote the work of others in the field and get information out to as many people as possible to help kind of Raise all boats together. So, yeah, we're really looking forward to another great event

Wojciech Wegrzynski: 51:36

I can confirm I've been into two or three, I think. And all of them were great. It's one of my favorite conferences. the location is convenient. It's in Brno in Czech Republic where you can get, probably from any place of the world flying to Prague or Vienna, and moving by train. So it's, quite easy to get, from wherever you are. And I think it's worth it. So, I, I'm sure I will be there.

Bryan Klein: 52:01

All right, I'll see you there.

Wojciech Wegrzynski: 52:03

to that,

Bryan Klein: 52:04

Yeah. It'd be great to get everybody together again, it's just as many new faces and familiar faces as we can. And,

Wojciech Wegrzynski: 52:10

Let's hope. That's hope for that. and if, it's like online, you'll have to stream beer in a, some sort of way. That's

Bryan Klein: 52:17

Yeah. We'll have to see , maybe Metta her Facebook has come up with a new way to like

Wojciech Wegrzynski: 52:21

Oh no. Oh no. no, no. Let's keep a fire safety in the metaverse,

Bryan Klein: 52:27

Yeah, separate spaces. All right. Great talking with you. Thank you.

Wojciech Wegrzynski: 52:32

again. Thank you so much. it was Great It was a pleasure. See around Bryan And that's it. I hope you've enjoyed this one. I certainly did. It's really interesting to view the world of fire modeling through the eyes of a developer and. So many aspects are being brought that. Probably the end users do not really think about that much. I really liked one thing that Brian mentioned, and that was the review mode for PyroSim that. That would allowed to review FDS codes. And I honestly think this would be an amazing feature. In engineering offices. For the authorities. For the firefighters who go through the simulations, this would actually be quite a good innovation that would help. Improve the general quality of a code. If there was an easy way to review what has been done in the code, I'm highly supportive for this. Development and I hope they, they deliver. And from what was mentioned, I also enjoy the BIM importer that's in the Pathfinder. really works like magic. I'm amazed by this. Tool. And I hope this makes. More appearance in the world of fire modeling, CFD modeling. Because that could be another step forward. And he also loved the cloud computing aspect of our talk, where we've discussed, how we can really benefit from scaling up the computational capabilities and going into hundreds of simulations and. What to get from that. So, Actually plenty of good. Practical takes from the this talk with a developer. And as mentioned in the introduction. Please go push him for the things that you want. Maybe plus one on the idea of CFast in. PyroSim I would absolutely love that. And they will be thrilled to have that. And plus one on the Contam in PyroSim that's also a great, great idea, and it will help so many people. And so many new people will use that too. So. Wow, great development. Anyway, I hope you've enjoyed that. I hope you've learned something new. I hope this episode brought some new ideas how you can work with your. fire engineering, modeling projects, not only with the tools brought by Thunderhead, but also with all other tools, because some concepts are Just universally good ideas, not really related to a brand or a company. And yeah, that will be it for this episode. Thank you very much for listening. And, see you here next week. The same time. See you. Bye.