FDS EVAC - corridor flow question

[Vladimir Mozer]

Hello,

I have a simple case of exit at the end of a short corridor  (3m long and 2,2m wide). This corridor stems off a room where the agents (1000) are initially located. I have tried the following ways of creating the corridor and they result in very different evacuation times caused by the entrance into the corridor :

1. one mesh + corridor created by OBSTs - exit time approx. 360s

2. one mesh + corridor created by OBSTs + DOOR+ENTR+KEEP_XY=.TRUE.  exit time approx. 540s

2. 2 meshes (room & corridor) + connection by DOOR+ENTR+KEEP_XY=.TRUE. - exit time approx. 540s

3. 2 meshes (room & corridor) + connection by DOOR+ENTR+KEEP_XY=.FALSE. - exit time approx. 420s

4. one mesh + exit straight from the room - exit time approx. 320s

Here is a figure from item 1:

And here is a figure from item 2.:

I understand that the DOOR+ENTR connection needs enough space to place agents in front of the ENTR which reduces the density and flow. This can be "improved" somewhat by turning off KEEP_XY.  

When I checked the densities and specific flows, the slowest option (2) had about 3.3 pers/m2 in front of the door and the resulting specific flow of about 0.85 pers/m/s which was in line with the fundamental diagram in the SFPE handbook. However, when simulating the same thing within single mesh with OBSTs simulating the corridor (option 1) the flow of persons is much higher. 

My main question is, what is the best way to simulate corridors? In addition, when connecting two meshes one has only the option of DOOR/ENTR. 

Also, is there any way of decreasing the amount of space required for an agent to be placed in front of an ENTR? And what is the actual space that is required in front of an ENTR?

Thanks for any advice.

Vlad

[Gregor]

Do you have a plot "specific flow over time" (entrance of corridor) for all cases?

[Vladimir Mozer]

Here are some quick diagrams for the first two cases shown in the figures in my original post - both measured at the entrance into the corridor:

1. one mesh + corridor created by OBSTs - exit time approx. 360s - average specific flow 1.31 pers/m/s

2. one mesh + corridor created by OBSTs + DOOR+ENTR+KEEP_XY=.TRUE.  exit time approx. 540s  - average specific flow 0.88 pers/m/s

[Gregor]

This explanation of Timo could be interesting for you.

[WP]

"My main question is, what is the best way to simulate corridors?"

I cannot get why CORR is used for this one-floor example.  The manual states that CORR is usually used to define stairs between two floors.  So you are using CORR in an unusual way.  

[Vladimir Mozer]

Hi,

the examples I posted are not using CORR. CORR is a "virtual" element not a visible building block of your geometry. The coridors in my examples are created either by using OBSTructions or MESHes as "visible" building blocks and connected by a combination of DOOR/ENTR, depending on the case. 

I was mainly asking about the impact of the DOOR/ENTR combination on the flow of agents in comparison to corridors, doors or other bottlenecks created with OBSTructions. Which approach is more appropriate for getting appropriate (not overly over or underestimated) flows of agents.

Vlad

[WP]

OK.  Got you question.  An interesting test case!

Your question is whether to use DOOR/ENTR or HOLE/OBST.  Personally I do not often use  DOOR/ENTR if the evac flow filed (eff) is able to guides agents to the destination.   If you take a look at the standard door flow example by Timo, there is no DOOR/ENTR, right?  In my opinion DOOR/ENTR is mainly useful for multiple-floor examples, where evac flow field does not work for transfer among differnt floors.  

In brief eff is a powerful stuff in current algorithm by Timo, and please try to use it first.  When eff cannot solve the problem, then try to place DOOR/ENTR there.  

[TimoK]

WP+´Gregor, thanks for the good help that you have been giving. And yes, try to avoid DOOR => ENTR connections if you can on a floor. For a floor => floor transition (e.g., staircase done using EVSS, also STRS, because you use DOOR => STRS anyhow) you can not do anything else than DOOR => ENTR (or DOOR without a TO_NODE which is practically an entr then). For a floor => floor transition, you can choose the location of the DOOR => ENTR usually (depends on your building geometry a little bit). You could put it in the intermediate landing (and put XYZ "the green cone" where the agents of the floor can see it). This works usually quite well. This has the advantage that the merging flow of the stairs and from the floors is done via "the Helbing/social forces" and you have no problem there. At the intermediate landing you have no merging flow and the flow is just "one-way".

I have also some example cases (well, probably not in V&V part of the guide), where I "drill holes" in the staircase walls, so that one can put the DOOR=>ENTR a little bit "inside the staircase wall". This way the downward going agent flow in the staircase is not blocking the "free area" in front of the ENTR, so DOOR=>ENTR is able to put agents there. Then, the agent are in the same "flow field" than the staircase agents and they feel each other, i.e., they exert social and contact forces on each other. This is actually the flaw of the DOOR=>ENTR. The DOOR side agents do not feel at all the ENTR side agents. One could program that in the source code, but that is not so easy to do, lot's of programming to be done. And it is not the first thing on my ToDo-list. The first thing (of "large improvements") is the internal doors within a floor. This way these internal doors (nowdays just HOLEs in the wall between a room and a corridor, for example) could be used in a door selection algorithm, i.e., the agent can chooce which door it uses to go outside of the room. And the guiding flow fields would also be calculated for the internal doors. But there would not be a DOOR=>ENTR, the agents would just need the HOLE in the wall. I.e., the internal doors would be just used to guide the agents. This has been "on hold" for some years, because one can not put a "sucking VENT" on a zero thick OBST in FDS. So, one should put an EVACUATION=.TRUE. OBST behind these internal doors, when the guiding flow fields are calculated and later to remove these OBSTs. This was not an easy task, when fire and evacuation meshes were treated at the same time. But for now (fds 6.76. onwards) the fire and evacuation meshes have separated in their own calculations, so it might be easier now. Actually, it should be much easier. The guiding flow fields are now calculated in the initialization run, so no need to move agents there, so no problem with the door hole OBSTs. Now I see, this will be really easy to program. I just add the OBSts behind the EXIT/DOORs in the initialization run. And in the phase 3 (read .eff and .fed and do evacuation), I do not add these OBST behind the EXIT/DOORs anymore. Problem solved! Just need to program it and test it and then debug quite much.

TimoK

[Vladimir Mozer]

Thanks Timo, Gregor and WP for your answer. I understand now better, and kind of have "investigated" the impact of the DOOR/ENTR connection of two meshes. I have read a couple of posts where people used DOOR/ENTR to "navigate" agents in the desired direction. It seems that given the way of the DOOR/ENTR connection works it will always reduce the flow, since it is not a continuous transfer of an agent across a line but remove an agent on the DOOR side, check/wait until there is enough space on the ENTR side, place the agent on the ENTR side. So if you want to connect two separate meshes, on the same or different floors, the flow through the DOOR/ENTR connection will be reduced. Timo recommended increasing the width to compesnate for the reduction and KEEP_XY=.FALSE. helps somewhat, but it is difficult to quantify its effect. 

Until the changes that Timo described are implemented, what is the "best" way to navigate agents in situations where prescribing known doors and probabilities is not appropriate. For example a large room from which a number of exits are available, but the EXITs are not directly visible, because the agents have to use corridors with bends? You can experiment with the XYZ position somewhat, but that is only possible if there is only one way to reach the EXIT. If you have, say, two room exits to two separate corridors leading to the same foyer with the main exit this would not work, because you only can specify one XYZ per EXIT or DOOR.

Any thoughts for the time being?

Vlad

[TimoK]

Well, for a complicate room like ours (bended corridors etc.) if would be best to place the initial agents using many different EVAC namelists and say, how many of your agents will go to which door. And do a sensitivity stydy on this. Depends what you want to calculate. You could set most of the agents to go the the common doors (the main doors, the doors that they used to go in) and see the total evacuation time. Then you could direct the agents to the closests exits. Well, this you can not do exactly (easily at least), but you could place many EVAC namelists and specify them to use whatever door is closest to this EVAC. For some parts you could allow FDS+Evac decide the fastest way out (the agents can see the exits).

But, as said, the outcome will be the one that you describe in the user inputs. So, you should do at least:

1) fastest egress: set many EVAC lines so that you can direct the agents to the closest (fastest) exits. For this, you should also consider the width of the doors (their capacity), so that the queues will be balanced. This approach corresponds to a little bit to prescribed codes saying like: add 400mm witdth for each 60 persons. There the assumption is that all doors are used with full capacity at all times.

2) Agents use mainly the familiar doors. This would be the quite usual case, especially at the fire drills. Well, depends on the country a little bit. If the fire drills are regular and well managed, then the occupants know that they should use also the fire exits. Typically, persons do not want to break "lock seals",  go through doors that says "an alarm will be sounded, if you open this door", etc. For a fire case, this could be the worst case scenario.

As said, the output depends what you give as inputs, i.e., how much you optimize the door usage. It is up to you and the authorities to decide/demand which kind of egress scenarios should be considered. Same as with the design fires. The outcame of a fire study is quite much dictated by the choice of the design fire.

TimoK