Skip to content

OD pair deduplication issues - #44

Draft
yo35 wants to merge 4 commits into
EMob-Lab:mainfrom
yo35:fix/od-pair-deduplication-issues
Draft

yo35 wants to merge 4 commits into
EMob-Lab:mainfrom
yo35:fix/od-pair-deduplication-issues

Conversation

@yo35

@yo35 yo35 commented Oct 14, 2026 •

Copy link
Copy Markdown
Contributor

3 reproducers showing issues related to the OD-pair deduplication mechanism (i.e. function find_duplicates(..) in cpp/src/shortest_path.cpp) that is used in most parallelXXX(..) functions.

Issue 1 (see testODPairDedup_issue_1_accessibleLinkLabel.cpp)

The OD ("origin-destination") pair deduplication mechanism does not consider the accessibleLinkLabels parameter.

Consequences:

  • If parallelDijkstra() is called with OD pairs that differ from each other only by their respective accessibleLinkLabels, some of them get the path computed for a set of links different from what is requested.
  • Same issue with all the other functions that use find_duplicates(), especially parallelKShortestPath().

Issue 2 (see testODPairDedup_issue_2_nodeIDConcatenation.cpp)

The OD pair deduplication mechanism identifies the OD pairs by concatenating the IDs of their origin and destination nodes.

Consequences:

  • If parallelDijkstra() is called with OD pairs whose concatenated node IDs are identical (e.g. "1" -> "23" and "12" -> "3"), some of them get the path computed for another OD pair.
  • Same issue with all the other functions that use find_duplicates(), especially parallelKShortestPath().

Issue 3 (see testODPairDedup_issue_3_kPaths.cpp)

The 3rd issue is specific to parallelKShortestPath(). In this function, OD pairs that differ from each other only by their respective kPaths parameter are computed once, with the largest kPaths. The post-process at the end of parallelKShortestPath() then keeps, for each OD pair, the kPaths paths with the lowest costs. This assumes that KShortestPath() returns the paths in order of increasing costs, which is not the case (see example in the reproducer).

Consequence: the paths returned by parallelKShortestPath() for an OD pair may depend of the other OD-pairs in the same batch, and may also be distinct from what would be returned by the non-parallel version of the same algorithm (i.e. KShortestPath()). This is less severe as issues 1 and 2, but this breaks the per-OD-pair result independence guarantee that could be expected from parallelKShortestPath().

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant