Skip to content
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

VF2PostLayout not running in Optimization Level 1 #9936

Closed
mtreinish opened this issue Apr 10, 2023 · 3 comments · Fixed by #9941
Closed

VF2PostLayout not running in Optimization Level 1 #9936

mtreinish opened this issue Apr 10, 2023 · 3 comments · Fixed by #9941
Assignees
Labels
bug Something isn't working priority: high
Milestone

Comments

@mtreinish
Copy link
Member

Environment

  • Qiskit Terra version: 0.23.x
  • Python version: 3.10
  • Operating system: Linux

What is happening?

When running with optimization level 1 if sabre layout is used for routing and routing is needed (which is a precondition for running vf2postlayout) then the vf2postlayout pass is not being run as part of the default transpile() pipeline. The issue is because SabreLayout runs SabreSwap internally and inserts any needed swaps so the special check we run on level 1 to determine if we already had a perfect layout returns true because there are no swaps needed. Prior to integrating the sabre passes together this check which runs before routing implied that trivial layout was perfect.

How can we reproduce the issue?

Run transpile() on any circuit that needs routing. If you turn on debug logging or use a callback you won't see VF2PostLayout run. The script I was working with when I found this was:

import time

from qiskit.circuit import QuantumCircuit
from qiskit.circuit.library import QuantumVolume, ExcitationPreserving
from qiskit.qpy import dump
from qiskit.compiler import transpile
from qiskit.providers.fake_provider import FakeAuckland
from qiskit.converters import dag_to_circuit

backend = FakeAuckland()
num_qubits = 5
# Circuit creation
true_start = time.perf_counter()
qc = QuantumCircuit(num_qubits)
for i in range(num_qubits - 1):
    qc.cry(0.2 * i, 0, i + 1)
qc.append(ExcitationPreserving(num_qubits, entanglement="pairwise"), range(num_qubits))
qc.measure_all()

count = 0

def callback(**kwargs):
    global count
    pass_name = kwargs['pass_'].name()
    dag = kwargs['dag']
    circuit = dag_to_circuit(dag)
    circuit.draw('mpl', filename=f"transpiler_output/{count:03}_{pass_name}_circuit.png", idle_wires=False)
    dag.draw(filename=f"transpiler_output/{count:03}_{pass_name}_dag.png") 
    with open(f"transpiler_output/{count:03}_{pass_name}.qpy", "wb") as fd:
        dump(circuit, fd)
    count += 1

create_stop  = time.perf_counter()
# Transpile
tqc = transpile(
    qc, backend, seed_transpiler=2023, callback=callback, optimization_level=1
)
transpile_stop = time.perf_counter()

What should happen?

After we run sabre layout we should run VF2PostLayout to potentially pick lower error rate qubits to run the circuit on.

Any suggestions?

The underlying issue is that we're using CheckMap to determine whether TrivialLayout succeeded in finding a perfect layout or not. The typical workflow for level 1 should be is:

TrivialLayout -> VF2Layout -> SabreLayout -> VF2PostLayout

Where if TrivialLayout or VF2Layout find a perfect match we stop there. But if we reach sabre layout then we should run sabre and vf2 post layout. The problem is now that sabre layout runs routing internally CheckMap will always return true so we never run vf2 post layout. To fix this we should change the condition for vf2postlayout to determine if a perfect layout was found. The easiest way would be to store whether trivial layout found a perfect match on a different property set field and then we don't need to worry about check map being overloaded. But if that's not so simple another option is to use a different pass to determine whether we should run vf2postlayout or not.

@mtreinish mtreinish added bug Something isn't working priority: high labels Apr 10, 2023
@mtreinish mtreinish added this to the 0.24.0 milestone Apr 10, 2023
@jakelishman
Copy link
Member

Is this an indication that we might want to run VF2Post after routing rather than after layout?

@mtreinish
Copy link
Member Author

Oh, it does run after routing that's a requirement for vf2 post layout to work. I skipped some steps in the flow above the check map which is messing up the condition for running vf2 post layout is the first pass in the routing stage (it's used to determine if we should run the routing pass or not):

https://github.com/Qiskit/qiskit-terra/blob/main/qiskit/transpiler/preset_passmanagers/common.py#L276

The issue is that Sabre layout is doing routing now too so the expected flow is a bit confused

@jakelishman
Copy link
Member

Oh sweet - that makes more sense to me. I should have checked our actual pass managers haha.

