Context
We are using fdsvismap 0.1.3 to pre-compute visibility maps for a fire evacuation routing model (T-corridor scenario, 300 s FDS run, 3 waypoints). Two issues came up when interpreting the diagnostic plots.
Issue 1 — Coverage map uses logical AND over all time steps (too strict)
Current behaviour
create_time_agg_wp_agg_vismap_plot aggregates with:
self.time_agg_wp_agg_vismap = np.logical_and.reduce(self.all_time_wp_agg_vismap_list)
A cell appears green only if it can see at least one waypoint at every time step. In any realistic fire scenario smoke eventually fills the domain, so virtually every cell ends up red — even cells that have clear sign visibility during the critical early evacuation window. The map becomes uninformative.
Suggested fix
- Change to logical OR (or make it configurable via a parameter): a cell is green if it can see any sign at any time step. This answers the practically useful question: "does this agent position ever have sign coverage?"
- Add a
t_max parameter to both the aggregation and the plot method, e.g.:
create_time_agg_wp_agg_vismap_plot(t_max=120)
Concrete example
300 s FDS run, smoke fills a T-corridor by t ≈ 60 s. With AND, the entire corridor is red at t > 60 s and the map shows almost nothing. With OR (or t_max=60), the map correctly shows which corridor zones had sign coverage during the window that matters for routing decisions.
Issue 2 — ASET map has misleading blue spots at sign locations
Current behaviour
create_aset_map_plot shows the time at which each cell first loses visibility to any sign. Cells immediately adjacent to a sign location always appear blue (latest visibility loss), even when those cells are in the densest smoke region (e.g., next to a fire source).
Why it happens
A cell at distance ≈ 0 from a sign always satisfies the Beer-Lambert condition c / K > distance, so it never "loses" visibility regardless of local smoke density. This is geometrically correct but physically misleading: it suggests that the area right next to the sign has the best visibility, when in reality it may be the most dangerous location in the scenario.
Suggested fix
Exclude cells within one grid cell of a waypoint position from the ASET colormap (or mark them with a distinct symbol/hatch), so the gradient in the surrounding area is not visually dominated by the proximity artifact. Alternatively, document this behaviour prominently in the docstring.
Context
We are using fdsvismap 0.1.3 to pre-compute visibility maps for a fire evacuation routing model (T-corridor scenario, 300 s FDS run, 3 waypoints). Two issues came up when interpreting the diagnostic plots.
Issue 1 — Coverage map uses logical AND over all time steps (too strict)
Current behaviour
create_time_agg_wp_agg_vismap_plotaggregates with:A cell appears green only if it can see at least one waypoint at every time step. In any realistic fire scenario smoke eventually fills the domain, so virtually every cell ends up red — even cells that have clear sign visibility during the critical early evacuation window. The map becomes uninformative.
Suggested fix
t_maxparameter to both the aggregation and the plot method, e.g.:Concrete example
300 s FDS run, smoke fills a T-corridor by t ≈ 60 s. With AND, the entire corridor is red at t > 60 s and the map shows almost nothing. With OR (or
t_max=60), the map correctly shows which corridor zones had sign coverage during the window that matters for routing decisions.Issue 2 — ASET map has misleading blue spots at sign locations
Current behaviour
create_aset_map_plotshows the time at which each cell first loses visibility to any sign. Cells immediately adjacent to a sign location always appear blue (latest visibility loss), even when those cells are in the densest smoke region (e.g., next to a fire source).Why it happens
A cell at distance ≈ 0 from a sign always satisfies the Beer-Lambert condition
c / K > distance, so it never "loses" visibility regardless of local smoke density. This is geometrically correct but physically misleading: it suggests that the area right next to the sign has the best visibility, when in reality it may be the most dangerous location in the scenario.Suggested fix
Exclude cells within one grid cell of a waypoint position from the ASET colormap (or mark them with a distinct symbol/hatch), so the gradient in the surrounding area is not visually dominated by the proximity artifact. Alternatively, document this behaviour prominently in the docstring.