Wolfram Language Paclet Repository
Community-contributed installable additions to the Wolfram Language
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. It is the IBM analogue of QUALink's , and it reads only the free metadata endpoints, so it runs no circuit and spends no quantum time.
QUAConnect[backend]["ErrorMap"]
The example below is , a 156-qubit Heron r2 device.
ibm_fez
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, because it differs from QUALink: 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
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"]
LocalSymbol["ibm_crn"]="crn:v1:bluemix:public:quantum-computing:us-east:...";ibm=ServiceConnect["IBMQuantumPlatform","New",Authentication{"apikey"api}]
Draw the map. A bare call uses the curated default styling shown above and the first available device:
ibm["ErrorMap"]
Pick a device by name with the parameter:
"Backend"
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):
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"
"CZErrors"
"ZZ"
"GateErrors"
"GateName"
"cz"
"ReadoutErrors"
"Coherence"
"Qubits"
"DeviceModel"
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, the analogue of QUALink's 0 sentinel) 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
Every channel is a parameter of the request, so the look is fully steerable; the defaults are the curated dark look above. Pass one override directly after the request name, or several wrapped in a list (the standard parameter form).
"ErrorMap"
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 |
A single override goes right after the request name:
ibm["ErrorMap","BackgroundColor"White]
Several overrides are passed as one list of rules:
ibm["ErrorMap",{"Backend""ibm_fez","BackgroundColor"White,"EdgeThicknessMetric""Duration"}]
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
How it works
The map lives entirely on the connection. The request reads and (the same IAM-token and service-CRN authentication the connection already carries), folds them into one normalized, provider-neutral device model, and draws it. The drawing uses only built-in graphics, so the feature adds no dependency on the quantum paclet. This mirrors QUALink's , with the per-pair crosstalk standing in for the Bell-state fidelity that QUA exposes and IBM does not.
"IBMQuantumPlatform"
"ErrorMap"
"RawBackendConfiguration"
"RawBackendProperties"
QUAConnect[backend]["ErrorMap"]
ZZ
 |
|
 |
|
""