Transizione di fase di Nishimori

Stima di utilizzo: 3 minuti su un processore Heron r2 (NOTA: questa è solo una stima. Il tempo di esecuzione effettivo potrebbe variare.)

Risultati di apprendimento

Dopo aver completato questo tutorial, gli utenti possono aspettarsi i seguenti risultati:

• Comprendere la transizione di fase di Nishimori e come si manifesta come l'emergere di entanglement a lungo raggio nel modello di Ising a legami casuali.
• Implementare il protocollo generation of entanglement by measurement (GEM) su hardware quantistico utilizzando misurazioni a metà circuito e circuiti a profondità costante.
• Caratterizzare la transizione estraendo la correlazione a due punti e la varianza normalizzata della magnetizzazione dai dati sperimentali.

Prerequisiti

Prima di procedere con questo tutorial, si raccomanda familiarità con i seguenti argomenti:

• La guida Misurare i qubit, in particolare la sezione sulle misurazioni a metà circuito su cui si basa il protocollo GEM.
• Simulazione esatta e rumorosa con le primitive Qiskit Aer, che è il metodo utilizzato per la sezione su piccola scala.
• Entanglement a lungo raggio con circuiti dinamici, un tutorial complementare che utilizza lo stesso paradigma di entanglement basato su misurazioni.
• Reticolo heavy-hex, la topologia hardware IBM® su cui è costruito il reticolo di plaquette.

Contesto

Questo tutorial dimostra come realizzare una transizione di fase di Nishimori su un processore quantistico. Questo esperimento è stato originariamente descritto in Realizing the Nishimori transition across the error threshold for constant-depth quantum circuits.

La transizione di fase di Nishimori si riferisce alla transizione tra fasi ordinate a corto e lungo raggio nel modello di Ising a legami casuali. Su un computer quantistico, la fase ordinata a lungo raggio si manifesta come uno stato in cui i qubit sono intrecciati attraverso l'intero dispositivo. Questo stato altamente intrecciato viene preparato utilizzando il protocollo generation of entanglement by measurement (GEM). Utilizzando misurazioni a metà circuito, il protocollo GEM è in grado di intrecciare qubit attraverso l'intero dispositivo utilizzando circuiti di sola profondità costante. Questo tutorial utilizza l'implementazione del protocollo GEM dal pacchetto software GEM Suite.

Requisiti

Prima di iniziare questo tutorial, assicurati di avere installato quanto segue:

• Qiskit SDK v1.0 o successivo, con supporto per la visualizzazione
• Qiskit Runtime v0.22 o successivo (pip install qiskit-ibm-runtime)
• Qiskit Aer v0.14 o successivo (pip install qiskit-aer)
• GEM Suite (pip install gem-suite)

Configurazione

# 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

Esempio con simulatore su piccola scala

In questa sezione, l'intero flusso di lavoro viene eseguito sul simulatore AerSimulator privo di rumore. Il reticolo di plaquette è limitato a una singola plaquette (12 qubit) in modo che la simulazione rimanga piccola e veloce, esercitando comunque ogni parte del protocollo GEM: misurazione a metà circuito, la variazione dell'angolo $R_{ZZ}$, la decodifica e l'analisi della varianza normalizzata. Lo stesso flusso di lavoro viene poi scalato a più plaquette e all'intero reticolo su hardware reale.

Passo 1: Mappare gli input classici a un problema quantistico

Il protocollo GEM funziona su un processore quantistico con connettività dei qubit descritta da un reticolo. I processori quantistici IBM Quantum® odierni utilizzano il reticolo heavy-hex. I qubit del processore sono raggruppati in plaquette in base a quale cella unitaria del reticolo occupano. Poiché un qubit potrebbe apparire in più di una cella unitaria, le plaquette non sono disgiunte. Sul reticolo heavy-hex, una plaquette contiene 12 qubit. Le plaquette stesse formano anche un reticolo, dove due plaquette sono connesse se condividono qubit. Sul reticolo heavy-hex, le plaquette vicine condividono tre qubit.

Nel pacchetto software GEM Suite, la classe fondamentale per implementare il protocollo GEM è PlaquetteLattice, che rappresenta il reticolo di plaquette (distinto dal reticolo heavy-hex). Una PlaquetteLattice può essere inizializzata da una mappa di accoppiamento dei qubit. Attualmente, sono supportate solo le mappe di accoppiamento heavy-hex.

La seguente cella di codice inizializza un reticolo di plaquette dalla mappa di accoppiamento di un'unità di elaborazione quantistica (QPU). Il reticolo di plaquette non comprende sempre l'intero hardware. Ad esempio, ibm_torino ha 133 qubit totali, ma il più grande reticolo di plaquette che si adatta al dispositivo utilizza solo 125 di essi, comprendendo 18 plaquette; ibm_pittsburgh (156 qubit) inserisce in modo analogo 144 qubit in 21 plaquette. Lo stesso schema vale per altri QPU heavy-hex con diversi conteggi di qubit.

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

Puoi visualizzare il reticolo di plaquette generando un diagramma della sua rappresentazione grafica. Nel diagramma, le plaquette sono rappresentate da esagoni etichettati, e due plaquette sono connesse da un arco se condividono qubit.

plaquette_lattice.draw_plaquettes()

Puoi recuperare informazioni sulle singole plaquette, come i qubit che contengono, utilizzando il metodo 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])

Puoi anche produrre un diagramma dei qubit sottostanti che formano il reticolo di plaquette.

plaquette_lattice.draw_qubits()

Oltre alle etichette dei qubit e agli archi che indicano quali qubit sono connessi, il diagramma contiene tre informazioni aggiuntive rilevanti per il protocollo GEM:

• Ogni qubit è ombreggiato (grigio) o non ombreggiato. I qubit ombreggiati sono qubit "sito" che rappresentano i siti del modello di Ising, e i qubit non ombreggiati sono qubit "legame" utilizzati per mediare le interazioni tra i qubit sito.
• Ogni qubit sito è etichettato come (A) o (B), indicando uno dei due ruoli che un qubit sito può svolgere nel protocollo GEM (i ruoli sono spiegati più avanti).
• Ogni arco è colorato utilizzando uno di sei colori, partizionando così gli archi in sei gruppi. Questa partizione determina come le porte a due qubit possono essere parallelizzate, nonché i diversi schemi di schedulazione che probabilmente comporteranno diverse quantità di errore su un processore quantistico rumoroso. Poiché gli archi in un gruppo sono disgiunti, uno strato di porte a due qubit può essere applicato su quegli archi simultaneamente. È in effetti possibile partizionare i sei colori in tre gruppi di due colori tali che l'unione di ciascun gruppo di due colori sia ancora disgiunta. Pertanto, sono necessari solo tre strati di porte a due qubit per attivare ogni arco. Ci sono 12 modi per partizionare i sei colori in questo modo, e ogni tale partizione produce una diversa schedulazione di porte a tre strati.

Ora che hai creato un reticolo di plaquette, il passo successivo è inizializzare un oggetto GemExperiment, passando sia il reticolo di plaquette che il backend su cui intendi eseguire l'esperimento. La classe GemExperiment gestisce l'effettiva implementazione del protocollo GEM, inclusa la generazione di circuiti, l'invio di job e l'analisi dei dati. La seguente cella di codice inizializza la classe dell'esperimento limitando il reticolo di plaquette a una singola plaquette (12 qubit), mantenendo la simulazione piccola e veloce. L'intero reticolo di plaquette viene utilizzato in seguito per scalare su hardware reale.

# 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 circuito del protocollo GEM è costruito utilizzando i seguenti passi:

1. Preparare lo stato all-$|+\rangle$ applicando una porta di Hadamard a ogni qubit.
2. Applicare una porta $R_{ZZ}$ tra ogni coppia di qubit connessi. Puoi farlo utilizzando tre strati di porte. Ogni porta $R_{ZZ}$ agisce su un qubit sito e un qubit legame. Se il qubit sito è etichettato (B), l'angolo è fisso a $\frac{\pi}{2}$. Se il qubit sito è etichettato (A), l'angolo può variare, producendo circuiti diversi. Per impostazione predefinita, l'intervallo degli angoli è impostato su 21 punti equidistanti tra $0$ e $\frac{\pi}{2}$, inclusi.
3. Misurare ogni qubit legame nella base di Pauli $X$. Poiché i qubit sono misurati nella base di Pauli $Z$, puoi farlo applicando una porta di Hadamard prima di misurare il qubit.

Si noti che l'articolo citato nell'introduzione a questo tutorial utilizza una convenzione diversa per l'angolo $R_{ZZ}$, che differisce dalla convenzione utilizzata in questo tutorial per un fattore di 2.

Nel passo tre, vengono misurati solo i qubit legame. Per capire in quale stato rimangono i qubit sito, è istruttivo considerare il caso in cui l'angolo $R_{ZZ}$ applicato ai qubit sito (A) nel passo due sia uguale a $\frac{\pi}{2}$. In questo caso, i qubit sito rimangono in uno stato altamente intrecciato simile allo stato GHZ,

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

A causa della casualità nei risultati delle misurazioni, lo stato effettivo dei qubit sito potrebbe essere uno stato diverso con ordine a lungo raggio, ad esempio, $\lvert 00110 \rangle + \lvert 11001 \rangle$. Tuttavia, lo stato GHZ può essere recuperato applicando un'operazione di decodifica basata sui risultati delle misurazioni. Quando l'angolo $R_{ZZ}$ viene ridotto da $\frac{\pi}{2}$, l'ordine a lungo raggio può ancora essere recuperato fino a un angolo critico, che in assenza di rumore è circa $0.3 \pi$. Al di sotto di questo angolo, lo stato risultante non mostra più entanglement a lungo raggio. Questa transizione tra la presenza e l'assenza di ordine a lungo raggio è la transizione di fase di Nishimori.

Nella descrizione sopra, i qubit sito sono stati lasciati non misurati, e l'operazione di decodifica può essere eseguita applicando porte quantistiche. Nell'esperimento come implementato nella GEM Suite, i qubit sito vengono invece misurati, e l'operazione di decodifica viene applicata in un passo di post-elaborazione classica.

Nella descrizione sopra, l'operazione di decodifica può essere eseguita applicando porte quantistiche ai qubit sito per recuperare lo stato quantistico. Tuttavia, se l'obiettivo è misurare immediatamente lo stato (ad esempio, per scopi di caratterizzazione), puoi misurare i qubit sito insieme ai qubit legame e applicare l'operazione di decodifica in un passo di post-elaborazione classica.

Oltre a dipendere dall'angolo $R_{ZZ}$ nel passo due, che per impostazione predefinita varia attraverso 21 valori, il circuito del protocollo GEM dipende anche dallo schema di schedulazione utilizzato per implementare i tre strati di porte $R_{ZZ}$. Come discusso in precedenza, ci sono 12 tali schemi di schedulazione. Pertanto, il numero totale di circuiti nell'esperimento è $21 \times 12 = 252$.

I circuiti dell'esperimento possono essere generati utilizzando il metodo circuits della classe GemExperiment.

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

Total number of circuits: 252

Per gli scopi di questo tutorial, è sufficiente considerare solo un singolo schema di schedulazione. La seguente cella di codice limita l'esperimento al primo schema di schedulazione. Di conseguenza, l'esperimento ha solo 21 circuiti, uno per ogni angolo $R_{ZZ}$ variato.

# 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 seguente cella di codice disegna un diagramma del circuito all'indice 5. Per ridurre la dimensione del diagramma, le porte di misurazione alla fine del circuito vengono rimosse.

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

Passo 2: Ottimizzare il problema per l'esecuzione su hardware quantistico

La transpilazione di circuiti quantistici per l'esecuzione su hardware comporta generalmente una serie di stadi. Tipicamente, gli stadi che comportano il maggior sovraccarico computazionale sono la scelta del layout dei qubit, il routing delle porte a due qubit per conformarsi alla connettività dei qubit dell'hardware, e l'ottimizzazione del circuito per minimizzare il conteggio di porte e la profondità. Nel protocollo GEM, gli stadi di layout e routing non sono necessari perché la connettività dell'hardware è già incorporata nel design del protocollo. I circuiti hanno già un layout di qubit, e le porte a due qubit sono già mappate su connessioni native. Inoltre, per preservare la struttura del circuito mentre l'angolo $R_{ZZ}$ viene variato, dovrebbe essere eseguita solo un'ottimizzazione del circuito molto basilare.

La classe GemExperiment transpila trasparentemente i circuiti durante l'esecuzione dell'esperimento. Gli stadi di layout e routing sono già sovrascritti per impostazione predefinita per non fare nulla, e l'ottimizzazione del circuito viene eseguita a un livello che ottimizza solo le porte a singolo qubit. Tuttavia, puoi sovrascrivere o passare opzioni aggiuntive utilizzando il metodo set_transpile_options. Per scopi di visualizzazione, la seguente cella di codice transpila manualmente il circuito visualizzato in precedenza e disegna il circuito transpilato.

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

Passo 3: Eseguire utilizzando le primitive Qiskit

Per eseguire i circuiti del protocollo GEM sull'hardware, chiama il metodo run dell'oggetto GemExperiment. Puoi specificare il numero di shot che desideri campionare da ciascun circuito. Il metodo run restituisce un oggetto ExperimentData che dovresti salvare in una variabile. Si noti che il metodo run invia solo job senza aspettare che finiscano, quindi è una chiamata non bloccante.

exp_data = gem_exp.run(shots=10_000)

Per attendere i risultati, chiama il metodo block_for_results dell'oggetto ExperimentData. Questa chiamata causerà il blocco dell'interprete fino a quando i job non saranno terminati.

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

Passo 4: Post-elaborare e restituire il risultato nel formato classico desiderato

A un angolo $R_{ZZ}$ di $\frac{\pi}{2}$, lo stato decodificato sarebbe lo stato GHZ in assenza di rumore. L'ordine a lungo raggio dello stato GHZ può essere visualizzato tracciando la magnetizzazione delle stringhe di bit misurate. La magnetizzazione $M$ è definita come la somma degli operatori di Pauli $Z$ a singolo qubit,

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

dove $N$ è il numero di qubit sito. Il suo valore per una stringa di bit è uguale alla differenza tra il numero di zeri e il numero di uno. Misurare lo stato GHZ produce lo stato di tutti zeri o lo stato di tutti uno con uguale probabilità, quindi la magnetizzazione sarebbe $+N$ metà del tempo e $-N$ l'altra metà del tempo. In presenza di errori dovuti al rumore, apparirebbero anche altri valori, ma se il rumore non è troppo grande, la distribuzione si concentrerebbe ancora vicino a $+N$ e $-N$.

Per le stringhe di bit grezze prima della decodifica, la distribuzione della magnetizzazione sarebbe equivalente a quella di stringhe di bit uniformemente casuali, in assenza di rumore.

La seguente cella di codice traccia la magnetizzazione delle stringhe di bit grezze e delle stringhe di bit decodificate all'angolo $R_{ZZ}$ di $\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')

Per caratterizzare più rigorosamente l'ordine a lungo raggio, puoi esaminare la correlazione media a due punti $f$, definita come

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

Un valore più alto indica un grado maggiore di entanglement. La classe GemExperiment calcola automaticamente questo valore per le stringhe di bit decodificate come parte dell'elaborazione dei dati sperimentali. Memorizza una figura accessibile tramite il metodo figure della classe dei dati sperimentali. In questo caso, il nome della figura è two_point_correlation.

exp_data.figure("two_point_correlation")

Per determinare il punto critico della transizione di fase di Nishimori, puoi osservare la varianza normalizzata di $M^2 / N$, definita come

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

che quantifica la quantità di fluttuazione nella magnetizzazione al quadrato. Questo valore è massimizzato al punto critico della transizione di fase di Nishimori. In assenza di rumore, il punto critico si verifica a circa $0.3 \pi$. In presenza di rumore, il punto critico è spostato verso valori più alti, ma la transizione di fase è ancora osservata finché il punto critico si verifica al di sotto di $0.5 \pi$.

exp_data.figure("normalized_variance")

Esempio su larga scala con hardware reale

Dopo aver validato il protocollo su un simulatore, puoi ora scalare l'esperimento ed eseguirlo sul backend di hardware quantistico reale selezionato nella sezione Configurazione. Questo esempio utilizza due dimensioni di problema più grandi:

• Sei plaquette (~49 qubit): un'esecuzione di dimensione media che mostra già lo spostamento verso destra del punto critico sotto il rumore hardware.
• L'intero reticolo di plaquette: ogni plaquette supportata dalla topologia heavy-hex del dispositivo (ad esempio, 18 plaquette / 125 qubit su ibm_torino o 21 plaquette / 144 qubit su ibm_pittsburgh), intrecciando qubit attraverso l'intero dispositivo con circuiti a profondità costante.

La singola cella di codice qui sotto è autosufficiente: costruisce il reticolo di plaquette dalla mappa di accoppiamento del backend ed esegue entrambi gli esperimenti, quindi questa sezione può essere eseguita dopo le celle Configurazione senza dover prima eseguire la sezione su piccola scala.

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

Si noti che, a seconda del livello di rumore del backend utilizzato, le curve di varianza normalizzata alle dimensioni maggiori potrebbero non mostrare un picco chiaro nell'intervallo di angoli esplorato. Nelle esecuzioni sopra riportate, il picco è stato spostato fino a $0.5 \pi$, il bordo destro dell'intervallo di esplorazione (l'analisi riporta critical_angle = 0.5000 sia per le esecuzioni con sei plaquette che per quelle con l'intero reticolo). Ciò significa che il rumore hardware ha spostato il punto critico fino al (o appena oltre il) confine dell'intervallo di angoli fisicamente significativo del protocollo, quindi la transizione si trova al limite di ciò che questa esplorazione può risolvere.

Conclusione

In questo tutorial, hai realizzato una transizione di fase di Nishimori su un processore quantistico utilizzando il protocollo GEM. Le metriche che hai esaminato durante la post-elaborazione — in particolare, la correlazione a due punti e la varianza normalizzata — servono come benchmark della capacità del dispositivo di generare stati intrecciati a lungo raggio. Questi benchmark estendono l'utilità del protocollo GEM oltre l'esplorazione di fisica interessante. Come parte del protocollo, hai intrecciato qubit attraverso l'intero dispositivo utilizzando circuiti di sola profondità costante. Questa impresa è possibile solo grazie all'uso da parte del protocollo di misurazioni a metà circuito. In questo esperimento, lo stato intrecciato è stato immediatamente misurato, ma considera di esplorare ulteriormente utilizzando questo stato in ulteriore elaborazione quantistica.

Prossimi passi

Raccomandazioni

Se hai trovato questo lavoro interessante, potresti essere interessato al seguente materiale:

• Entanglement a lungo raggio con circuiti dinamici
• Codici di ripetizione
• Feedforward classico e flusso di controllo

Riferimenti

[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.