Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

About Smoke-and-Human Interaction #3

Open
godisreal opened this issue Mar 26, 2019 · 2 comments
Open

About Smoke-and-Human Interaction #3

godisreal opened this issue Mar 26, 2019 · 2 comments
Labels
enhancement New feature or request

Comments

@godisreal
Copy link
Owner

godisreal commented Mar 26, 2019

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.

firemodels/fds#1475

@godisreal godisreal added the enhancement New feature or request label May 13, 2019
@godisreal
Copy link
Owner Author

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
Copy link
Owner Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant