-
Notifications
You must be signed in to change notification settings - Fork 67
Conversation
This PR wont be mergable until qiskit 0.45 (planned for November 2nd). Ideally, this change should support qiskit 0.44 and 0.45. Some sort of big version of https://github.com/Qiskit/qiskit-ibm-provider/pull/732/files#diff-03ea62db1eae52df4e6d533f70d5511657eb4c5b1f164c04b2960f35b5491623R356-R360 is needed, i think. |
One thing you'll want to do is with regard with Qiskit/qiskit#10820 when you port it is to ensure that the provider is setting |
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.
Can we move forward with this PR now?
I think it's still blocked on the qiskit release as new QPY changes for format version 10 might merge between now and the actual release. |
The qiskit-ibm-provider package maintains a fork of the QPY serialization module from upstream qiskit. This is done primarily because Qiskit only supports writing a single qpy format version per release (whatever the most recent is). However, since the server side of the ibm runtime version does not always support the latest QPY format version immediately and tends to lag a bit behind what upstream Qiskit is emitting. The fork in qiskit-ibm-provider is used to control the QPY format version that is used for job submission so it ensure the leading edge only moves as quickly as the server side is updated. However, for the upcoming qiskit 0.45.0 release there were some internal object model changes and the fork of qpy (which is a copy of the qpy module from qiskit-terra 0.25.x/qiskit 0.44.x) is incompatible with those changes. This results in errors during the serialization because the qpy module is trying to serialize the circuit with assumptions of the code that do not hold with the upcoming 0.45.0 release. To further complicate matters qiskit 0.45.0 also introduced QPY version 10 which is completely incompatible with version 9 being used by the ibm runtime currently. This means the normal strategy of porting all the changes from qiskit during the upcoming release to the provider isn't viable in the short term, at least until the server side is updated to support QPY version 10. To address this compatibility in the short term, this commit is a partial backport of the changes made in qiskit 0.45.0 to the qpy module, but only those changes made to accomodate the internal qiskit changes during the release. It's also done in a manner where it doesn't require the 0.45.0 release, so that the provider can be used with either qiskit 0.44.x and 0.45.0. However, this is only a short term solution, once the server side is updated to support QPY we should use Qiskit#736 and release a new minor version of the provider package to just use QPY format version 10. This commit is explicitly only for the 0.7.x release series and is being proposed directly to the stable/0.7 branch. For 0.8.0 Qiskit#736 will port over the upstream changes to QPY including QPY format version 10 which is a more sustianable fix longer term. But this is blocked until the server side has support for QPY format version 10. To simplify the dependency tree, and to enable users to submit ibm runtime jobs using 0.45.0rc1 this targets solely compatibility between qiskit 0.45.0 and qiskit-ibm-provider 0.7.x. Fixes Qiskit#755
The qiskit-ibm-provider package maintains a fork of the QPY serialization module from upstream qiskit. This is done primarily because Qiskit only supports writing a single qpy format version per release (whatever the most recent is). However, since the server side of the ibm runtime version does not always support the latest QPY format version immediately and tends to lag a bit behind what upstream Qiskit is emitting. The fork in qiskit-ibm-provider is used to control the QPY format version that is used for job submission so it ensure the leading edge only moves as quickly as the server side is updated. However, for the upcoming qiskit 0.45.0 release there were some internal object model changes and the fork of qpy (which is a copy of the qpy module from qiskit-terra 0.25.x/qiskit 0.44.x) is incompatible with those changes. This results in errors during the serialization because the qpy module is trying to serialize the circuit with assumptions of the code that do not hold with the upcoming 0.45.0 release. To further complicate matters qiskit 0.45.0 also introduced QPY version 10 which is completely incompatible with version 9 being used by the ibm runtime currently. This means the normal strategy of porting all the changes from qiskit during the upcoming release to the provider isn't viable in the short term, at least until the server side is updated to support QPY version 10. To address this compatibility in the short term, this commit is a partial backport of the changes made in qiskit 0.45.0 to the qpy module, but only those changes made to accomodate the internal qiskit changes during the release. It's also done in a manner where it doesn't require the 0.45.0 release, so that the provider can be used with either qiskit 0.44.x and 0.45.0. However, this is only a short term solution, once the server side is updated to support QPY we should use #736 and release a new minor version of the provider package to just use QPY format version 10. This commit is explicitly only for the 0.7.x release series and is being proposed directly to the stable/0.7 branch. For 0.8.0 #736 will port over the upstream changes to QPY including QPY format version 10 which is a more sustianable fix longer term. But this is blocked until the server side has support for QPY format version 10. To simplify the dependency tree, and to enable users to submit ibm runtime jobs using 0.45.0rc1 this targets solely compatibility between qiskit 0.45.0 and qiskit-ibm-provider 0.7.x. Fixes #755 Co-authored-by: Kevin Tian <kevin.tian@ibm.com>
I believe all the updates are ready on the provider side. After qiskit |
The only suggestion I have is: #736 (comment) although we can do this in a follow up PR. But we'll want to make sure to add that before releasing 0.8.0. The performance gains from using symengine's native serialization will be really good for circuits that are using It should just be adding |
Pull Request Test Coverage Report for Build 7413984599
💛 - Coveralls |
The qiskit-ibm-provider package maintains a fork of the QPY serialization module from upstream qiskit. This is done primarily because Qiskit only supports writing a single qpy format version per release (whatever the most recent is). However, since the server side of the ibm runtime version does not always support the latest QPY format version immediately and tends to lag a bit behind what upstream Qiskit is emitting. The fork in qiskit-ibm-provider is used to control the QPY format version that is used for job submission so it ensure the leading edge only moves as quickly as the server side is updated. However, for the upcoming qiskit 0.45.0 release there were some internal object model changes and the fork of qpy (which is a copy of the qpy module from qiskit-terra 0.25.x/qiskit 0.44.x) is incompatible with those changes. This results in errors during the serialization because the qpy module is trying to serialize the circuit with assumptions of the code that do not hold with the upcoming 0.45.0 release. To further complicate matters qiskit 0.45.0 also introduced QPY version 10 which is completely incompatible with version 9 being used by the ibm runtime currently. This means the normal strategy of porting all the changes from qiskit during the upcoming release to the provider isn't viable in the short term, at least until the server side is updated to support QPY version 10. To address this compatibility in the short term, this commit is a partial backport of the changes made in qiskit 0.45.0 to the qpy module, but only those changes made to accomodate the internal qiskit changes during the release. It's also done in a manner where it doesn't require the 0.45.0 release, so that the provider can be used with either qiskit 0.44.x and 0.45.0. However, this is only a short term solution, once the server side is updated to support QPY we should use Qiskit#736 and release a new minor version of the provider package to just use QPY format version 10. This commit is explicitly only for the 0.7.x release series and is being proposed directly to the stable/0.7 branch. For 0.8.0 Qiskit#736 will port over the upstream changes to QPY including QPY format version 10 which is a more sustianable fix longer term. But this is blocked until the server side has support for QPY format version 10. To simplify the dependency tree, and to enable users to submit ibm runtime jobs using 0.45.0rc1 this targets solely compatibility between qiskit 0.45.0 and qiskit-ibm-provider 0.7.x. Fixes Qiskit#755 Co-authored-by: Kevin Tian <kevin.tian@ibm.com>
Summary
Credit to:
Qiskit/qiskit#10314
Qiskit/qiskit#10758
Qiskit/qiskit#10820
Qiskit/qiskit#10835
Qiskit/qiskit#10875
Qiskit/qiskit#11014
Qiskit/qiskit#10809
Qiskit/qiskit#10898
Qiskit/qiskit#10754
Qiskit/qiskit#11074
Qiskit/qiskit#11206
Qiskit/qiskit#11261
Details and comments