252 - Substantiating Fire Models with Craig Hofmeister and Bryan Klein

Why We Overreach For CFD

Bryan Klein 0:00

Hello and welcome to the Fire Science Show. We are living in a very weird world of, uh, engineering where you are kind of expected by many forces out there to immediately jump to the most complicated models at hand to, you know, prove that your solution for fire, uh, works. Uh, I'm talking about immediately jumping to FDS, immediately jumping to CFD models for literally anything in the modern world. While for different problems, different solutions, uh, exist, different models exist, and, uh, following a very dear to my heart philosophy of, uh, consistent level of crudeness that, um, colleagues from Canterbury are preaching, uh, I really think we should think a little bit more about what tools are applied as a part of fire safety engineering. And, if you think about that, you need a framework to prove or decide, like how does, how does one decide which model is actually appropriate for a problem? And, this is something that is not only bothering me, but it was bothering a lot of people. And in the SFPE, Society for Protection Engineers, uh, a task group was formed and, uh, a guideline was produced. The first edition of that guideline was released in 2011, and now they are finalizing the revision of the guideline, which hopefully will hit the market very soon. The guideline is called Substantiating a Fire Model for a Given Application. It was chaired by Craig Hofmeister from the Fire Consultants with many other authors, contributors on a very long list of contributors there. And as you can imagine, I have this exactly as the subject of today's podcast episode. I have invited Craig to talk with me about this guideline, but also invited Brian Klein from Thunderhead Engineering and Apex Edition, who I know is teaching this. He is giving courses on substantiating a fire model. And the last one has been in Singapore, where I had the chance to talk with him. And we've decided, yeah, this should be a podcast episode. So in today's podcast episode, we will go through the framework, really. It's not a book review episode. It's a framework episode. And for you to better understand what the framework is immediately, I'm going to very briefly outline it. It's a methodology to decide which model is appropriate for the fire problem at hand. It starts by definition of the problem, definition of the questions. It moves into selection of candidate models. It goes into evaluation, model verification, validation. It goes into uncertainties, user effects, user inputs, and documentation of this process of substantiating the model. A lot of that is project specific. Some of that is user specific or code specific. And we're not just talking about CFD models. We're talking about a range of variety of models from simple physical models, algebraic equations, the ones that you find in the handbooks, through zone and lumped parameter models like CFEST, like Ventus, like Contam, into the most complicated CFD models applied at different levels of complexity within the CFD codes, because there's also a variety out there within the models themselves. So this is the framework that we will be discussing in this podcast episode. Even if you don't have access to the book, it's not fully released yet, but even this, I think, gives you a very good idea on how to carry out this decision process and how to carry out building up a case for the model that you have used, that this is the correct model. As a very long introduction, I think I'll just pass the voice to Craig and Brian, and they can definitely tell you more about this and why it's important. Let's spin the intro and jump into the episode.

Sponsor Message And Partnership

Meet The Guideline Authors

Wojciech Wegrzynski 4:25

Th e Fire Science Show podcast is brought to you in partnership with OFR Consultants. OFR is the UK's leading independent multi-award winning fire engineering consultancy with a reputation for delivering innovative safety driven solutions. we've been on this journey together for three years so far, and here it begins the fourth year of collaboration between the Fire Science Show and the OFR. So far, we've brought you more than 150 episodes, Which translate into nearly 150 hours of educational content available, free, accessible, all over the planet without any paywalls advertisement or hidden agendas. This makes me very proud and I am super thankful to OFR for this long lasting partnership. I'm extremely happy that we've just started the year four, and I hope there will be many years after that to come So big thanks, OFR for your support to the Fire Science show and the support to the fire safety community at large that we can deliver together. And for you, the listener, if you would like to learn more or perhaps even become a part of OR, they always have opportunities awaiting. Check their website@orconsultants.com And now let's head back to the episode. Hello, everybody. Welcome to the "Fire Science Show." I am joined today by Craig Hofmeister from the Fire Consultants. Hey, Craig, welcome to the "Fire Science Show."

Craig Hofmeister 5:50

Hey. Hello.

Wojciech Wegrzynski 5:51

nice to have you in the podcast, and, uh, together with us, uh, Brian Klein from Thunderhead and Apex Erudition. Hey, Brian, welcome back.

Bryan Klein 5:58

Hey, good to see you again.

Wojciech Wegrzynski 6:00

we need to do an update on the new stuff, uh, happening around in the world of technology and, and modeling one day. I miss... I, I'm missing that one. That was fun.

Bryan Klein 6:09

Yep

Wojciech Wegrzynski 6:09

was fun to do. But, uh, today, uh, we're here on a very particular subject, uh, covering a very particular guideline by the Society of Fire Protection Engineers. Craig, you've been the chair of the committee. The book is "Guidelines for Substantiating a Fire Model for a Given Application." Which is, as you're listening, either in its final rounds or already, uh, released, but it's heading your way. And, it looks like something that can help, fire engineers a lot, but, uh, let's perhaps build a case, uh, for that. So Craig, uh, I know you've been involved in the version one of that. Can you tell me a little bit more about background of how this type of document came around and, uh, what was the, the goal of providing such a guidance?

Why The SFPE Guide Exists

Craig Hofmeister 6:55

Yeah, I think the-- in the most simplest form, I'll, I'll speak as a consulting engineer. I think it started as, you know, what do you do if you are using fire modeling and somebody, whether it be an authority having jurisdiction or third-party reviewer or something, says, "How do you know that you used the model correctly, and how do you know that the model is appropriate for what you're using it for?" I think that was the intent from SFPE, uh, originally, was to try to develop a document and a a common sense and a, a process so that you could go through and try to establish that, yes, this is the appropriate model for what I'm trying to use it for.

Wojciech Wegrzynski 7:28

When it first came about, uh, was it alreader-- al-already the age of CFD prevalence over an-anything else? how did the landscape look like? What were the worries of fire engineers when they were picking up their models back then? I think it was the 2011. Yeah, that, that was the age of CFD for sure.

Craig Hofmeister 7:49

Yeah. So we-- there certainly was CFD. Pyrosim was, was around as well, and so there was becoming more

Wojciech Wegrzynski 7:55

Definitely.

Craig Hofmeister 7:55

of, of fire modeling. and then it always comes back to, well, you know, do I use algebraic equations? Do I use zone models? Do I use CFD? How do I know that I'm using something that, that is correct for the problem I have?

Wojciech Wegrzynski 8:07

You may believe it or not, but in 2011 I was already teaching Pyrosim in Poland. So it was that definitely, back then. So, the choice for me o-o-of a fire model seems pretty straightforward from practical, you know, perspective. I choose CFD because it's the one that is accepted by the authorities or expected or, or, or just, you know, the standard or, whatever force that pushes me into that. And I don't like that situation because I see a lot of benefit on other models. W-what's your take on that?

Craig Hofmeister 8:41

mean, I think I would agree. speaking from a consulting engineering perspective, you know, of course, we have budgets and gotta answer to the client and so forth. So, you know, I've run into situations where you might have a pretty simple atrium, and actually any of the three correlations, zone model or CFD may work. Um, sometimes the client wants to see something a little, you know, prettier pictures or something a little more in-depth. Sometimes AHJ wants to see that as well. so yes, I think we're, we're just trying to make sure that whatever we're using is, is appropriate and we can justify it at the end of the day. I think so it's trying to go from one end to the other. There's a lot of cases where algebraic models may not be appropriate and CFD is. some cases where algebraic models are appropriate and CFD still is, and of course, zone model is in the middle of that. So again, just trying to make sure that at the end of the day, we're, we're using or, or presenting a process that we're using the model appropriately.

