-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix tracking of routing permutation in Sabre with disjoint backends #13833
Conversation
If the backing coupling graph is disjoint, and unused components of the coupling graph would not be considered when constructing the complete routing permutation. In practice, Sabre aborts immediately after layout without attempting to route, if it needed to split the DAG across more than one disjoint component, because it can't guarantee correctness of the final routing in the presence of component-spanning barriers or classical communication, so the only way for a component to be forgotten is if the backend is disjoint, but the DAG fits into a single component.
One or more of the following people are relevant to this code:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!! Thanks @jakelishman for diving right into the rabbit hole!
qc.cx(2, 0) | ||
|
||
disjoint = CouplingMap([(0, 1), (1, 2), (3, 4), (4, 5)]) | ||
layout_routing_pass = SabreLayout(disjoint, seed=2025_02_12, swap_trials=1, layout_trials=1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very precise seed
…13833) If the backing coupling graph is disjoint, and unused components of the coupling graph would not be considered when constructing the complete routing permutation. In practice, Sabre aborts immediately after layout without attempting to route, if it needed to split the DAG across more than one disjoint component, because it can't guarantee correctness of the final routing in the presence of component-spanning barriers or classical communication, so the only way for a component to be forgotten is if the backend is disjoint, but the DAG fits into a single component.
Hmm I removed the PR from the queue because I saw the failed neko test in the merge CI run, but I don't think it's related to this PR. I think it's related to changes in qiskit-aer. |
…13833) If the backing coupling graph is disjoint, and unused components of the coupling graph would not be considered when constructing the complete routing permutation. In practice, Sabre aborts immediately after layout without attempting to route, if it needed to split the DAG across more than one disjoint component, because it can't guarantee correctness of the final routing in the presence of component-spanning barriers or classical communication, so the only way for a component to be forgotten is if the backend is disjoint, but the DAG fits into a single component. (cherry picked from commit b933179)
…13833) (#13835) If the backing coupling graph is disjoint, and unused components of the coupling graph would not be considered when constructing the complete routing permutation. In practice, Sabre aborts immediately after layout without attempting to route, if it needed to split the DAG across more than one disjoint component, because it can't guarantee correctness of the final routing in the presence of component-spanning barriers or classical communication, so the only way for a component to be forgotten is if the backend is disjoint, but the DAG fits into a single component. (cherry picked from commit b933179) Co-authored-by: Jake Lishman <[email protected]>
Summary
If the backing coupling graph is disjoint, and unused components of the coupling graph would not be considered when constructing the complete routing permutation. In practice, Sabre aborts immediately after layout without attempting to route, if it needed to split the DAG across more than one disjoint component, because it can't guarantee correctness of the final routing in the presence of component-spanning barriers or classical communication, so the only way for a component to be forgotten is if the backend is disjoint, but the DAG fits into a single component.
Details and comments
Fix #13732, though there's a whole cornucopia of bugs split between very old versions of Qiskit, this commit's parent, and the example in the issue itself that lead from that issue seeing a regression in Qiskit 1.3 to this one.
In actuality, this bug has been around since the disjoint-coupling handling was first added in #9802 (qiskit-terra 0.24), and the test case in this PR would fail that version too (the fact that
TranspileLayout.initial_index_layout
wasn't added til later notwithstanding - the first assertion fails).