Way to freeze flame spread similar to freezing time for ramp input? #13234
Comments
|
Bryan -- we're going to implement a way to control spreading fires with more features than just freezing it. But if you look at the test case called |
|
I looked into this issue some more. Anything can be done with spread rates, but it would be more costly than what we do now because if we make |
|
I think Bryan was looking for a solution to do this when you don't know a priori how far it will spread. |
|
Sorry to hijack the thread, but I have some features I would like to see in fires with SPREAD_RATE: You may have thought of all these already. Thanks for reading! |
|
Let me push back a bit here. Currently, the user specifies a constant However, all of the suggestions put forth above will cost more because they require that surface cells be scanned at each time step to determine ignition and various other behaviors. Not a lot of cost, but more than before for a feature that may or may not be widely used. In my opinion, the idea of the "t-squared" fire has been extended far beyond its original intent because of regulatory requirements and general practice. But nevertheless, we implemented what I have described above as a convenience for end users who need to conform to these requirements. But now, much like the layer height concept, this concept is beginning to go beyond what is called for by basic practice or regulatory requirements. I worry that if we add all these new variations, we risk confusing real fire spread behavior with these ad hoc mathematical shapes. Sure, we can make the fire spread like an oval rather than a circle, but where does that end? I would prefer that if fire spread is to be modeled in a more realistic way that there be some rationale for it. For example, we use a more sophisticated spread model for wildland applications, the so-called level set method, but this is based on the actual physics of spread over complex terrain and different fuel types. We are very cautious about making the fire spread in a way that cannot be justified other than as some hypothetical construct. |
|
You are right that I am driven to t-squared growth by regulatory definitions. I do not have a problem with that: we need to distinguish between "slow" and "fast" growth situations, and t-squared growth factors are a shared language that defines growth. (It also has some basis in reality, for a constant spread rate over a circular fire bed.) It does not seem unreasonable to me to want to combine t-squared growth with a later rampdown (for example because the fire is extinguished). Currently I do this by using SPREAD_RATE to define the growth and by creating an OBST on a timer over the fire bed to kill it suddenly, effectively like dropping a drain cover onto a fire bed. This does the job. One route to satisfy the features I mentioned would be a connection between RAMP_Q and facet-by-facet timing. (Currently there is a connection between t-squared growth rate and facet-by-facet timing, or between an arbitrary RAMP_Q and variable Heat Release Rate Per Unit Area. The current implementation of RAMP_Q by using variable HRRPUA is less realistic than anything I have suggested.) |
|
If you make 'RAMP_Q' a step function whose duration is dictated by the fuel load (mass per area), then you have a ring of fire that expands outwards until it reaches the boundary of the |
|
Wtih DEVC and CTRL functions you should be able to script out any desired rate of growth over any arbitrary set of VENT or OBST including decay. For example, for oval spread you could define rings of VENTs each with a different SURF_ID and RAMP_Q. |
|
@mcgratta : I am not completely sure I understand what you're suggesting. If you're suggesting a combination of Here is an example -- I'll put the code at the end of this post. This is intended to give "fast" t-squared growth (as defined in UK regulations), which should reach 1000 kW in 146 seconds. Then a plateau, then sudden extinguishing, ramping down from 100% at t=300s to 0% at t=310s. This is what happens instead: There are several aspects I would like to change about this HRR curve: @drjfloyd -- Yes, I could define rings of VENTS to define ovals. I could even define a different Here's the example code. It runs in a few minutes: |
|
What you are doing is what I suggested, even though it is not exactly what you want. To do what you want would require making this feature far more complicated and prone to error and CPU bloat. I am uncomfortable going to all this effort to replicate a fictitious and unnatural heat release rate curve. If you want to mimic exactly any HRR curve, do not use the spread feature and just ramp up the fire over a given area to exactly match the curve. |
|
"Not exactly what you want" is an understatement -- I specified the fire to die out by t=310s, but it is still at full power at t=320s and it does not die completely until after t=470s. I could argue with your other points as well, but for now I'll be quiet. |
|
You specified a RAMP that stops 310 s after the wall cell ignites. The T in RAMP_Q is time since ignition not overall simulation time. My guess is the last wall cell is igniting at 160 s (160 + 310 = 470). What you are asking for is to have multiple control function inputs governing just the t2 growth vent type plus a bunch of logic to deal with a list of facets and times. This is not as trivial as change as you might think. We implemented the detailed control function logic in part so that user's can implement more complex needs without us having to develop new code, make verificaiton test cases for new code, document new code, and maintain new code in perpetuity. |
|
Discussed this a bit and we think we can make a fairly simple change to how ramps are processed that would move us in the right direction. The key issue is decoupling the "T" in the RAMP from the "TSI" or Time Since Ignition in the ramp that multiplies the mass flux at a wall cell. One thought is to have a logical on the RAMP line that tells FDS whether T is meant to be TIME or TSI. Another option would be to use different parameters (T for TIME and TSI for Time Since Ignition---this is my preference but might not be very backward compatible). If I make this hack in the code with your simple ramp, then I get this for the result (with twice the resolution; getting rid of the initial spike is also resolution dependent, but as you said we can tackle that later). In general, the ramp function can be set to handle different spread rates and vent areas as follows. Suppose we have a vent with area A_VENT and a spread rate S. The circular area of the spread is A_SPREAD = pi*(S*T)^2. If F is the ramp function we would use for a t^2 fire with A_VENT, then the new ramp function is simply, F_NEW(T) = F(T) * A_VENT/MIN(A_VENT,A_SPREAD[T]) Until A_SPREAD>A_VENT, this is just a constant that depends on the spread rate (if S is used for F[T] the constant is just 1) and beyond that you get back the original F(T). I'm not sure if this solves all problems, but it seems to me it would get us moving toward what you are asking for. Let us know if this is worth implementing. |
|
Will that give the correct mass flux as a function of time and location
over the burner? All cells that are burning will have the same mass flux
rather than now where the first cells ignite and grow following the ramp.
Everytime a new ring of cells ignites, all current cells will see a sudden
drop.
…On Thu, Aug 22, 2024, 07:58 Randy McDermott ***@***.***> wrote:
Discussed this a bit and we think we can make a fairly simple change to
how ramps are processed that would move us in the right direction. The key
issue is decoupling the "T" in the RAMP from the "TSI" or Time Since
Ignition in the ramp that multiplies the mass flux at a wall cell. One
thought is to have a logical on the RAMP line that tells FDS whether T is
meant to be TIME or TSI. Another option would be to use different
parameters (T for TIME and TSI for Time Since Ignition---this is my
preference but might not be very backward compatible).
If I make this hack in the code with your simple ramp,
&RAMP ID='fire_ramp', T= 0.0, F=1.0/
&RAMP ID='fire_ramp', T=300.0, F=1.0/
&RAMP ID='fire_ramp', T=310.0, F=0.0/
then I get this for the result (with twice the resolution; getting rid of
the initial spike is also resolution dependent, but as you said we can
tackle that later).
Figure_1.png (view on web)
<https://github.com/user-attachments/assets/36456da8-5582-451d-aed8-b4d608405f15>
In general, the ramp function can be set to handle different spread rates
and vent areas as follows. Suppose we have a vent with area A_VENT and a
spread rate S. The circular area of the spread is A_SPREAD = pi*(S*T)^2. If
F the ramp function we would use for a t^2 fire with A_VENT, then the new
ramp function is simply,
F_NEW(T) = F(T) * A_VENT/MIN(A_VENT/A_SPREAD[T])
Until A_SPREAD>A_VENT, this is just a constant that depends on the spread
rate, and beyond that you get back the original F(T).
I'm not sure if this solves all problems, but it seems to me it would get
us moving toward what you are asking for. Let us know if this is worth
implementing.
—
Reply to this email directly, view it on GitHub
<#13234 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADBUZ4N2V5QAVKC4QY6GVATZSUEQPAVCNFSM6AAAAABLRFLILKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBTGA3TSMBUGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
A few comments: • I do not understand the usefulness of a new parameter • "The T in RAMP_Q is time since ignition not overall simulation time." • I accept @drjfloyd 's point that this is combining two controls that affect fire size -- the facet-by-facet spread, and the ramp -- and this is potentially complicated. • One point I want to make is that all this is helping to reach more realistic fire models without massive user input. • One extra feature that would be convenient would be a freeze on spread rate, in the same way that a |
|
@drjfloyd It depends on what you mean by "correct". For the period when the A_S < A_V, the fire grows with t^2 simply by following F=1, with T in the ramp being TIME. If you want each newly activated cell to have its own ramp based on TSI, then my approach will not work. But I think that using TIME instead of TSI gives the tight control over the shutdown that Ed is after. So, it's a bit of a compromise: easy coding and controls shutdown, but it does not solve all problems. |
|
@obscureed you can define mutiple vents each with their own set of ramps and if you wanted those ramps to experience decay based on some event in FDS, that can be also be done using control functions. I recognize that this is more work for the user, but it can be done and gives much greater flexibility. @rmcdermo At the instant of spread to the next cells in the current approach, the effective diameter of the fire does not change. We get a smooth change in the effective physical size of the fire which with the heat release rate drives entrainment. With your proposed approach we will a see jump up in the size of the fire diameter and a jump down in the burning intensity when each new ring ignites. This is going to cause some kind of step change in the entrainement. I see this change as potentially taking us further from the concept of what a t2 fire is (which I recognize is in itself just a convenient way of looking at real fires on solid fuels). Is this change in behavior going to be a net good or net bad for the typical user of SPREAD_RATE? |
|
"With your proposed approach we will a see jump up in the size of the fire diameter and a jump down in the burning intensity when each new ring ignites." I don't think we are on the same page. Taking T to be TIME in the RAMP, yes, with each new ring we get an increase in size, that is just how a t^2 fire grows. But we will not get a reduction in mass flux of fuel at the new wall cell. In this case F is 1 and the HRRPUA is a constant. |
|
I think we are not on the same page. Say I am using a RAMP plus SPREAD_RATE to give a t2 growing fire. At some time t I have 100 kW and 0.1 m2 at t and at t+dt jumps to the next ring of cells giving 0.2 m2 and grows slightly (we generally have small timesteps) so the new HRR is 101 kW. My HRRPUA has gone from 1000 kW/m2 to 505 kW/m2 and the effective fire diameter has jumped by a factor of 2 over a timestep. In the old method, the original 0.1 m2 would keep the 1000 kW/m2 and the new would start at 5 kW/m2. My effective fire diameter and burning intensity will hardly change. |
|
With the idea I'm proposing T_IGN is used for activation of a wall cell, but not for the RAMP of Q. I probably should not have complicated the idea with a discussion of rescaling F, forget about that for now. All F does is go to zero at a specific time (when Ed wants to turn off the fire). While the A_S(T) = pi * (S * T)^2 is less than the XB area of the VENT (assume a huge VENT area for now), each active cell has an HRRPUA of whatever is on the SURF line. The fire grows in size only by an increase in the number of active wall cells (which increases the AREA by t^2). |
|
In my experience users now use RAMP with SPREAD_RATE so as the area jumps
to the next ring there is a smooth growth in fire size and the original
cells don't change in HRRPUA. Those users do not want the HRR to have step
changes as the area increases as behavior they cannot control.
…On Fri, Aug 23, 2024, 06:19 Randy McDermott ***@***.***> wrote:
With the idea I'm proposing T_IGN is used for activation of a wall cell,
but not for the RAMP of Q. I probably should not have complicated the idea
with a discussion of rescaling F, forget about that for now. All F does is
go to zero at a specific time (when Ed wants to turn off the fire). While
the A_S(T) = pi * (S * T)^2 is less than the XB area of the VENT (assume a
huge VENT area for now), each active cell has an HRRPUA of whatever is on
the SURF line. The fire grows in size only by an increase in the number of
active wall cells (which increases the AREA by t^2).
—
Reply to this email directly, view it on GitHub
<#13234 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADBUZ4JVZR554YLYRC74SFTZSZBT5AVCNFSM6AAAAABLRFLILKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBVGU2TSMBVGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Yes, for now at least, in my approach the step changes are resolution dependent. As I said, my method does 2 things: it's easy to code and it tightly controls the shutdown of the fire. |
Discussed in #13222
Originally posted by bwklein July 25, 2024
I'm looking for a way to freeze the 'spread' of a fire growth that is based on the SPREAD_RATE parameter.
Similar to how we can freeze the time value input to a ramp for HRRPUA, is there a way to do this with the input to the spreading function. Essentially, stopping the spread of the fire, but keeping the cells active that are within the spread radius.
The text was updated successfully, but these errors were encountered: