Some Qiskit gates are not supported (during the internal conversion to Cirq)

[andreamari]

Some Qiskit gates are not supported (during the internal conversion to Cirq).
It would be good to support more gates.
Since we are relying on Cirq conversion functions, a possible way to do achieve can be via up-streaming these requests to Cirq.

Gates that are currently not supported (please add more if you know more):

• sx = \sqrt{X} : up-to-a-phase equivalent to RX(pi/2)
• cu1 (see QFT circuit containing CU1 gates cannot be converted to internal mitiq circuit #558)
• PhaseGate(theta) = up-to-a-phase equivalent to RZ(theta)
• u(theta)
• ECRGate: echoed cross-resonance (ECR) gate.

[rmlarose]

• Phase gate (https://discord.com/channels/764231928676089909/773957956659052605/897658569510502441).

Logistically, I suggest closing #558 and using this issue to track to avoid duplicates.

[github-actions]

This issue had no activity for 2 months, and will be closed in one week unless there is new activity. Cheers!

[github-actions]

This issue had no activity for 4 months, and will be closed in 2 weeks unless there is new activity. Cheers!

[natestemen]

Scope of this ticket is twofold:

1. Do some investigation to figure out if the gates mentioned above are still failing (and documenting the results)
2. Adding support for failing gates

For milestone 0.25 lets complete point 1, and add support for failing gates that are straightforward to fix.

[MaldoAlberto]

I can work on this issue

[MaldoAlberto]

Hi @andreamari ! I'm working on this issue and I find Qiskit works now with OpenQASM3 and cirq with OpenQASM2, and using less gates than qiskit, so my question is convenient to do a function to converts OpenQASM3 to OpenQASM2 and include the equivalents gates, for example

cu(pi/2, pi/2, pi/2, 0) q[1], q[0];

will be

p(0) q[1];
p((pi/2 + pi/2) / 2) q[1];
p((pi/2 - pi/2) / 2) q[0];
cx q[1], q[0];
u(-pi/2 / 2, 0, -(pi/2 + pi/2) / 2) q[0];
cx q[1], q[0];
u(pi/2 / 2, pi/2, 0) q[0];

[andreamari]

Hi @MaldoAlberto,

Thanks for isolating the root of problem so well!
I am not sure about writing from scratch a QASM3<->QASM2 within Mitiq. It would be a complex piece of code to maintain which could solve this bug, but could create 100 new bugs :-)

Two less dangerous solutions are perhaps the following:

• Open some issues on Cirq or Qiskit about conversion problems. Having good Qiskit<-->Cirq conversions is in their interest and they may find good and stable solutions.
• Replace non-supported gates with equivalent supported decompositions, before converting. This is similar to what you proposed, but instead of doing it at the QASM level, it could be done at the qiskit.QuantumCircuit level.

Note that the last step is not as easy as it seems, since the pipeline of conversion layers in mitiq.interface is a bit complicated (e.g. nested decorators).

[MaldoAlberto]

Hi @MaldoAlberto,

Thanks for isolating the root of problem so well! I am not sure about writing from scratch a QASM3<->QASM2 within Mitiq. It would be a complex piece of code to maintain which could solve this bug, but could create 100 new bugs :-)

Two less dangerous solutions are perhaps the following:

• Open some issues on Cirq or Qiskit about conversion problems. Having good Qiskit<-->Cirq conversions is in their interest and they may find good and stable solutions.
• Replace non-supported gates with equivalent supported decompositions, before converting. This is similar to what you proposed, but instead of doing it at the QASM level, it could be done at the qiskit.QuantumCircuit level.

Note that the last step is not as easy as it seems, since the pipeline of conversion layers in mitiq.interface is a bit complicated (e.g. nested decorators).

That's true! I can try to do both. Additionally, I'll examine the conversion in 'qiskit.Quantum' to resolve it as soon as possible. Thank you for your suggestions.

[cosenal]

On hold until migration to Qiskit 1.0 is completed #2204 Qiskit 1.0 is now supported, this issue is ready to be worked on.

[jordandsullivan]

Let's check if the original statement of this issue is still valid for the new Qiskit 1.0 integration. If so, I suggest splitting the issue into separate ones for each gate.

[cosenal]

The original statement, as well as the rest of the discussion, still hold for Qiskit 1.0. In order to reproduce the issue, one can run a small modification of the code snippet from #558 (the modifications were to make the snippet compatible with the latest qiskit packages):

import functools

from mitiq.interface.mitiq_qiskit import initialized_depolarizing_noise
from qiskit_aer import QasmSimulator
from qiskit import QuantumRegister, ClassicalRegister, transpile
from qiskit import QuantumCircuit
from qiskit.circuit.library import QFT
from mitiq.zne import execute_with_zne


