Qiskit
An user should have an easy way to verify a circuit is compatible with a target backend
What is the expected feature or enhancement?
If I am given a circuit, I would like an easy way to verify if it is, or is not, compatible with a given backend.
Tket has such functionality: https://tket.quantinuum.com/api-docs/backends.html#pytket.backends.Backend.valid_circuit and it would be nice to include it here as well.
Acceptance criteria There is an easy way to verify a circuit will run on a target backend.
@1ucian0 do you agree that this should be in Qiskit? Given Target lives in Qiskit, and this could apply to non-IBM target backend as well.
yeap, I agree
On Tue, Jul 30, 2024, 11:33 PM Jessie Yu @.***> wrote:
@1ucian0 https://github.com/1ucian0 do you agree that this should be in Qiskit? Given Target lives in Qiskit, and this could apply to non-IBM target backend as well.
— Reply to this email directly, view it on GitHub https://github.com/Qiskit/qiskit/issues/12916, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAF3FZKP6TJUR2SEMFRZG3LZPABA7AVCNFSM6AAAAABLKVT6E2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJZGI2DSMJXGY . You are receiving this because you were mentioned.Message ID: @.***>
Is there already an issue in qiskit tracking this? I'd like to add some information.
First, FYI @nonhermitian the function https://github.com/Qiskit/qiskit-ibm-runtime/blob/3a9b08ed422e0de52981275537340c0a2af7a75b/qiskit_ibm_runtime/utils/utils.py#L78 I believe this is what you're looking for.
Note that currently the function is suspected to contain a bug, tracked in Qiskit/qiskit-ibm-runtime#1843.
Second, when the function is written in qiskit, I recommend not to write from scratch but to copy from qiskit-ibm-runtime. Although it looks easy, as you see it's not entirely trivial (we've spotted at least two bugs since its first version), so it will be a pity to repeat the same mistakes again in qiskit.
It is a bit confusing calling it an isa check. I don't think the underlying topology is part of the isa.
The documentation related to ISA from the beginning has always included connectivity, see for example https://www.ibm.com/quantum/blog/isa-circuits and https://docs.quantum.ibm.com/guides/get-started-with-primitives.
Huh, did not know that. The implication is that every Eagle has a different ISA.
I'll take a look into this. I'm assuming we could evaluate the instructions present in the circuit, as well as the parameters bound to them, with the Target's instruction_supported method.
This is what's done in qiskit-ibm-runtime, you can copy from there (up to a potential bug).
Fwiw, we have the GatesInBasis transpiler pass, which is most of the logic of the ask here already:
from qiskit.transpiler.passes import GatesInBasis
def is_supported(circuit, target):
pass_ = GatesInBasis(target=target)
pass_(circuit)
return pass_.property_set["all_gates_in_basis"]
(or something like that). Maybe the next step of discussion is whether this can be done purely by documentation, or if there should be a helper function, and if so, what its API should be.
Yeah, if the input is a Target we check things precisely. It also handles control-flow ops, etc.
@jake-lishman I'm not familiar with the DAG representation that the pass is using. In qiskit-ibm-runtime we skip instructions with calibrations: https://github.com/Qiskit/qiskit-ibm-runtime/blob/157233c731433067f6e2860b7795d8fd14efcf0d/qiskit_ibm_runtime/utils/utils.py#L63.
Will the pass do something equivalent?
Looking at it now, that pass doesn't check calibrations. I'm not entirely familiar with the calibration-level workflows (so maybe there's a reason), but that does feel slightly awkward to me that it doesn't.