godisreal / test-crowd-dynamics

Testing Result of Crowd Evacuation Behavior by Using FDS+Evac
4 stars 2 forks source link

About Smoke-and-Human Interaction #3

Open godisreal opened 5 years ago

godisreal commented 5 years ago

My Comments for FDS+EVAC:

When the fire/smoke spread towards people, people normally desire moving faster to escape from danger. Thus, we suggest that the desired velocity v0 should be increased when smoke density increases, and the self-driving force is thus increased. The fact that people may slow down in a smoke area is instead characterized by adding a resistance force which is proportional to the smoke density. This force describes how smoke reduces the visibility and impedes people's motion. As a result, both of the self-driving force and smoke resistance are increased when people are walking in smoke. If the self-driving force is larger than the resistance, people can accelerate, otherwise people slow down. The following plot exemplifies the increasing curve of the self-driving force and smoke resistance when the smoke density increases. When the smoke density increases initially, the smoke is not thick so that people are able to speed up. As the smoke density keeps increasing, the resistance from smoke is predominant and people have to slow down.

https://github.com/firemodels/fds/issues/1475

godisreal commented 5 years ago

Now the key problem exists in the exit selection algorithm with smoke or other hazard information. There is some problem with current algorithm. For example, there are two subroutines See_each_other and See_door(). It seems that the only difference between See_each_other() and See_door() is whether the smoke information is used between the two points.

 LOGICAL FUNCTION See_each_other(nm, r1_x, r1_y, r2_x, r2_y)
    ! This function returns true, if the two points have a line-of-sight.
    ! This function does not use smoke information, i.e., it just sees if
    ! there are obstacles between the two points.
    ! Inputs:  nm: mesh index, r1 an r2 should belong to the same mesh
    !          (r1_x,r1_y): co-ordinates of the first agent
    !          (r2_x,r2_y): co-ordinates of the second agent
    ! NOTE: This works for thick and thin OBSTs.
 LOGICAL FUNCTION See_door(nm, r1_x, r1_y, r2_x, r2_y, ave_K, max_fed)
    ! This function returns true, if the two points have a line-of-sight.
    ! This function does use smoke information, i.e., it sees if
    ! there are obstacles and/or too much smoke between the two points.
    ! Inputs:  nm: mesh index, r1 an r2 should belong to the same mesh
    !          (r1_x,r1_y): co-ordinates of the agent
    !          (r2_x,r2_y): co-ordinates of the door
    ! Outputs: ave_K: average extinction coefficient of the path
    !          max_fed: maximum level of FED at the path

However, in the subroutine Change_Target_Door(), See_each_other() are also widely used, which means that sometimes smoke information is not used in the door selection algorithm. I do not quite get it. In fact, the smoke should be modeled like "moving walls," and when checking the visibility of two points, it seems reasonable to always consider smoke density along the line between the two points. .

godisreal commented 4 years ago

Not sure if this is also useful to smoke spread, especially in stairways.
https://groups.google.com/forum/?fromgroups#!topic/fds-smv/CTKBtLnm1Ho If you put an EXIT (or DOOR) on an OBST, then the evacuation read in routine will make there a special VENT that is used to calculate the guiding flow fields towards the exit/door. And an EXIT (or DOOR) line will define one grid cell thick OBST behind it, if there is not such thing there already. This automatic OBST is defined with a keyword PERMIT_HOLE=.FALSE., so your own HOLEs should not crash the logig.