Minimum density and Numerical Instability

[MrAhriman]

Dear esteemed developers and experts of the FDS community,
I hope this message finds you in good spirits. As a newcomer in the field, I have been grappling with some challenges while endeavoring to construct a FDS model for tunnel fire ventilation. Specifically, I have encountered issues related to 'Minimum density' and 'ERROR: Numerical Instability'. When the fan volume rate remains constant and substantial (at 60 and 80 m³/s), the simulation proceeds smoothly, maintaining stability for at least 80 seconds without any hiccups.

However, the situation changes when I employ the RESTART function to dynamically adjust the fan volume every second before the simulation. This approach has led to the emergence of the aforementioned 'Minimum density' and 'ERROR: Numerical Instability' issues. Accompanying this message, you will find an image depicting a density slice within the tunnel, along with the relevant FDS input file, the error log file, and a document outlining the temporal variations in fan volume (with time in the first column and corresponding fan volume in the second).

I am eager to receive your expert insights and guidance on how to resolve these challenges.

Thank you for your attention and assistance.

Warm regards

Time-Volume-Temp.txt
error.txt
jzw_0_5.out.txt
jzw_0_5.fds.txt

[rmcdermo]

Have you explored the options in the user guide section, 21.3 Pressure Considerations in Long Tunnels ?

[MrAhriman]

I attempted to use the 'TUNNEL_PRECONDITIONER=T' setting, but encountered an error within the first few seconds (2s) of the simulation. Despite the absence of a 'minimum density', the error was related to numerical instability. I haven't tried the methods following 21.3, as I am uncertain about their effectiveness and I may not be aware of whether they would work.

Currently, I am experimenting with reducing the frequency of adjusting the fan air volume, changing from once per second to once every five seconds. This approach was inspired by the stable operation when the fan air volume is kept constant. So far, the simulation is running normally, having reached 23 multiples of 5 seconds.

Best regards,

[rmcdermo]

TUNNEL_PRECONDITIONER=T should be used here. I cannot think of a reason not to. If you still have stability issues after that, then something else is likely the cause.

If this fails quickly, that is actually good from a debug point of view. If you could submit the case that fails to the Issue page, that would be good. Thanks

[rmcdermo]

The RESTART issue may be separate. Could you please try to make a very simple case that demonstrates the issue and submit this to the Issues page? Thanks

[MrAhriman]

I would like to kindly request your permission to first attempt to reproduce the issue using a single MPI process. If successful, I will endeavor to create a related issue. I would like to inform you that due to the nature of parallel computing, the supercomputer platform scheduling commands I use are not universally applicable and may not be well reproducible on your computer. I appreciate your understanding and cooperation in this matter.

[drjfloyd]

I think the way restart is being used may be pushing an already fragile simulation over the edge. We know that tunnels with fires and multiple meshes can be challenging for the pressure solver. When a wall velocity is changed during restart, that change is implemented instanteously. Typical timestep sizes for a case like this are going to be ~0.01 to 0.001 seconds. To have a large acceleration in the wall adjacent grid cell over a single timestep is going to require a pressure solution that imposes a large pressure gradient in that cell. Rather than simply changing VOLUME_FLOW, another approach would be to use a RAMP. Rather than this input:

&HVAC ID='Duct-fan1', TYPE_ID='DUCT', DIAMETER=0.3048, FAN_ID='Fan01', NODE_ID='Node-fan1','Node-outletfan1', ROUGHNESS=1.0E-3, LENGTH=139.319545/
&HVAC ID='Fan01', TYPE_ID='FAN', TAU_FAN=25.0, VOLUME_FLOW=-16.382604783821854/

have:

&HVAC ID='Duct-fan1', TYPE_ID='DUCT', DIAMETER=0.3048, VOLUME_FLOW=1, RAMP_ID='VF Ramp', NODE_ID='Node-fan1','Node-outletfan1', ROUGHNESS=1.0E-3, LENGTH=139.319545/

&RAMP ID='VF RAMP',T=0,F=0/
&RAMP ID='VF RAMP',T=1,F=xx/ where xx is whatever the flow should be at 1 second.

Then when you restart, edit the ramp to impose the new flow over the next second. So at 2 s you would have:

&RAMP ID='VF RAMP',T=1,F=xx/
&RAMP ID='VF RAMP',T=2,F=yy/ where yy is the new flow

at 3 s

&RAMP ID='VF RAMP',T=2,F=yy/
&RAMP ID='VF RAMP',T=3,F=zz/

and so on. Now you won't be trying to impose a step velocity change inside a tunnel simulation.

[MrAhriman]

I think the way restart is being used may be pushing an already fragile simulation over the edge. We know that tunnels with fires and multiple meshes can be challenging for the pressure solver. When a wall velocity is changed during restart, that change is implemented instanteously. Typical timestep sizes for a case like this are going to be ~0.01 to 0.001 seconds. To have a large acceleration in the wall adjacent grid cell over a single timestep is going to require a pressure solution that imposes a large pressure gradient in that cell. Rather than simply changing VOLUME_FLOW, another approach would be to use a RAMP. Rather than this input:

&HVAC ID='Duct-fan1', TYPE_ID='DUCT', DIAMETER=0.3048, FAN_ID='Fan01', NODE_ID='Node-fan1','Node-outletfan1', ROUGHNESS=1.0E-3, LENGTH=139.319545/ &HVAC ID='Fan01', TYPE_ID='FAN', TAU_FAN=25.0, VOLUME_FLOW=-16.382604783821854/

have:

&HVAC ID='Duct-fan1', TYPE_ID='DUCT', DIAMETER=0.3048, VOLUME_FLOW=1, RAMP_ID='VF Ramp', NODE_ID='Node-fan1','Node-outletfan1', ROUGHNESS=1.0E-3, LENGTH=139.319545/

&RAMP ID='VF RAMP',T=0,F=0/ &RAMP ID='VF RAMP',T=1,F=xx/ where xx is whatever the flow should be at 1 second.

Then when you restart, edit the ramp to impose the new flow over the next second. So at 2 s you would have:

&RAMP ID='VF RAMP',T=1,F=xx/ &RAMP ID='VF RAMP',T=2,F=yy/ where yy is the new flow

at 3 s

&RAMP ID='VF RAMP',T=2,F=yy/ &RAMP ID='VF RAMP',T=3,F=zz/

and so on. Now you won't be trying to impose a step velocity change inside a tunnel simulation.

Your response has truly been an enlightening experience for me

[rmcdermo]

@MrAhriman @drjfloyd Is it possible to reproduce the RESTART problem on a single mesh using the ULMAT pressure solver? In my mind, without mesh errors and without penetration errors, nothing should prevent a restart over a single time step. Would be interesting if we could trap a problem like this---could help make RESTART more robust.

[drjfloyd]

People have been making changes to things like vent velocities with restart for years and we have not been seeing reports of this nature. I doubt the problem is restart itself, but likely the interaction of changing the boundary conditions in tunnel simulation where there was no usage of the guidance in 21.3. The restart capability in FDS has only ever been intended for use in reocvering from a simulation interrupted via an external factor. FDS does not have any way of knowing that there has been an input file change for it to somehow modify the user change to improve the likelihood that a tunnel simulation stays stable.

After Julich I have other tasks I need to focus on. I wouldn't have much time for this for a while.

[MrAhriman]

The scenario where the wind speed changes every 5 seconds and 'TUNNEL_PRECONDITIONER=F' has encountered a numerical instability error again when the simulation runs to approximately 370 seconds. Next, I will attempt to use the RAMP method.
error.185306.txt
Time-Volume-Temp_370.txt

[MrAhriman]

The scenario where the wind speed changes every 5 seconds and 'TUNNEL_PRECONDITIONER=F' has encountered a numerical instability error again when the simulation runs to approximately 370 seconds. Next, I will attempt to use the RAMP method. error.185306.txt Time-Volume-Temp_370.txt

