Transition de phase de Nishimori

Estimation d'utilisation : 3 minutes sur un processeur Heron r2 (REMARQUE : il ne s'agit que d'une estimation. Ton temps d'exécution peut varier.)

Résultats d'apprentissage

Après avoir suivi ce tutoriel, les utilisateurs peuvent s'attendre aux résultats suivants :

• Comprendre la transition de phase de Nishimori et comment elle se manifeste par l'apparition d'une intrication à longue portée dans le modèle d'Ising à liaisons aléatoires.
• Implémenter le protocole de génération d'intrication par mesure (GEM) sur du matériel quantique en utilisant des mesures en milieu de circuit et des circuits de profondeur constante.
• Caractériser la transition en extrayant la corrélation à deux points et la variance normalisée de l'aimantation à partir de données expérimentales.

Prérequis

Nous recommandons de se familiariser avec les sujets suivants avant de suivre ce tutoriel :

• Le guide Mesurer les qubits, en particulier la section sur la mesure en milieu de circuit sur laquelle le protocole GEM s'appuie.
• Simulation exacte et bruitée avec les primitives Qiskit Aer, qui est la méthode d'exécution utilisée pour la section à petite échelle.
• Intrication à longue portée avec des circuits dynamiques, un tutoriel complémentaire qui utilise le même paradigme d'intrication basée sur la mesure.
• Réseau hexagonal lourd, la topologie matérielle IBM® sur laquelle le réseau de plaquettes est construit.

Contexte

Ce tutoriel montre comment réaliser une transition de phase de Nishimori sur un processeur quantique. Cette expérience a été décrite à l'origine dans Realizing the Nishimori transition across the error threshold for constant-depth quantum circuits.

La transition de phase de Nishimori fait référence à la transition entre les phases ordonnées à courte et longue portée dans le modèle d'Ising à liaisons aléatoires. Sur un ordinateur quantique, la phase ordonnée à longue portée se manifeste comme un état dans lequel les qubits sont intriqués à travers l'ensemble du dispositif. Cet état fortement intriqué est préparé à l'aide du protocole de génération d'intrication par mesure (GEM). En utilisant des mesures en milieu de circuit, le protocole GEM est capable d'intriquer des qubits à travers l'ensemble du dispositif en utilisant des circuits de profondeur constante uniquement. Ce tutoriel utilise l'implémentation du protocole GEM fournie par le package logiciel GEM Suite.

Prérequis d'installation

Avant de commencer ce tutoriel, assure-toi d'avoir installé les éléments suivants :

• Qiskit SDK v1.0 ou ultérieur, avec le support de visualisation
• Qiskit Runtime v0.22 ou ultérieur (pip install qiskit-ibm-runtime)
• Qiskit Aer v0.14 ou ultérieur (pip install qiskit-aer)
• GEM Suite (pip install gem-suite)

Configuration

# Added by doQumentation — required packages for this notebook
!pip install -q gem-suite matplotlib qiskit qiskit-aer qiskit-ibm-runtime

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

Exemple de simulateur à petite échelle

Dans cette section, le flux de travail complet est parcouru sur l'AerSimulator sans bruit. Le réseau de plaquettes est restreint à une seule plaquette (12 qubits) pour que la simulation reste petite et rapide, tout en exercitant chaque partie du protocole GEM : mesure en milieu de circuit, balayage de l'angle $R_{ZZ}$, décodage et analyse de variance normalisée. Le même flux de travail est ensuite mis à l'échelle vers plusieurs plaquettes et le réseau complet sur du matériel réel.

Étape 1 : Transposer les entrées classiques en un problème quantique

Le protocole GEM fonctionne sur un processeur quantique dont la connectivité des qubits est décrite par un réseau. Les processeurs quantiques IBM Quantum® actuels utilisent le réseau hexagonal lourd. Les qubits du processeur sont regroupés en plaquettes en fonction de la cellule unitaire du réseau à laquelle ils appartiennent. Comme un qubit peut apparaître dans plus d'une cellule unitaire, les plaquettes ne sont pas disjointes. Sur le réseau hexagonal lourd, une plaquette contient 12 qubits. Les plaquettes elles-mêmes forment également un réseau, où deux plaquettes sont connectées si elles partagent des qubits. Sur le réseau hexagonal lourd, les plaquettes voisines partagent trois qubits.

Dans le package logiciel GEM Suite, la classe fondamentale pour implémenter le protocole GEM est PlaquetteLattice, qui représente le réseau de plaquettes (distinct du réseau hexagonal lourd). Un PlaquetteLattice peut être initialisé à partir d'une carte de couplage des qubits. Actuellement, seules les cartes de couplage hexagonales lourdes sont prises en charge.

La cellule de code suivante initialise un réseau de plaquettes à partir de la carte de couplage d'une unité de traitement quantique (QPU). Le réseau de plaquettes n'englobe pas toujours l'intégralité du matériel. Par exemple, ibm_torino possède 133 qubits au total, mais le plus grand réseau de plaquettes pouvant être inscrit sur le dispositif n'utilise que 125 d'entre eux, comprenant 18 plaquettes ; ibm_pittsburgh (156 qubits) fait de même en regroupant 144 qubits en 21 plaquettes. Ce schéma est le même pour les autres QPU hexagonaux lourds avec des nombres de qubits différents.

# QiskitRuntimeService.save_account(channel="ibm_quantum", token="<YOUR_API_KEY>", overwrite=True,
# set_as_default=True)
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()))}")

Tu peux visualiser le réseau de plaquettes en générant un diagramme de sa représentation sous forme de graphe. Dans le diagramme, les plaquettes sont représentées par des hexagones étiquetés, et deux plaquettes sont reliées par une arête si elles partagent des qubits.

plaquette_lattice.draw_plaquettes()

Tu peux obtenir des informations sur les plaquettes individuelles, telles que les qubits qu'elles contiennent, en utilisant la méthode plaquettes.

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

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

Tu peux également produire un diagramme des qubits sous-jacents qui forment le réseau de plaquettes.

plaquette_lattice.draw_qubits()

En plus des étiquettes de qubits et des arêtes indiquant quels qubits sont connectés, le diagramme contient trois informations supplémentaires pertinentes pour le protocole GEM :

• Chaque qubit est soit ombré (gris), soit non ombré. Les qubits ombrés sont des qubits « site » qui représentent les sites du modèle d'Ising, et les qubits non ombrés sont des qubits « liaison » utilisés pour médier les interactions entre les qubits site.
• Chaque qubit site est étiqueté soit (A), soit (B), indiquant l'un des deux rôles qu'un qubit site peut jouer dans le protocole GEM (les rôles sont expliqués plus loin).
• Chaque arête est colorée à l'aide de l'une des six couleurs, partitionnant ainsi les arêtes en six groupes. Ce partitionnement détermine comment les portes à deux qubits peuvent être parallélisées, ainsi que les différents schémas d'ordonnancement susceptibles d'engendrer des quantités différentes d'erreur sur un processeur quantique bruité. Comme les arêtes d'un groupe sont disjointes, une couche de portes à deux qubits peut être appliquée simultanément sur ces arêtes. En fait, il est possible de partitionner les six couleurs en trois groupes de deux couleurs de sorte que l'union de chaque groupe de deux couleurs reste disjointe. Par conséquent, seules trois couches de portes à deux qubits sont nécessaires pour activer chaque arête. Il existe 12 façons de partitionner ainsi les six couleurs, et chaque partition produit un schéma de portes à 3 couches différent.

Maintenant que tu as créé un réseau de plaquettes, l'étape suivante consiste à initialiser un objet GemExperiment, en passant à la fois le réseau de plaquettes et le backend sur lequel tu as l'intention d'exécuter l'expérience. La classe GemExperiment gère l'implémentation effective du protocole GEM, y compris la génération des circuits, la soumission des tâches et l'analyse des données. La cellule de code suivante initialise la classe d'expérience en restreignant le réseau de plaquettes à une seule plaquette (12 qubits), ce qui maintient la simulation petite et rapide. Le réseau de plaquettes complet est utilisé plus tard lors de la mise à l'échelle vers du matériel réel.

# 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()

Un circuit du protocole GEM est construit en suivant les étapes suivantes :

1. Préparer l'état tout-$|+\rangle$ en appliquant une porte de Hadamard à chaque qubit.
2. Appliquer une porte $R_{ZZ}$ entre chaque paire de qubits connectés. Cela peut être réalisé en 3 couches de portes. Chaque porte $R_{ZZ}$ agit sur un qubit site et un qubit liaison. Si le qubit site est étiqueté (B), alors l'angle est fixé à $\frac{\pi}{2}$. Si le qubit site est étiqueté (A), alors l'angle est libre de varier, produisant différents circuits. Par défaut, la plage d'angles est définie sur 21 points également espacés entre $0$ et $\frac{\pi}{2}$, inclus.
3. Mesurer chaque qubit liaison dans la base de Pauli $X$. Comme les qubits sont mesurés dans la base de Pauli $Z$, cela peut être accompli en appliquant une porte de Hadamard avant de mesurer le qubit.

Note que l'article cité dans l'introduction de ce tutoriel utilise une convention différente pour l'angle $R_{ZZ}$, qui diffère de la convention utilisée dans ce tutoriel par un facteur de 2.

À l'étape 3, seuls les qubits liaison sont mesurés. Pour comprendre dans quel état se trouvent les qubits site restants, il est instructif de considérer le cas où l'angle $R_{ZZ}$ appliqué aux qubits site (A) à l'étape 2 est égal à $\frac{\pi}{2}$. Dans ce cas, les qubits site sont laissés dans un état fortement intriqué similaire à l'état GHZ,

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

En raison du caractère aléatoire des résultats de mesure, l'état réel des qubits site pourrait être un état différent présentant un ordre à longue portée, par exemple, $\lvert 00110 \rangle + \lvert 11001 \rangle$. Cependant, l'état GHZ peut être récupéré en appliquant une opération de décodage basée sur les résultats de mesure. Lorsque l'angle $R_{ZZ}$ est réduit à partir de $\frac{\pi}{2}$, l'ordre à longue portée peut encore être récupéré jusqu'à un angle critique, qui, en l'absence de bruit, est d'environ $0.3 \pi$. En dessous de cet angle, l'état résultant ne présente plus d'intrication à longue portée. Cette transition entre la présence et l'absence d'ordre à longue portée est la transition de phase de Nishimori.

Dans la description ci-dessus, les qubits site n'étaient pas mesurés, et l'opération de décodage peut être effectuée en appliquant des portes quantiques. Dans l'expérience telle qu'implémentée dans la GEM suite, les qubits site sont en réalité mesurés, et l'opération de décodage est appliquée lors d'une étape de post-traitement classique.

Dans la description ci-dessus, l'opération de décodage peut être effectuée en appliquant des portes quantiques aux qubits site pour récupérer l'état quantique. Cependant, si l'objectif est de mesurer immédiatement l'état (par exemple, à des fins de caractérisation), alors tu peux mesurer les qubits site en même temps que les qubits liaison, et appliquer l'opération de décodage lors d'une étape de post-traitement classique.

En plus de dépendre de l'angle $R_{ZZ}$ à l'étape 2, qui par défaut balaye 21 valeurs, le circuit du protocole GEM dépend également du schéma d'ordonnancement utilisé pour implémenter les 3 couches de portes $R_{ZZ}$. Comme discuté précédemment, il existe 12 schémas d'ordonnancement de ce type. Par conséquent, le nombre total de circuits dans l'expérience est de $21 \times 12 = 252$.

Les circuits de l'expérience peuvent être générés en utilisant la méthode circuits de la classe GemExperiment.

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

Total number of circuits: 252

Pour les besoins de ce tutoriel, il suffit de considérer un seul schéma d'ordonnancement. La cellule de code suivante restreint l'expérience au premier schéma d'ordonnancement. En conséquence, l'expérience ne comporte que 21 circuits, un pour chaque angle $R_{ZZ}$ balayé.

# 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()}")

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]

La cellule de code suivante dessine un diagramme du circuit à l'indice 5. Pour réduire la taille du diagramme, les portes de mesure à la fin du circuit sont supprimées.

# 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)

Étape 2 : Optimiser le problème pour l'exécution sur le matériel quantique

La transpilation des circuits quantiques pour l'exécution sur le matériel implique généralement un certain nombre d'étapes. En règle générale, les étapes qui entraînent le plus de surcharge de calcul sont le choix de la disposition des qubits, le routage des portes à deux qubits pour se conformer à la connectivité des qubits du matériel, et l'optimisation du circuit pour minimiser son nombre de portes et sa profondeur. Dans le protocole GEM, les étapes de disposition et de routage sont inutiles car la connectivité du matériel est déjà intégrée dans la conception du protocole. Les circuits disposent déjà d'une disposition de qubits, et les portes à deux qubits sont déjà mappées sur les connexions natives. De plus, afin de préserver la structure du circuit lorsque l'angle $R_{ZZ}$ varie, seule une optimisation de circuit très basique doit être effectuée.

La classe GemExperiment transpile les circuits de manière transparente lors de l'exécution de l'expérience. Les étapes de disposition et de routage sont déjà remplacées par défaut pour ne rien faire, et l'optimisation du circuit est effectuée à un niveau qui n'optimise que les portes à un seul qubit. Cependant, tu peux remplacer ou passer des options supplémentaires en utilisant la méthode set_transpile_options. À des fins de visualisation, la cellule de code suivante transpile manuellement le circuit affiché précédemment et dessine le circuit transpilé.

# 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)

Étape 3 : Exécuter à l'aide des primitives Qiskit

Pour exécuter les circuits du protocole GEM sur le matériel, appelle la méthode run de l'objet GemExperiment. Tu peux spécifier le nombre de tirs que tu souhaites échantillonner pour chaque circuit. La méthode run renvoie un objet ExperimentData que tu dois enregistrer dans une variable. Note que la méthode run soumet uniquement les tâches sans attendre leur achèvement, il s'agit donc d'un appel non bloquant.

exp_data = gem_exp.run(shots=10_000)

Pour attendre les résultats, appelle la méthode block_for_results de l'objet ExperimentData. Cet appel fera attendre l'interpréteur jusqu'à ce que les tâches soient terminées.

# 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

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'])

Étape 4 : Post-traiter et renvoyer le résultat dans le format classique souhaité

À un angle $R_{ZZ}$ de $\frac{\pi}{2}$, l'état décodé serait l'état GHZ en l'absence de bruit. L'ordre à longue portée de l'état GHZ peut être visualisé en traçant l'aimantation des chaînes de bits mesurées. L'aimantation $M$ est définie comme la somme des opérateurs de Pauli $Z$ à un seul qubit,

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

où $N$ est le nombre de qubits site. Sa valeur pour une chaîne de bits est égale à la différence entre le nombre de zéros et le nombre de uns. Mesurer l'état GHZ donne l'état tout zéros ou l'état tout uns avec une probabilité égale, de sorte que l'aimantation serait $+N$ la moitié du temps et $-N$ l'autre moitié du temps. En présence d'erreurs dues au bruit, d'autres valeurs apparaîtraient également, mais si le bruit n'est pas trop important, la distribution resterait piquée près de $+N$ et $-N$.

Pour les chaînes de bits brutes avant décodage, la distribution de l'aimantation serait équivalente à celle de chaînes de bits uniformément aléatoires, en l'absence de bruit.

La cellule de code suivante trace l'aimantation des chaînes de bits brutes et des chaînes de bits décodées à l'angle $R_{ZZ}$ de $\frac{\pi}{2}$.

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")

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

Pour caractériser plus rigoureusement l'ordre à longue portée, tu peux examiner la corrélation moyenne à deux points $f$, définie comme

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

Une valeur plus élevée indique un degré d'intrication plus important. La classe GemExperiment calcule automatiquement cette valeur pour les chaînes de bits décodées dans le cadre du traitement des données expérimentales. Elle stocke une figure accessible via la méthode figure de la classe de données expérimentales. Dans ce cas, le nom de la figure est two_point_correlation.

exp_data.figure("two_point_correlation")

Pour déterminer le point critique de la transition de phase de Nishimori, tu peux examiner la variance normalisée de $M^2 / N$, définie comme

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

qui quantifie la quantité de fluctuation de l'aimantation au carré. Cette valeur est maximisée au point critique de la transition de phase de Nishimori. En l'absence de bruit, le point critique se situe à environ $0.3 \pi$. En présence de bruit, le point critique est décalé vers le haut, mais la transition de phase est toujours observée tant que le point critique se situe en dessous de $0.5 \pi$.

exp_data.figure("normalized_variance")

Exemple de matériel à grande échelle

Après avoir validé le protocole sur un simulateur, tu peux maintenant mettre à l'échelle l'expérience et l'exécuter sur le backend de matériel quantique réel sélectionné dans la section Configuration. Cet exemple utilise deux tailles de problème plus grandes :

• Six plaquettes (~49 qubits) : une exécution de taille intermédiaire qui montre déjà le décalage vers la droite du point critique sous le bruit matériel.
• Le réseau de plaquettes complet : toutes les plaquettes que la topologie hexagonale lourde du dispositif supporte (par exemple, 18 plaquettes / 125 qubits sur ibm_torino ou 21 plaquettes / 144 qubits sur ibm_pittsburgh), intriquant des qubits à travers l'ensemble du dispositif avec des circuits de profondeur constante.

La cellule de code unique ci-dessous est autonome : elle construit le réseau de plaquettes à partir de la carte de couplage du backend et exécute les deux expériences, de sorte que cette section peut être exécutée après les cellules Configuration sans avoir d'abord exécuté la section à petite échelle.

# -------------------------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")

Total number of circuits (full lattice): 21

Note que, selon le niveau de bruit du backend utilisé, les courbes de variance normalisée aux tailles plus grandes peuvent ne pas montrer de pic clair dans la plage d'angles balayée. Dans les exécutions ci-dessus, le pic a été poussé jusqu'à $0.5 \pi$, le bord droit du balayage (l'analyse indique critical_angle = 0.5000 pour les exécutions à six plaquettes et au réseau complet). Cela signifie que le bruit matériel a décalé le point critique jusqu'à (ou juste au-delà de) la limite de la plage d'angles physiquement significative du protocole, de sorte que la transition se situe à la limite de ce que ce balayage peut résoudre.

Conclusion

Dans ce tutoriel, tu as réalisé une transition de phase de Nishimori sur un processeur quantique en utilisant le protocole GEM. Les métriques que tu as examinées lors du post-traitement — en particulier, la corrélation à deux points et la variance normalisée — servent de benchmarks de la capacité du dispositif à générer des états intriqués à longue portée. Ces benchmarks étendent l'utilité du protocole GEM au-delà de l'exploration de phénomènes physiques intéressants. Dans le cadre du protocole, tu as intriqué des qubits à travers l'ensemble du dispositif en utilisant des circuits de profondeur constante uniquement. Cet exploit n'est possible que grâce à l'utilisation par le protocole de mesures en milieu de circuit. Dans cette expérience, l'état intriqué a été immédiatement mesuré, mais envisage d'explorer davantage en utilisant cet état dans un traitement quantique supplémentaire.

Prochaines étapes

Recommandations

Si tu as trouvé ce travail intéressant, tu pourrais être intéressé par le matériel suivant :

• Intrication à longue portée avec des circuits dynamiques
• Codes de répétition
• Retour d'information classique et flux de contrôle

Références

[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. Realizing the Nishimori transition across the error threshold for constant-depth quantum circuits. arXiv:2309.02863 (2023).

[2] GEM Suite software package.