You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There definitely is a bug in Qiskit here somewhere, but it's not in TranspileLayout - it happens before that, somewhere in the Rust-only version of SabreLayout. I suspect that it's because the Rust version of Sabre only gets told about 4 qubits (because of the coupling map).
We can fix that, but to get you moving: I suspect your test is actually typoed, and you meant for the coupling map to have 5 qubits, like Manila does? If so, you might find:
As it happens, this is a bug in SabreLayout's handling of disjoint coupling maps, and it's been around for just under two years. The fact that there's a disjoint coupling map in the test case is, I think, just a typo in the test case as mentioned above: you start with a 5q backend, then reduce its connectivity to 4q (using a mix of tight [Target] and loose [coupling_map] constraints that please bear in mind will be invalid in Qiskit 2), but it's still a 5q backend. So there's now an isolated qubit, so the coupling map is disjoint, and we get the bug.
The reason this seemed to appear in Qiskit 1.3 is because of a (correct) bug fix in how transpile and generate_preset_pass_manager handled the loose constraints used by this method. Before #13394, those methods incorrectly threw away the Target in the backend and used only the loose constraints to generate the pseudo-Target, which means that in Qiskit 1.2, your test case comes out compiled to a 4q backend which isn't actually compatible with the Manila-except-with-4q-linear-connectivity backend that your test case attempts to construct. So prior to Qiskit 1.3 your test also hit a Qiskit bug, just in a way that didn't affect your assertion. Qiskit 1.3 corrected that, which meant you hit another, which does affect you.
#13833 fixes this, and the output is now (as of this commit, might change in the future due to randomisation) [2, 0, 1, 3, 4] - correctly using 5q.
Environment
What is happening?
On certain circuits transpiled with a backend and a coupling map, this call fails
raising
KeyError: "The item Qubit(QuantumRegister(5, 'q'), 3) does not exist in the Layout"
.This worked fine until qiskit 1.3.0
How can we reproduce the issue?
Running the following code:
What should happen?
There should not be any error in the call. The output to that particular example in
qiskit 1.2.4
is[3, 1, 2, 0]
Any suggestions?
No response
The text was updated successfully, but these errors were encountered: