Wolfram Language Paclet Repository
Community-contributed installable additions to the Wolfram Language
An IBM Quantum Error Map
An IBM Quantum Error Map
A quantum processor is only as good as its current calibration, and that calibration drifts from hour to hour. This note draws a single picture of an IBM device's instantaneous health: the qubit connectivity graph with the live per-qubit and per-bond calibration painted onto it.
What IBM actually exposes
What IBM actually exposes
Two read-only endpoints carry everything the map needs. The device's connection to already defines both as raw requests.
"IBMQuantumPlatform"
◼
configuration
{cz,id,rx,rz,rzz,sx,x}
◼
properties
T
1
T
2
general
ZZ
One thing is worth stating plainly: IBM publishes no Bell-state fidelity. There is no two-qubit fidelity number beyond the gate error itself. So the error becomes the bond color, and the natural second per-bond channel is the static crosstalk: the always-on residual coupling a pair carries even while idle, an error source independent of the gate error.
cz
cz
ZZ
Building the map
Building the map
The error map is a property of the connection. It needs IBM credentials for the read-only metadata fetch: an API key, and the IBM Cloud resource name stored as .
"IBMQuantumPlatform"
LocalSymbol["ibm_crn"]
In[1]:=
api="Your_IBM_API";LocalSymbol["ibm_crn"]="Your_IBM_CRN";ibm=ServiceConnect["IBMQuantumPlatform","New",Authentication{"apikey"api}]
Draw the map. The parameter is required and names the device; the curated default styling is used:
"Backend"
In[2]:=
ibm["ErrorMap","Backend""ibm_fez"]
The connection also exposes the underlying error model and its projections, each keyed by the sorted qubit pair, so the map's numbers are independently queryable (still no circuit, no quantum time):
In[3]:=
ibm["DeviceModel","Backend""ibm_fez"]
The accessor family is , , , , , , (which takes a parameter, default ), , , and . fetches once and carries every projection as a key, so it is the efficient path when you need several at once; nothing device-specific is hardcoded, so a metric the device adds later is ingested with no change.
"DeviceModel"
"CouplingMap"
"CouplingGraph"
"CZErrors"
"CZDurations"
"ZZ"
"GateErrors"
"GateName"
"cz"
"ReadoutErrors"
"Coherence"
"Qubits"
"DeviceModel"
Where returns the bare list of connected pairs, returns that same connectivity as a : the physical qubit indices as vertices, the couplers as edges, and the device's heavy-hex layout carried as the vertex coordinates. Because it is an ordinary graph, the built-in graph functions apply to it directly, from between two qubits to a that picks out a linear chain to map a circuit onto.
"CouplingMap"
"CouplingGraph"
FindShortestPath
Subgraph
In[4]:=
ibm["CouplingGraph","Backend""ibm_fez"]
Reading the map
Reading the map
The drawing carries four calibration channels at once, plus the qubit labels and the defect markers.
◼
Bond color is the of the gate error, on a temperature scale: blue is a clean coupler, red a lossy one.
log
10
cz
◼
Bond thickness is the static crosstalk (0 to about 26 kHz on ): a thick bond leaks more always-on coupling.
ZZ
ibm_fez
◼
Vertex color is on an avocado scale. Larger is better, so a long-lived qubit is dark green and a short-lived one glows yellow.
T
1
T
1
◼
Vertex size is the readout error, but inverted so that a big disk is a good (low-readout) qubit. The single worst qubit is therefore the smallest dot.
◼
Vertex label is the physical qubit index, so a problem qubit can be named, not just pointed at.
A coupler IBM currently flags as uncalibrated (gate error reported as exactly 1) is drawn as a dashed gray defect bond, and a qubit with no readout number as a dashed defect site, so the full physical lattice is always visible. The bonds carry double-headed arrows; the next section says why.
Options
Options
Every channel is a parameter of the request, so the look is fully steerable; the defaults are the curated dark look. Because is required, pass it together with any style overrides as one list of rules (the standard parameter form).
"ErrorMap"
"Backend"
ServiceConnect
Parameter | Default | Meaning | |
"EdgeColorScheme" | "TemperatureMap" | gradient for the cz | |
"VertexColorScheme" | "AvocadoColors" | gradient for the T 1 | |
"VertexColorReversed" | True | map low T 1 | |
"VertexSizeReversed" | True | big disk = low readout error (good); set False | |
"EdgeThicknessMetric" | "ZZ" | bond thickness source: "ZZ" "Duration" cz None | |
"EdgeThicknessRange" | {4.,12.} | thinnest-to-thickest bond width in points | |
"EdgeArrows" | True | double-headed arrows on the bonds | |
"ShowQubitLabels" | True | print the qubit index in each disk | |
"BackgroundColor" | Black | canvas; the title, legends, and outlines follow its luminance |
The backend and any overrides go together in one list, for example a white canvas with the edge thickness driven by the duration:
cz
In[5]:=
ibm["ErrorMap",{"Backend""ibm_fez","BackgroundColor"White,"EdgeThicknessMetric""Duration"}]
Why the bonds are bidirectional
Why the bonds are bidirectional
IBM's native two-qubit gate is the controlled-, , which is symmetric: swapping the two qubits leaves the gate unchanged, and the hardware calibrates both orderings to identical numbers. There is therefore no control or target for a , which is why the bonds are undirected and the arrows are drawn double-headed (bidirectional) rather than one-way.
Z
CZ=diag(1,1,1,-1)
cz
A directional is synthesized from a and single-qubit gates, with the basis-change Hadamards placed on whichever qubit you choose. So a can be realized in either orientation on the same physical bond: either qubit can serve as control or target.
CNOT
cz
CNOT
 |
|
 |
|
""