Backend-Eigenschaften mit Echtzeit-Benchmarking aktualisieren

Geschätzte Nutzungsdauer: 3 Minuten auf ibm_kingston (HINWEIS: Dies ist lediglich eine Schätzung. (Die Laufzeit kann variieren.)

Lernziele

• Warum die von einer QPU gemeldeten Eigenschaften hinter dem aktuellen Verhalten des Geräts zurückbleiben können und wann es sich lohnt, sie selbst erneut zu messen
• Was bei jedem der fünf Standard-Charakterisierungsexperimente (Readout, „Single-Qubit Randomized Benchmarking“, „Layered Two-Qubit Randomized Benchmarking“, „ $T_1$ “ und „ $T_2$ “) gemessen wird
• So führen Sie die gesamte Charakterisierungssuite in einem einzigen Aufruf oder Schritt für Schritt aus und erhalten ein Backend-Objekt mit aktualisierten Eigenschaften zurück
• Wie lassen sich die gemessenen Eigenschaften mit den angegebenen vergleichen, und warum sind manche Abweichungen eher auf die Messmethodik als auf eine Drift des Geräts zurückzuführen?

Voraussetzungen

• Der Qiskit-Patterns -Workflow
• Qiskit Runtime Ausführungsmodi, insbesondere der Batch-Modus
• So rufen Sie Informationen zur QPU ab, z. B. Backend-Eigenschaften und Kalibrierungsdaten

Hintergrund

Jede „ IBM Quantum® “-QPU meldet eine Reihe von Eigenschaften, die beschreiben, wie gut jedes ihrer Qubits derzeit funktioniert: Relaxationszeiten ( $T_1$ ), Kohärenzzeiten ( $T_2$ ), Auslesefehler sowie Fehler bei Ein- und Zwei-Qubit-Gattern. Diese Zahlen spielen in der Praxis eine Rolle. Der Transpiler nutzt sie, um zu entscheiden, auf welchen physikalischen Qubits Ihre Schaltung ausgeführt werden soll; Techniken zur Fehlerminderung stützen sich auf sie, und Sie können sie nutzen, um zu beurteilen, ob ein Gerät für ein Experiment gut genug funktioniert.

Die gemeldeten Werte stammen aus Kalibrierungsvorgängen, die in der Regel etwa einmal täglich durchgeführt werden. Supraleitende Qubits können jedoch bereits auf kürzeren Zeitskalen driften, und vorübergehende Defekte (sogenannte Zwei-Niveau-Systeme) können ein Qubit, das zum Zeitpunkt der Kalibrierung noch einwandfrei erschien, vorübergehend beeinträchtigen. Zudem wird ein Job oft schon lange vor seiner tatsächlichen Ausführung transpiliert, sodass Entscheidungen, die auf den gemeldeten Eigenschaften basieren, möglicherweise auf veralteten Informationen beruhen. Das Tutorial „Echtzeit-Benchmarking zur Qubit-Auswahl“ zeigt, wie stark diese Eigenschaften von Tag zu Tag schwanken können, und erstellt manuell einen vollständigen Charakterisierungs-Workflow aus einzelnen Qiskit-Experimenten.

Dieses Tutorial zeigt die optimierte Version dieses Arbeitsablaufs unter Verwendung des Dienstprogramms BackendCharacterization aus dem Qiskit Device Benchmarking, das die Erstellung des Experiments, die Übermittlung des Auftrags und die Kurvenanpassung in wenigen Aufrufen bündelt. Sie benötigen etwa 70 Sekunden QPU-Zeit und erhalten im Gegenzug ein Backend-Objekt, dessen Eigenschaften den aktuellen Zustand des Geräts widerspiegeln und das sofort mit den gemeldeten Werten verglichen oder an nachgelagerte Tools weitergeleitet werden kann.

Die Charakterisierungsversuche

Die Suite umfasst fünf Objekte, von denen jedes ein Standardexperiment enthält:

• Auslesefehler (readout): Jedes Qubit wird in den Zuständen $|0\rangle$ oder $|1\rangle$ vorbereitet und sofort gemessen. Die Wahrscheinlichkeit, den falschen Zustand auszulesen, ergibt den SPAM-Fehler (State Preparation and Measurement).
• Fehler bei Einzelqubit-Gates (rb_1q): Beim Randomized Benchmarking (RB) werden Sequenzen zufälliger Clifford-Gates für einzelne Qubits ausgeführt, die sich im Idealfall zur Identitätsmatrix zusammensetzen. Die Art und Weise, wie die Überlebenswahrscheinlichkeit mit der Sequenzlänge abnimmt, ergibt den durchschnittlichen Fehler pro Gate, unabhängig von SPAM-Fehlern.
• Fehler bei Zwei-Qubit-Gattern (rb_2q): Dasselbe RB-Konzept, angewendet auf vollständige Schichten von nicht überlappenden Zwei-Qubit-Gattern, die gleichzeitig ausgeführt werden, wie in einem Experiment zur Schichttreue. Da viele Gatter gleichzeitig arbeiten, beinhalten die daraus resultierenden Fehlerraten Übersprecheffekte und entsprechen eher den tatsächlichen Bedingungen in einer tiefen Schaltung.
• $T_1$ (t1): Jedes Qubit wird nach zunehmend längeren Verzögerungen angeregt und gemessen. Der Zerfall der Population im angeregten Zustand ergibt die Relaxationszeit.
• $T_2$ (t2): Bei einem Hahn-Echo-Experiment wird jedes Qubit in eine Überlagerung versetzt, nach der Hälfte der Verzögerungszeit ein Echoimpuls angelegt und gemessen, wie schnell die Phasenkohärenz verloren geht. Standardmäßig wird ein einzelnes Echo verwendet; eine Variante mit mehreren Echos (im CPMG-Stil) wird am Ende dieses Tutorials vorgestellt.

Was die Auffrischung bewirkt und was nicht

Beachten Sie bei der Verwendung dieses Arbeitsablaufs bitte drei Punkte:

• Die aktualisierten Eigenschaften sind ausschließlich in dem Backend-Objekt enthalten, das an Sie zurückgegeben wird. Am Gerät selbst oder an den Kalibrierungsdaten, die IBM Quantum an andere Nutzer übermittelt, ändert sich nichts.
• Die Messwerte stellen eine Momentaufnahme dar, die nach einer bestimmten Methodik ermittelt wurde. Einige davon, insbesondere die geschichteten Zwei-Qubit-Fehler und die Werte für die parallele Single-Echo- $T_2$, werden anders gemessen als in den veröffentlichten Kalibrierungsdaten, sodass ein Teil der von Ihnen beobachteten Abweichung eher auf methodische Unterschiede als auf eine Drift zurückzuführen ist. In dieser Anleitung wird gezeigt, wo dies geschieht.
• Die Charakterisierung selbst kostet QPU-Zeit (etwa 70 Sekunden für die gesamte Testsuite auf einem Heron- r2 -Prozessor) – das ist der Preis für aktuelle Informationen.

Der Arbeitsablauf folgt den vier Schritten eines Qiskit-Musters:

• Schritt 1: Ordnen Sie klassische Eingaben einem Quantenproblem zu. Wählen Sie das Gerät und die zu messenden Eigenschaften aus.
• Schritt 2: Optimierung des Problems für die Ausführung auf Quantenhardware. Das Dienstprogramm erstellt die Versuchsschaltungen direkt in den nativen Logikgattern des Bausteins und parallelisiert sie über den gesamten Chip hinweg.
• Schritt 3: Führen Sie den Befehl „ Qiskit primitives “ aus. Die Experimente werden als Sampler-Jobs innerhalb eines Batches ausgeführt.
• Schritt 4: Nachbearbeitung und Ausgabe des Ergebnisses im gewünschten klassischen Format. Ordnen Sie die Messdaten den Fehlerkarten pro Qubit zu, aktualisieren Sie das Backend und vergleichen Sie die gemessenen Eigenschaften mit den gemeldeten.

Anforderungen

Bevor Sie mit dieser Anleitung beginnen, stellen Sie bitte sicher, dass Folgendes installiert ist:

• Qiskit SDK v2.0 oder höher, mit Visualisierungsunterstützung
• Qiskit Runtime v0.40 oder später (pip install qiskit-ibm-runtime)
• Qiskit Device Benchmarking, bei dem auch Qiskit Experiments (pip install git+https://github.com/qiskit-community/qiskit-device-benchmarking.git) installiert wird

Einrichtung

Importieren Sie die erforderlichen Bibliotheken.

import logging
import sys

import numpy as np
from qiskit_ibm_runtime import Batch, QiskitRuntimeService

from qiskit_device_benchmarking.utilities.characterization_utils import (
    BackendCharacterization,
    plot_characterization_comparison,
)

Die Charakterisierungssuite erstellt mehrere Experimente, übermittelt mehrere Aufträge und wertet die Ergebnisse aus, was insgesamt einige Minuten dauern kann. Aktivieren Sie die Protokollierung auf der Stufe „INFO“, damit jede Phase ihren Fortschritt in Echtzeit anzeigt.

logger = logging.getLogger("qiskit_device_benchmarking")
logger.setLevel(logging.INFO)
logger.addHandler(logging.StreamHandler(stream=sys.stdout))

Beispiel für einen Simulator im kleinen Maßstab

Dieses Tutorial enthält kein Simulatorbeispiel. Der Arbeitsablauf misst die physikalischen Unvollkommenheiten eines bestimmten Geräts: wie schnell sich seine Qubits entspannen und aus der Phase geraten und wie oft seine Gatter und Auslesevorgänge fehlschlagen. Ein idealer Simulator weist keine dieser Unvollkommenheiten auf, sodass es nichts zu charakterisieren gibt. Man könnte ein synthetisches Rauschmodell an ein gefälschtes Backend anbinden, aber die Experimente würden dann nur die Zahlen wiedergeben, die man selbst eingegeben hat. Aus diesem Grund gehen wir direkt zur Hardware über, die in die vier Schritte eines Qiskit-Musters unterteilt ist.

Beispiel für groß angelegte Hardware

Schritt 1: Klassische Eingaben auf ein Quantenproblem abbilden

In diesem Arbeitsablauf ist das „Problem“ das Gerät selbst: Die klassischen Eingaben sind die QPU, die charakterisiert werden soll, und die Liste der zu messenden Eigenschaften, und die Quantenexperimente sind die daraus generierten Charakterisierungsschaltungen.

Wählen Sie zunächst ein Backend aus. In diesem Tutorial wird ein „Heron“ r2 -Prozessor mit 156 Qubits verwendet ibm_kingston; Sie können stattdessen jedes beliebige „ IBM Quantum “-Gerät verwenden, auf das Sie Zugriff haben (oder eines mit […] auswählen service.least_busy()).

service = QiskitRuntimeService()
device = "ibm_kingston"
backend = service.backend(device)

Wählen Sie als Nächstes aus, welche Eigenschaften gemessen werden sollen. Sie können eine beliebige Teilmenge der folgenden Experimente bestehen:

• readout: SPAM-Experiment (Zustandsvorbereitung und -messung)
• rb_1q: Isoliertes, randomisiertes Benchmarking mit einem einzelnen Qubit
• rb_2q: Gleichzeitiges randomisiertes Benchmarking mit zwei Qubits anhand eines Experiments zur Schichtentreue
• t2: $T_2$ Hahn-Echo-Experiment (standardmäßig ein einzelnes Echo)
• t1: $T_1$ -Entspannungsversuch

Führen Sie die gesamte Testsuite aus, um sich einen umfassenden Überblick über das Gerät zu verschaffen; entfernen Sie Einträge aus der Liste, wenn Sie nur an bestimmten Eigenschaften interessiert sind und QPU-Zeit sparen möchten.

experiments = ["readout", "rb_1q", "rb_2q", "t1", "t2"]

Schritt 2: Optimierung des Problems für die Ausführung auf Quantenhardware

In den meisten Tutorials würde man an dieser Stelle seine Schaltungen transpilieren. Hier BackendCharacterization kümmert sich intern darum. Es baut die Versuchskreisläufe direkt in den nativen Gattern des Bausteins auf, führt die Einzel-Qubit-Experimente auf allen Qubits parallel durch und plant die Zwei-Qubit-Benchmarks über disjunkte Schichten der Kopplungskarte so, dass der gesamte Baustein mit nur wenigen Aufträgen abgedeckt wird. Aufgrund dieser Parallelisierung benötigt die gesamte Suite nur etwa 70 Sekunden QPU-Zeit.

Initialisieren Sie die Klasse, die den Workflow verwaltet:

# Initialize the class used to run the experiments
characterizer = BackendCharacterization(backend)

Schritt 3: Mit „ Qiskit primitives “ ausführen

Die Methode run_experiments erstellt die Schaltkreise und übermittelt sie als Sampler -Aufträge. Führen Sie es in einem Kontext Batch aus, damit die Jobs gemeinsam auf der QPU eingeplant werden und die Methode erst dann zurückkehrt, wenn alle Jobs übermittelt wurden. (Du kannst es auch außerhalb eines Batch-Skripts oder innerhalb eines ausführen Session.)

# Run the characterization experiments inside a Batch
with Batch(backend=backend):
    jobs = characterizer.run_experiments(experiments=experiments)

Output:

base_primitive.get_mode_service_backend:WARNING:2026-07-14 14:23:02,051: A backend was passed in as the mode but a session context manager is open so this job will run inside this session/batch instead of in job mode.

Building readout experiments
Building 1Q RB experiments
Building 2Q RB experiments
Building T1 experiments
Building T2 experiments
Layered two-qubit RB submitted: ['d9b7tfu6hjac73ffba2g', 'd9b7tjug26ic73dfju3g', 'd9b7u3u6hjac73ffban0', 'd9b7u7rv6alc73csmicg']
Readout job submitted: d9b7u8bv6alc73csmidg
T1 experiment submitted: ['d9b7u8ug26ic73dfjuqg']
T2 (Hahn) experiment submitted: ['d9b7u9fu62qs738othg0']
Single-qubit RB submitted: ['d9b7v8m6hjac73ffbc40', 'd9b7veeg26ic73dfk040']

Die Methode gibt die übermittelten Aufträge als Dictionary zurück, dessen Schlüssel die Experiment-Bezeichnungen sind. Dies ist nützlich, um sie im Dashboard unter „ IBM Quantum Platform “ zu verfolgen oder zur Fehlerbehebung.

# Print all the job IDs for debugging purposes
jobs

Output:

{'rb_2q': [<RuntimeJobV2('d9b7tfu6hjac73ffba2g', 'sampler')>,
  <RuntimeJobV2('d9b7tjug26ic73dfju3g', 'sampler')>,
  <RuntimeJobV2('d9b7u3u6hjac73ffban0', 'sampler')>,
  <RuntimeJobV2('d9b7u7rv6alc73csmicg', 'sampler')>],
 'readout': [<RuntimeJobV2('d9b7u8bv6alc73csmidg', 'sampler')>],
 't1': [<RuntimeJobV2('d9b7u8ug26ic73dfjuqg', 'sampler')>],
 't2': [<RuntimeJobV2('d9b7u9fu62qs738othg0', 'sampler')>],
 'rb_1q': [<RuntimeJobV2('d9b7v8m6hjac73ffbc40', 'sampler')>,
  <RuntimeJobV2('d9b7veeg26ic73dfk040', 'sampler')>]}

Schritt 4: Nachbearbeitung und Ausgabe des Ergebnisses im gewünschten klassischen Format

Die Ergebnisse analysieren

Die Methode analyze_results wartet, bis die Jobs abgeschlossen sind, und passt die Messdaten an: exponentielle Abklingkurven für $T_1$ und $T_2$, Überlebenswahrscheinlichkeitskurven für die RB-Experimente und Zuordnungsmatrizen für das Auslesen. Die Funktion gibt ein Wörterbuch mit Fehlerabbildungen zurück, mit einem Eintrag pro gemessener Eigenschaft, wobei jede Abbildung ein Qubit (oder ein Qubit-Paar) seinem Messwert zuordnet.

error_maps = characterizer.analyze_results()

print(f"The following error maps are available: {list(error_maps.keys())}")
readout_q0 = error_maps["readout_error"][0]
print(f"For example, readout error for qubit 0 is {readout_q0}")

Output:

The following error maps are available: ['readout_error', 'oneq_error_x', 'oneq_error_sx', 'lf_error_map', 't1_map', 't2_map']
For example, readout error for qubit 0 is 0.007600000000000051

Die Diagramme zeigen Auslesefehler, Einzel-Qubit- und x sx Gatterfehler, die geschichteten Zwei-Qubit-Fehler (lf_error_mapaus dem Experiment zur Schichttreue) sowie die Zeiten für „ $T_1$ “ und „ $T_2$ “ in Sekunden.

Die Backend-Eigenschaften aktualisieren

Die Methode update_backend schreibt die Messwerte in die Eigenschaften einer Kopie des Backends und gibt diese zurück. Das ursprüngliche Objekt backend speichert die gemeldeten Kalibrierungsdaten, sodass wir beide miteinander vergleichen können, wie unten dargestellt. Beachten Sie, dass diese Aktualisierung ausschließlich für Ihre „ Python “-Sitzung gilt; sie hat keinerlei Auswirkungen auf das Gerät oder andere Benutzer.

backend_updated = characterizer.update_backend()

Output:

Updating readout error
Updating single-qubit X error
Updating single-qubit SX error
Updating two-qubit error
Updating T1
Updating T2

Vergleichen Sie die gemessenen Eigenschaften mit den angegebenen

Zeichnen Sie schließlich die gemessenen Echtzeit-Eigenschaften als Diagramm auf, verglichen mit den vom Backend gemeldeten Werten. In jedem Diagramm sind die Qubits (bzw. Qubit-Paare) nach dem Messwert sortiert, sodass die Messkurve naturgemäß glatt verläuft und die Streuung der angegebenen Werte um diese Kurve herum zeigt, wo die beiden Ergebnisse voneinander abweichen. Für das Einzel-Qubit-RB wird nur ein einziges Diagramm dargestellt, da beiden Gatter sx – sowohl dem als x auch dem – derselbe gemessene Fehler pro Gatter zugeordnet wird. Die Achsenbegrenzungen werden aus dem Großteil der Daten so gewählt, dass einige wenige extreme Ausreißer die Diagramme nicht verzerren; alle Punkte außerhalb dieses Bereichs werden in einer Anmerkung im Diagramm aufgeführt (oder mit dem Befehl pass können ylim die Begrenzungen überschrieben werden).

plot_characterization_comparison(
    old_props=backend.properties().to_dict(),
    new_props=backend_updated.properties().to_dict(),
    plots=["readout", "rb_1q", "rb_2q", "t1", "t2"],
)

Output:

Diese Diagramme erfordern eine sorgfältige Betrachtung, denn nicht jede Lücke zwischen den beiden Kurven bedeutet, dass das Gerät abgedriftet ist:

• Auslesung und Einzel-Qubit-Fehler : Die Messwerte stimmen bei den meisten Qubits mit den angegebenen Werten überein, während der angegebene Wert für einige wenige Qubits weit von der Messkurve abweicht. Genau diese punktuellen Unstimmigkeiten sollen durch diesen Arbeitsablauf aufgefangen werden.
• $T_1$ : Die beiden Datensätze verteilen sich umeinander herum, ohne dass ein systematischer Versatz erkennbar ist, was mit den natürlichen Schwankungen von „ $T_1$ “ im Zeitverlauf übereinstimmt.
• Zwei-Qubit-Fehler : Die gemessenen Werte liegen systematisch über den angegebenen Werten. Dies ist zu erwarten, da die angegebenen Werte an isolierten Gates gemessen werden, während beim Experiment zur Schichttreue viele Gates gleichzeitig betrieben werden und daher Übersprechen auftritt. Die geschichteten Zahlen sind für tiefe Schaltkreise relevanter, lassen sich jedoch nicht direkt mit den veröffentlichten Kalibrierungsdaten vergleichen.
• $T_2$ : Die gemessenen Werte liegen bei den meisten Qubits deutlich unter den angegebenen Werten. Auch hier spielt die Methodik eine große Rolle, wie im nächsten Abschnitt erläutert wird.

Einzelne Versuchsergebnisse überprüfen

Sie können die Rohdaten der einzelnen Charakterisierungsversuche auch über die Eigenschaft experiment_data einsehen, die die zugrunde liegenden Qiskit-Experiments -Objekte ExperimentData zurückgibt. Das folgende Beispiel zeigt beispielsweise die gemessene Abklingkurve von „ $T_1$ “ für ein einzelnes Qubit. Dies ist nützlich, um die Qualität einer Anpassung zu überprüfen, bevor man sich auf den daraus resultierenden Wert verlässt.

t1_data = characterizer.experiment_data["t1"]

# Each qubit has its own fit figure
n_figs = len(t1_data.figure_names)
print(f"{n_figs} figures available, e.g. {t1_data.figure_names[0]}")

# Show the T1 decay curve of the first qubit
t1_data.figure(0)

Output:

156 figures available, e.g. T1_Q0_c78ef792.svg

T2 -Messung mit einer dynamischen Entkopplungsfolge

Standardmäßig wendet das Experiment „ $T_2$ “ ein einzelnes Hahn-Echo an und misst alle Qubits parallel, was – wie die obige Vergleichsgrafik gezeigt hat – zu deutlich niedrigeren Werten für „ $T_2$ “ führen kann, als vom Backend gemeldet werden. Eine Hypothese betrifft die Anzahl der Echos: Die gemeldeten Werte könnten unter Berücksichtigung der dynamischen Entkopplung kalibriert sein, wodurch niederfrequente Störgeräusche unterdrückt werden. Um dies zu testen, führen Sie eine Charakterisierung ausschließlich mit „ $T_2$ “ durch, wobei Sie den Wert auf einen höheren Wert einstellen t2_num_echoes , wodurch eine Folge von Echoimpulsen im CPMG-Stil angewendet wird. Die Verzögerungen entsprechen in beiden Fällen der gesamten Zeit der freien Entwicklung, sodass die angepassten Werte für „ $T_2$ “ direkt mit den Ergebnissen aus der Ein-Echo-Messung vergleichbar sind.

# Run a T2-only characterization using a CPMG-style train of 8 echoes
characterizer_dd = BackendCharacterization(backend)
backend_updated_dd = characterizer_dd.run_and_update(
    experiments=["t2"], t2_num_echoes=8
)

Output:

Building T2 experiments
T2 (Hahn) experiment submitted: ['d9b96s6g26ic73dflcn0']
Updating T2

# Compare the multi-echo T2 against the backend-reported values
plot_characterization_comparison(
    old_props=backend.properties().to_dict(),
    new_props=backend_updated_dd.properties().to_dict(),
    plots=["t2"],
    title_prefix="8-echo CPMG",
)

# Compare medians across the reported values, the single-echo run,
# and the 8-echo run
reported_t2s = [
    prop["value"]
    for qubit in backend.properties().to_dict()["qubits"]
    for prop in qubit
    if prop["name"] == "T2"
]
t2_reported = np.median(reported_t2s)
t2_single = np.median(list(error_maps["t2_map"].values())) * 1e6
t2_dd = (
    np.median(list(characterizer_dd.analyze_results()["t2_map"].values()))
    * 1e6
)
print(
    f"Median T2 — reported: {t2_reported:.0f} us | "
    f"single echo: {t2_single:.0f} us | 8-echo CPMG: {t2_dd:.0f} us"
)

Output:

Median T2 — reported: 142 us | single echo: 53 us | 8-echo CPMG: 56 us

In diesem Durchlauf hatten die zusätzlichen Echos kaum Einfluss auf das Ergebnis: Der Medianwert für 8 Echos (56 µs) liegt nahe am Medianwert für ein einzelnes Echo (53 µs), und beide liegen weit unter dem angegebenen Medianwert (142 µs). Die Anzahl der Echos allein erklärt diese Diskrepanz nicht; es spielen noch weitere methodische Unterschiede eine Rolle, wie beispielsweise Einzelheiten des Kalibrierungsverfahrens, die parallele statt isolierte Messung aller Qubits und so weiter.

Die praktische Erkenntnis daraus ist, dass man Vergleiche von „ $T_2$ “ (und „layered two-qubit error“) zwischen verschiedenen Methoden mit Vorsicht betrachten sollte. Die aktualisierten Werte stellen eine in sich konsistente Momentaufnahme unter Bedingungen dar, die einer realen Arbeitslast nahekommen, wodurch sie sich gut dafür eignen, Qubits miteinander zu vergleichen oder die Entwicklung eines Geräts im Zeitverlauf zu verfolgen. Eine Abweichung gegenüber den gemeldeten Kalibrierungsdaten ist jedoch nicht automatisch ein Hinweis auf eine Drift.

Die Schritte 1–4 in einem einzigen Aufruf zusammengefasst

Im Alltag benötigt man die Zwischenergebnisse nur selten. Die Methode run_and_update verknüpft alle oben durchgeführten Schritte (Erstellen, Übermitteln, Anpassen und Aktualisieren) zu einem einzigen Aufruf, der das aktualisierte Backend zurückgibt. Es akzeptiert dieselbe experiments Liste (und leitet Optionen wie weiter t2_num_echoes) und kann ebenfalls in einen Batch oder Kontext Session eingebettet werden.

# Initialize a fresh characterizer
characterizer = BackendCharacterization(backend)

# Run all of the experiments and update the backend in a single call
backend_updated = characterizer.run_and_update(experiments=experiments)

Output:

Building readout experiments
Building 1Q RB experiments
Building 2Q RB experiments
Building T1 experiments
Building T2 experiments
Layered two-qubit RB submitted: ['d9b7oqnu62qs738otat0', 'd9b7p76g26ic73dfjolg', 'd9b7pnm6hjac73ffb57g', 'd9b7q4fu62qs738otce0']
Readout job submitted: d9b7q4mg26ic73dfjprg
T1 experiment submitted: ['d9b7q57u62qs738otcfg']
T2 (Hahn) experiment submitted: ['d9b7q5m6hjac73ffb5pg']
Single-qubit RB submitted: ['d9b7r4e6hjac73ffb71g', 'd9b7reu6hjac73ffb7d0']
Updating readout error
Updating single-qubit X error
Updating single-qubit SX error
Updating two-qubit error
Updating T1
Updating T2

Das aktualisierte Objekt backend_updated kann nun überall dort verwendet werden, wo Backend-Eigenschaften in Ihren Workflow einfließen. Probieren Sie diesen Vorgang in Verbindung mit dem Tutorial „Echtzeit-Benchmarking zur Qubit-Auswahl“ aus, um beim Transpiling einer Schaltung die leistungsstärksten Qubits auszuwählen. Da das Gerät ständig abweicht, sollten Sie die Eigenschaften kurz vor der tatsächlichen Ausführung Ihrer Arbeitslast aktualisieren.

Nächste Schritte

Wenn Sie diese Arbeit interessant fanden, könnten Sie auch an folgenden Materialien interessiert sein: