-
Notifications
You must be signed in to change notification settings - Fork 157
Consolidate two similar pages (get-qpu-information and qpu-information) #4313
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
base: main
Are you sure you want to change the base?
Conversation
|
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
jyu00
left a comment
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.
Sorry if I reviewed too early... didn't realize it's still in draft!
| " <IBMBackend('ibm_brisbane')>,\n", | ||
| " <IBMBackend('ibm_fez')>,\n", | ||
| " <IBMBackend('ibm_torino')>,\n", | ||
| " <IBMBackend('ibm_marrakesh')>,\n", |
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 can't comment on the specific line, but the schemas linked in
Use these keyword arguments to filter by any attribute in backend configuration (JSON schema) or status (JSON schema).
are no longer valid. You can link to the runtime API instead - BackendConfiguration and BackendStatus
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 actually can't parse that sentence! Can you tell me if this is an accurate rewrite? @jyu00
These JSON schemas list the keyword arguments to use when filtering by attribute.
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 we can just link those in the first sentence, since the code example already uses attributes from backend configuration (simulator=False) and status (operational=True).
Filter backends
You can also filter the available backends by their configuration or status. For more general filters, set thefiltersargument to a function that accepts a backend object and returnsTrueif it meets your criteria. Refer to the API documentation for more details.The following code returns only backends that fit these criteria and are available to you on your currently selected instance:
...
A similar method is QiskitRuntimeService.least_busy() ...
| "### Details section\n", | ||
| "\n", |
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.
All of these fields (with the exception of region) is also available in backend properties. This is why we wanted to merge these 2 pages together, since this is duplicate information.
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.
Right - so do you want me to add to each field the code to get it programmatically (some of it is in the first half of the page)? Or just state more clearly in the Platform section of this page, that you can also use Qiskit to find all of these?
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.
Perhaps this page can be organized so that each section first introduces the data, then explain how to get that data from Qiskit / IQP. It'd be nice if we can have clickable tabs to show Qiskit vs IQP.
For example, we can have these sections
- Static QPU information
- Dynamic QPU information
- List and filter backends
And Static QPU information can say
Static QPU information
Some information about a backend does not change regularly, such as its name, version, the number of qubits it has, and the types of features it supports.
Native gates and operations
Each processor family has a native gate set. By default, the QPUs in each family only support running the gates and operations in the native gate set. Thus, every gate in the circuit must be translated (by the transpiler) to the elements of this set.
View with Qiskit | View on IQP (these are clickable tabs)
QPU versioning
...
And for the Dynamic QPU information section it'd just list out the attributes such as T1, T2, 2Q error, etc. Then clickable tabs to show how to find that data via Qiskit and IQP.
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.
@jyu00 should I remove the headers "Qubit properties" and "Instruction properties", and just put them all together under Dynamic QPU info?
| "\n", | ||
| "### QPU versioning\n", | ||
| "\n", | ||
| "Each QPU has a version number in the form X.Y.Z (major.minor.revision). A circuit compiled for a given version number is guaranteed to run on that QPU. If the revision number changes, the circuit will continue to run. If the major or minor number changes, the circuit is not guaranteed to run, although it may do so.\n", |
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.
A circuit compiled for a given version number is guaranteed to run on that QPU
I don't know if this statement is really true. For example, I'm not sure if the version number changed when we toggled dynamic circuits support. I'll ask in Jan when people are back.
| "Each [processor family](/docs/guides/processor-types) has a native gate set. By default, the QPUs in each family only support running the gates and operations in the native gate set. Thus, every gate in the circuit must be translated (by the transpiler) to the elements of this set.\n", | ||
| "\n", | ||
| "You can view the native gates and supported instructions, including non-gate-type instructions, for a QPU with Qiskit. The IBM Quantum Platform Compute resources page lists the basis gates for a QPU.\n", |
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.
Personally I dislike the use of native gate set to also include non-gate-type operations. I think we should just say supported instructions to match the Qiskit method. Here's my suggestion
Every processor family natively supports a limited set of instructions. This set includes single- and two-qubit gates, as well as non-unitary operations such as
measureandreset. Every gate in the circuit must be translated (by the transpiler) to the elements of a QPU's supported instruction set before it can run on the QPU.You can view the supported instruction sets for a QPU with Qiskit. The IBM Quantum Platform Compute resources page lists only the supported unitary gates (basis gates) for a QPU.
In addition, this page should be updated to use the same wording. The use of basis gates there is different from the basis gates on IQP 😅
| " from qiskit_ibm_runtime import QiskitRuntimeService\n", | ||
| "\n", | ||
| " service = QiskitRuntimeService()\n", | ||
| "\n", | ||
| " for backend in service.backends():\n", | ||
| " config = backend.configuration()\n", | ||
| " if \"simulator\" in config.backend_name:\n", | ||
| " continue\n", | ||
| " print(f\"Backend: {config.backend_name}\")\n", | ||
| " print(f\" Processor type: {config.processor_type}\")\n", | ||
| " print(f\" Supported instructions:\")\n", | ||
| " for instruction in config.supported_instructions:\n", | ||
| " print(f\" {instruction}\")\n", | ||
| " print()\n", | ||
| " ```\n", |
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.
This code block should be simplified to
from qiskit_ibm_runtime import QiskitRuntimeService
service = QiskitRuntimeService()
backend = service.backend("ibm_fez")
print(f"Backend: {backend.name}")
print(f" Processor type: {backend.processor_type}")
print(f" Supported instructions: {backend.supported_instructions}")because (1) the old code loops through all backends, which is very slow and (2) you can extract backend information directly; no need to get its configuration.
| "\n", | ||
| "| | |\n", | ||
| "| --- | --- |\n", | ||
| "| **View with Qiskit** | `backend.properties().t1(qubit)` |\n", |
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.
| "| **View with Qiskit** | `backend.properties().t1(qubit)` |\n", | |
| "| **View with Qiskit** | `backend.properties().t1(<qubit>)` |\n", |
I think the standard is to use <> to mean a field that needs to be updated?
| "| | |\n", | ||
| "| --- | --- |\n", | ||
| "| **View with Qiskit** | `backend.properties().t1(qubit)` |\n", | ||
| "| **View on IBM Quantum Platform** | Details section |\n", |
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.
| "| **View on IBM Quantum Platform** | Details section |\n", | |
| "| **View on IBM Quantum Platform** | Qubits section in QPU detailed view|\n", |
Assuming this fits inside the cell..
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 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 added Qubit because this page has a lot of information, and it may not be obvious this is under the dropdown menu under Qubit:
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.
Gotcha 👍
| "| **View with Qiskit** | `backend.properties().frequency(qubit)` |\n", | ||
| "| **View on IBM Quantum Platform** | Calibration data section, graph view |\n", | ||
| "\n", | ||
| "#### `anharmonicity`\n", |
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'll need to investigate more about frequency and anharmonicity, to see if they are no longer reported or is just broken in qiskit-ibm-runtime.
| "id": "67525443-070e-4798-99b3-72a599bf96c8", | ||
| "metadata": {}, | ||
| "source": [ | ||
| "### Instruction properties\n", |
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 know you're not done merging the pages, but instruction properties are also available on IQP - e.g. single qubit gate length under Qubit.
Similarly, everything available on IQP should be queryable from Qiskit.
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 all properties fit neatly under the two subheadings of "Instruction properties" and Qubit properties"? Or do we dispense with the subheaders and just list all properties in the Dynamic backend information section ?
Either way, I plan to do an in-page toc to easily jump to a property - as in what we do here in the current page:

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 all properties fit neatly under the two subheadings of "Instruction properties" and Qubit properties"?
Unfortunately no. But we can have a third "Additional information" (or some better name) for other backend data like total pending jobs and CLOPS.
I think it'd help dividing them into sections... even better if the sections can be collapsed 😄.
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.
We will collapse them!
Other than CLOPS and total pending - what else falls under "Additional information"?

CC: @jyu00
Consolidate two files containing similar/overlapping content: Get backend information with Qiskit and QPU information.
@Eric-Arellano @frankharkins @arnaucasau FYI: when it is time to merge, can you please set up a redirect from
qpu-information.mdxtoget-qpu-information.ipynb?Closes #4249