firemodels
HVAC pressure fluctuation v6.10.1
Following up on #13673 I rerun the previously discussed cases in release versions of 6.10.1 and 6.9.1.
Findings:
- I think the test bundle had fixed the issue (I had tested it) but release version 6.9.1. did not. (I had not test the case in release version before)
- Simple case runs without fluctuation issue in 6.10.1 but
main casestill has the issue.
I can help further if you have any instructions for me to do. Thanks,
Main case: fds file: test.txt
Run files: 6p10p1.zip
Simple case Then I also ran the simple case @mcgratta provided. The issue is present in 6.9.1 but not in 6.10.1.
Jason, in the "Main case", if I replace the HVAC duct with a hole of the same size, I do not see ringing. Could this be an issue of having a short, wide duct with little loss and roughness?
A louvered opening is going to have at least a C_d ~ 0.6 to 0.7 or a K of ~2 to 2.8 When you replace the louver with a hole, the CFD solution is going to approximate that C_d.
Are things stable if you run with a more physical value for the loss?
I started simplifying the case.
-I removed the DYNAMIC_PRESSURE. Still see oscillations develop as doors open and close. Suggests something to do with CONNECTED_ZONES, or pressure relaxation between zones, and/or how HVAC uses CONNECTED_ZONES. Need to investigate this more.
-I ran it with all the doors open. A small amount of flow developed in the domain (~E-5 m3/s) but no oscillations
-I set NOISE=F and a 1E-6 velocity tolerance. Somewhat less flow but still there.
-I set RADIATION=F and the flow dropped to E-16 m3/s. Something amiss there. Might be an issue with handling real number spacing in the solver. Need to investigate this more.
I found a bug in updating the mapping of ductnodes to pressure zones. I think fixing this should solve most of the problem. The radiation issue was an ADIABATIC thing I think I have a fix for.
With the fix, flows are much better behaved when the dynamic pressure is off. @mcgratta There seems to be a pressure zone issue though. The negative pressure spike is the middle room when both doors close. All the other pressure points including the HVAC louver stay at ambient. The spike stays even if I set a really small VELOCITY_TOLERANCE with 1000 pressure iterations.
With the dynamic pressure on things look reasonable now.
This is what I see when I run the case with the latest source
There are only 3 pressure devices in the original case.
That plot was with DYNAMIC_PRESSURE removed from the one OPEN bondary.
The other two points were just adding two NODE PRESSURE DEVC for the louver.
OK, RADIATION is the cause of the drop in pressure, but I haven't figured out why.
The door that closes at 6 s is very cold. Must be some sort of initialization problem with the reappearing object.
that was it. With everything INERT that the pressure in that middle room is much better behaved.
The question now is -- should we attempt to fix this? I'll see if there is something obvious that can be done, but generally speaking, ADIABATIC is not a good BC to use for a practical scenario, especially in this case where objects are coming and going and the radiation is only updated every third time step. That is how I found the bug -- I noticed that my debug printout was identical three time steps in a row.
I think this falls into the category of time smoothing for heat transfer. We see this all over the place. We are explicit but we are not really time resolved in the energy equation and these wild temperature swings cause lots of problems. I think that, at a minimum, heat fluxes at surfaces should be smoothed over a time scale commensurate with a full update of the RTE, but probably several times that time scale.
Getting rid of ADIABATIC and going to INERT reduces that peak by quite a bit. In this case not sure getting ADIABATIC to work for all things user's might do with OBST creation and removal may not be worth it. Maybe review the guide to make sure we are appropriately cautioning users that this BC is really intended for verificaiton type applications.
I still want to play a bit with this case and see if I can do better with pressure behavior as those doors open and close.
I found that Q_RAD_IN is being set to zero either when the door is removed or reappears. That is why the door surface temperature suddenly dropped. I'll look to see where Q_RAD_IN is being changed or zeroed out.
This has raised an interesting issue. FDS runs through all radiation angles in the first time step so that all boundaries have a complete set of angular fluxes. We don't do this if an object appears mid-calc. That's the problem here. When the door closes, it only absorbs one-fifth of the radiation angles, thus it takes about 15 time steps to bring it up to speed. I'll see if we can just update the radiation completely when an obstruction is created or removed.
It appears that the updating of all radiation angles fixed the pressure drop caused by the erroneous cold wall. I'm going to declare victory and drop out of this thread.
I think the remainder of the oscillation is the somewhat non-physical nature of the case combined with the HVAC model.
In reality, a door doesn't close in zero time. There is some non-zero time where the area decreases from fully open to fully closed. As that area decreases, the volume flow through the opening decreases and the pressure at the inside face of the louver will decrease.
In the simulation, the door closes instantly. There is no more in flow into the closed volume, but there is still momentum in the air flow leaving. The flow decellerates but not to zero. The resulting outflow causes a decrease in room pressure and the room goes negative.
I made a simpler case of three rooms in series connected by doors with air blowing in the front and louver at the back. If I close the doors in stages (flow) the amount of pressure oscillation is much less than if the doors are closed at once (flow2). In the flow case the door closes in 5 steps. The pressure oscillation drops in half.
closing since no more discussion over the last few months. it can be reopened or a new issue if needed