Thunderhead Engineering Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Forum moved to https://forum.thunderheadeng.com

Author Topic: Blocking Occupants from Using a Certain Room?  (Read 2262 times)

wflanagan

  • New Member
  • *
  • Posts: 1
    • View Profile
Blocking Occupants from Using a Certain Room?
« on: September 23, 2011, 11:15:56 am »

Hey I don't know if anyone could give me any insight into this problem.

Basically I have a model with three auditoriums in a row that have people exiting out both sides into a hallway and the main area. The issue I've been facing is that people from the bottom auditorium will exit out the doors into the main area and move up towards an exit. Then randomly they will duck into the entrance of one of the other auditoriums because they think this is a faster route. This causes a major blockage of the occupants trying to exit that auditorium.

Is there a way that the occupants can be told not to enter a room? Also is there a way to tell them not to go back into a room?

Also a side note, has anyone else been having problems with their simulation locking up when way points are being used? And if so any luck finding a solution?
Logged

Charlie Thornton

  • Thunderhead
  • *****
  • Posts: 851
    • View Profile
Re: Blocking Occupants from Using a Certain Room?
« Reply #1 on: September 23, 2011, 02:37:11 pm »

The problem you are describing sounds eerily similar to a never-released bug in locally quickest we called "magic closets". When that bug was around, you could put a tiny room (like a phone booth) with doors on each side in the back corner of a normal-sized room and when a big enough queue formed, the people toward the back of the queue would think it was faster to turn around and go through the "closet" and THEN line up in the queue to exit the normal room.

We managed to fix that by adding an improvement to our locally quickest algorithm that checked to see if the "tail" part of the path (the part occurring after passing through the first door) re-entered the occupant's current room. If it did, the tail estimate was increased based on information the occupant had about the queue (rather than assuming that the queue would be magically empty if the occupant left and then came back).

If this problem still exists in some form, it's a serious problem and we need to stamp it out. However, I'm guessing you have something more like another issue we've seen.

In hallways, there is often very little difference between a path that follows the hallway directly and a path that entered a room at the first of two doors that join the room to the hallway. In fact, if there is a large queue, the minor increase in travel distance is not enough to overwhelm the queue wait time and the re-entrant path becomes time-equivalent when calculating the fastest local door. To prevent occupants from taking a bizarre and serpentine (but just as fast) path through the adjoining rooms, we've added a priority system that causes occupants to prefer non-re-entrant paths. That system seems to work well, but it's possible that you've found a case that we missed.

We eventually want to include an option that allows users to specify exit signs on the model - effectively converting the room graph to a directed acyclic graph. I think that would be the natural solution where you don't want people short-cutting through a big room.

I hope all that helps. If you think there might be something buggy going on, please send your model (PTH file) to support@thunderheadeng.com and we can let you know what we find.

EDIT: And no, there is not currently any way to force the wayfinding algorithm to ignore a particular room once the occupants have left.
Logged