Skip to main content
IBM Quantum Platform

Transition de phase de Nishimori

Estimation de la durée d'exécution : 3 minutes sur un processeur Heron r2 (REMARQUE : il s'agit uniquement d'une estimation. (La durée d'exécution peut varier.)


Acquis d'apprentissage

À l'issue de ce tutoriel, les utilisateurs devraient obtenir les résultats suivants :

  • Comprendre la transition de phase de Nishimori et la manière dont elle se manifeste par l'apparition d'un enchevêtrement à longue portée dans le modèle d'Ising à liaisons aléatoires.
  • Mettre en œuvre le protocole de génération d'intrication par mesure (GEM) sur du matériel quantique à l'aide de mesures en cours de circuit et de circuits à profondeur constante.
  • Caractériser la transition en calculant la corrélation à deux points et la variance normalisée de la magnétisation à partir des données expérimentales.

Prérequis

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


Arrière-plan

Ce tutoriel explique comment réaliser une transition de phase de Nishimori sur un processeur quantique. Cette expérience a été décrite pour la première fois dans l'article intitulé « Realizing the Nishimori transition across the error threshold for constant-depth quantum circuits ».

La transition de phase de Nishimori désigne 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 par un état dans lequel les qubits sont intriqués à l'échelle de l'ensemble du dispositif. Cet état fortement intriqué est préparé à l'aide du protocole de génération d'intrication par mesure (GEM). Grâce à des mesures effectuées à mi-parcours, le protocole GEM permet d'intricer des qubits sur l'ensemble du dispositif en utilisant uniquement des circuits de profondeur constante. Ce tutoriel utilise l'implémentation du protocole GEM fournie par la suite logicielle GEM Suite.


Exigences

Avant de commencer ce tutoriel, assurez-vous que les éléments suivants sont installés :

  • Qiskit SDK v1.0 ou plus tard, avec prise en charge de la visualisation
  • Qiskit Runtime v0.22 ou version ultérieure (pip install qiskit-ibm-runtime)
  • Qiskit Aer v0.14 ou version ultérieure (pip install qiskit-aer)
  • GEM Suite (pip install gem-suite)

Configuration

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

AerSimulatorDans cette section, le déroulement complet du processus est présenté sur le format sans bruit. Le réseau de plaquettes est limité à une seule plaquette (12 qubits), ce qui permet de conserver une simulation de petite taille et rapide, tout en mettant en œuvre l'ensemble des étapes du protocole GEM : mesure en cours de circuit, balayage de l'angle d' RZZR_{ZZ}, décodage et analyse de la variance normalisée. Ce même flux de travail est ensuite étendu à plusieurs plaquettes, puis à l'ensemble du réseau, sur du matériel réel.

Étape 1 : Mettre en correspondance les entrées classiques avec 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 « IBM Quantum® » actuels utilisent le réseau hexagonal dense. Les qubits du processeur sont regroupés en plaquettes en fonction de la cellule élémentaire du réseau qu'ils occupent. Étant donné qu'un qubit peut se trouver dans plusieurs cellules unitaires, les plaquettes ne sont pas disjointes. Sur le réseau hexagonal dense, une plaquette contient 12 qubits. Les plaquettes elles-mêmes forment également des réseaux, dans lesquels deux plaquettes sont reliées si elles partagent des qubits. Sur le réseau hexagonal dense, les plaquettes voisines partagent trois qubits.

Dans la suite logicielle GEM Suite, la classe fondamentale permettant de mettre en œuvre le protocole GEM est PlaquetteLattice, qui représente le réseau de plaquettes (à ne pas confondre avec le réseau « heavy-hex »). A PlaquetteLattice peut être initialisé à partir d'une carte de couplage de qubits. À l'heure actuelle, seules les cartes de couplage « heavy-hex » 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 ne recouvre pas toujours l'ensemble du matériel. Par exemple, ibm_torino dispose au total de 133 qubits, mais le plus grand réseau de plaquettes pouvant tenir sur le dispositif n’en utilise que 125, répartis sur 18 plaquettes; ibm_pittsburgh (156 qubits) intègre de la même manière 144 qubits dans 21 plaquettes. La même tendance s'observe pour d'autres QPU à structure hexagonale dense comportant un nombre différent de qubits.

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

Vous pouvez visualiser le treillis de plaquettes en générant un diagramme de sa représentation graphique. 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()

Output:

Output of the previous code cell

Vous pouvez obtenir des informations sur des plaquettes individuelles, telles que les qubits qu'elles contiennent, à l'aide de la méthode plaquettes .

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

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

plaquette_lattice.draw_qubits()

Output:

Output of the previous code cell

Outre les étiquettes des qubits et les arêtes indiquant les qubits 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 "sites" qui représentent les sites du modèle d'Ising, et les qubits non ombrés sont des qubits "liens" utilisés pour médier les interactions entre les qubits sites.
  • Chaque qubit de site est étiqueté (A) ou (B), indiquant l'un des deux rôles qu'un qubit de site peut jouer dans le protocole GEM (les rôles sont expliqués plus loin).
  • Chaque arête est colorée selon l'une des six couleurs, ce qui permet de répartir les arêtes en six groupes. Ce découpage détermine la manière dont les portes à deux qubits peuvent être parallélisées, ainsi que les différents schémas de planification susceptibles d'entraîner des niveaux d'erreur variables sur un processeur quantique soumis à du bruit. Les arêtes d'un groupe étant disjointes, il est possible d'appliquer simultanément une couche de portes à deux qubits sur ces arêtes. En effet, il est possible de répartir les six couleurs en trois groupes de deux couleurs de telle 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 bord. Il existe 12 façons de répartir les six couleurs de cette manière, et chacune de ces répartitions donne lieu à un programme de portes à trois couches différent.

Maintenant que vous avez créé un réseau de plaquettes, l'étape suivante consiste à initialiser un GemExperiment objet en lui transmettant à la fois le réseau de plaquettes et le backend sur lequel vous comptez exécuter l'expérience. Cette GemExperiment classe gère la mise en œuvre concrète du protocole GEM, notamment la génération de circuits, l'envoi de tâches et l'analyse des données. Le bloc de code suivant initialise la classe d'expérience tout en limitant le réseau de plaquettes à une seule plaquette (12 qubits), ce qui permet de conserver une simulation de petite taille et rapide. Le réseau de plaquettes complet est utilisé par la suite lors du passage à l'échelle réelle sur du matériel physique.

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

Output of the previous code cell

Un circuit de 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. Appliquez une porte « RZZR_{ZZ} » entre chaque paire de qubits connectés. Pour ce faire, vous pouvez utiliser trois niveaux de portes logiques. Chaque porte « RZZR_{ZZ} » agit sur un qubit de site et un qubit de liaison. Si le qubit de site est identifié par (B), l'angle est alors fixé à π2\frac{\pi}{2}. Si le qubit de site est identifié par (A), l'angle peut varier, ce qui permet d'obtenir différents circuits. Par défaut, la plage d'angles est définie sur 21 points équidistants compris entre 00 et π2\frac{\pi}{2}, inclus.
  3. Mesurer chaque qubit de liaison dans la base d' XX s de Pauli. Comme les qubits sont mesurés dans la base d' ZZ s de Pauli, vous pouvez y parvenir en appliquant une porte de Hadamard avant de mesurer le qubit.

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

À la troisième étape, seuls les qubits de liaison sont mesurés. Pour comprendre dans quel état se trouvent les qubits de site, il est utile d'envisager le cas où l'angle d' RZZR_{ZZ} ion appliqué aux qubits de site (A) à la deuxième étape est égal à π2\frac{\pi}{2}. Dans ce cas, les qubits de site se retrouvent dans un état fortement intriqué, similaire à l'état GHZ,

GHZ=0000+1111.\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 du site pourrait être un état différent présentant un ordre à longue portée, par exemple 00110+11001\lvert 00110 \rangle + \lvert 11001 \rangle. Cependant, l'état GHZ peut être reconstitué en appliquant une opération de décodage basée sur les résultats de mesure. Lorsque l'angle d' RZZR_{ZZ} est réduit à partir de π2\frac{\pi}{2}, l'ordre à longue portée peut encore être rétabli jusqu'à un angle critique qui, en l'absence de bruit, est d'environ 0.3π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 de site n'ont pas été mesurés, et l'opération de décodage peut être effectuée en appliquant des portes quantiques. Dans l'expérience telle qu'elle est mise en œuvre dans la suite GEM, les qubits de site sont en effet 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 réalisée en appliquant des portes quantiques aux qubits du site afin de reconstituer l'état quantique. Toutefois, si l'objectif est de mesurer immédiatement l'état (par exemple, à des fins de caractérisation), il est alors possible de mesurer les qubits de site en même temps que les qubits de liaison, puis d'appliquer l'opération de décodage lors d'une étape de post-traitement classique.

Outre l'angle d' RZZR_{ZZ}, défini à l'étape 2 et qui, par défaut, balaye 21 valeurs, le circuit du protocole GEM dépend également du schéma de planification utilisé pour mettre en œuvre les trois couches de portes d' RZZR_{ZZ}. Comme nous l'avons vu précédemment, il existe 12 modèles de planification de ce type. Par conséquent, le nombre total de circuits dans l'expérience est de 21×12=25221 \times 12 = 252 s.

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

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

Output:

Total number of circuits: 252

Pour les besoins de ce tutoriel, il suffit de considérer un seul modèle d'ordonnancement. La cellule de code suivante limite l'expérience au premier modèle d'ordonnancement. Par conséquent, l'expérience ne comporte que 21 circuits, un pour chaque angle RZZR_{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()}")

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]

La cellule de code suivante dessine un schéma du circuit à l'index 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)

Output:

Output of the previous code cell

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

La compilation des circuits quantiques en vue de leur exécution sur du matériel comporte généralement plusieurs étapes. En règle générale, les étapes qui génèrent la plus grande charge de calcul sont le choix de la disposition des qubits, l'acheminement des portes à deux qubits afin de s'adapter à la connectivité des qubits du matériel, et l'optimisation du circuit pour réduire au minimum le nombre de portes et sa profondeur. Dans le protocole GEM, les étapes de disposition et de routage ne sont pas nécessaires, car la connectivité matérielle est déjà intégrée à la conception du protocole. Les circuits comportent déjà une configuration de qubits, et les portes à deux qubits sont déjà mappées sur des connexions natives. De plus, afin de préserver la structure du circuit lorsque l'angle d' RZZR_{ZZ} est modifié, il convient de ne procéder qu'à une optimisation très basique du circuit.

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

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

Output of the previous code cell

Étape 3 : Exécutez à l'aide d' Qiskit primitives

Pour exécuter les circuits du protocole GEM sur le matériel, appelez la méthode run de l'objet GemExperiment . Vous pouvez spécifier le nombre de prises de vue que vous souhaitez échantillonner dans chaque circuit. La méthode run renvoie un objet ExperimentData que vous devez enregistrer dans une variable. Notez que la méthode run ne fait que soumettre des travaux sans attendre qu'ils se terminent, il s'agit donc d'un appel non bloquant.

exp_data = gem_exp.run(shots=10_000)

Pour attendre les résultats, appelez la méthode block_for_results de l'objet ExperimentData . Cet appel entraîne la suspension de l'interprète jusqu'à ce que les travaux soient terminés.

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

Étape 4 : Post-traitement et restitution du résultat dans le format classique souhaité

À un angle de RZZR_{ZZ} de π2\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 MM est définie comme la somme des opérateurs de Pauli ZZ à qubit unique,

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

NN correspond au nombre de qubits du 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. La mesure de l'état GHZ donne, avec une probabilité égale, soit l'état « tout zéros », soit l'état « tout uns »; ainsi, la magnétisation serait de +N+N la moitié du temps et de N-N l'autre moitié du temps. En présence d'erreurs dues au bruit, d'autres valeurs pourraient également apparaître, mais si le bruit n'est pas trop important, la distribution atteindrait tout de même son maximum aux valeurs +N+N et N-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 représente la magnétisation des chaînes de bits brutes et des chaînes de bits décodées à l'angle RZZR_{ZZ} de π2\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")

Output:

Text(0.5, 1.0, 'Magnetization distribution with and without decoding')
Output of the previous code cell

Pour caractériser plus rigoureusement l'ordre à longue portée, vous pouvez examiner la corrélation moyenne à deux points ff, définie comme suit

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

Une valeur plus élevée indique un degré d'enchevêtrement 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. Il stocke une figure accessible via la méthode figure de la classe de données d'expérience. Dans ce cas, le nom de la figure est two_point_correlation.

exp_data.figure("two_point_correlation")

Output:

Output of the previous code cell

Pour déterminer le point critique de la transition de phase de Nishimori, vous pouvez examiner la variance normalisée de M2/NM^2 / N, définie comme suit

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

qui quantifie l'importance de la fluctuation de l'aimantation au carré. Cette valeur est maximale au point critique de la transition de phase de Nishimori. En l'absence de bruit, le point critique se situe approximativement à 0.3π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π0.5 \pi.

exp_data.figure("normalized_variance")

Output:

Output of the previous code cell

Exemple de matériel à grande échelle

Après avoir validé le protocole sur un simulateur, vous pouvez désormais passer à une échelle supérieure et exécuter l'expérience sur le matériel quantique réel sélectionné dans la section « Configuration ». Cet exemple utilise deux problèmes de plus grande envergure :

  • Six plaquettes (environ 49 qubits) : une série de taille moyenne qui montre déjà le décalage vers la droite du point critique sous l'effet du bruit matériel.
  • Le réseau complet de plaquettes : toutes les plaquettes prises en charge par la topologie « heavy-hex » du dispositif (par exemple, 18 plaquettes / 125 qubits sur ibm_torino ou 21 plaquettes / 144 qubits sur ibm_pittsburgh), permettant d’intricer les qubits sur l’ensemble du dispositif à l’aide de circuits à profondeur constante.

La cellule de code 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; cette section peut donc être exécutée après les cellules de configuration, sans qu'il soit nécessaire d'exécuter au préalable 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")

Output:

Total number of circuits (full lattice): 21
Output of the previous code cell Output of the previous code cell Output of the previous code cell

Il convient de noter que, selon le niveau de bruit du backend utilisé, les courbes de variance normalisée pour les grandes tailles peuvent ne pas présenter de pic net dans la plage d'angles balayée. Dans les simulations ci-dessus, le pic a été repoussé jusqu’à 0.5π0.5 \pi, soit le bord droit de la plage d’analyse (les rapports critical_angle = 0.5000 d’analyse concernent à la fois les simulations à six plaquettes et celles sur le réseau complet). Cela signifie que le bruit matériel a décalé le point critique vers (ou juste au-delà de) la limite de la plage d'angles physiquement significative du protocole; la transition se situe donc à la limite de ce que ce balayage est capable de résoudre.


Conclusion

Dans ce tutoriel, vous avez réalisé une transition de phase de Nishimori sur un processeur quantique à l'aide du protocole GEM. Les paramètres que vous avez analysés lors du post-traitement — notamment la corrélation en deux points et la variance normalisée — servent de repères pour évaluer la capacité du dispositif à générer des états intriqués à longue portée. Ces tests de performance élargissent le champ d'application du protocole GEM au-delà de l'étude de phénomènes physiques intéressants. Dans le cadre de ce protocole, vous avez mis en corrélation des qubits sur l'ensemble du dispositif à l'aide de circuits de profondeur constante uniquement. Cet exploit n'est possible que grâce à l'utilisation, par le protocole, de mesures en cours de transmission. Dans cette expérience, l'état intriqué a été mesuré immédiatement, mais on pourrait envisager d'approfondir la recherche en utilisant cet état dans d'autres traitements quantiques.


Etapes suivantes

Recommandations

Si ce travail vous a paru intéressant, les documents suivants pourraient vous intéresser :


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. Réalisation de la transition de Nishimori au-delà du seuil d'erreur pour des circuits quantiques à profondeur constante. arXiv:2309.02863 (2023).

[2.] La suite logicielle GEM.

Cette page a-t-elle été utile ?
Signaler un bogue, une coquille ou proposer du contenu sur GitHub.