-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Transpiler with target unrolls even if gate is natively supported #10592
Comments
I came across the same thing too, I had opened: #10568 to track it. I'm going to close this as a duplicate of it. The specific issue is basically this function: https://github.com/Qiskit/qiskit/blob/main/qiskit/transpiler/passes/optimization/optimize_1q_decomposition.py#L152-L180 isn't taking into account that the default should be to not translate the gate if the all have the same error rates (which in a simulator will be None). |
Ah thanks for bringing that up and sorry for the noise. Is that something you have on the radar internally and are working on a fix or would you appreciate a community contribution there? |
I haven't started to work on it besides identifying the root cause a few weeks ago. If you have the bandwidth to work on it that would be greatly appreciated. If you leave a comment on #10568 I can assign the issue to you. |
Environment
What is happening?
Calling
transpile
with a custom target on a circuit causes transpilation even though all gates of a circuit are in the target's list of supported operations. See the below MRE that demonstrates the issue.The underlying issue is much broader than that. Given a target that contains the
U3Gate
and any other single-qubit gate, the transpiled circuit will always contain au3
gate instead of the original gate.How can we reproduce the issue?
yields
u3
What should happen?
The
X
gate is in the list of supported instructions. As such, I would have expected no transpilation to take place and thatqc == qc_transpiled
.Interestingly, using
produces the desired result.
Any suggestions?
If the behavior above is not desired, it is at least unexpected and some clarification would be great.
If this is really a bug, I suspect that some early stopping criterion is missing somewhere.
The text was updated successfully, but these errors were encountered: