Remove pulse support in QPY in 2.0#13814
Conversation
Pull Request Test Coverage Report for Build 13522069571Details
💛 - Coveralls |
|
One or more of the following people are relevant to this code:
|
raynelfss
left a comment
There was a problem hiding this comment.
Just a typo I found :)
Co-authored-by: Raynel Sanchez <87539502+raynelfss@users.noreply.github.com>
|
One or more of the following people are relevant to this code:
|
|
One or more of the following people are relevant to this code:
|
mtreinish
left a comment
There was a problem hiding this comment.
Overall this looks good. I left a few comments and suggestions inline, but nothing major.
I was confused at first by the changes in the binary_io/schedules.py flle because I skipped over the module docs. But it's clear now that it's basically a bunch of seek() methods now. It's obvious now they're needed because the size to read for the pulse parts isn't known ahead of time, so this is needed to skip the pulse portion of a pulse gates circuit payload.
|
Thanks for the review @mtreinish, all comments have been addressed. |
mtreinish
left a comment
There was a problem hiding this comment.
This LGTM, I had two small inline comments but nothing worth blocking over. Mostly my idle musings and one extra space in a docstring. Thanks for doing this and the quick updates.
Summary
This PR removes support for saving
ScheduleBlockprograms inqpy.dump. It also includes support for loading payloads withScheduleBlocks or pulse gates while ignoring the actual pulse information, returning partially specified circuits.Part of #13662
Details and comments
Some details to note and give feedback on:
ScheduleBlockprogram viaqpy.loadresults with aQuantumCircuitobject containing only the name and possibly metadata of thatScheduleBlock. Loading aQuantumCircuitpayload with pulse gates leads to getting circuit object with undefined custom instructions (representing pulse gates without calibrations). In both cases warnings of typeQPYLoadingDeprecatedFeatureWarningare being issued. Is this the type of warning we want to use here? Maybe we should add something likeQPYLoadingRemovedFeatureWarningand update the Compatibility section in the QPY doc page accordingly?loadcontinues to work (since it still includes code for reading calibrations, for graceful backward compatibility).Open Tasks:
test/qpy_compat