Faster Tools And Better Fit

Wojciech Wegrzynski 9:33

Brian, how does it look for you? You're a, a developer of, uh, o-o-of an interfaces for different models. It used to be mostly, uh, CFD, but now with Ventus you're also providing an interface for, let's say, uh, uh, an algebraic model of, of some sort. Like how do you even call that class of models?

Bryan Klein 9:52

it's, it is definitely more of a, I'd, I'd say a node network model,

Wojciech Wegrzynski 9:57

Modern. Okay. Yeah.

Bryan Klein 9:58

it's, it's not...

Wojciech Wegrzynski 9:59

in, somewhere in between.

Bryan Klein 10:01

Yeah, your nodes represent volumes. There's connections, you know,

Wojciech Wegrzynski 10:04

Yeah.

Bryan Klein 10:05

with flow paths and, and those are represented orifices or some kind of a sub-model to represent that, flow field. And I mean that as an example, I mean, Ventus is a, is a simplified model compared to, FDS, or through using the PyRESim interface to build those models. And, you know, there's definitely interest in a faster tool to get your analysis done in a reasonable way that you can justify then be able to get on with your work. You know, you don't need to wait two weeks to get, the pressurization solution from FDS. For a whole building, you can get it in 20 seconds or two minutes from, from a tool like Ventus. And, so I think still, you know, there's some requirements and understanding the limitations and the assumptions and all of that, of the various models and knowing like, is this appropriate? And really what this guide, think, really walks you through, is just thinking through the application of the tool to the problem making sure you feel confident, can justify the use, for whatever the problem is that you're trying to solve. and, and so I think when things-- I, I kind of tend to think of things as a temporal and spatial resolution issue, that when you need more resolution in time or in space, you need a tool that can resolve that. And then if that's not critical and you're looking at big bulk movements or flows that are on the zone or, node network level, then you can use the-- that's a completely appropriate tool for the job and can come in faster and under budget and all the other, all the other benefits that can come with that. I think the other thing too is that tools like FDS and PyroSim require of inputs, and those inputs all have to be justified. and sometimes you may not have the data that you need to fully, you know, resolve the model. So instead of pretending like you have good assumptions or good data, you maybe just don't even reach for that tool if you just really don't have the input to support the use well, or you have to go through a more time-consuming validation process or t- or sensitivity study process to kind of check your, check your answers. So anyway, we got a lot of requests from engineers. The, the reason Ventus came to be was people saying, "I use CONTAM in almost every single project, and it's painful." You know? No, I'm, I'm not trying to slight the developers of the CONTAM UI, but it's, it's a schematic sketchpad pixel art kind of a deal, and it's hard to see things in 3D, make sure you have all your connections,

Wojciech Wegrzynski 12:24

It's old school.

Bryan Klein 12:25

yeah, it's very old school. And, and so, you know, a lot of people are like, "Can you make a CONTAM that looks like Pathfinder or like PyroSim?" You know, nice 3D UI with visual nice filters and, you know, help me see the model, not just kind of think through it in terms of 2D sketches and layers. and so that, that came out of, you know, quite a few years. Five-- I'd almost say like 10 years of people cornering us at conferences saying like, "Can you please do something about CONTAM?" And so there's definitely a need for tools that are, I, I think at a less spatially, temporally resolved model that can get the job done fast and, and are used all the time. In fact, somebody told me once, "We use CONTAM for every project. use PyroSim for many projects, and we use Pathfinder on a few projects. Like there's this, you know, kind of scale of like need and, utility and frequency of use. And so, we wanna make sure that we, we provide tools and, that can address those needs. And we're even looking at like, can we throw pre-process stuff into the pre-processor to help people use basically hand calculations? Like a fire is this big, what's the flux to that thing over there? And just give you like a flux to target calculation, right? Before you even run a simulation, just simple tools to check your answers and get scaling values out of things. So anyway, I, I think there's place for all of this and as a developer of kind of both ends of the spectrum, you know, a tool, tool developer at both ends, you know, we, we get a lot of demand for both and a lot of interest, especially in markets that aren't really traditionally using Contam even, you know. Like in the UK, they, they didn't really use Contam very much over there, and now they're starting to go, "Oh, this is better than my spreadsheets. I, I think this would be useful." You know, I c- these different connections coming together and giving me a more complete picture of what's going on in the pressurization system. So, um,

Wojciech Wegrzynski 14:09

Yeah.

Bryan Klein 14:09

the hope there.

Wojciech Wegrzynski 14:10

Off-topic question, when I'm getting my interface to ZoneModel?

Bryan Klein 14:14

Well, now we have to pick. Do we s- do we put it in PyroSim? Do we put it in Ventus, or

Wojciech Wegrzynski 14:19

Okay. Yeah,

Bryan Klein 14:19

make a new thing? Like,

Wojciech Wegrzynski 14:21

yeah.

Bryan Klein 14:21

definitely on our list of,

Wojciech Wegrzynski 14:23

I know it's on your list for like a decade.

Bryan Klein 14:26

And that, you know, it's-- Ventus is actually

Wojciech Wegrzynski 14:28

yeah.

Bryan Klein 14:29

in

Wojciech Wegrzynski 14:29

I

Bryan Klein 14:30

to

Wojciech Wegrzynski 14:30

know.

Bryan Klein 14:31

than PyroSim. You know,

Wojciech Wegrzynski 14:32

Yeah. Yeah,

Bryan Klein 14:33

it's got all the connections, it's got a lot of the same, characteristics. So we'll see where that ends up.

Wojciech Wegrzynski 14:38

back to substantiating, uh, models. Um, I also feel, you know, that in the modern world as a consultant today, for me, it's not like I have to provide my client, A reason for using CFD. It's, it's more like I would have to provide substantial reason to not use CFD, you know, to get away with a simpler model. And, uh, I wonder if this kind of document can... Is this meant for engineers to choose? Is this meant for authorities to understand why people chose the models? Or is it something, something that I could credibly use to convince my stakeholders that actually the stuff that I'm using is the, the right stuff?

Craig Hofmeister 15:21

Yeah. I mean, I think yes to all of those actually. I mean, at its core, it's just making sure that You are using the model that's appropriate for the problem. But you can also, like you said, I think a lot of HJ's sometimes want to be able to see it. And so when you want to see it, you're pretty much into CFD, FDS, or something that's gonna allow the en-- the HDA to be able to, you know, view it and have some understanding or at least visual understanding of what you're modeling. When you're trying to do that with a, with correlations or with a zone model, that's a lot more difficult. And so I think this document will allow you to say, "Yes, look, we went through a process, and we can justify that the zone model is, is

Wojciech Wegrzynski 16:00

Yeah,

Craig Hofmeister 16:01

We don't always have to use CFD, but there's a lot of times when we need to use CFD.

Wojciech Wegrzynski 16:05

that's a nice way to put it that, uh, they want to see it. I, I guess this is, a lot of the technical trouble. Anyway, let's perhaps, uh, move into the contents. Uh, one more question because, uh, it has been published in 2011. Now there's y- you're working on a revision of the document, uh, outside of technological advancement in the world of modeling. Any other, uh, special reasons why this is, uh, reworked or it's just a refreshment of already good, uh, piece of, uh, of, of reference document?

Craig Hofmeister 16:38

I mean, I think it's a, it's a refreshment, although we did start at the core. I mean, we went through in the beginning and said, "Do we need to change the format? Do we need to change how it's organized? What do

Wojciech Wegrzynski 16:48

so perhaps

Craig Hofmeister 16:48

add? What do we need to streamline?"

Wojciech Wegrzynski 16:50

uh,

Craig Hofmeister 16:54

you know, people wanted to see more examples. They wanted to see

Wojciech Wegrzynski 16:57

introduce the

Craig Hofmeister 17:01

to go through. So we tried to address that. I mean, we added examples within the document, and then we added an annex that has an example of going through the process. So it needed refreshed after time, and there has been a lot of advancements in modeling. There was new information in areas like, know, verification and validation. So we need to make sure the document was up to date with that information as well.

Start With Questions Not CAD

Wojciech Wegrzynski 17:23

listeners to The framework. So where does it start, Because I assume the core question that a person is answering through the framework provided by this guideline is that they are having some sort of engineering problem, issue, question, design choice to be done, and this pathway should tell them which model is best fit for this problem. So broadly speaking, how does the, the, the way to this answer look like?

Craig Hofmeister 18:00

I'll take a jump at it first, Brian, and you can chime in. But,

Bryan Klein 18:02

Yep.

Craig Hofmeister 18:03

I mean, I mean, we call it defining the problem as a chapter, the-- one of the first chapters in the book or in the guide, and that's, know, what are you trying to

Wojciech Wegrzynski 18:10

Yeah.

Craig Hofmeister 18:14

a hot upper layer. Is it a fire plume, a smoke plume? What are, what are we trying to address? And at the end of the day, is it something like atrium smoke control? Is it heat transfer from one object to another? What are we trying to address? And then from there, we can define, you know, what kind of physics do we need to look at? What kind of quantities or key physics do we need to look at to address that problem?

Bryan Klein 18:35

Yeah, and I like the, I like in the beginning of that chapter, and that's something I kind of lean into when I'm teaching this is, you know, what questions the model is being asked to answer. That if you start with a set of questions and what answers you're expecting, what falls out of that is everything Craig was just saying. It's to answer that question, what physics need to be resolved? What quantity? What inputs do you need? What, you know, all of it kind of falls out of, of the questions and, and that's a good place to start with a lot of modeling work, 'cause I see that happen in many times in the kind of support cases we get is people are like, they have a CAD file, and so they start with the CAD. And that's a hard place to start because sometimes you only need a room or a couple of rooms of the building. You don't need the whole entire warehouse to

Wojciech Wegrzynski 19:17

Or, just the height of it.

Bryan Klein 19:19

Right. so if you start with the questions, then, then you can pick, well, what do I need to answer the

Wojciech Wegrzynski 19:24

Ca-

Bryan Klein 19:24

And then that just

Wojciech Wegrzynski 19:25

ca--

Bryan Klein 19:25

helps

Wojciech Wegrzynski 19:26

Gi- gi- given that you are teaching this on, on, on various, uh, courses, uh, I seen you run one in Singapore just a few weeks ago, w- w- what kind of questions do engineers bring into the problem? Is it like kind of a question like what's the maximum temperature for this space? Uh, like, can, can you drop some ideas on, on what the questions could be?

Bryan Klein 19:47

Yeah, sure. I mean, you typically get something related to device activations. You know, when do the sprinklers activate? When would the heat detectors activate? You get t- something about maybe tenability paths, egress paths, tenability questions. You know, can, can we re- maintain tenability for 30 minutes in this, whatever the problem might be. Um, it's, uh, time to flashovers. Sometimes it's not as usually as, as common. Um, there might be suppression related things. You know, what's the influence of sprinklers on visibility, with somebody's... Can we maintain visibility for a certain amount of time or in this space? so as you're framing it, you're thinking like, you know, can design do X? And so the-- and the X might be a many different, criteria or phenomena that might be interesting for, for that space. And again, then, you know, if, if it's about sprinkler activation, for example, in a certain part of the warehouse, you know, how many square meters of the warehouse do you need answer the, uh, the fire under a sprinkler? Or, you know, like, do you need the whole building to look at atrium filling, or do you just need like the atrium space and some bounding walls? So, yeah. And, and I'll, I'll just see that all the time. People come in, and then they start meshing a whole entire warehouse just to answer, you know, a detector activation question, which you can do that in, in CFAST usually. You know, if it's, especially if it's kind of rectangular space or,

Wojciech Wegrzynski 21:04

details.

Bryan Klein 21:05

and detect, right? Right. So I think that's the approach here. Start with your questions, and then from the questions, figure out what model can address those. You know, what, what's the real problem here, and how do you move forward?

Wojciech Wegrzynski 21:15

Okay, nailed the question. what's further? I see in the book subchapters on the domain, time, event, material. Like, how does that influence your, um, y-your choice? The, the quality of your inputs are a driver in here?

Bryan Klein 21:32

I mean, you could do the availability of your inputs could be a driver. You know, do you know the, do you know the information? Do you have that from the project? and the, the, I think the other part of it here is with the question then defines key physics like, like Craig mentioned, key physics and phenomena. then you can go from there to like, what are your objectives? Like, which was really again, the questions. And then, maybe you got structural stuff. Maybe you're doing load-bearing structure and looking at, insult to those or insulative capabilities. You know, all, all of that comes together and then can drive forward. Does this model represent-- does this tool have capability to represent those key physics and phenomena accurately? What level of accuracy can you expect from that? So...

Craig Hofmeister 22:16

you know, there's things that maybe shouldn't impact it but do, or maybe they should impact it. I mean, it's You're trying to model a three million square foot, factory. Uh, you know, can you do a grid resolution of six inches? Probably not. I mean, that's gonna be a very tough, tough problem to solve. So as Brian said, you need to kind of break it down, um, decide what you need to actually model to get the information that you need. things like what's the temperature inside versus outside? How does that, how does that impact, the phenomena going on or the model or how may it impact the model? What are the obstructions? You know, any number of things that aren't even basic physics or what the problem is, but you need to consider it when you're putting together the overall

Wojciech Wegrzynski 22:55

I like that, uh, within this part of the book, you also have documentation brought up already requesting-- This is a short chapter, but I think it's important one, uh, requesting that, those things are well-defined. How important is that from your perspective, uh, as an engineer?

Craig Hofmeister 23:12

I mean, I think very important. I mean, you could say that it's right or say that it's wrong, but unless you're able to provide the documentation to prove it. So if you notice in the book, we made a very conscious decision about we have a chapter on documentation, but then within each other chapter leading up to that, we have information on documentation and what-- how that feeds into the overall. the end of the day, how do you document that you're using a model appropriately?

How To Select Candidate Models

Wojciech Wegrzynski 23:36

The next part, uh, so we have the problem definition, we have the question that one is, trying to answer with their modeling. Um, this-- the next chapter in the book is selecting a candidate model. So that looks like a, a key step in all of that or the main step in all of that. So, um, how does one approach that and, and, uh, what do you feel is the process in here?

Bryan Klein 23:58

Yeah, I mean, I, I think it tends to reflect back on the previous chapter that you begin with the physics phenomenon, and then you start looking at, the capabilities of the various tools that are available and if they can represent those physics and phenomena to a level of-- satisfactory level of acc-accuracy. and just by starting again with, I can pick any of them, how do I justify the use of it, of one of them or more-- one or more of those? the, the whole process of the selection is really a comparison to like, well, what are the n-- are the outputs compatible with the answers that I need from the model? Can I get detector activation time? can I get visibility as an output or something, um, is that possible? is there any, any verification or validation? Uh, that's a little bit later, but like, uh, really it's more about can I get the level of accuracy? Does it have the necessary inputs? Does it have the necessary outputs? And going through each of the, each of the different model types, I guess, and evaluating those against those criteria. And there's, there's kind of a breakdown of four criteria in this section of how you evaluate it, which, which I think is nice. Um, there's a nice summary in section 4.2 currently. But it, it's like, does it have either the right, uh, the required output, sufficient resources of it are available? And that's even a consideration that's kind of outside of the modeling capability. But do you have the expertise on hand? who's really good at that, are they on vacation during the project or not? You know, do you have, do you have the timeline? Do you have-- Is there a deadline that you just can't run a two-month study within three weeks or whatever, you know? and then the inputs are available, that those are p- that you have the data for the inputs. And then, like, can you get the right level of accuracy, spatial, temporal, whatever you're looking for? So I think that's a nice starting point for how you start thinking through picking, selecting a model for this use case.

Wojciech Wegrzynski 25:50

But you're not giving a list of models. Like, it-- there's literally a point where you're, you're expecting of, of the user to create a list of models, but, there's no explicit list of model. You think it's the responsibility of the, of the user to get through that list? I mean, uh, if-- it's perhaps difficult for a user to understand everything that's available, though you could argue if they don't know about a particular model, they certainly do not have expertise to use it, so.

Craig Hofmeister 26:16

Right. mean, I think we tried hard not to, you know, tailor to any specific models or anything like that. That's why we keep it in categories, whether it be

Bryan Klein 26:24

Yeah,

Craig Hofmeister 26:28

I think most of the people who are gonna use this guide actually probably, if you went into the process, you probably have an idea of what model you would like to use before you even start. And so your first selected candidate model may be the model you're thinking of ahead of time, and then this just provides a way to justify that choice or not. It, it may not work at all, and you may need to look at other models. I'll give an example of y- you know, several years ago, I was doing a project that involved modeling of solid rocket motors for spacecraft. I had no idea if there was ever a model in existence that could even come close to handling that. Number one, the size of the space, number two, the fuel that was involved and the amount of heat and, uh, release rate that it was gonna put out. So, you know, we kinda went in. This, this guide didn't exist at the time, but we kinda went in and said, "Well, I guess it's gonna be FDS. It's gotta be a CFD model, right?" And I wish we did have some sort of way to kind of break it down and think about it. At the end of the day, we ended up working with Kevin McGrattan and the model to do what we needed it to do. But it was still something that, you know, a CFD model may not have done it. A zone model may have done it just as well or maybe even better in some ways, and w- this kind of document would give you an idea of how to break that down and make that decision.

Wojciech Wegrzynski 27:39

So you'd say that, uh, for, for this particular, task o-o-of the engineer to choose the model, they should pretty much have, a range of, of models they feel could perhaps answer the question, And, then evaluate them versus those four criteria. does the model provide you the output that you need? The ones that you've listed, but I-I'll, I'll reread them because they're-- that, that's a good framework. The model provides the required output, sufficient resources are available, required model inputs are available, and, uh, acceptable acc-accuracy can be obtained. So based on that, you give them a score, explicit, implicit, wha-wha-whatever, uh, you know, and, and, and based on that, you pick up-- pick one of them. Is that correct?

Bryan Klein 28:26

there is actually a secondary, um, after those four criteria, which are your primary. There's also a secondary selection, to choose the best, and that is, it could-- You, you are supposed to go to your stakeholders, you know, and not just you, but you also go to the stakeholders and, maybe sensitive to project costs, or it might be a schedule issue, or might be a preference by the AHJ, or it might be some other... You know, even though tool is the best for the job in your opinion, there may be some other constraints or requirements from the stakeholders that might drive a different choice Choice. And so it's, it's again, the best from the set, might have other requirements that aren't just technical capabilities of the tool itself.

Wojciech Wegrzynski 29:06

I'm right in the middle of such a process where, uh, we are designing a bunch of road tunnels with longitudinal ventilation, and in the contractual documents, there is a requirement that we run CFD modeling, but for, the sanitary mode ventilation in the tunnel, which basically means I have to build the model of transport for the tunnel and calculate the emissions of the vehicles. And then by the power of CFD, prove that if I inject one gram of n-nitric ox-oxide into a hundred kilograms of air, at the end of the tunnel, I get exactly one gram of nitric oxide flowing outside of my tunnel, you know? And, uh, I really do not need CFD to prove that, conservation of mass is universally valid also in tunnels, you know? And they-- Like, it's, it's ridiculous that I have to go through that process because there's almost zero, you know, spatial variability in, in those in longitudinal ventilated tunnel. Yet it's part of the contractual documents, and here we are, you know? Uh,

Bryan Klein 30:11

a really interesting shortcut on that specific project, which I saw at our last FEMTC, where they used the stations or, like, the primary area around the fire and everything was done in full 3D

Wojciech Wegrzynski 30:24

Yeah.

Bryan Klein 30:25

FDS. And then they connected the long lengths of the tunnel with the HVAC system representing, like, large orifice, large, large tubes essentially connecting one end of the tunnel to the other. So they didn't need to do, know, a, a kilometer long three d- three-dimensional flow sim. So that was kind of an interesting

Wojciech Wegrzynski 30:44

Diego, Prof. Diego was, was doing that in my office, and we even have a paper out of that. So,

Bryan Klein 30:49

there you go. Cool.

Wojciech Wegrzynski 30:52

know that. But for, for, you know, traffic, you have a distribution of vehicles along the tunnel. So it's just, you know, a continuous, uh, uh,

Bryan Klein 30:59

Sources all

Wojciech Wegrzynski 31:00

a continuous source, uh, across your tunnel. But it's, it's kind of the, the problem we're touching here. Like, you know, there is a specific question in, in mind: What is the, concentration of, potentially dangerous gases in my tunnel related to the, um, motion of vehicles? I have a sub-model for that to calculate how much emissions I will have in the tunnel, and I do not do that by CFD. I have to build an, uh, a spreadsheet, basically, a ridiculously complicated spreadsheet that refers me to road association data, uh, emissions by cars, by angle of, of slope, by velocity. Uh, class of the engine, diesel, gasoline, electric, you know. The electrics ones also have emissions because the tires and, brakes are wearing down, so it's not that they magically come to zero. So I already built an, a ridiculously complicated model to, to get the number in grams per second, and actually that's my answer. Here it is. Yeah, i-if it's five grams per second in the tunnel, at the end of the tunnel, it's gonna be just that. There's like no magic in between that's gonna turn this five grams into 100 or one because it, it doesn't really work like that, you know? Okay, there's some dilution, but it's only gonna go down. And, and yet, this stage is insufficient for solution of the problem because it explicitly-- the, the client kind of expects that I run it through three-dimensional CFD modeling, you know? And again, I, I tie back to what you said that you like to think about the problem in a temporal and spatial manner, you know? And here I have a steady state problem in one-dimensional manner. you know, if, if I did it through, through your, way of thinking, let me open that. does the model provide required output, the single dimensional spreadsheet? Yes. It provides me in grams per second. Sufficient resources are available? Absolutely. I have the PR data for vehicles, and I know the architecture of the, of the tunnel, which for my purpose is the slope. Are the required inputs available? Yes, they are. I have the prediction of the traffic in the tunnel. I'm Literally good to go. Uh, what's the fourth one? acceptable accuracy can be obtained. Well, that's a question because if you want, uh, a number, like a lump sum at the end of the tunnel, yes. If you want to know it, like is it the-- what's the concentration at the floor level, at the ceiling, perhaps not, but, it's not gonna make a difference after all. Uh, that, that's a very interesting framework in here.

Bryan Klein 33:35

at the end, which is you're getting caught in a stakeholder requirement, not a

Wojciech Wegrzynski 33:42

Yeah.

Bryan Klein 33:43

requirement that might be a, that might be a constraint to, to use for how you choose what model to use. So that is included in the framework as a kind of a,

Wojciech Wegrzynski 33:52

Other considerations.

Bryan Klein 33:53

as you've gotta account for that. And if somebody-- if it's in the contract, then that's gonna be a driver of the choice you have to make. Yeah. Yeah.

Wojciech Wegrzynski 34:00

Do you often end up like this in your consultancy work, uh, Craig?

Craig Hofmeister 34:03

Yeah. Yeah. Yeah, for sure.

Wojciech Wegrzynski 34:05

more often than you would like, right?

Craig Hofmeister 34:07

Yeah, probably so. I-- It actually makes me think at, just as an anecdote, makes me laugh. I used to have an older car and,

Wojciech Wegrzynski 34:13

Huh.

Craig Hofmeister 34:13

we have em-emissions standards in the US. Um, it happened to be an old Porsche nine eleven and, um, e-you know, emission standards, and it was based on a concentration, so the engine could not meet the particulate conc-concentration. So they-- what did Porsche do? They put a little air pump on the engine that just pumped air into the exhaust, so they met the concentration requirement. The engine still puts out all the same particulate and emissions that it did before. I like to think of that as both silly and genius at the same time. I mean, and sometimes we run into that in modeling, for sure.

Verification Versus Validation

Wojciech Wegrzynski 34:44

Absolutely. a pristine piece of German engineering. Okay. Let, let, let's move forward. so we have answered those questions. Uh, we have a candidate model in mind that meets our requirements, whether it be technical requirements, client requirements, a combination of both. Now, I think a quite important step that, uh, actually I don't see that much in, engineering work, which is the V&V, valid- verification and validation. Uh, how do you approach that? Fir- perhaps first let's discuss the difference between what's a verification, what's a validation. Brian, you're teaching that. You must have a nice, uh, you know, slides about that.

Bryan Klein 35:23

I mean, it's always like check the math, check the physics, uh, check reality. You know, those are the two. So, you know, that the, that the numerical method that's l-- for FDS, for example, it's in the, in the technical reference. They have a nice, you know, algebraic expression that describes some kind of a function to make sure that, if you plug all the right numbers in, you get the right number out, and that each of the functions or features of the tool kinda meet their analytical, you know, objective for, for what they're supposed to produce. all the right answers from the math doesn't mean it's reflecting reality. so you do also then need to check it against some test of, of reality to, to make sure that it's, uh, able to predict that. And that's where you start testing predictions against measured, experimental work, typically. Um, it can do some analytical, but it's almost always experimentally compared because that's the best data that we have available for a particular phenomena that we might be interested in. So, um, that's the way I usually break it down. Check the math, check the physics, or check reality, and then, uh, make sure that we get-- uh, that it covers both bases. verification is easier because when people are writing software or whatever, they do unit tests or they do some kind of a test to make sure that what they've coded has the right outputs. But, I'm surprised around the world there's a lot of tools and very few check against reality. Many make claims that they can do things, but they don't have the validation side well documented, at least not to of a same level of standard of like FDS and CFAST. Like they really are, I think, kind of a, a golden, you know, the, the gold standard, so to speak, for like verification and validation of your tool. And so what I, I would like to see, and that will make this part of the process much easier if there is really good documentation for all of the tools for their verification and validation. I think it makes the model user, uh, have an easier task at this point in the process

Wojciech Wegrzynski 37:25

Craig, do you think a user can actually do the proper verification of a complex model on their own? Or is it really just the trust on the software package they've purchased or obtained at some point? Because I-- like, you know, I can follow a model for critical velocity in a tunnel and, you know, cross-check it. I can follow a plume calculation and cross-check it. But when I have, you know, a 10 million cell, you know, CFD I feel like I'm-- I potentially could try and do that, but I feel it's kind of outside of my competency to do the proper verification whether it calculates right. So I'm kind of, you know, forced to believe whatever the manufacturer tells me here.

Craig Hofmeister 38:14

Yeah, I mean, I would, I would agree with that. I think we did try to address that a little bit in the, in the guide. I mean, obviously, uh, we had Kevin McGrattan that was heavily involved in this regardless, but involved in this chapter specifically and the original guide as well. And trying to break it down a little bit in terms of what's V&V of the model development itself and what's V&V for what the user use. he talks about things like, you know, normalized parameters and things, you know, Fired Fruit Number and flame, flame length ratio and those kind of things. So as a user, we might be able to focus on that and say, All right, well, if I look at a flame length ratio as an example, if I have a typical couch burning in a, in an atrium, sure, I think we're, we're in the range that we're talking about and has been addressed in the, like, FDS, validation guide." but then if I'm looking at a, again, back to the solid rocket motor, that may be completely outside the bounds of what was considered in this. So then what do I do? what work do I need to do as a user then to try to figure out whether I can still use this model or maybe I can't use this model and is there a model that I can use or how do I basically at the end of the day get the best engineering judgment I can if there is no model? Let me go back and like I said, in that case, we did go to the model developer and sat down and tried to go through it a little bit.

Wojciech Wegrzynski 39:27

if you as a user are running the V&V process against known experiments, known scenarios, it, it's possible to do that. Like, as Brian mentioned, uh, FDS has the golden standard V&V guide with like six hundred pages of, of those examples, and they're actually all there in FDS, uh, that you can look into and just run them, uh, on your computer. I've actually did an ASMR reading of one of them, which was ridiculous. anyway, uh, If an user is, for example, placing this one megawatt fire in their room to see what are the ceiling temperatures of that or what's the ceiling jet that they get out of that, is this a part of the user building their trust towards the tool and their competency to run the models, or this is a part of a specific project for which they're using the mo- the model? Because I feel it would be more like a general, you know, kind of building your own white paper on, "Yes, I can use this model, and here is the reason why I trust it," rather than, "Yes, for this particular shopping mall, we've run 20 cases of, of this model to show that it gives me the same exact outcome as always."

Bryan Klein 40:41

Yeah. One of the things I like to mention about the FDS's take on validation specifically is they break it down by phenomena of interest

Wojciech Wegrzynski 40:50

Mm-hmm.

Bryan Klein 40:50

and that's a nice way to assemble, assemble this set of phenomena based on what you're expecting, what you need to resolve, and then be able to look at how well FDS predicts that kind of fire behavior dynamic, and then have a sense of some level of confidence and understanding, like, how does FDS tend to predict this? Does it tend to over-predict that particular phenomena in general? Does it tend to under-predict it? and then it also, I think something that's unusual when I compare to a lot of other tools and what they report on is that it gives you a really nice matrix or I guess just a, a table of these n-non-denomina-- uh, non-dimensional, I should say, uh, parameters, and so that you can get a sense of the scope and scale of the validation suite and where your particular project might fall into that scope. But also, um, a nice table of of the different phenomena and just their bias, their model bias, and their uncertainty and things, you know. So, as a quick reference, you know, you can just look that up, kind of look at your original problem statement, look at the key phenomena and physics, go to the v-ver-validation and say, "Where does my problem fit into here? Am I within scope?" And you can kind of come away from that either with more confidence that it's within scope and FDS does a good job of demonstrating it can do those things, or I'm outside of scope and I need to do more work or figure out maybe another s- another tool or another, another way to solve this problem. So, um, those kind of quick references I think can be helpful, um, and those are available and, and it is broken down a bit in this, in this part of the guidelines of like how do you look at some of these like non, uh, dimensional values or, scaling parameters that you can use to figure out, know, where, where you might fall in there. Um, and then there's also accounting for model uncertainty and user uncertainty, which is kind of a whole other part of this

Wojciech Wegrzynski 42:36

Yeah, well, we will just, just get to that. I'll just gonna-- I'm just gonna ask one more question from this chapter, which is the accreditation. Uh, you mentioned that sometimes the models will require some sort of, um, accreditation. Uh, I wonder whether this is an, uh, kind of an accreditation or certification scheme for the model user or both. And if you can give me some examples of, of such schemes. I, I probably know only the nuclear regulatory body that, that kind of, you know, provides you an explicit list of models that you can use. I, I'm not sure if I, I know another one like that.

Bryan Klein 43:11

I'm not aware of any sort of globally or internationally or even locally recognized accreditation body who says, "Yes, this tool is good for this problem, and you can use it for that or anything," or that it's like it has our stamp of approval on some kind of a, you know, um, meeting some ISO standard or something like that. so I think it is definitely a user issue. Um, but as you mentioned, like DOE or DOJ or maybe one of these, you know, a government agency somewhere might have like, need to at least go through our IT or review competency process so that we can say, yes, it's adequate or acceptable to be used in our application space." but I think that's organization specific. There's no sort of third-party universal accreditation process I know of. of the tools or the users. Like there's no, "I'm a certified FDS user." You can't get that stamp anywhere, right? You can get training. You can more or less confidence in your skills and how much people wanna pay you to do those things if they believe that you have those skills or not. But there's no like, this class and now I'm-- I can do any modeling project." It's, it's really case by case, I think,

Wojciech Wegrzynski 44:19

do, do you get karma on the discussion group? I, I don't think you get karma points. Like

Bryan Klein 44:24

um, zero.

Wojciech Wegrzynski 44:24

you, if you, if you were getting karma points on, on, on the discussion group, on the FDS group, and you just gathered like a thousand of them, you get, you know, like a golden FDS button you can put behind you. That, that would work.

Bryan Klein 44:36

That'd

Wojciech Wegrzynski 44:41

did with Stack Overflow, before chatbots ate it, right? Uh, they would, uh, showcase like their,

Bryan Klein 44:46

Yeah.

Uncertainty User Effects And Sensitivity

Wojciech Wegrzynski 44:47

know, score on answering difficult questions, uh, to people, uh, in their, uh, recruitment process. Um, again, I see documentation, uh, which I guess is another important step. Like every, every single step in this guide has, has a documentation part, which I appreciate. Now, uh, chapter six, evaluation of the model uncertainties and, user effects. Again, a difficult one to be able to actually quantify the uncertainty because there's uncertainty in your input, in your calculation itself, in the problem definition perhaps, like s-so many sources of... H-how do you approach this? It's a long chapter actually.

Craig Hofmeister 45:27

Yeah. I mean, I think it's just trying to break it down and have the, uh, user of the document think about these things, 'cause sometimes they just barrel right ahead and don't, don't go through any sort of process. So as you said, there's lots of sorta areas of uncertainty, everything from the model itself to the V&V, to what the user impact and what the user is doing themselves. So I think we try to address the beginning parts of that in the previous chapters, and then this eventually is other than really thinking about what the uncertainties are and, and trying to get an idea overall of what that looks like Then also thinking about what the user uncertainty is as well, what the input is. How sure are you of what you are inputting into this model? Because the, the more uncertainty you have in the input, obviously the more uncertainty you're gonna have in the output, uh, for sure. I mean, I think it's really just trying to make the... or not make, but have the user of the document go through and think about all the different aspects that can result in uncertainty in the model, and then how do you want to address that.

Wojciech Wegrzynski 46:26

Is there any overarching rule that, if you have extremely crude input, you should not use a detailed output model, or you're allowing users to do that, or it's something the user should decide on themselves?

Craig Hofmeister 46:39

I mean, I think it's basically on the user themselves. I mean, having been a reviewer for a large company, I used to get very aggravated when someone would say the temperature is like eighty-one point two degrees Fahrenheit. Like, no, it is not. You're not anywhere in the ballpark of thinking that's what it is. So you need to go, like, actually go through and think about that.

Bryan Klein 46:57

Yeah, and there, there are some, techniques described in this section about, different methods of analysis and modeling work to help address areas of uncertainty. There's, like, bounding analysis and parametric analysis and a few different options to help you say you know, how well do I know the impact of these uncertainties on the results, on the important, you know, critical results or critical phenomena that I'm modeling? and then get a sense from that, like, okay, well, I went, you know, let's say plus or minus 10% on this value I can see how that impacts my critical, you know, phenomena, my detector activation time. Maybe it has a significant impact, maybe it doesn't, and we can look at those changes. There's some nice, processes described here on how you could start to address dealing with your uncertainty and then, and then documenting that. so I, I appreciate that part of this. It's not just throwing you to the wolves saying like, "Yeah, things are uncertain. Good luck." It's like, "Here's some ways you could start to work through this problem and get a grip on your, your level of confidence in, in your choice."

Wojciech Wegrzynski 47:57

H-how about sensitivity analysis? Are they expected that the user runs them, or again, this is something that user shall decide for themself?

Craig Hofmeister 48:04

I mean, I think it's one of the approaches that's outlined. and if you chose, choose to go that route, I mean, that's one that I've seen more often than, than some of the others. But again, we didn't wanna limit it to just one, type of review. and then once you go through whatever it is, whether it be sensitivity or differential or whatever kind of, uh, analysis. I mean, we do talk about like things like grid sensitivity in particular because could be a large Uh, area or, or impact for uncertainty depending on what model you're using. then it goes through and, like, how do you deal with that? how are you looking at-- How do you account for that uncertainty? Whether that be, you know, conservative assumptions or which can sometimes be too conservative. how else, you know, safety factors or what-- how are you gonna address... Once you've established or have an idea of what you think the general level of uncertainty is, then how do you address that to have confidence in your results?

Wojciech Wegrzynski 48:54

is there a direct link between complexity of a model and uncertainty? Like, does a simple model have to be more certain than a CFD model always or h-h-h-how do you evaluate that?

Bryan Klein 49:07

you, you would certainly have fewer variables, fewer inputs and outputs to have to account for in the analysis if you have a simple-- You know, an algebraic might have two input variables and one, one resultant variable, whereas CFD might have hundreds on both ends, right? So, So I think complexity just sort of breeds like, an increased requirement for, Accounting for more level-- many more potential areas of uncertainty. and again, that might be a time savings issue too. But

Wojciech Wegrzynski 49:38

Mm-hmm.

Bryan Klein 49:38

I, I wanted to mention at this point is because, uh, this came up in my talk in Singapore about this. Somebody asked at the end in the Q and-- Q&A, they asked, um, How do people deal with this gap? Like, they start looking at this and they're like, "I'm not doing all of this. Like, I have to do this for every job? I have to

Wojciech Wegrzynski 49:55

Yeah, that's, that, that's a big concern, yeah.

Bryan Klein 49:57

like, overwhelming," you know? And, my response to that, and I think the intent of this guide is that this is an accumulating value that as you go through this process for one problem, you've done it for that kind of problem, and you can rely on that the next time that kind of problem comes up. You don't have to do it all again every time. Maybe only handle the significant differences between the last time you did it and the next time. But that this becomes kind of a library or a compendium of, like, I have gone through this process before, and I have more confidence in, like, this is the tool I should use. You don't have to go back and do it for every project. It's more like based on the questions and the, and the critical physics and things. So,