@mtreinish mtreinish self-assigned this Apr 11, 2023
mtreinish added a commit to mtreinish/qiskit-core that referenced this issue Apr 11, 2023
This commit fixes an issue where we were incorrectly not running
VF2PostLayout in the one case where it should be run. Optimization level
1 is more involved than higher optimization levels because for backwards
compatibility it runs multiple different passes to try and find a
perfect layout, first starting with TrivialLayout, then VF2Layout, and
only if those 2 fail to find a perfect match do we run SabreLayout (or
DenseLayout and StochasticSwap if control flow are present). We only
should run VF2PostLayout if we're running the heuristic layout pass.
However, when we integrated routing into SabreLayout the checking for
whether we found a pefect layout in the layout stage stopped working as
expected.

To fix this issue a new flag is added to the CheckMap pass to specify an
alternative property set field to store the results of the check in. The
underlying issue was that the property set field between the earlier
check that we found a perfect layout and the later check whether we
should run a standalone routing pass. To fix this the new flag is used
to spearate the results from the multiple CheckMap calls. and then we
only condition the VF2PostLayout condition on the results of the perfect
layout check and not the later routing check.

Fixes Qiskit#9936
mtreinish added a commit to mtreinish/qiskit-core that referenced this issue Apr 11, 2023
This commit fixes an issue where we were incorrectly not running
VF2PostLayout in the one case where it should be run. Optimization level
1 is more involved than higher optimization levels because for backwards
compatibility it runs multiple different passes to try and find a
perfect layout, first starting with TrivialLayout, then VF2Layout, and
only if those 2 fail to find a perfect match do we run SabreLayout (or
DenseLayout and StochasticSwap if control flow are present). We only
should run VF2PostLayout if we're running the heuristic layout pass.
However, when we integrated routing into SabreLayout the checking for
whether we found a pefect layout in the layout stage stopped working as
expected.

To fix this issue a new flag is added to the CheckMap pass to specify an
alternative property set field to store the results of the check in. The
underlying issue was that the property set field between the earlier
check that we found a perfect layout and the later check whether we
should run a standalone routing pass. To fix this the new flag is used
to spearate the results from the multiple CheckMap calls. and then we
only condition the VF2PostLayout condition on the results of the perfect
layout check and not the later routing check.

Fixes Qiskit#9936
giacomoRanieri pushed a commit to giacomoRanieri/qiskit-terra that referenced this issue Apr 16, 2023
…it#9941)

* Ensure we run VF2PostLayout when needed in optimization level 1

This commit fixes an issue where we were incorrectly not running
VF2PostLayout in the one case where it should be run. Optimization level
1 is more involved than higher optimization levels because for backwards
compatibility it runs multiple different passes to try and find a
perfect layout, first starting with TrivialLayout, then VF2Layout, and
only if those 2 fail to find a perfect match do we run SabreLayout (or
DenseLayout and StochasticSwap if control flow are present). We only
should run VF2PostLayout if we're running the heuristic layout pass.
However, when we integrated routing into SabreLayout the checking for
whether we found a pefect layout in the layout stage stopped working as
expected.

To fix this issue a new flag is added to the CheckMap pass to specify an
alternative property set field to store the results of the check in. The
underlying issue was that the property set field between the earlier
check that we found a perfect layout and the later check whether we
should run a standalone routing pass. To fix this the new flag is used
to spearate the results from the multiple CheckMap calls. and then we
only condition the VF2PostLayout condition on the results of the perfect
layout check and not the later routing check.

Fixes Qiskit#9936

* Fix remove out of date comments
king-p3nguin pushed a commit to king-p3nguin/qiskit-terra that referenced this issue May 22, 2023
…it#9941)

* Ensure we run VF2PostLayout when needed in optimization level 1

This commit fixes an issue where we were incorrectly not running
VF2PostLayout in the one case where it should be run. Optimization level
1 is more involved than higher optimization levels because for backwards
compatibility it runs multiple different passes to try and find a
perfect layout, first starting with TrivialLayout, then VF2Layout, and
only if those 2 fail to find a perfect match do we run SabreLayout (or
DenseLayout and StochasticSwap if control flow are present). We only
should run VF2PostLayout if we're running the heuristic layout pass.
However, when we integrated routing into SabreLayout the checking for
whether we found a pefect layout in the layout stage stopped working as
expected.

To fix this issue a new flag is added to the CheckMap pass to specify an
alternative property set field to store the results of the check in. The
underlying issue was that the property set field between the earlier
check that we found a perfect layout and the later check whether we
should run a standalone routing pass. To fix this the new flag is used
to spearate the results from the multiple CheckMap calls. and then we
only condition the VF2PostLayout condition on the results of the perfect
layout check and not the later routing check.

Fixes Qiskit#9936

* Fix remove out of date comments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working priority: high
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants