Numerical Instability caused by sudden removal of multiple obstacles (Burn-away simulation)

[fjzeng1999-cloud]

Hi everyone,
（FDS-6.10.1-0-g12efa16-release）

fire0207fds.TXT
fire0207out.TXT

I am simulating a fire in a wooden building consisting of multiple enclosed rooms. I am encountering numerical instability exactly when the fire reaches its peak intensity. Around 1213s, I simulate the disappearance of windows (using timers), which introduces fresh air and triggers the room to flashover. To simulate the structural failure caused by the intense heat of this flashover, I configured &DEVC timers to remove multiple &OBST elements (walls/floors) shortly after 1213s. The goal is to allow the fire to spread and induce a larger-scale flashover.To simulate the structural failure and fuel contribution of the wooden walls/floors, I am using the BURN_AWAY logic.

The simulation runs stable until 1280s. However, the moment these enclosing boundaries are removed (via &OBST disappearing), the simulation crashes immediately with "Numerical Instability" (High Max Divergence).

It seems that the sudden disappearance of these obstacles causes a massive spike in velocity/pressure as previously separated zones become connected instantly.

My question is: Is there a recommended way to "gently" remove obstacles to avoid this shock? Or should I stagger the removal times to prevent the solver from crashing?

Any advice would be appreciated. Thanks!

[drjfloyd]

I will run your case with the current source and take a look.

One comment is I would delete this: WALL_INCREMENT=100. You are predicting fire growth, and this says only update the wall solution every 100 timesteps. With the 5 cm grid around your fuel, 100 steps is probably around every 0.1 s and is decoupling to some extent your pyrolysis from the local conditions. The wall routines are typically single digit percentages of the run time so you are not saving much time by doing this.

[fjzeng1999-cloud]

Thank you so much for your reply and for taking the time to run my case.

I appreciate the insight regarding WALL_INCREMENT=100. I didn't realize that updating the wall solution so infrequently could decouple the pyrolysis from the local conditions to such an extent. I will follow your advice and delete this parameter immediately.

I will re-run the simulation with this change. Thanks again for the help!

[drjfloyd]

Look at your hrr file. You use up the oxygen in the compartment within 200 s. After that a small amount of combustion is supported due to leakage flows. You are still; however, pumping in fuel from the burner at a rate of 0.02 kg/s. Over the 1000 s between when you use up the O2 and you open the windows, you have added ~20 kg of fuel to compartment but only consumed a couple kg of it. When you suddenly remove the windows all that fuel will encouter oxygen. With the default autoignition temperature of 0 K, it will burn immeadiately causing a large pressure spike and large velocities that lead to instability.

In an actual residential compartment fire, if all the doors and windows remain closed, a fire will burn itself out. Then as pyrolyzing surfaces cool they will emit less and less fuel. If a vent is opened due to window failure or someone opening a door, you won't suddently ignite all the unburned fuel instantly (as happens with the default assumption of a 0 K auto ignition temperature). Fuel and oxygen have to mix into a combustible mixture and that mixture must be hot enough or see an igniton source. Maybe it burns, maybe it doesn't. Maybe surfaces are still hot enough to rekindle, maybe they are not.

You need to think carefully on your modeling assumpitons, and what it is you are telling the model to do. For example, why are all the windows being removed within a short period of time when the fire is contained to a single compartment?

[fjzeng1999-cloud]

Thank you so much for analyzing my HRR file and pointing out the issue with fuel accumulation. I am a beginner with FDS, so your insights are incredibly helpful.
I am trying to validate a full-scale experiment of a timber structure compartment fire.
In the actual experiment, the room was not perfectly sealed; there were significant leakage paths (gaps in the timber construction). The fire did not burn out completely when oxygen dropped; instead, the HRR grew very slowly due to these leaks until the windows eventually failed thermally, leading to flashover.
Since modeling the progressive thermal failure of glass is complex, I used timers to remove the windows, which I now realize created the "sudden shock" you described.
You are absolutely right about the "fuel bomb" effect. My burner kept pumping fuel (0.02 { kg/s}) even when the fire was choked, creating that massive accumulation
To better match reality, should I define a RAMP for the burner's HRR to simulate a slower growth (or decay) when oxygen is limited, rather than a constant output? In any case, I will carefully review the model and implement these optimizations before re-running the simulation.
Thank you again for your patience and advice！

[drjfloyd]

If you are trying to replicate an experiment, then you need to have your inputs reflect the actual experimental conditions as closely as possible. Your input file says the ignition source is a gasoline pool. You have a constant HRRPUA for 3600 s that puts in 10s of liters of gasoline. For igniting a wood crib I suspect that fuel pan contained 100s of ml up to a liter and not 10s of liters. You say the leakage was significant and allowed the fire to grow slowly. That did not happen with your inputs. This strongly suggests you are not adequately accounting for leakage.

[drjfloyd]

since this isn't a bug converting to a discussion.