Wojciech Wegrzynski 50:35

Yeah,

Bryan Klein 50:35

um, yeah, it's,

Wojciech Wegrzynski 50:36

y- th-

Bryan Klein 50:36

to know that. Don't get overwhelmed by the, by the process because it, it, can build on itself. Yeah.

Wojciech Wegrzynski 50:41

that's what I meant saying you're building your own white paper, which is basically not the model, not the assumptions, it's you. It's you using the model for specific assumptions and how you handle the task. And if you build it up for yourself, it gives you b- greater confidence, uh, in, in your own modeling, and perhaps could be useful one day when you have to convince someone that, uh, a, a different approach is used and you have a, a good track to show them, like what's possible, what's not possible.

Bryan Klein 51:09

And, and even as organizational or institutional knowledge and, and, like, support within your company or your, your group. So you can, you can hand this off to somebody else and say, "Here's what I did. What do you think?" And they could, like, maybe expose some areas to do better work on or be able to go, "Yeah, that seems reasonable," and you can move on more quickly from there.

Craig Hofmeister 51:28

I think what you mentioned earlier, you gain confidence in a model for the application or the problem that you're using it for. And so then that helps you understand when you're outside of that confidence and that you may need to go back and look a little bit further.

Wojciech Wegrzynski 51:42

In this consideration, the potential for human error, is it a factor? Because, you know, when I, have a simple plume model, there are three variables I fill in, and that's not a huge space to make a mistake. If I'm running, you know, extremely complicated CFD modeling case, the space for making a mistake is tremendous. is this a factor to be considered as well?

Craig Hofmeister 52:05

I think it should be. Um, hopefully something like that may come out in, you know, a sensitivity analysis or a bounding analysis or something where results don't necessarily make sense compared to other results that you're looking at. So you may wanna go back and look a little further. Um, but it, it certainly is, as you mentioned, like when you have simple models, uncertainty of the user is, fairly small if you only have a few input, inputs. The uncertainty of the model itself may be a little larger when you're-- depending on the output you're trying to get. Um, if you're using a more complex model, you're getting much more uncertainty in the user, uh, as you have a lot of inputs, a lot of parameters, a lot of variables. not necessarily saying the uncertainty of the model itself goes down, but it's just something that increases the uncertainty of the user itself. but yeah, like to your original question, I think hopefully when you're going through the, the process of, defining what that is and looking at the, the bounding or the sensitivity or whatever you're looking at for the uncertainty and the final results, that you would pick that up in terms of things don't make sense. Some of the, the answers that you're getting aren't making sense.

Appendices Phenomena Lists And Worked Example

Wojciech Wegrzynski 53:08

You know, every, every time we start this podcast episodes, I start with the thought like, uh, can we really talk about this for an hour? And now I see we're almost ending, and we've yet to reach the final parts of the, of the document. The last chapter is documentation, which, the need of, of documentation we have already covered. Unless there is some specific thought that you will-- you think you have to co-cover, uh, I, I can give you space to do so. But I would love to jump to appendixes, which are, doing like you said, uh, in the FDS, uh, guideline, uh, Brian, uh, phenomenon by phenomenon, like this understanding of what different types of, of models can give you. And the second one, a worked example. M-maybe, Brian, you can try and guide me through what the user can find in, in, in appendixes because I think they are very useful part of the document.

Bryan Klein 53:57

And, and just on the, the last section about documentation of the substantiation, it, it really does just kind create an outline and a restructuring of all of the sections, and that was very intentional. Originally Finally, documentation was kind of at the end. Like we, we went through this process, and we didn't really talk about what you were needed to... Like, what was the output of the n- of that step to give to the next step? And like, and then at the end, how do you put it all together? So I think this is a much more holistic way to kind of think through the whole process, and then as you go through it, you're compiling this information resource that then you can organize and put it all together. And it gives a really nice outline in the document of like all the information from each section and just to re-remind you as a user how to, how to put it all together. So, um, yeah. So as we get into really the, the appendix, you know, like appendix A is kind of a breakdown of a whole bunch of phenomena, physics, key physics, things to think about. we really tried not to be too model-specific. I, I mean, it's category-specific but not particular model-specific. and, and that was intentional. and, and part of that is, I mean, yes, some of these tools have been around for a long time, and everybody's pretty familiar with them, but tomorrow could be a new one, and we still want this in t- in five years from now. Before the next third edition is created, there could be something new out there that everybody's using, and the, the approach should still be valid for any tool within these categories. So, what we don't have in here is an AI super mind that you just ask it, you know, "Is this okay or not?" And it tells you, "Yes." And then you're like, "Okay, cool. Build a building." Right? So we don't, we don't have that in this process. But, in, in terms of the tools p-people will probably be using for a while, um, that. So really, the more interesting one, I think, um, is appendix B, where we go through an example. And so this is kind of the application of the process where we, um, start with a problem statement and some requirements, some, some constraints on the project, and then give kind of a-- I wouldn't say it's a typical case, but it's common enough in fire engineering. You have an atrium and some stairwells and different levels of a building and, you know, it's, it's kind of a complex setup. And then, then a few i- problems. So as we mentioned at the beginning, defining the problem here, here are these statements, these questions. Like we have to determine the fan flow rate and size and location for exhaust outlets and make up air. So these are very common, sort of,

Wojciech Wegrzynski 56:17

Design questions, yeah.

Bryan Klein 56:18

right? And then turn that into what are the key quantities, and it really breaks it down nicely. We just think through the process and in this example, giving you like suggestions, that it should be able to account for these things, right? And this isn't comprehensive by any means, but it's like a really nice, you know, work through of the process to give somebody an example of how, how this could be applied to a very common, um, problem statement or problem set. Yeah. I think it's a, I think it's a very nice, uh, way to do it. There's even some examples of like tables, like how you might put your information together. For example, candidate model selection in, in this section here, it's what are a few different models. There's like hand calcs, CFAST, and FDS, what type they are, the four criterion for selection, and then like a little grid of does it pass or not in this particular criteria for this, for these problems. And can start to see, oh, I could, I could use a table like that to start organizing my, my information as well. So it, it's also sort of an example or a template for a report, you know, for, for the kind of output that you might have from this process. So,

Wojciech Wegrzynski 57:22

Brilliant.

Craig Hofmeister 57:23

I mean, I think going into the, uh, the example, we thought it was gonna be simple and it would be a, a real easy exercise to go through, and it ended up being fairly difficult. In fact, the example problem we used is from one of the SFPE performance-based design conferences. it was one of the case

Wojciech Wegrzynski 57:37

looks familiar.

Craig Hofmeister 57:38

studies, and that was referenced, and then people got confused when we referenced it, so we took all that out. Yeah, going through the process is not easy. for us as a committee, we also had to think about we don't wanna give something that people are just gonna use. Like Hey, this is smoke control, always use FDS." So we had to be very careful about, like, focusing on the process, not what the outcome would be. And that's very difficult for engineers to

Bryan Klein 58:01

