Make limit on waveform amplitude optional#6345
Conversation
2f562aa to
6940100
Compare
|
Rebase to main |
6940100 to
8c0bd9c
Compare
taalexander
left a comment
There was a problem hiding this comment.
I believe the problem with failing linting is due to the recent incorporation of Black in #6361. It should be sufficient to run the black formatter over the files touched in this PR.
|
Simple question: What happens if we send pulse with amplitude > 1. to our backend? Will it return 9999 error? |
For the openpulse backend of https://qiskit.org/textbook/ch-quantum-hardware/calibrating-qubits-pulse.html there is an error: |
b69727a to
d98f165
Compare
Thanks for highlighting this, I've created an internal ticket to add a more informative error in a future release. |
taalexander
left a comment
There was a problem hiding this comment.
:py:attr:~some_property
Co-authored-by: Thomas Alexander <thomasalexander2718@gmail.com>
|
@taalexander Added release notes to the PR. Let me know whether we need to add something more. |
taalexander
left a comment
There was a problem hiding this comment.
Thank you for additional changes, my only follow-up question is should we consider extending the limit_amplitude kwarg to the existing parametric pulse constructors?
…mit-c58e2ec61f6789e6.yaml Co-authored-by: Thomas Alexander <thomasalexander2718@gmail.com>
…mit-c58e2ec61f6789e6.yaml Co-authored-by: Thomas Alexander <thomasalexander2718@gmail.com>
…mit-c58e2ec61f6789e6.yaml Co-authored-by: Thomas Alexander <thomasalexander2718@gmail.com>
I would suggest creating a new issue/PR for this since it will be backwards incompatible. (if we follow the same convention as for the other parametric pulses, e.g. |
|
@taalexander I rebased to main. Let me know whether I should make any additional changes to the PR. |
|
Created a follow up issue #6544 for propagating |
…qiskit-terra into feat/waveform_amplitude_limit
Summary
Remove limit of waveform amplitude.
Details and comments
Fixes #6012