def qs_noisy_simulation(circuit: QuantumCircuit, correct_bitstring, shots: int = 1) -> float:

    noise_model = initialized_depolarizing_noise(noise_level=0.02)
    backend = QasmSimulator(noise_model=noise_model)
    # Transpile the circuit so it can be properly run
    exec_circuit = transpile(
        circuit,
        backend=backend,
        basis_gates=noise_model.basis_gates if noise_model else None,
        optimization_level=0, # Important to preserve folded gates.
    )
    # Run the circuit
    job = backend.run(exec_circuit, shots=shots)

    return job.result().get_counts().get(correct_bitstring, 0.0) / shots

q = QuantumRegister(5,'q')
c = ClassicalRegister(5,'c')

circuit = QuantumCircuit(q,c)
circuit.x(q[0])
circuit.x(q[2])
circuit.x(q[4])
circuit &= QFT(num_qubits=5, approximation_degree=0, do_swaps=True, inverse=False, insert_barriers=True, name='qft')
circuit &= QFT(num_qubits=5, approximation_degree=0, do_swaps=True, inverse=True, insert_barriers=True, name='qft')
circuit.measure(q,c)

print(circuit)

correct_bitstring = "11111"
unmitigated = qs_noisy_simulation(circuit, correct_bitstring)
# circuit = qiskit.compiler.transpile(circuit, basis_gates=["u1", "u2", "u3", "cx"])
mitigated = execute_with_zne(circuit, functools.partial(qs_noisy_simulation, correct_bitstring=correct_bitstring))

print(unmitigated)
print(mitigated)

The commented transpile statement (as suggested by @rmlarose in #558) makes it work, but it's not clear to the user that such a step is required for circuits with certain unsupported gates.

I am keeping the discussion here, and not splitting it in multiple issues, because the solution may be general and agnostic of the specific unsupported gate, e.g., @MaldoAlberto's suggestion to support a QASM3-->2 compiler would achieve that ¹.

Footnotes

1. Even though we would rather not go for that solution for the reasons mentioned by Andrea above in the discussion. ↩

[cosenal]

@nathanshammah @andreamari Do you think transpiling to a fixed set of basis gates as a fallback each time a gate is not supported could be a viable option? I know that for QEM we generally want to keep the circuit we are manipulating as close as possible to the original input circuit, but perhaps QEM on a transpiled version of the circuit is still better than no QEM whatsoever? Any thoughts?

[nathanshammah]

For me this could be a viable option, possibly with a warning and with the option to disable this compilation. We'd need to discuss the default.

[cosenal]

@nathanshammah OK, great, I will create a separate issue for the transpiling solution than.

[andreamari]

@nathanshammah @andreamari Do you think transpiling to a fixed set of basis gates as a fallback each time a gate is not supported could be a viable option? I know that for QEM we generally want to keep the circuit we are manipulating as close as possible to the original input circuit, but perhaps QEM on a transpiled version of the circuit is still better than no QEM whatsoever? Any thoughts?

Makes sense to me!
Note also that similar transpilations are already implicitly used by Mitiq in other contexts (see e.g. here).

[andreamari]

FYI: I just added the ECRGate to the list of non-supported gates in the description of this issue.
Thanks to @simonecantori for noticing this.

[gluonhiggs]

@andreamari Is there anything else I can do to fully resolve this issue as you mentioned it in #2579? Apart from addingsx, cu1, PhaseGate, u, and ECR to GATES_TO_DECOMPOSE, are there additional steps or considerations needed to ensure all unsupported gates are properly handled?

[andreamari]

Hi @gluonhiggs, thanks for your interest and help!
I think the change that you mentioned, combined with new unit tests to check that all works as expected, would be a good and useful improvement to the current situation.

The utopic ideal solution would be a faithful conversion of gates, without the need of using fallback decompositions. But we know that this is a non-trivial problem. See e.g. the old comments above in this issue.
A step in this direction is to open issues and/or PRs to Cirq in order to enable the conversion of new gates. Maybe it's just a matter of adding a couple new gates somewhere on this file, but I am not sure.

[gluonhiggs]

I have added a new PR here. I hope it can fully resolve this without the need to modify Cirq.

Hi @gluonhiggs, thanks for your interest and help! I think the change that you mentioned, combined with new unit tests to check that all works as expected, would be a good and useful improvement to the current situation.

The utopic ideal solution would be a faithful conversion of gates, without the need of using fallback decompositions. But we know that this is a non-trivial problem. See e.g. the old comments above in this issue. A step in this direction is to open issues and/or PRs to Cirq in order to enable the conversion of new gates. Maybe it's just a matter of adding a couple new gates somewhere on this file, but I am not sure.