-
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
Fix delay padding to respect target's constraints #10007
Conversation
Thank you for opening a new pull request. Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient. While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone. One or more of the the following people are requested to review this:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is an urgent PR, so please feel free to add commits directly if necessary. @nkanazawa1989 @mtreinish
@@ -138,7 +138,8 @@ def run(self, dag): | |||
for bit in node.qargs: | |||
delta = t0 - idle_before[bit] | |||
if delta > 0: | |||
new_dag.apply_operation_front(Delay(delta, time_unit), [bit], []) | |||
if self.target is None or (bit_indices[bit],) in self.target.get("delay", []): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have a better way to check if an instruction is supported in a target? @mtreinish
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you can use this method.
https://github.com/Qiskit/qiskit-terra/blob/908adb34323682cf48a8bbc711d01f651dd26932/qiskit/transpiler/target.py#L568-L573
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Umm, it may not work for a target that does not support only the delay instruction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is the instruction_supported
method you can use to do this lookup: https://qiskit.org/documentation/stubs/qiskit.transpiler.Target.instruction_supported.html#qiskit.transpiler.Target.instruction_supported it should handle all the edge cases around doing the lookup correctly
Pull Request Test Coverage Report for Build 4772053053
💛 - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall this looks great, thanks for fixing this! The approach you're doing here looks to be the best way to handle this. I left 2 comments inline, neither is really a blocker, just questions more than anything.
As a procedural point, this technically is adding a new argument to the PadDelay
, PadDynamicalDecoupling
and BasePadding
classes which normally would not be eligible for backporting for a stable release. But for 0.24.0 #9993 was identified as an issue where the transpiler is producing incorrect output circuits with real hardware when using the scheduling_method
and we need to pass the Target
to the padding passes to fix this. So since we're still in the rc period I think it's ok to backport this for the 0.24.0 release as an exception to fix the high priority bug.
if self.target is None or self.target.instruction_supported( | ||
"delay", qargs=(bit_indices[bit],) | ||
): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I started to look it this after opening #9993 I was thinking here we'd need to also handle the gates in DD sequences here besides just delays. But I think as a first step and fixing what we support in transpile()
this enough. Maybe for the DD padding pass we do the additional validation of the extra sequence instructions inside the pass (as a second follow-ups PR)?
t_end=circuit_duration, | ||
next_node=node, | ||
prev_node=prev_node, | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think we should log a message to indicate to users why we're not putting a delay on the the qubit (maybe DEBUG level)? I'm not sure it's needed but I'm wondering if it'll be confusing for users of the scheduling passes if they ask for scheduling and there are qubits without delays?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for the quick updates. It'll be really good to have this fixed for 0.24.0
* Add and update tests * Fix padding passes to respect target's constraints * Fix transpile with scheduling to respect target's constraints * Add release note * fix reno * use target.instruction_supported * simplify * Add check if all DD gates are supported on each qubit * Add logging * Update DD tests * Make DD gates check target-aware * Fix legacy DD pass (cherry picked from commit 117d188)
* Add and update tests * Fix padding passes to respect target's constraints * Fix transpile with scheduling to respect target's constraints * Add release note * fix reno * use target.instruction_supported * simplify * Add check if all DD gates are supported on each qubit * Add logging * Update DD tests * Make DD gates check target-aware * Fix legacy DD pass (cherry picked from commit 117d188) Co-authored-by: Toshinari Itoko <[email protected]>
* Add and update tests * Fix padding passes to respect target's constraints * Fix transpile with scheduling to respect target's constraints * Add release note * fix reno * use target.instruction_supported * simplify * Add check if all DD gates are supported on each qubit * Add logging * Update DD tests * Make DD gates check target-aware * Fix legacy DD pass
Summary
Fixes delay padding in
transpile()
function and tranpiler passes to respect target's constraints.Details and comments
PadDelay
andPadDynamicalDecoupling
are fixed so that they do not pad any idle time of qubits for which thetarget
does not supportDelay
instruction. For that, the parentBasePadding
as well asPadDelay
is updated so that it optionally takestarget
argument. Legacy scheduling passesASAPSchedule
andALAPSchedule
, which pad delays internally, are also fixed in the same way. In addition,transpile()
is fixed to callPadDelay
with atarget
object so that it works correctly when called withscheduling_method
option.Fixes #9993