Nishimori-Phasenübergang

Geschätzte Laufzeit: 3 Minuten auf einem Heron- r2 -Prozessor (HINWEIS: Dies ist lediglich eine Schätzung. (Die Laufzeit kann variieren.)

Lernziele

Verstehen Sie den Nishimori-Phasenübergang und wie er sich im Ising-Modell mit zufälligen Bindungen als Fernverschränkung manifestiert.
Implementiere das GEM-Protokoll ( Generation of Entanglement by Measurement ) auf Quantenhardware unter Verwendung von Messungen während des Schaltablaufs und Schaltkreisen mit konstanter Tiefe.
Charakterisieren Sie den Übergang, indem Sie aus den experimentellen Daten die Zweipunktkorrelation und die normierte Varianz der Magnetisierung ermitteln.

Voraussetzungen

Der Leitfaden zu Mess-Qubits, insbesondere der Abschnitt über Messungen während des Schaltvorgangs, auf den sich das GEM-Protokoll stützt.
Exakte und ungenaue Simulation mit Qiskit-Aer-Primitiven – so wird der Abschnitt mit kleinem Maßstab ausgeführt.
Fernverschränkung mit dynamischen Schaltkreisen – ein begleitendes Tutorial, das dasselbe Paradigma der messungsbasierten Verschränkung verwendet.
Heavy-Hex-Gitter – die „ IBM® “-Hardware-Topologie, auf der das Plaquette-Gitter aufbaut.

Hintergrund

Dieses Tutorial zeigt, wie man einen Nishimori-Phasenübergang auf einem Quantenprozessor realisiert. Dieses Experiment wurde ursprünglich in dem Artikel „Realizing the Nishimori transition across the error threshold for constant-depth quantum circuits“ beschrieben.

Der Nishimori-Phasenübergang bezeichnet den Übergang zwischen Phasen mit kurz- und langreichweitiger Ordnung im Ising-Modell mit zufälligen Bindungen. Auf einem Quantencomputer äußert sich die langreichweitig geordnete Phase in einem Zustand, in dem die Qubits über das gesamte Gerät hinweg verschränkt sind. Dieser stark verschränkte Zustand wird mithilfe des GEM-Protokolls ( Generation of Entanglement by Measurement ) erzeugt. Durch die Verwendung von Messungen in der Mitte des Schaltkreises ist das GEM-Protokoll in der Lage, Qubits über das gesamte Gerät hinweg mithilfe von Schaltkreisen mit nur konstanter Tiefe zu verschränken. In diesem Tutorial wird die Implementierung des GEM-Protokolls aus dem Softwarepaket „GEM Suite“ verwendet.

Anforderungen

Bevor Sie mit diesem Tutorial beginnen, sollten Sie sicherstellen, dass Sie Folgendes installiert haben:

Qiskit SDK v1.0 oder später, mit Visual isierungsunterstützung
Qiskit Runtime v0.22 oder später (pip install qiskit-ibm-runtime)
Qiskit Aer v0.14 oder höher (pip install qiskit-aer)
GEM Suite (pip install gem-suite)

Einrichtung

import matplotlib.pyplot as plt
import warnings

from collections import defaultdict

from qiskit_ibm_runtime import QiskitRuntimeService
from qiskit_aer import AerSimulator

from qiskit.transpiler import generate_preset_pass_manager

from gem_suite import PlaquetteLattice
from gem_suite.experiments import GemExperiment

Beispiel für einen Simulator im kleinen Maßstab

AerSimulatorIn diesem Abschnitt wird der gesamte Arbeitsablauf am Beispiel von „noiseless“ erläutert. Das Plaquette-Gitter ist auf eine einzige Plaquette (12 Qubits) beschränkt, sodass die Simulation überschaubar und schnell bleibt, dabei aber dennoch alle Teile des GEM-Protokolls abdeckt: Messungen während des Schaltvorgangs, den „ $R_{ZZ}$ “-Winkeldurchlauf, die Dekodierung und die Analyse der normierten Varianz. Derselbe Arbeitsablauf wird später auf mehrere Plaquetten und das gesamte Gitter auf realer Hardware ausgeweitet.

Schritt 1: Klassische Eingaben einem Quantenproblem zuordnen

Das GEM-Protokoll läuft auf einem Quantenprozessor, dessen Qubit-Verbindungen durch ein Gitter beschrieben werden. Die heutigen „ IBM Quantum® “-Prozessoren nutzen das „Heavy-Hex“-Gitter. Die Qubits auf dem Prozessor werden je nachdem, welche Elementarzelle des Gitters sie einnehmen, zu Plaquettes zusammengefasst. Da ein Qubit in mehr als einer Einheitszelle vorkommen kann, sind die Plaquetten nicht disjunkt. Auf dem Heavy-Hex-Gitter enthält eine Plaquette 12 Qubits. Auch die Plaquettes selbst bilden Gitter, wobei zwei Plaquettes miteinander verbunden sind, wenn sie gemeinsame Qubits aufweisen. Auf dem Heavy-Hex-Gitter teilen sich benachbarte Plaquetten drei Qubits.

PlaquetteLatticeIm Softwarepaket „GEM Suite“ ist die Basisklasse zur Implementierung des GEM-Protokolls, die das Gitter aus Plaquettes darstellt (das sich vom Heavy-Hex-Gitter unterscheidet). A PlaquetteLattice kann anhand einer Qubit-Kopplungsabbildung initialisiert werden. Derzeit werden ausschließlich „Heavy-Hex“-Kopplungskarten unterstützt.

Die folgende Codezelle initialisiert ein Plaquette-Gitter anhand der Kopplungskarte einer Quantenverarbeitungseinheit (QPU). Das Plakettengitter umfasst nicht immer die gesamte Hardware. Beispielsweise ibm_torino verfügt über insgesamt 133 Qubits, doch das größte Plaquettengitter, das auf das Gerät passt, nutzt nur 125 davon, bestehend aus 18 Plaquetten; ibm_pittsburgh (156 Qubits) fasst ebenfalls 144 Qubits in 21 Plaquetten. Das gleiche Muster gilt auch für andere „Heavy-Hex“-QPUs mit unterschiedlicher Qubit-Anzahl.

service = QiskitRuntimeService()
backend = service.least_busy(
    operational=True, simulator=False, min_num_qubits=127
)
aer_backend = AerSimulator.from_backend(backend)
plaquette_lattice = PlaquetteLattice.from_coupling_map(backend.coupling_map)

print(f"Number of qubits in backend: {backend.num_qubits}")
print(
    f"Number of qubits in plaquette lattice: {len(list(plaquette_lattice.qubits()))}"
)
print(f"Number of plaquettes: {len(list(plaquette_lattice.plaquettes()))}")

Sie können das Plaquette-Gitter visualisieren, indem Sie ein Diagramm seiner graphischen Darstellung erstellen. In dem Diagramm werden die Plaketten durch beschriftete Sechsecke dargestellt, und zwei Plaketten sind durch eine Kante verbunden, wenn sie gemeinsame Qubits haben.

plaquette_lattice.draw_plaquettes()

Output:

Mit der Methode plaquettes können Sie Informationen über einzelne Plaketten abrufen, z. B. über die darin enthaltenen Qubits.

# Get a list of the plaquettes
plaquettes = list(plaquette_lattice.plaquettes())
# Display information about plaquette 0
plaquettes[0]

Output:

PyPlaquette(index=0, qubits=[3, 4, 5, 6, 7, 16, 17, 23, 24, 25, 26, 27], neighbors=[4, 3, 1])

Sie können auch ein Diagramm der zugrunde liegenden Qubits erstellen, die das Plaquette-Gitter bilden.

plaquette_lattice.draw_qubits()

Output:

Zusätzlich zu den Qubit-Beschriftungen und den Kanten, die anzeigen, welche Qubits miteinander verbunden sind, enthält das Diagramm drei weitere Informationen, die für das GEM-Protokoll relevant sind:

Jedes Qubit ist entweder schattiert (grau) oder nicht schattiert. Die schattierten Qubits sind "Site"-Qubits, die die Sites des Ising-Modells darstellen, und die nicht schattierten Qubits sind "Bond"-Qubits, die Wechselwirkungen zwischen den Site-Qubits vermitteln.
Jedes Standort-Qubit ist entweder mit (A) oder (B) gekennzeichnet, was eine von zwei Rollen angibt, die ein Standort-Qubit im GEM-Protokoll spielen kann (die Rollen werden später erklärt).
Jede Kante wird mit einer von sechs Farben eingefärbt, wodurch die Kanten in sechs Gruppen unterteilt werden. Diese Aufteilung bestimmt, wie Zwei-Qubit-Gatter parallelisiert werden können, sowie verschiedene Ausführungsmuster, die auf einem verrauschten Quantenprozessor voraussichtlich zu unterschiedlichen Fehlerraten führen. Da die Kanten innerhalb einer Gruppe disjunkt sind, kann auf diese Kanten gleichzeitig eine Schicht aus Zwei-Qubit-Gattern angewendet werden. Tatsächlich ist es möglich, die sechs Farben in drei Zweiergruppen so einzuteilen, dass die Vereinigung jeder Zweiergruppe weiterhin disjunkt ist. Daher sind nur drei Schichten mit Zwei-Qubit-Gattern erforderlich, um jede Kante zu aktivieren. Es gibt 12 Möglichkeiten, die sechs Farben auf diese Weise aufzuteilen, und jede dieser Aufteilungen führt zu einem anderen dreistufigen Gate-Zeitplan.

Nachdem Sie nun ein Plaquette-Gitter erstellt haben, besteht der nächste Schritt darin, ein GemExperiment Objekt zu initialisieren, wobei Sie sowohl das Plaquette-Gitter als auch das Backend übergeben, auf dem Sie das Experiment ausführen möchten. Die GemExperiment Klasse übernimmt die eigentliche Implementierung des GEM-Protokolls, einschließlich der Erstellung von Schaltkreisen, der Übermittlung von Aufträgen und der Analyse der Daten. Die folgende Codezelle initialisiert die Experimentklasse und beschränkt dabei das Plaquettengitter auf eine einzige Plaquette (12 Qubits), um die Simulation überschaubar und schnell zu halten. Das vollständige Plaquette-Gitter wird später bei der Skalierung auf echte Hardware verwendet.

# Filter the plaquette lattice down to a single plaquette (12 qubits)
# so the AerSimulator run stays fast. The full lattice is used later
# in the large-scale hardware example.
gem_exp = GemExperiment(plaquette_lattice.filter([9]), backend=aer_backend)

# visualize the plaquette lattice after filtering
plaquette_lattice.filter([9]).draw_qubits()

Output:

Eine GEM-Protokollschaltung wird in folgenden Schritten aufgebaut:

Bereiten Sie den Zustand $|+\rangle$ vor, indem Sie auf jedes Qubit ein Hadamard-Gatter anwenden.
Wende zwischen jedem Paar verbundener Qubits ein „ $R_{ZZ}$ “-Gatter an. Dazu können Sie drei Schichten von Toren verwenden. Jedes „ $R_{ZZ}$ “-Gatter wirkt auf ein Standort-Qubit und ein Bindungs-Qubit ein. Ist das Standort-Qubit mit (B) gekennzeichnet, ist der Winkel fest auf $\frac{\pi}{2}$ festgelegt. Ist das Standort-Qubit mit (A) gekennzeichnet, kann der Winkel variieren, wodurch sich unterschiedliche Schaltkreise ergeben. Standardmäßig ist der Winkelbereich auf 21 gleichmäßig verteilte Punkte zwischen $0$ und $\frac{\pi}{2}$ (einschließlich) festgelegt.
Messen Sie jedes Bindungs-Qubit in der Pauli- $X$ -Basis. Da Qubits in der Pauli- $Z$ -Basis gemessen werden, kannst du dies erreichen, indem du vor der Messung des Qubits ein Hadamard-Gatter anwendest.

Beachten Sie, dass die in der Einleitung zu diesem Tutorial zitierte Arbeit eine andere Konvention für den Winkel $R_{ZZ}$ verwendet, die sich von der in diesem Tutorial verwendeten Konvention um den Faktor 2 unterscheidet.

In Schritt drei werden ausschließlich die Bindungs-Qubits gemessen. Um zu verstehen, in welchem Zustand sich die Standort-Qubits befinden, ist es aufschlussreich, den Fall zu betrachten, in dem der in Schritt zwei auf die Standort-Qubits (A) angewendete Winkel „ $R_{ZZ}$ “ gleich „ $\frac{\pi}{2}$ “ ist. In diesem Fall verbleiben die Standort-Qubits in einem stark verschränkten Zustand, der dem GHZ-Zustand ähnelt,

\lvert \text{GHZ} \rangle = \lvert 00 \cdots 00 \rangle + \lvert 11 \cdots 11 \rangle.

Aufgrund der Zufälligkeit der Messergebnisse könnte der tatsächliche Zustand der Standort-Qubits ein anderer Zustand mit Fernordnung sein, beispielsweise $\lvert 00110 \rangle + \lvert 11001 \rangle$ . Der GHZ-Zustand lässt sich jedoch durch eine auf den Messergebnissen basierende Dekodierungsoperation wiederherstellen. Wird der Winkel „ $R_{ZZ}$ “ von „ $\frac{\pi}{2}$ “ herabgesetzt, lässt sich die Fernordnung bis zu einem kritischen Winkel wiederherstellen, der ohne Rauschen bei etwa „ $0.3 \pi$ “ liegt. Unterhalb dieses Winkels weist der resultierende Zustand keine Fernverschränkung mehr auf. Dieser Übergang zwischen dem Vorhandensein und dem Fehlen einer Fernordnung wird als Nishimori-Phasenübergang bezeichnet.

In der obigen Beschreibung wurden die Site-Qubits nicht gemessen, und die Dekodierung kann durch Anwenden von Quanten-Gattern durchgeführt werden. In dem Experiment, wie es in der GEM-Suite umgesetzt wurde, werden die Standort-Qubits tatsächlich gemessen, und die Dekodierung erfolgt in einem klassischen Nachbearbeitungsschritt.

In der obigen Beschreibung kann der Dekodierungsvorgang durch Anwenden von Quantengattern auf die Standort-Qubits durchgeführt werden, um den Quantenzustand wiederherzustellen. Sollte das Ziel jedoch darin bestehen, den Zustand sofort zu messen (beispielsweise zu Charakterisierungszwecken), dann können Sie die Standort-Qubits zusammen mit den Bindungs-Qubits messen und die Dekodierungsoperation in einem klassischen Nachbearbeitungsschritt durchführen.

Neben dem in Schritt zwei verwendeten Winkel „ $R_{ZZ}$ “, der standardmäßig über 21 Werte durchlaufen wird, hängt die Schaltung des GEM-Protokolls auch von dem Scheduling-Muster ab, das zur Implementierung der drei Schichten von „ $R_{ZZ}$ “-Gattern verwendet wird. Wie bereits erwähnt, gibt es 12 solcher Planungsmuster. Daher beträgt die Gesamtzahl der Schaltkreise im Experiment $21 \times 12 = 252$ .

Die Schaltkreise des Experiments können mithilfe der circuits Methode der GemExperiment Klasse generiert werden.

circuits = gem_exp.circuits()
print(f"Total number of circuits: {len(circuits)}")

Output:

Total number of circuits: 252

Für die Zwecke dieses Tutorials reicht es aus, nur ein einziges Zeitplanungsmuster zu betrachten. Die folgende Codezelle beschränkt das Experiment auf das erste Zeitplanungsmuster. Daher hat das Experiment nur 21 Schaltkreise, einen für jeden überstrichenen Winkel $R_{ZZ}$ .

# Restrict experiment to the first scheduling pattern
gem_exp.set_experiment_options(schedule_idx=0)

# There are less circuits now
circuits = gem_exp.circuits()
print(f"Total number of circuits: {len(circuits)}")

# Print the RZZ angles swept over
print(f"RZZ angles:\n{gem_exp.parameters()}")

Output:

Total number of circuits: 21
RZZ angles:
[0.         0.07853982 0.15707963 0.23561945 0.31415927 0.39269908
 0.4712389  0.54977871 0.62831853 0.70685835 0.78539816 0.86393798
 0.9424778  1.02101761 1.09955743 1.17809725 1.25663706 1.33517688
 1.41371669 1.49225651 1.57079633]

Die folgende Codezelle zeichnet ein Diagramm der Schaltung bei Index 5. Um die Größe des Diagramms zu verringern, werden die Messgatter am Ende der Schaltung entfernt.

# Get the circuit at index 5
circuit = circuits[5]
# Remove the final measurements to ease visualization
circuit.remove_final_measurements()
# Draw the circuit
circuit.draw("mpl", fold=-1, scale=0.5)

Output:

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

Das Transpiling von Quantenschaltkreisen zur Ausführung auf Hardware umfasst in der Regel mehrere Schritte. In der Regel sind die Schritte, die den größten Rechenaufwand verursachen, die Auswahl des Qubit-Layouts, die Anpassung der Zwei-Qubit-Gatter an die Qubit-Konnektivität der Hardware sowie die Optimierung der Schaltung zur Minimierung der Gatteranzahl und der Schaltungstiefe. Im GEM-Protokoll sind die Layout- und Routing-Phasen überflüssig, da die Hardware-Konnektivität bereits in die Gestaltung des Protokolls integriert ist. Die Schaltungen verfügen bereits über eine Qubit-Anordnung, und die Zwei-Qubit-Gatter sind bereits auf native Verbindungen abgebildet. Um zudem die Struktur der Schaltung bei einer Änderung des „ $R_{ZZ}$ “-Winkels beizubehalten, sollte nur eine sehr grundlegende Schaltungsoptimierung durchgeführt werden.

Die Klasse GemExperiment setzt die Schaltkreise bei der Ausführung des Experiments transparent um. Die Layout- und Routing-Phasen sind bereits standardmäßig so eingestellt, dass sie nichts tun, und die Schaltungsoptimierung wird auf einer Ebene durchgeführt, die nur Ein-Qubit-Gatter optimiert. Sie können jedoch mit der Methode set_transpile_options zusätzliche Optionen außer Kraft setzen oder übergeben. Zur Veranschaulichung transponiert die folgende Codezelle die zuvor angezeigte Schaltung manuell und zeichnet die transponierte Schaltung.

# Demonstrate setting transpile options
gem_exp.set_transpile_options(
    optimization_level=1  # This is the default optimization level
)
pass_manager = generate_preset_pass_manager(
    backend=aer_backend,
    initial_layout=list(gem_exp.physical_qubits),
    **dict(gem_exp.transpile_options),
)
transpiled = pass_manager.run(circuit)
transpiled.draw("mpl", idle_wires=False, fold=-1, scale=0.5)

Output:

Schritt 3: Mit „ Qiskit primitives “ ausführen

Um die GEM-Protokollschaltungen auf der Hardware auszuführen, rufen Sie die Methode run des Objekts GemExperiment auf. Sie können die Anzahl der Aufnahmen angeben, die Sie von jedem Stromkreis abfragen möchten. Die Methode run gibt ein ExperimentData objekt zurück, das Sie in einer Variablen speichern sollten. Beachten Sie, dass die Methode run nur Aufträge übermittelt, ohne auf deren Beendigung zu warten, es handelt sich also um einen nicht-blockierenden Aufruf.

exp_data = gem_exp.run(shots=10_000)

Um auf die Ergebnisse zu warten, rufen Sie die Methode block_for_results des Objekts ExperimentData auf. Dieser Aufruf führt dazu, dass der Interpreter hängen bleibt, bis die Aufträge beendet sind.

# The noiseless AerSimulator produces zero-variance UFloat objects in the
# analysis, which triggers a harmless warning from the `uncertainties`
# library. Suppress it so the output stays clean.
with warnings.catch_warnings():
    warnings.filterwarnings(
        "ignore", message="Using UFloat objects with std_dev==0"
    )
    exp_data.block_for_results()
exp_data

Output:

ExperimentData(GemExperiment, 90bf2a90-f729-4c4e-a6da-664aecb11039, job_ids=['04a7c405-47fd-46ca-aa4b-aaf7e339cfbe'], metadata=<5 items>, figure_names=['two_point_correlation.svg', 'normalized_variance.svg', 'plaquette_ops.svg', 'bond_ops.svg'])

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

Bei einem Winkel von $R_{ZZ}$ von $\frac{\pi}{2}$ wäre der dekodierte Zustand der GHZ-Zustand bei Abwesenheit von Rauschen. Die langreichweitige Ordnung des GHZ-Zustands kann durch Auftragen der Magnetisierung der gemessenen Bitstrings veranschaulicht werden. Die Magnetisierung $M$ ist definiert als die Summe der Ein-Qu-Bit-Pauli-Operatoren $Z$ ,

M = \sum_{j=1}^N Z_j,

wobei $N$ die Anzahl der Standort-Qubits ist. Sein Wert für eine Bitfolge entspricht der Differenz zwischen der Anzahl der Nullen und der Anzahl der Einsen. Die Messung des GHZ-Zustands ergibt mit gleicher Wahrscheinlichkeit entweder den „All-Zeros“-Zustand oder den „All-Ones“-Zustand, sodass die Magnetisierung in der einen Hälfte der Zeit $+N$ und in der anderen Hälfte der Zeit $-N$ wäre. Bei Fehlern aufgrund von Rauschen würden zwar auch andere Werte auftreten, doch wenn das Rauschen nicht allzu stark ist, würde die Verteilung dennoch ihren Höchstwert in der Nähe von $+N$ und $-N$ erreichen.

Für die rohen Bitstrings vor der Dekodierung würde die Verteilung der Magnetisierung derjenigen von gleichmäßig zufälligen Bitstrings entsprechen, wenn kein Rauschen vorhanden ist.

Die folgende Codezelle stellt die Magnetisierung der rohen Bitstrings und der dekodierten Bitstrings unter dem Winkel $R_{ZZ}$ von $\frac{\pi}{2}$ dar.

def magnetization_distribution(
    counts_dict: dict[str, int],
) -> dict[str, float]:
    """Compute magnetization distribution from counts dictionary."""
    # Construct dictionary from magnetization to count
    mag_dist = defaultdict(float)
    for bitstring, count in counts_dict.items():
        mag = bitstring.count("0") - bitstring.count("1")
        mag_dist[mag] += count
    # Normalize
    shots = sum(counts_dict.values())
    for mag in mag_dist:
        mag_dist[mag] /= shots
    return mag_dist


# Get counts dictionaries with and without decoding
data = exp_data.data()
# Get the last data point, which is at the angle for the GHZ state
raw_counts = data[-1]["counts"]
# Without decoding
site_indices = [
    i for i, q in enumerate(gem_exp.plaquettes.qubits()) if q.role == "Site"
]
site_raw_counts = defaultdict(int)
for key, val in raw_counts.items():
    site_str = "".join(key[-1 - i] for i in site_indices)
    site_raw_counts[site_str] += val
# With decoding
_, site_decoded_counts = gem_exp.plaquettes.decode_outcomes(
    raw_counts, return_counts=True
)

# Compute magnetization distribution
raw_magnetization = magnetization_distribution(site_raw_counts)
decoded_magnetization = magnetization_distribution(site_decoded_counts)

# Plot
plt.bar(*zip(*raw_magnetization.items()), label="raw")
plt.bar(*zip(*decoded_magnetization.items()), label="decoded", width=0.3)
plt.legend()
plt.xlabel("Magnetization")
plt.ylabel("Frequency")
plt.title("Magnetization distribution with and without decoding")

Output:

Text(0.5, 1.0, 'Magnetization distribution with and without decoding')

Um die Fernordnung genauer zu charakterisieren, kann man die durchschnittliche Zweipunktkorrelation $f$ untersuchen, die wie folgt definiert ist

f = \frac{1}{N^2} \left(\langle M^2 \rangle - \langle M \rangle ^2\right).

Ein höherer Wert deutet auf einen höheren Grad der Verflechtung hin. Die Klasse GemExperiment berechnet diesen Wert automatisch für die dekodierten Bitstrings als Teil der Verarbeitung der experimentellen Daten. Sie speichert eine Zahl, die über die Methode figure der Datenklasse Experiment zugänglich ist. In diesem Fall lautet der Name der Figur two_point_correlation.

exp_data.figure("two_point_correlation")

Output:

Um den kritischen Punkt des Nishimori-Phasenübergangs zu bestimmen, kann man die normalisierte Varianz von $M^2 / N$ betrachten, die wie folgt definiert ist

g = \frac{1}{N^3} \left(\langle M^4 \rangle - \langle M^2 \rangle^2\right),

die das Ausmaß der Fluktuation der quadrierten Magnetisierung quantifiziert. Dieser Wert wird am kritischen Punkt des Nishimori-Phasenübergangs maximiert. Bei Abwesenheit von Rauschen tritt der kritische Punkt bei etwa $0.3 \pi$ auf. Bei Vorhandensein von Rauschen verschiebt sich der kritische Punkt nach oben, aber der Phasenübergang wird immer noch beobachtet, solange der kritische Punkt unter $0.5 \pi$ liegt.

exp_data.figure("normalized_variance")

Output:

Beispiel für groß angelegte Hardware

Nachdem Sie das Protokoll auf einem Simulator validiert haben, können Sie das Experiment nun skalieren und auf der im Abschnitt „Setup“ ausgewählten realen Quantenhardware ausführen. In diesem Beispiel werden zwei größere Problemgrößen verwendet:

Sechs Plaquettes (ca. 49 Qubits) : ein mittelgroßer Versuch, der bereits die Verschiebung des kritischen Punkts nach rechts unter dem Einfluss von Hardware-Rauschen zeigt.
Das vollständige Plaquette-Gitter : alle Plaquettes, die die „Heavy-Hex“-Topologie des Bausteins unterstützt (beispielsweise 18 Plaquettes / 125 Qubits auf ibm_torino oder 21 Plaquettes / 144 Qubits auf ibm_pittsburgh), wobei Qubits über den gesamten Baustein hinweg mit Schaltkreisen konstanter Tiefe verschränkt werden.

Die folgende einzelne Codezelle ist in sich geschlossen: Sie erstellt das Plaquette-Gitter anhand der Kopplungskarte des Backends und führt beide Experimente durch, sodass dieser Abschnitt nach den Setup -Zellen ausgeführt werden kann, ohne dass zuvor der Abschnitt mit dem kleinen Maßstab ausgeführt werden muss.

# -------------------------Step 1-------------------------
# Initialize the runtime service, pick a real quantum hardware backend,
# and build the plaquette lattice from its coupling map. This is repeated
# from the small-scale example so this cell can run standalone after the
# Setup section. The full plaquette lattice is the "large-scale" target;
# a six-plaquette subset (range(3, 9)) is also used to show an intermediate
# scaling step.
service = QiskitRuntimeService()
backend = service.least_busy(
    operational=True, simulator=False, min_num_qubits=127
)
plaquette_lattice = PlaquetteLattice.from_coupling_map(backend.coupling_map)

# Build a GemExperiment for the full plaquette lattice and one for the
# six-plaquette subset, each restricted to a single scheduling pattern so
# the experiment has one circuit per RZZ angle (21 circuits total).
gem_exp_full = GemExperiment(plaquette_lattice, backend=backend)
gem_exp_full.set_experiment_options(schedule_idx=0)
gem_exp_6 = GemExperiment(
    plaquette_lattice.filter(range(3, 9)), backend=backend
)
gem_exp_6.set_experiment_options(schedule_idx=0)

circuits = gem_exp_full.circuits()
print(f"Total number of circuits (full lattice): {len(circuits)}")

# -------------------------Step 2-------------------------
# GemExperiment transpiles internally for the target backend: the layout
# and routing stages are overridden because the plaquette lattice already
# matches the hardware connectivity, and optimization is restricted so the
# RZZ angle structure is preserved. The code below manually transpiles one
# circuit from the six-plaquette experiment with the same settings this
# experiment will use, and draws it for inspection. (The full-lattice
# transpiled circuit has too many qubits to visualize cleanly, so the
# six-plaquette circuit is used here as a representative example.)
gem_exp_6.set_transpile_options(optimization_level=1)
circuits_6 = gem_exp_6.circuits()
pass_manager = generate_preset_pass_manager(
    backend=backend,
    initial_layout=list(gem_exp_6.physical_qubits),
    **dict(gem_exp_6.transpile_options),
)
transpiled = pass_manager.run(circuits_6[5])
display(transpiled.draw("mpl", idle_wires=False, fold=-1, scale=0.5))

# -------------------------Step 3-------------------------
# Run both problem sizes on real hardware:
#   1. Six plaquettes (~49 qubits) — an intermediate scale-up.
#   2. The full plaquette lattice — every plaquette the device supports.
exp_data_6 = gem_exp_6.run(shots=10_000, job_tags=["TUT_NPT"])
exp_data_full = gem_exp_full.run(shots=10_000, job_tags=["TUT_NPT"])
exp_data_6.block_for_results()
exp_data_full.block_for_results()

# -------------------------Step 4-------------------------
# Plot the normalized variance at each scale. The peak marks the critical
# point of the Nishimori transition; as the system grows, hardware noise
# shifts the peak rightward.
display(exp_data_6.figure("normalized_variance"))
exp_data_full.figure("normalized_variance")

Output:

Total number of circuits (full lattice): 21

Beachten Sie, dass die Kurven der normierten Varianz bei größeren Größen je nach Rauschpegel des verwendeten Backends möglicherweise keinen deutlichen Peak innerhalb des durchlaufenen Winkelbereichs aufweisen. In den oben genannten Durchläufen wurde der Spitzenwert bis auf $0.5 \pi$ verschoben, was dem rechten Rand des Schwankungsbereichs entspricht (die Analyseberichte critical_angle = 0.5000 sowohl für die Durchläufe mit sechs Plaquetten als auch für die Durchläufe mit vollem Gitter). Das bedeutet, dass das Hardware-Rauschen den kritischen Punkt an die Grenze des physikalisch aussagekräftigen Winkelbereichs des Protokolls (oder knapp darüber hinaus) verschoben hat, sodass der Übergang am Rand dessen liegt, was dieser Durchlauf auflösen kann.

Fazit

In diesem Tutorial haben Sie mithilfe des GEM-Protokolls einen Nishimori-Phasenübergang auf einem Quantenprozessor realisiert. Die Kennzahlen, die Sie im Rahmen der Nachbearbeitung untersucht haben – insbesondere die Zweipunktkorrelation und die normalisierte Varianz – dienen als Maßstab für die Fähigkeit des Geräts, verschränkte Zustände mit großer Reichweite zu erzeugen. Diese Benchmarks erweitern den Anwendungsbereich des GEM-Protokolls über die Untersuchung interessanter physikalischer Phänomene hinaus. Im Rahmen des Protokolls haben Sie die Qubits über das gesamte Gerät hinweg mithilfe von Schaltkreisen mit ausschließlich konstanter Tiefe verschränkt. Diese Leistung ist nur möglich, weil das Protokoll Messungen während des Durchlaufs nutzt. In diesem Experiment wurde der verschränkte Zustand sofort gemessen; man könnte jedoch erwägen, diesen Zustand für weitere Quantenverarbeitungsprozesse zu nutzen und so die Forschung weiter voranzutreiben.

Nächste Schritte

Empfehlungen

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

Referenzen

[1] E. H. Chen, „ G.-Y “. Zhu, R. Verresen, A. Seif, E. Bäumer, D. Layden, N. Tantivasadakarn, G. Zhu, S. Sheldon, A. Vishwanath, S. Trebst, A. Kandala. Realisierung des Nishimori-Übergangs über die Fehlerschwelle hinweg für Quantenschaltungen mit konstanter Tiefe. arXiv:2309.02863 (2023).

[2.] Das Softwarepaket „GEM Suite “.

War diese Seite hilfreich?

Melden Sie auf GitHub einen Fehler, einen Tippfehler oder fordern Sie Inhalte an.