Yeah. I mean, and we have some historical artifact of people's tendency to do that. I mean, if you might remember the old FDS database from FDS4, was like, "This is NIST standard concrete because it's in the database file, and I'm just gonna use this density." That doesn't mean it's the density of your concrete, you know, that's just a number that was put in there as an example, so they, they pulled it out as a way of, don't, don't just rely on these things. And we've even done that in tools like PyROSim, where, if you-- We, we used to have a-- The, the default end time was like 10 seconds, I think, or something like that. people would start running a model, and then they would... And it might take a week or, know, multiple hours, two days to get to 10 seconds, and then they realized, "Oh, I didn't set the right end time. I needed six hun- I needed 10 minutes, not 10 seconds," and they didn't even think of that input. So we tried to put a few kind of low friction resistance points and like, "Ah, you didn't define a reaction. You've got to think about that problem. Oh, you didn't define your end time. You better think about that," and not just set everything to default values so that somebody just clicks run and gets, um, the wrong answer.

Wojciech Wegrzynski 59:05

this kind of goes back to the user-introduced, uh, you know, error that I mentioned between the easy model and, and the complex one. The complex one just gives you like a whole greater array, you know, to screw up. In, in Ansys, I, I, I really like the solution in Ansys. Like you turn on the model, there's nothing in it. Like you don't even have energy equation yet. You want energy equation, you have to turn it on. You want smoke, you have to create a model for that. You want turbulence, hey, it's laminar by default, you know? And, If you are not completing the conscious choice of sub-models, you just don't have a model that works. On the other hand, uh, I always called the FDS, you know, kind of this connoisseur curated, uh, list of models

Bryan Klein 59:49

Yeah,

Wojciech Wegrzynski 59:49

that just work beautifully in the fire problem. You know, it's like, you know, you, you go through a three-star Michelin course and you don't tell the chef how you want your steak to be done. It, it's them who know, not you. So,

Bryan Klein 1:00:02

like radiation is

Wojciech Wegrzynski 1:00:03

yeah, that, that, that's how I find FDS. They know what you need to solve a fire problem, and if there's a better way, in the next version you're gonna find that one because, uh, they're not gonna intentionally make it worse. They're gonna intentionally make it better through and through explicit V&V they will be sure and have proof that it is or it is not better, right?

Bryan Klein 1:00:24

have to turn it off because typically you need radiation in a fire problem. So

Wojciech Wegrzynski 1:00:30

Yeah.

Bryan Klein 1:00:31

you're right. Like it's, it doesn't default off universally. But, for example, FDS used to have a default reaction of propane.

Craig Hofmeister 1:00:38

Right.

Bryan Klein 1:00:38

you just ran the simulation, you'd get propane. You didn't have to define a reaction. You could just define a fuel, and you would get

Wojciech Wegrzynski 1:00:44

it...

Bryan Klein 1:00:45

And, and now it doesn't do that. You have

Craig Hofmeister 1:00:47

people

Bryan Klein 1:00:47

to

Publishing Status And Final Thoughts

Wojciech Wegrzynski 1:00:48

we, we could use a few more angles in the discrete ordnance model in FDS, but yeah, it's, it's turned on, on, on the default. Well, gentlemen, uh, I thank you very much for, covering this important piece of SFP resources. I think the new one is somewhere between, uh, the public comments and being published, so hopefully it will be out there, uh, in near future. Uh, doesn't, uh, change the fact that the, the framework, uh, exists and it's known. Uh, Craig, you have papers on that. Brian, you're teaching that. If someone wants to know more, resources, uh, you shall find in the show notes.

Bryan Klein 1:01:28

Mm-hmm. Yeah, that's great. And we've already done the public comment and incorporated all changes into that. It went off to editorial review committee. There were some snags with people on the review board were the same as the authors in a lot of cases, and so they had to get like the right number of people and the right people to look at it. Then I think know, Craig, correct me if I'm wrong, but I think it might be either still at that point or it's gone on to publisher review, which they'll do one more kind of publishing editorial process before it goes to print. Um, I don't think you can get the old version. I don't think you can buy the old version anymore. I, I don't think it's available for sale on the website, so, through SFPE. but, yeah, keep an eye out, I guess. Like, it, it's been a long-- We took a long time to work through this, um, through the committee and a lot of really deliberate effort working through each section and really organizing it. And it's a great group of folks. I mean, we have-- I-- In my talk in Singapore, I had a slide where I just had, three columns of company names of all of the different contributors, and it was-- and organization names, and it's pretty impressive to see how everybody came together contributed all over research and engineering and consultancy and just super good collection of points of view to look at this thing. So, I think it's gonna be super valuable, and I can't wait to-- for it to fall out. I always say it's weird that I'm teaching a class on a book that doesn't exist because like, "Hey, there's more to read. Go to chapter four." There's no chapter four to read. So hopefully we get that out sooner than later, and people can start processing it themselves.

Wojciech Wegrzynski 1:02:59

Yeah,

Craig Hofmeister 1:03:00

that's one of

Wojciech Wegrzynski 1:03:00

r-

Craig Hofmeister 1:03:01

Like, as Brian said, there's a very wide range of backgrounds that were contributing to the committee. And I think one of the big upgrades from the first, uh, roundabout for this committee was, uh, a lot more international presence, and so brought some different perspectives that we may not have thought about from being more North America-focused in the past. and I think that was very, very valuable at the end of the day, just to help think about how others think about these models as well. Um, and then, yeah, as far as I know, the committee work is complete, and the, the document should be Ready, ready to either be in the final stages of publishing or thereabouts very soon.

Wojciech Wegrzynski 1:03:35

Hopes are high that it goes out soon. I think we still provided listeners substantial amount of knowledge on substantiating the FIRE models and, uh, let's call it a day on here. Thank you guy-guys.

Where To Find Drafts And Closing

Bryan Klein 1:03:47

Thanks, Ojok. See you later. And that's it. Thank you for listening. If you are dying to try out the framework and you need more information on the guidance itself, while it's not yet publicly made available, uh, through SFP, there are kind of copies of that, uh, in the public feedback, uh, form, uh, which was shared by the-- by SFP publicly. So if you Google that, I'm pretty sure you can find those, uh, very late drafts of the document which give you perhaps most of what's the content, uh, of the final document gonna be. And I really hope that the, the, the final document will reach the daylight, uh, very soon. And if it does, I will be sure to update the show notes of this episode with a link to where you can obtain your copy. In the meantime, you can try also following Brian. Uh, he's giving courses on that. Perhaps some resources will be made available through the online, uh, teaching of SFP, so another opportunity. And in general, you know, the framework that we have discussed in here is to some extent straightforward and known. Define the problem, select the candidate model, evaluate the model through verification and validation, evaluate the model uncertainties and the user effects, and then document all the process, uh, along the way. That gets you most of the way. And then, um, what, what's really nice in the document, which you don't see right now, but you will see in the future, is that, uh, they kind of break it down by phenomena in, in the appendices. I'll perhaps read out the phenomena. They, they break it down by heat release rate, flame height, ceiling jets, hot gas layers, heat fluxes, non-thermal combustion products, target response to fire, detectors and sprinklers, room pressure, ventilation, visibility, gas dispersion, and explosions. So these are the sets of physical phenomena through which they kind of go through the physics of the problem, the algebraic models that are used, you know, to define the problem in kind of the handbook way, uh, zone and lumped parameter models that exist, and field models like CFD, which can be used for a particular problem at hand. So yeah, this breakdown by phenomena gives a very interesting insight to how you can use a particular model to answer particular question at hand. Because once you define the question at hand, you will be good on your way to pick the right model for your need, and maybe you will not be stuck like me having to prove that, uh, my Toxic product concentrations in tunnels in the CFD are exactly the same as I defined to put them into my CFD. It's really frustrating. Anyway, thank you very much for being here with me in the Fire Science Show today. And if you are looking for more fire science and engineering, it's coming your way next Wednesday. Be there with us. Cheers. Bye.