@rmcdermo @drjfloyd However, using the RAMP method did not lead to a successful simulation; the numerical instability error reappeared at around 120 seconds.
error.186987.txt
jzw_0_5_ramp.out.txt

Time-Volume-Temp_RAMP.txt

[MrAhriman]

The scenario where the wind speed changes every 5 seconds and 'TUNNEL_PRECONDITIONER=F' has encountered a numerical instability error again when the simulation runs to approximately 370 seconds. Next, I will attempt to use the RAMP method. error.185306.txt Time-Volume-Temp_370.txt
Previously, I placed the fire vent between two MPI computational grids. Now, I am attempting to move this fire vent into a single grid. I am not sure about the outcome and whether it will prevent further errors.

[MrAhriman]

The scenario where the wind speed changes every 5 seconds and 'TUNNEL_PRECONDITIONER=F' has encountered a numerical instability error again when the simulation runs to approximately 370 seconds. Next, I will attempt to use the RAMP method. error.185306.txt Time-Volume-Temp_370.txt
Previously, I placed the fire vent between two MPI computational grids. Now, I am attempting to move this fire vent into a single grid. I am not sure about the outcome and whether it will prevent further errors.

The error persists.

[obscureed]

[This is unofficial advice; I am not affiliated with NIST etc]:
I do not have a fix for you, but I have some comments:
• "&TIME DT=1.0 /" is a very aggressive setting for startup. It may also apply when you load up a restart file, and that's not a good time for aggressive settings.
• If your timestep is anything like 1.0s, then insisting that the simulation saves a restart every 1.0s will interfere with timestepping. The timestep choice is adjusted to make restarts happen exactly when requested (unlike most postprocessing, I think, where the output happens at the next appropriate moment), and this can interfere with stability. You might think that short timesteps would be stable, but it isn't always so, particularly jumping from long (or sensible) timesteps to short ones.
• You should monitor "Pressure Iterations" in the .out file. These pressure iterations are from mesh-block to mesh-block. If the solver hits the maximum (which is 10 here), then the flow exchanged between mesh-blocks can be completely wrong. If your timesteps are consistently hitting the Pressure Iterations limit, then the solution could be completely wrong from that time onwards. This is happening in your .out files, so the source of the final instability is well before the crash.
• When you define the changes using RAMP, you should make the changes gradual -- certainly over several timesteps, and possibly enough for the change to transmit itself gradually along the entire tunnel.
• As a wider question, why is the wind changing every 5 seconds? Is it so that you can test various steady wind conditions in a single simulation? If that is the reason, and your simulations are suffering from instability, then you should make the changes more slowly and less often.
• In fact, apply everything more slowly: for example, ramp up the fans at the start over 10 or 20 seconds; grow the fire at least that slowly. Some of the changes I have mentioned will make your models run slower, but getting good answers slowly is better than hitting instability.
• Looking at your geometry, I see that you have created the curved profile of the tunnel wall, but left fluid voids outside the wall. Why not fill in those voids with OBST? This makes the solver's job easier. Also, I would put the fans further inside the model, some distance away from the OPEN boundary condition. (If the fans are actually at the entrance to the tunnel, then add a mesh block of a few metres of exterior space, and apply the OPEN boundaries to the far faces of the new block. It is always good to separate complicated flow from any OPENs.)

If/when you find a solution (or if you have already found one), please tell us what worked!

[drjfloyd]

In the current release, DT_RESTART behaves like all other DT. You get the closet time to the requested.

[obscureed]

Thanks for the correction, @drjfloyd . Something in the OP's first run (reported in jzw_0_5.out.txt above, running version 6.9.1) caused the simulation to hit Total time = 2.00s, 3.00s, 4.00s, etc. I assumed it was &DUMP DT_RESTART=1.0 /, and now I do not know what caused this.