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
In some circumstances after #9840 when targeting backends with disjoint coupling maps if there is a barrier spanning multiple connected components on the target backend the SabreLayout pass will raise an error: DAGCircuitError: 'Replacing the specified node block would introduce a cycle'. This is caused by the pass attempting to recombine the barriers after re-assembling the combined circuit after splitting it to solve the layout and routing for the circuit, the cycle check was left on to catch this exact case where combining the barriers on re-assembly would result in an invalid dag.
The transpile() call should not error. The root cause is the barrier spanning across the connected components would result in a cycle in the dag.
Any suggestions?
I was worried about this #9840 but I don't have a good solution. The first thought is on encountering a cycle we keep the dag split and just drop the UUID label which doesn't seem great. My bigger concern is that this means doing routing on the split dags is not valid and we need to apply the layout first and then run routing on the full circuit to be able to reliably do it. This has a performance overhead, but would only apply if the number of connected components > 1 so it might be worth it. We already take this hit if there is any classical data shared between components in the circuit so it might just be worth it to expand https://github.com/Qiskit/qiskit-terra/blob/33704ea61f6a3fa60612cbe4463894d2859fe9ec/qiskit/transpiler/passes/layout/sabre_layout.py to be for all circuits with > 1 connected component.
The text was updated successfully, but these errors were encountered:
This commit fixes an issue in the `SabreLayout` pass when run on
backends with a disjoint connectivity graph. The `SabreLayout`
pass internally runs routing as part of its operation and as a
performance efficiency we use that routing output by default. However,
in the case of a disjoint coupling map we are splitting the circuit up
into different subcircuits to map that to the connected components on
the backend. Doing final routing as part of that split context is no
sound because depsite the quantum operations being isolated to each
component, other operations could have a dependency between the
components. This was previously discovered during the development
of Qiskit#9802 to be the case with classical data/bits, but since merging
that it also has come up with barriers. To prevent any issues in the
future this commit changes the SabreLayout pass to never use the routing
output during the layout search when there is >1 connected component
because we *need* to rerun routing on the full circuit after applying
the layout.
FixesQiskit#9995
* Don't run routing in SabreLayout with split components
This commit fixes an issue in the `SabreLayout` pass when run on
backends with a disjoint connectivity graph. The `SabreLayout`
pass internally runs routing as part of its operation and as a
performance efficiency we use that routing output by default. However,
in the case of a disjoint coupling map we are splitting the circuit up
into different subcircuits to map that to the connected components on
the backend. Doing final routing as part of that split context is no
sound because depsite the quantum operations being isolated to each
component, other operations could have a dependency between the
components. This was previously discovered during the development
of Qiskit#9802 to be the case with classical data/bits, but since merging
that it also has come up with barriers. To prevent any issues in the
future this commit changes the SabreLayout pass to never use the routing
output during the layout search when there is >1 connected component
because we *need* to rerun routing on the full circuit after applying
the layout.
FixesQiskit#9995
* Remove unused shared_clbits logic
* Remove swap and routing assertions from disjoint sabre layout tests
* Fix lint
Environment
What is happening?
In some circumstances after #9840 when targeting backends with disjoint coupling maps if there is a barrier spanning multiple connected components on the target backend the
SabreLayout
pass will raise an error:DAGCircuitError: 'Replacing the specified node block would introduce a cycle'
. This is caused by the pass attempting to recombine the barriers after re-assembling the combined circuit after splitting it to solve the layout and routing for the circuit, the cycle check was left on to catch this exact case where combining the barriers on re-assembly would result in an invalid dag.How can we reproduce the issue?
What should happen?
The
transpile()
call should not error. The root cause is the barrier spanning across the connected components would result in a cycle in the dag.Any suggestions?
I was worried about this #9840 but I don't have a good solution. The first thought is on encountering a cycle we keep the dag split and just drop the UUID label which doesn't seem great. My bigger concern is that this means doing routing on the split dags is not valid and we need to apply the layout first and then run routing on the full circuit to be able to reliably do it. This has a performance overhead, but would only apply if the number of connected components > 1 so it might be worth it. We already take this hit if there is any classical data shared between components in the circuit so it might just be worth it to expand https://github.com/Qiskit/qiskit-terra/blob/33704ea61f6a3fa60612cbe4463894d2859fe9ec/qiskit/transpiler/passes/layout/sabre_layout.py to be for all circuits with > 1 connected component.
The text was updated successfully, but these errors were encountered: