-
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
Add ESP readout support to Qiskit #6543
Conversation
I'm not clear why this needed to be merged into terra at all. It's an ibm backend only option right? Why isn't this just exposed as an option from the ibmq provider backend? It should be passed through the kwargs for the run command (and execute() by extension) if it's exposed through the options interface correctly. Also we shouldn't be updating the schemas here anymore. They're deprecated and frozen slated for removal soon (see #6558 ) |
Agreed, this is a backend-only option. Unfortunately, the provider is calling out to
Ok, these changes are just a mirror of Qiskit/ibm-quantum-schemas#10. We will not make further updates to these schemas. |
Sure, I agree that we should copy the assembler and from qiskit.compiler import assemble
from qiskit import QuantumCircuit
import qiskit
print(qiskit.__version__)
qc = QuantumCircuit(2)
qc.h(0)
qc.cx(0, 1)
qc.measure_all()
print(assemble(qc, use_measure_esp=True)) with the current release of qiskit-terra and it returns:
So all this is doing in practice is raising an exception at |
The changes made in Qiskit#6543 were unecessary and add ibm backend specific options to common interfaces in terra. This commit reverts Qiskit#6543 so it can be isolated to just the ibmq provider as the new options added in it are not common to all providers and isolated to just ibm backends. The changes made in Qiskit#6543 should have been done directly in the ibm provider and no changes to terra are actually needed here. Terra already provides all the functionality to enable the provider to add custom options like this. A provider can advertise the new run time option via the backend's `Options` object, expose the backend configuration option as a custom attribute at construction time, and pass the setting from the options to assemble so it gets set in the qobj config appropriately without requiring any changes from terra. However, this isn't all necessarily clear as the interface for `BackendV1` was primarily inherited from `BaseBackend` which didn't have this level of flexibility and doesn't make the distinction between required, optional, and custom options and backend attributes super clear. This is something we can hopefully address in the next version of the backend interface `BackendV2` (ideas for this are being collected in Qiskit#5885). This reverts commit 6d605a0.
One thing I will say is it was far easier to debug and test from assemble than the provider. |
This can be revoked in favor of Qiskit/qiskit-ibmq-provider#952. |
The changes made in #6543 were unecessary and add ibm backend specific options to common interfaces in terra. This commit reverts #6543 so it can be isolated to just the ibmq provider as the new options added in it are not common to all providers and isolated to just ibm backends. The changes made in #6543 should have been done directly in the ibm provider and no changes to terra are actually needed here. Terra already provides all the functionality to enable the provider to add custom options like this. A provider can advertise the new run time option via the backend's `Options` object, expose the backend configuration option as a custom attribute at construction time, and pass the setting from the options to assemble so it gets set in the qobj config appropriately without requiring any changes from terra. However, this isn't all necessarily clear as the interface for `BackendV1` was primarily inherited from `BaseBackend` which didn't have this level of flexibility and doesn't make the distinction between required, optional, and custom options and backend attributes super clear. This is something we can hopefully address in the next version of the backend interface `BackendV2` (ideas for this are being collected in #5885). This reverts commit 6d605a0. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Summary
Adds flag
use_measure_esp
toassemble
, which sets the final measurement in a circuit to use Excited State Promoted (ESP) readout. See https://arxiv.org/pdf/2008.08571.pdf for reference.A backend configuration flag
measure_esp_enabled
is included. The ESP feature can only be used ifmeasure_esp_enabled=True
.