✨ Qiskit v2.0 Compatibility

[simon1hofmann]

Resolves #521

[burgholzer]

This is probably blocked by #429, right?

[simon1hofmann]

This is probably blocked by #429, right?

Not necessarily. The main problem is that in Qiskit v2.0, transpile does not accept the basis_gates argument with custom basis gates anymore.

From the migration guide (https://docs.quantum.ibm.com/migration-guides/qiskit-2.0): The basis_gates argument no longer accepts custom basis gates. The suggested alternative is the target argument, which can be built from scratch or through [Target.from_configuration](https://docs.quantum.ibm.com/api/qiskit/qiskit.transpiler.Target#from_configuration) such as:

from qiskit.circuit.library import XGate
from qiskit.transpiler.target import Target
 
basis_gates = ["my_x", "cx"]
custom_name_mapping = {"my_x": XGate()}
target = Target.from_configuration(
    basis_gates=basis_gates, num_qubits=2, custom_name_mapping=custom_name_mapping
)
pm = generate_preset_pass_manager(target=target)

How should we handle that on the target independent level?
target_independent = transpile(qc, basis_gates=openqasm_gates)

with:

openqasm_gates= [ "u3", "u2", "u1", "cx", "id", "u0", "u", "p", "x", "y", "z", "h", "s", "sdg", "t", "tdg", "rx", "ry", "rz", "sx", "sxdg", "cz", "cy", "swap", "ch", "ccx", "cswap", "crx", "cry", "crz", "cu1", "cp", "cu3", "csx", "cu", "rxx", "rzz", "rccx", "rc3x", "c3x", "c3sqrtx", "c4x"]

[burgholzer]

This is probably blocked by #429, right?

Not necessarily. The main problem is that in Qiskit v2.0, transpile does not accept the basis_gates argument with custom basis gates anymore.

From the migration guide (https://docs.quantum.ibm.com/migration-guides/qiskit-2.0): The basis_gates argument no longer accepts custom basis gates. The suggested alternative is the target argument, which can be built from scratch or through [Target.from_configuration](https://docs.quantum.ibm.com/api/qiskit/qiskit.transpiler.Target#from_configuration) such as:

from qiskit.circuit.library import XGate
from qiskit.transpiler.target import Target
 
basis_gates = ["my_x", "cx"]
custom_name_mapping = {"my_x": XGate()}
target = Target.from_configuration(
    basis_gates=basis_gates, num_qubits=2, custom_name_mapping=custom_name_mapping
)
pm = generate_preset_pass_manager(target=target)

How should we handle that on the target independent level? target_independent = transpile(qc, basis_gates=openqasm_gates)

with:

openqasm_gates= [ "u3", "u2", "u1", "cx", "id", "u0", "u", "p", "x", "y", "z", "h", "s", "sdg", "t", "tdg", "rx", "ry", "rz", "sx", "sxdg", "cz", "cy", "swap", "ch", "ccx", "cswap", "crx", "cry", "crz", "cu1", "cp", "cu3", "csx", "cu", "rxx", "rzz", "rccx", "rc3x", "c3x", "c3sqrtx", "c4x"]

Yeah. I saw that. But this basically means that we should be switching to defining gate sets not as lists of strings, but rather as Qiskit Target objects. And this is somewhat intertwined with the device refactor in #429.
Moving to Qiskit Targets is a reasonable thing to do and would probably fit nicely within #429.

As for the openqasm_gates: I would be heavily in favour of dropping these completely. They are an annoying artefact from the limit capabilities of OpenQASM 2.
As we now have an OpenQASM 3 output option, which should actually be the default going forward, the independent level should simply run transpile without a target.
With that, the algorithm level is just taking the circuit as is, while the independent level is applying device-independent optimisations. This is essentially how it was intended from the very beginning.