This idea means that evac is executed as an independent program, and it does not necessarily run together with fds. There are several benefits of doing so. I will write a brief proposal as below. Maybe someone would join and cooperate with me to implement this idea.

1. User Perspective: From the user side, users commonly do not need to run fds and evac together, especially for large-scale examples. Because evac simulation can run very fast when there is no fire computation. Normally users just run fire+evac together in the first run, and then run multiple evac simulation without fire computation because EVAC itself runs much faster than FDS. So it does not increase much computational cost if EVAC is oursourced from FDS.

2. Technical Features: FDS require much computational time while EVAC does not. Existing technical requirement for FDS and EVAC are quite different. For example. FDS needs MPI for large-scale simulation, but EVAC usually does not. EVAC module is not well designed for MPI execuation and this has caused several problems if EVAC runs together with FDS. So outsourcing EVAC can help to simplify some code and improve reliability of EVAC module. Since Timo is busy with many other things, I think he will prefer a more reliable evac module, which will bring less problems for him to solve on Github. The major work is rewriting a script to call evac subroutins. A major difficulty may exist in outputting .smv file for smokeview because it will share .smv with FDS. Or maybe we can write another small visualizer especially for evac module.

fds6 is more user-friendly. Users only need to define main evacuation meshes and other door flow meshes are automatically generated. The trade-off is that evac module is deeply coupled with fds modules.
In contrast fds5.5 is less user-friendly because users have to manually specify door flow meshes in input files. However, the benefit is that evac module is more independent and it looks less coupled with fds modules.

I think there are two different concepts regarding door selection of agents.

The first thing is whehter an agent knows a door or not, and it is boolean logic (know it or not know it), and it is characterized by known_door_names in the current program (evac.f90). The second issue is how an agent is familiar with a known door, and it should be measured by a real number from 0 to 1 (Just like a probality). An agent can only be familiar with a known door. If one does not know the door, there is no issue of being familiar to it. Thus, the familiarity measure is specified by known_door_probs, and it is only effective for the known doors. That is, known_door_probs=1.0 means being fully familiar with a door while known_door_probs=0.0 means unfamilarity.

In EXIT namelist Users are also allowed to give a value in between like 0.6 or 0.3 (0.0<=known_door_probs<=1.0). This is very similar to probablity, and familiarity to an exit is thus understood as the frequence of using the exit in the historical data (prior information). From there one can infer the probablity of how agents select the doors and exits in the simulation run.

However, exiting program (evac.f90) only provides a good user interface, but the inner algorithm of exit selection is far from perfect. The algorithm generates a random number and compare it with known_door_probs to assign the exit either familiar or unfamiliar (boolean logic). A better method is integrating the real familiary measure in the preference order in the door selection algorithm (User Guide pp. 29, Table3). As a result, the familarity is not a yes/no logic, but with the real number given by known_door_probs.

The original weblink is as below.
firemodels/fds#2206

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

Excuse me. I run an example as below. However, the smoke does not enter the small room top right.
I also run another example where soot reaches the wall and reflects back like air flow. So may I ask what problem it is?

&HEAD CHID='soot_upload2019',TITLE='soot_problem' /
&MESH IJK=39,24,3, XB=-0.6,30.6, -0.6,18.6, 0.0,3.0 /
&TIME T_END = 220.0, DT=0.2 /

&MISC SURF_DEFAULT = 'WALL',
      RADIATION=.FALSE.
	EVAC_SURF_DEFAULT = 'EVAC_WALL',  
	EVACUATION_DRILL=.false.  
	EVACUATION_MC_MODE=.false. /

&DUMP SMOKE3D=.TRUE.,
      NFRAMES=2000,
      DT_PART=0.5,
      DT_HRR=1.0,
      DT_SLCF=1.0,
      DT_BNDF=5.0,
      DT_PL3D=1000.0,
      DT_ISOF=5.0 /

&REAC ID         = 'POLYURETHANE'
      FYI        = 'C_6.3 H_7.1 N O_2.1, NFPA Handbook, Babrauskas'
      SOOT_YIELD = 0.10
      N          = 1.0
      C          = 6.3
      H          = 7.1
      O          = 2.1  /

&SURF ID='BURNER', HRRPUA=1000., COLOR='RASPBERRY' /

&MATL ID            = 'GYPSUM PLASTER'
      FYI           = 'Quintiere, Fire Behavior'
      CONDUCTIVITY  = 0.48
      SPECIFIC_HEAT = 0.84
      DENSITY       = 1440. /

&SURF ID             = 'WALL'
      RGB            = 160,160,160
      MATL_ID        = 'GYPSUM PLASTER'
      THICKNESS      = 0.012 /

 Boundary condition for the evacuation flow fields:
&SURF ID = 'OUTFLOW', VEL = +0.000001, TAU_V=0.1 /

&SURF ID    = 'EVAC_WALL'
      RGB   = 200,0,200 / or COLOR
	  
=======================================================
============= FIRE FDS GEOMETRY STARTS ================
=======================================================

Basic Outlines
&OBST XB = 0.0, 20.0, 17.9,18.0, 0.0,3.0, SURF_ID='WALL' / 
&OBST XB = 0.0, 20.0, 0.0, 0.2, 0.0,3.0, SURF_ID='WALL' /
&OBST XB = 0.0, 0.1,  0.0,18.0, 0.0,3.0, SURF_ID='WALL' /
&OBST XB = 20.0,20.1, 16.5,18.0, 0.0,3.0, SURF_ID='WALL' / 

Right Lounge Area
&OBST XB = 20.0,30.0,  0.0,0.2,  0.0,3.0, SURF_ID='WALL' / 
&OBST XB = 20.0,27.0, 15.9,16.0, 0.0,3.0, SURF_ID='WALL' /
&OBST XB = 27.0,30.0, 17.9,18.0, 0.0,3.0, SURF_ID='WALL' /
&OBST XB = 29.9,30.0,  0.0,18.0, 0.0,3.0, SURF_ID='WALL' /
&OBST XB = 27.0,27.1,  9.0,18.0, 0.0,3.0, SURF_ID='WALL' /

&OBST XB = 27.0,30.0, 9.0,9.1, 0.0,3.0, SURF_ID='WALL' /
&OBST XB = 27.0,30.0, 13.5,13.6, 0.0,3.0, SURF_ID='WALL' /

&OBST XB = 20.0,20.1, 2.0,14.5, 0.0,3.0, SURF_ID='WALL' / 

Doors and Exits in Right Lounge Area
&HOLE XB= 26.8,27.2, 14.5,15.5, 0.0,2.0 /
&HOLE XB= 26.8,27.2, 11,12, 0.0,2.0 /

Left Lounge Area
&OBST XB = 16.0, 20.0, 6.0, 6.2, 0.0,3.0, SURF_ID='WALL' /
&OBST XB = 6.0, 14.0, 6.0, 6.2, 0.0,3.0, SURF_ID='WALL' /
&OBST XB = 0.0, 4.0, 6.0, 6.2, 0.0,3.0, SURF_ID='WALL' /
OBST XB = 10.0, 10.2, 0.0, 6.0, 0.0,3.0, SURF_ID='WALL' /


The fire as a burner.
&OBST XB= 28.50, 29.50, 10.00, 11.00, 0.00, 0.60, SURF_ID='INERT' /
&VENT XB= 28.50, 29.50, 10.00, 11.00, 0.60, 0.60, SURF_ID='BURNER' /

&VENT MB='YMIN',SURF_ID='OPEN' / 
&VENT MB='YMAX',SURF_ID='OPEN' / 

There are several models in evacuation module which seem out of use for long.
Is there any instruction on how to use them?

1 hawk-dove game
2 group model
3 fall down model

Is it possible to reuse evac.f90 in another program without fds? I start a trial here. The compilation is through, but there is a segmentation error SIGSEGV (Invalid memory reference). Does anyone know how to solve this problem?
@tkorhon1 @chraibi

I have tried to use fds+evac to simulate the doorway scenario, and I did not observe the faster-is-slower effect either. However, when I enable the falling-down model in fds+evac, and it does show some interesting result. Maybe I should explore more along this direction. The falling-down model in fds+evac was initailly developed by a student in Timo's group, and it has been included in the offiscial version of fds since fds6 (Not in fds5). Any comments? @fij

It is important to modify mobility of agents during tpre time period. Otherwise agents before tpre (in pre-evacuation stage) will block others' way in the simulation result.

In order to solve this problem TPRE_TAU and TPRE_TAU_INER are added in PERS namelist so that agents can move around during tpre time period so that they will not block others' way. Please refer to color4test44.zip for detailed result.

Below is the discussion about this feature in FDS google forum. Thanks Timo for guidance.
https://groups.google.com/forum/?fromgroups#!searchin/fds-smv/tpre%7Csort:date/fds-smv/qNAbpZ8Y2-A/m4DT7Vh2BgAJ

I have got a simple visualizer for Evac prt5 file by using pygame (SDL for Python).
https://github.com/godisreal/test-crowd-dynamics/tree/master/visualize_evac
The program is developed from a python script that reads evac prt5 data, and it was initially provided by Topi in this thread. @sbenkorichi
(Thank Salah Benkorichi for sending this thread to me.).

https://groups.google.com/forum/m/?utm_medium=email&utm_source=footer#!msg/fds-smv/dFUWR00T6hw/pntxx0rABgAJ

Now evac output data (prt5) can be alternatively visualized by pygame (SDL for python)
in 2D style. This could be supplementary to smokeview for visualizing evac output data,
and it is useful to draw the agents' compete tracjactory as many users required.

In addition we modify xyz.shape = (7,nplim) for evac prt5 data.
Maybe xyz.shape = (3,nplim) on Topi's script is just for Lagrangian Particles. I haven't got time to test it, and comments are much welcome.

Currently this program has no GUI, and it only reads one evacuation mesh and visualize the simulation data in two-dimensional space, and it is easy to further develop this small program for multiple evacuation meshes. A small GUI is also preferable. Comments are much welcome.

This small tool is now uploaded in the following repo.
https://github.com/godisreal/evac-prt5-tool

Useful information about I_HERDING_TYPE:

https://groups.google.com/forum/?fromgroups#!topic/fds-smv/hN4HK5Ntaac

http://virtual.vtt.fi/virtual/proj6/fdsevac/documents/Readme.txt
(NOT accessible in China Mainland)

=======================================
User Input Changes, Evac 2.3.1 vs 2.3.0

*) Added herding behaviour for agents.
EVAC-namelist:
AGENT_TYPE: Default is 2
1 rational agents (visible doors and known doors equal)
2 known doors first, then the visible ones (like in the manual)
3 herding (choose the door that the others are using if no known doors given)
PERS-namelist: I_HERDING_TYPE=0 (default)
0: default herding (follow the default flow field if no door found)
1: keep the first choice (follow the default flow field if no door found)
2: do not move, if no door found
3: do not move, if no door found + keep the first choice
(keep the first choice: If the agent does know/see any door then it tries
to check the other agents. If it finds this way a door, then it does not
try anymore to find any other door. The other mode of operation is that
the agent constantly sees what the others are doing around and changes
its mind accordingly, if no known or visible door available.)

NOTE: The I_HERDING_TYPE affects the behaviour of other agent types than 3 (herding agents) also, when these other agent types do not find any door that they can use. Then these agetns are "lost" and they try to find some door/exit using the herding method. If you set I_HERDING_METHOD >1 then the agents that have no target door, do no move towards any door, they stand still. "stand still" means that their target velocity vector (the v0_i vector in the manual) is zero vector. If other agents pushes these "stand still" agents, they will move a little bit.

I will redirect my question here so that Timo or Gregor or anyone else can discuss or answer the question. I ask this question for long-term solution as Randy expected. The question is related to FDS Issue #8386, but not limited to that issue.

In divg.f90 Timo wrote as below
! Evacuation flow field calculation: Change the outflow vent pressure zone and initialize everything
! New exit/door flow field calculation (new outflow-vent), do the necessary initializaions,
! because same arrays are used for exits/doors at a main evacuation mesh. Each evacuation
! flow field calculation has just one exit/door, i.e., outflow vent, so the pressure zone
! is defined so that the front of the door is in the pressure zone. So, pressure zone
! is also redefined for this main evacuation mesh.
! One pressure zone is defined for each main evacuation mesh.

In brief my question is why the evac pressure zones are defined in fds6 and how they affact evacuation flow field. If I understand Timo's algorithm correctly, such pressure zones are not defined in fds5. If Randy expects that evac runs after fds as a long-term solution and Timo has supported this solution, the evacuation flow field is a critical issue to deal with in Timo's algorithm.

The probelm refers to multiple evacuation runs for the same fire/smoke scenario. When users give EVACUATION_MC_MODE=.TRUE., FED file is directly read in, not recalculated, but it turns out that 3D smoke cannot be shown in smokeview. There is no load/unload->3Dsmoke.
Current solution is given as below. However, it is not a convenient method.

https://groups.google.com/forum/?fromgroups#!searchin/fds-smv/FDS$2BEVAC$3A$20Smokeview$20visualization/fds-smv/EQqIu2mDYzs/WmZinTftrP4J

It seems that no fire/smoke data will be changed when EVACUATION_MC_MODE=.TRUE.
So why 3D smoke cannot be visualize directly?

Not sure whether the existing group model in FDS+EVAC works or not. There is no documents about it. In fact there is a new force-based model of group dynamics. Personally I think it is a better model, and it is reasonable to replace existing model with the new one.

https://groups.google.com/forum/#!msg/fds-smv/zbIIieEBzjc/NBIyLKAwBAAJ

In existing code in evac.f90:
HR%GROUP_ID < 0 -- Individual (Lonely Agent)
HR%GROUP_ID = 0 -- Agents from Entr Namelist
HR%GROUP_ID > 0 -- In Groups

After checking the code in evac.f90, I personally think that HR%GROUP_ID > 0 does not work well.