FDS: Numerical Instability (max divergence) after timed vent opening + OBST removal + BURN_AWAY

[fjzeng1999-cloud]

Hello respected engineers,

fire0305fds.txt
fire0305out.txt
fire0305b_devc.csv
fire0305b_hrr.csv
fire0305b_steps.csv
Revision : FDS-6.10.1-0-g12efa16-release

I have recently been simulating fire spread in a timber building composed of multiple enclosed rooms. When the fire reaches its peak intensity, the numerical simulation becomes unstable. At around 1213 s, I simulated the disappearance of a window (using a timer), which introduces fresh air and triggers flashover in the compartment. To represent structural failure caused by the high temperatures generated during flashover, I set up &DEVC timers to remove several non-combustible &OBST elements (a tiled roof) shortly after flashover. The purpose is to allow the fire to spread and trigger a larger-scale flashover. To model structural failure of timber walls and their fuel contribution, I used the BURN_AWAY logic.

The simulation runs stably until 1456 s, when it crashes with “Numerical Instability” (max divergence).

My question is: What could be causing the numerical instability in this simulation? Based on the recommendations in the FDS User Guide, I have modified many parameters and performed more than 50 runs, but the numerical instability error still occurs at apparently random times. The longest run lasted about 1700 s, and the shortest about 1250 s.

Thank you very much for your suggestions!Please! Help me.

[Er9y714]

Have you read the User guide section 4.2 Common Error Statements > Numerical Instability Errors?

If there is a significant change in the model at a timestep, default number of iterations might not be sufficient to overcome this change. Have you tried increasing the number of iterations?
Is there an underventilation in the model which can cause spurious ignitions and pressure spikes?

[fjzeng1999-cloud]

Yes, I tried that. I increased the maximum number of iterations to 50, but the error still occurs. In the model, I tested both zone leakage and HVAC leakage. The spurious ignition issue was addressed by limiting AIT, but the error still persists.

[drjfloyd]

This appears to be the same input (with some minor changes) to the one you posted in this discussion last month: #15937. It is best to continue in the same discussion thread so the entire history of the discussion is apparent to all.

You are predicting fire growth and spread which is a research application. Your input file has almost no outputs in it (a few thermocouples). No slice files of temperature, velocity, fuel mass fraction. No boundary files of wall temperature or burning rate. I recommend you add such outputs and examine them to see if you observe non-physical behavior around the time the instability happens.

[mcgratta]

Yes, I closed the other thread.

[fjzeng1999-cloud]

What I’m studying is fire spread in timber buildings, where the building itself acts as fuel, so using BURN_AWAY is necessary. I have tested a standalone wood crib/pile, and it can run to completion without issues. However, once I include the house geometry in the simulation, numerical instability occurs very easily. I have repeatedly modified many settings and also asked an FDS researcher/practitioner I know. He told me that it’s difficult to determine the cause just by looking at the FDS input file, and that the only way is to keep troubleshooting through trial-and-error simulations. But so far, I still haven’t found what triggers the error.

Thank you again for your reply.

[drjfloyd]

Similar to comments I made before, you need to look at how well are you capturing the experiment in your inputs. Here is your burner:

&SURF ID='Burner_Gasoline',
COLOR='RED',
HRRPUA=500.0,
RAMP_Q='Burner_Gasoline_RAMP_Q',
TMP_FRONT=1200.0,
MASS_FRACTION=1.0,
SPEC_ID='SFPE WOOD_Fir_fuel',
TAU_MF=1.0/

While you are no longer pumping in 10s of liters of gasoline you still have TMP_FRONT=1200. THis means that surface is ALWAYS 1200 C. That is a strong radiating source. Below is the HRR and fuel mass loss rate for the first ~400 s. At first the fuel mass loss rate and the HRR track one another. By 350 s there is a growing mass loss rate but a dropping HRR. I

Here is the burning rate with the domain clipped to show the inside of the crib. All the burning is at the bottom which sees the 1200 C radiant heater you have specified. There is no burning inside the crib.

As a result, once again you have filled the volume with a lot of fuel

[drjfloyd]

Another suggestion is ignore the building for now. Just model your wood crib and a physically plausible ignition source out in the open. Does your current SURF for the crib result in reasonable growth and spread over the crib?

[fjzeng1999-cloud]

Thank you very much for your response and assistance. Yes, I tested the standalone combustion of the wood crib. The wood crib only serves as the ignition source for the room, with the main focus being on the spread after the wooden structure is ignited. To ensure the wood crib enters a rapid burning phase, additional fuel was added after 1200 seconds. However, based on my runs, the wood crib may not be the main cause of the error.

[mcgratta]

I have run this case in several different ways. I suggest you do the following:

1. Install the latest nightly build.
2. Remove MINIMUM_LAYER_THICKNESS from all SURF lines. This parameter will only make the case less stable.
3. Add a &PRES line with MAX_PRESSURE_ITERATIONS=50. If this does not work, add SOLVER='ULMAT'.

If the case still fails, there might also be a numerical issue that I am currently investigating related to the optimization level of the compiler.

[mcgratta]

Actually, this case is crashing for various reasons. I suspect there is a bug in FDS, and I have to track it down. I have converted this Discussion thread into Issue #16034. You can make comments there if you'd like.

[fjzeng1999-cloud]

Alright, thank you very much for your response and assistance. I had already tried setting MAX_PRESSURE_ITERATIONS=50 previously, but it didn’t work, including adding SOLVER='ULMAT'.

I rebuilt the model over the last couple of days, expanding the grid to 0.2 m and removing mesh refinement. After multiple runs, I’ve found that the simulation occasionally runs successfully, but even with exactly the same case, numerical instability can still appear at different times and locations—it only succeeds with a small probability.

So far, I've performed about 50 runs, and only around 8 of them have completed successfully. I still can’t pinpoint the exact cause, but my hypothesis is that the burn away of numerous wooden obstacles creates multiple ventilation openings in the scene, leading to instability in the flow field.

[mcgratta]

Hopefully, these issues are now resolved. Try the latest nightly build.