Different router are implemented. However:

Refactoring! Actually the router-class is undergoing a major refactoring ...

Floorfield Router

The floorfield-router uses floorfields to calculate the distances among the doors of the same subroom. The major difference to any other router is, that it does not need convex subrooms/rooms any longer. There is no need for adding helplines.

It fills an adjacency matrix and calculates global-shortest paths via the Floyd-Warshall algorithm.

The floorfield-router will give intermediate targets within thesubroom of each agent. It works in combination with exit strategies 8 and 9.1

3D geometries: To use it successfully in multi-storage buildings, the user must provide a geometry file, where stair-cases (or any other structur), which connects two floors/levels must be a separate room. Further, that room must only connect two levels. Rooms stretching over more than 2 levels are not valid.

If there are two points with the same ()-coordinates, which differ only in the -coordinate, the router will face problems, thus we defined the restriction above. That should avoid any such cases.

The floorfield router provides one mode: ff_global_shortest

ff_local_shortest and ff_quickest will follow shortly.

Important! If you use a router, which allows non-convex subrooms/rooms, you should use an exit-strategy, which also allows non-convex subrooms/rooms. Exit-strategies 8 and 9 will work best with the floorfield router.

Following snippet is a definition example of the routing information:

<route_choice_models>
  <router router_id="1" description="ff_global_shortest">
  <write_VTK_files>true</write_VTK_files>
  </router>

  <!-- Not yet implemented -->
  <!--router router_id="2" description="ff_local_shortest">
  </router-->
  <!-- Not yet implemented -->
  <!--router router_id="3" description="ff_quickest">
  </router-->
</route_choice_models>

Global shortest path

At the beginning of the simulation, the Dijkstra algorithm is used to build a network which is then cached and used through the simulation life time.

Detailed information about the aforementioned models are presented in: KemlohWagoum2012a

Following snippet is a definition example of the routing information:

<route_choice_models>
  <router router_id="1" description="global_shortest">
    <parameters>
      <navigation_lines file="routing.xml" />
    </parameters>
  </router>
</route_choice_models>

AI router

See this talk to get the idea

<router router_id="7" description="cognitive_map">
  <sensors>
      <sensor sensor_id="1" description="Room2Corridor"/>
      <sensor sensor_id="2" description="Smoke" status="activated"/>
  </sensors>
  <cognitive_map status="complete" />
</router>
Important! Note: In case the smoke sensor is used, `JPSfire` should be initialised before the router

For example add a JPSfire section like this:

<JPSfire>
    <A_smoke_sensor smoke_factor_grids="/path/tp//3_sfgrids/" update_time="10.0" final_time="100.0" />
</JPSfire>

See also the smoke sensor documentation in JPSfire

Updates

For current development updates, please check this issue on our GitLab Repo.

  1. If convex subrooms are provided, any exit strategy will work. In these special cases, global router will be faster in computation time.