Transizione di fase di Nishimori

Stima del tempo di esecuzione: 3 minuti su un processore Heron r2 (NOTA: si tratta solo di una stima. (La durata potrebbe variare.)

Risultati di apprendimento

Dopo aver seguito questo tutorial, gli utenti dovrebbero ottenere i seguenti risultati:

Comprendere la transizione di fase di Nishimori e come essa si manifesti sotto forma di entanglement a lungo raggio nel modello di Ising a legami casuali.
Implementare il protocollo GEM ( Generation of Entanglement by Measurement ) su hardware quantistico utilizzando misurazioni a metà circuito e circuiti a profondità costante.
Caratterizzare la transizione estraendo dai dati sperimentali la correlazione a due punti e la varianza normalizzata della magnetizzazione.

Prerequisiti

Prima di seguire questo tutorial, ti consigliamo di acquisire familiarità con i seguenti argomenti:

La guida sui qubit di misura, in particolare la sezione dedicata alla misura a metà circuito su cui si basa il protocollo GEM.
Simulazione esatta e con rumore utilizzando le primitive di Qiskit Aer : è così che viene eseguita la sezione su piccola scala.
Entanglement a lungo raggio con circuiti dinamici, un tutorial complementare che utilizza lo stesso paradigma dell’entanglement basato sulla misurazione.
Reticolo esagonale denso, la topologia hardware “ IBM® ” su cui è basato il reticolo a plaquette.

Sfondo

Questo tutorial illustra come realizzare una transizione di fase di Nishimori su un processore quantistico. Questo esperimento è stato descritto originariamente nell'articolo “Realizing the Nishimori transition across the error threshold for constant-depth quantum circuits ”.

La transizione di fase di Nishimori indica il passaggio tra fasi ordinate a corto e a lungo raggio nel modello di Ising a legami casuali. In un computer quantistico, la fase ordinata a lungo raggio si manifesta come uno stato in cui i qubit sono intrecciati su tutta l'estensione del dispositivo. Questo stato altamente intrecciato viene preparato utilizzando il protocollo GEM ( Generation of Entanglement by Measurement ). Grazie alle misurazioni effettuate a metà circuito, il protocollo GEM è in grado di intrecciare i qubit su tutto il dispositivo utilizzando circuiti di profondità costante. Questo tutorial utilizza l'implementazione del protocollo GEM contenuta nel pacchetto software GEM Suite.

Requisiti

Prima di iniziare questa esercitazione, assicuratevi di aver installato quanto segue:

Qiskit SDK v1.0 o versioni successive, con supporto alla visualizzazione
Qiskit Runtime v0.22 o versioni successive (pip install qiskit-ibm-runtime)
Qiskit Aer v0.14 o versione successiva (pip install qiskit-aer)
GEM Suite (pip install gem-suite)

Configura

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 di simulatore su piccola scala

AerSimulatorIn questa sezione viene illustrato in dettaglio l'intero flusso di lavoro su. Il reticolo a placchette è limitato a una singola placchetta (12 qubit), in modo che la simulazione rimanga di dimensioni ridotte e veloce, pur mettendo alla prova ogni parte del protocollo GEM: misurazione a metà circuito, scansione dell’angolo di “ $R_{ZZ}$ ”, decodifica e analisi della varianza normalizzata. Lo stesso flusso di lavoro viene successivamente esteso a più plaquette e all’intero reticolo su hardware reale.

Fase 1: mappare gli input classici su un problema quantistico

Il protocollo GEM funziona su un processore quantistico in cui la connettività dei qubit è descritta da un reticolo. I processori " IBM Quantum® " odierni utilizzano il reticolo a esagoni pesanti. I qubit presenti sul processore sono raggruppati in plaquette in base alla cella unitaria del reticolo che occupano. Poiché un qubit può trovarsi in più di una cella unitaria, le placchette non sono disgiunte. Sul reticolo a esagoni pesanti, una placchetta contiene 12 qubit. Anche le plaquette stesse formano reticoli, in cui due plaquette sono collegate se condividono dei qubit. Sul reticolo a esagoni pesanti, le placchette adiacenti condividono tre qubit.

Nel pacchetto software GEM Suite, la classe fondamentale per l'implementazione del protocollo GEM è PlaquetteLattice, che rappresenta il reticolo delle plaquette (distinto dal reticolo heavy-hex). A PlaquetteLattice può essere inizializzato a partire da una mappa di accoppiamento dei qubit. Al momento sono supportate solo le mappe di accoppiamento con esagoni pesanti.

La seguente cella di codice inizializza un reticolo a placchette a partire dalla mappa di accoppiamento di un'unità di elaborazione quantistica (QPU). Il reticolo a placchette non sempre copre l'intero hardware. Ad esempio, ibm_torino dispone di 133 qubit in totale, ma il reticolo di plaquette più grande che può essere contenuto nel dispositivo ne utilizza solo 125, suddivisi in 18 plaquette; ibm_pittsburgh (156 qubit) allo stesso modo riesce a contenere 144 qubit in 21 plaquette. Lo stesso schema vale anche per altre QPU a esagoni pesanti con un numero diverso di qubit.

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

È possibile 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 collegate da un bordo se condividono dei qubit.

plaquette_lattice.draw_plaquettes()

Output:

È possibile 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]

Output:

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

È inoltre possibile produrre un diagramma dei qubit sottostanti che formano il reticolo di plaquette.

plaquette_lattice.draw_qubits()

Output:

Oltre alle etichette dei qubit e agli spigoli che indicano quali qubit sono collegati, il diagramma contiene altre tre informazioni 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, mentre i qubit non ombreggiati sono qubit "legame" usati per mediare le interazioni tra i qubit sito.
Ogni qubit del sito è etichettato con (A) o (B), a indicare uno dei due ruoli che un qubit del sito può svolgere nel protocollo GEM (i ruoli sono spiegati più avanti).
Ogni spigolo è colorato con uno dei sei colori, suddividendo così gli spigoli in sei gruppi. Questa suddivisione determina in che modo è possibile parallelizzare le porte a due qubit, nonché i diversi schemi di schedulazione che potrebbero comportare livelli di errore variabili su un processore quantistico soggetto a rumore. Poiché i bordi di un gruppo sono disgiunti, è possibile applicare contemporaneamente su tali bordi uno strato di porte a due qubit. Infatti, è possibile suddividere i sei colori in tre gruppi di due colori ciascuno, in modo tale che l'unione di ciascun gruppo di due colori rimanga disgiunta. Pertanto, sono sufficienti solo tre livelli di porte a due qubit per attivare ogni bordo. Esistono 12 modi per suddividere i sei colori in questo modo, e ciascuna di queste suddivisioni produce una diversa sequenza di gate a tre livelli.

Ora che hai creato un reticolo a plaquette, il passo successivo consiste nell'inizializzare un GemExperiment oggetto, passando sia il reticolo a plaquette sia il backend su cui intendi eseguire l'esperimento. La GemExperiment classe gestisce l'implementazione effettiva del protocollo GEM, compresa la generazione dei circuiti, l'invio dei lavori e l'analisi dei dati. La seguente cella di codice inizializza la classe dell'esperimento, limitando al contempo il reticolo di plaquette a una singola plaquette (12 qubit), in modo da garantire che la simulazione rimanga di dimensioni ridotte e veloce. Il reticolo a placchette completo viene utilizzato in seguito, quando si passa all'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()

Output:

Il circuito del protocollo GEM si costruisce con i seguenti passaggi:

Preparare lo stato all- $|+\rangle$ applicando un gate Hadamard a ogni qubit.
Applicare un gate di tipo “ $R_{ZZ}$ ” tra ogni coppia di qubit collegati. È possibile farlo utilizzando tre livelli di porte logiche. Ogni porta di tipo “ $R_{ZZ}$ ” agisce su un qubit di sito e su un qubit di legame. Se il qubit di sito è contrassegnato con (B), l'angolo è fissato a $\frac{\pi}{2}$ . Se il qubit di sito è contrassegnato con (A), l'angolo può variare, generando circuiti diversi. Per impostazione predefinita, l'intervallo angolare è impostato su 21 punti equidistanti compresi tra $0$ e $\frac{\pi}{2}$ , inclusi.
Misurare ciascun qubit di legame nella base di Pauli $X$ . Poiché i qubit vengono misurati nella base di Pauli $Z$ , è possibile farlo applicando un gate di Hadamard prima di misurare il qubit.

Si noti che il documento citato nell'introduzione di questa esercitazione utilizza una convenzione diversa per l'angolo $R_{ZZ}$ , che differisce dalla convenzione utilizzata in questa esercitazione di un fattore 2.

Nella fase tre vengono misurati solo i qubit di legame. Per comprendere in quale stato rimangano i qubit di sito, è utile considerare il caso in cui l’angolo di $R_{ZZ}$ e applicato ai qubit di sito (A) nella fase due sia pari a $\frac{\pi}{2}$ . In questo caso, i qubit di 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à dei risultati delle misurazioni, lo stato effettivo dei qubit del sistema potrebbe essere uno stato diverso caratterizzato da un ordine a lungo raggio, ad esempio $\lvert 00110 \rangle + \lvert 11001 \rangle$ . Tuttavia, lo stato GHZ può essere ricostruito applicando un’operazione di decodifica basata sui risultati delle misurazioni. Quando l'angolo dell' $R_{ZZ}$ e viene ridotto da $\frac{\pi}{2}$ , l'ordine a lungo raggio può comunque essere ripristinato fino a un angolo critico, che in assenza di rumore è approssimativamente pari a $0.3 \pi$ . Al di sotto di tale angolo, lo stato risultante non presenta più entanglement a lungo raggio. Questa transizione tra la presenza e l'assenza di un ordine a lungo raggio è la transizione di fase di Nishimori.

Nella descrizione sopra riportata, i qubit del sito non sono stati misurati e l'operazione di decodifica può essere eseguita applicando porte quantistiche. Nell'esperimento così come è stato implementato nella suite GEM, i qubit del sito vengono effettivamente misurati e l'operazione di decodifica viene applicata in una fase di post-elaborazione classica.

Nella descrizione sopra riportata, l'operazione di decodifica può essere eseguita applicando porte quantistiche ai qubit del sito per ricostruire lo stato quantistico. Tuttavia, se l'obiettivo è misurare immediatamente lo stato (ad esempio, a fini di caratterizzazione), è possibile misurare i qubit di sito insieme ai qubit di legame e applicare l'operazione di decodifica in una fase di post-elaborazione classica.

Oltre a dipendere dall’angolo dell’ $R_{ZZ}$ e nella fase due, che per impostazione predefinita varia tra 21 valori, il circuito del protocollo GEM dipende anche dallo schema di programmazione utilizzato per implementare i tre livelli di porte “ $R_{ZZ}$ ”. Come già detto in precedenza, esistono 12 modelli di programmazione di questo tipo. Pertanto, il numero totale di circuiti nell'esperimento è pari a $21 \times 12 = 252$ o.

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

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

Output:

Total number of circuits: 252

Ai fini di questa esercitazione, è sufficiente considerare un solo modello di schedulazione. La cella di codice seguente limita l'esperimento al primo modello di schedulazione. Di conseguenza, l'esperimento dispone di soli 21 circuiti, uno per ogni angolo di $R_{ZZ}$ sorvolato.

# 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 seguente cella di codice disegna il diagramma del circuito all'indice 5. Per ridurre le dimensioni del diagramma, le porte di misura alla fine del circuito sono state 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)

Output:

Fase 2: Ottimizzazione del problema per l'esecuzione su hardware quantistico

La transpilazione dei circuiti quantistici per l'esecuzione su hardware comporta generalmente una serie di fasi. In genere, le fasi che comportano il maggior carico computazionale sono la scelta della disposizione dei qubit, l'instradamento delle porte a due qubit in modo che rispettino la connettività dei qubit dell'hardware e l'ottimizzazione del circuito per ridurre al minimo il numero di porte e la profondità. Nel protocollo GEM, le fasi di layout e instradamento non sono necessarie poiché la connettività hardware è già integrata nella progettazione del protocollo. I circuiti presentano già una configurazione a qubit e le porte a due qubit sono già mappate sulle connessioni native. Inoltre, al fine di preservare la struttura del circuito al variare dell'angolo d' $R_{ZZ}$ e, è opportuno eseguire solo un'ottimizzazione di base del circuito.

La classe GemExperiment trasporta in modo trasparente i circuiti durante l'esecuzione dell'esperimento. Le fasi di layout e routing sono già sovrascritte per impostazione predefinita per non fare nulla e l'ottimizzazione dei circuiti viene eseguita a un livello che ottimizza solo le porte a singolo qubit. Tuttavia, è possibile sovrascrivere o passare opzioni aggiuntive utilizzando il metodo set_transpile_options . Per motivi di visualizzazione, la seguente cella di codice traspone manualmente il circuito visualizzato in precedenza e disegna il circuito traspilato.

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

Passaggio 3: eseguire utilizzando Qiskit primitives

Per eseguire i circuiti del protocollo GEM sull'hardware, richiamate il metodo run dell'oggetto GemExperiment . È possibile specificare il numero di scatti che si desidera campionare da ciascun circuito. Il metodo run restituisce un ExperimentData che deve essere salvato in una variabile. Si noti che il metodo run invia solo i lavori senza aspettare che finiscano, quindi è una chiamata non bloccante.

exp_data = gem_exp.run(shots=10_000)

Per attendere i risultati, richiamare il metodo block_for_results dell'oggetto ExperimentData . Questa chiamata fa sì che l'interprete si blocchi finché i lavori non sono 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

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

Fase 4: Post-elaborazione e restituzione del risultato nel formato classico desiderato

Con 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 somma degli operatori di Pauli $Z$ a singolo qubit,

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

dove $N$ è il numero di qubit del sito. Il suo valore, per una stringa di bit, è pari alla differenza tra il numero di zeri e il numero di uno. La misurazione dello stato GHZ produce con uguale probabilità lo stato "tutti zeri" o lo stato "tutti uno", quindi la magnetizzazione sarebbe $+N$ per metà del tempo e $-N$ per l'altra metà. In presenza di errori dovuti al rumore, comparirebbero anche altri valori, ma se il rumore non è troppo elevato, la distribuzione continuerebbe comunque a raggiungere il picco in prossimità di $+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 cella di codice seguente traccia la magnetizzazione delle stringhe di bit grezze e delle stringhe 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")

Output:

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

Per caratterizzare in modo più rigoroso l'ordine a lungo raggio, si può 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 maggior grado di entanglement. La classe GemExperiment calcola automaticamente questo valore per le stringhe decodificate durante l'elaborazione dei dati sperimentali. Memorizza una figura accessibile tramite il metodo figure della classe di dati dell'esperimento. In questo caso, il nome della figura è two_point_correlation.

exp_data.figure("two_point_correlation")

Output:

Per determinare il punto critico della transizione di fase di Nishimori, si può 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 della magnetizzazione al quadrato. Questo valore è massimizzato nel punto critico della transizione di fase Nishimori. In assenza di rumore, il punto critico si verifica a circa $0.3 \pi$ . In presenza di rumore, il punto critico è spostato più in alto, 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")

Output:

Esempio di hardware su larga scala

Dopo aver verificato il protocollo su un simulatore, è ora possibile estendere la portata dell'esperimento ed eseguirlo sul backend hardware quantistico reale selezionato nella sezione "Setup ". In questo esempio vengono utilizzate due dimensioni del problema più grandi:

Sei plaquette (~49 qubit) : una serie di medie dimensioni che mostra già lo spostamento verso destra del punto critico in presenza di rumore hardware.
Il reticolo completo di plaquette : tutte le plaquette supportate dalla topologia “heavy-hex” del dispositivo (ad esempio, 18 plaquette / 125 qubit su ibm_torino o 21 plaquette / 144 qubit su ibm_pittsburgh), che consentono l’entanglement dei qubit su tutto il dispositivo tramite circuiti a profondità costante.

La singola cella di codice riportata di seguito è autonoma: costruisce il reticolo a placchette a partire dalla mappa di accoppiamento del backend ed esegue entrambi gli esperimenti; pertanto, questa sezione può essere eseguita dopo le celle di 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")

Output:

Total number of circuits (full lattice): 21

Si noti che, a seconda del livello di rumore del backend utilizzato, le curve della varianza normalizzata alle dimensioni maggiori potrebbero non mostrare un picco evidente all'interno dell'intervallo di angolo di scansione. Nelle simulazioni sopra riportate, il picco è stato spostato fino a $0.5 \pi$ , il bordo destro dell'intervallo di variazione (come riportato critical_angle = 0.5000 nei rapporti di analisi sia per le simulazioni a sei plaquette che per quelle a reticolo completo). Ciò significa che il rumore dell'hardware ha spostato il punto critico al limite (o appena oltre) dell'intervallo angolare fisicamente significativo del protocollo, per cui la transizione si trova al limite di ciò che questa scansione è in grado di risolvere.

Conclusione

In questo tutorial hai realizzato una transizione di fase di Nishimori su un processore quantistico utilizzando il protocollo GEM. Le metriche che avete esaminato durante la post-elaborazione — in particolare, la correlazione a due punti e la varianza normalizzata — fungono da parametri di riferimento per valutare la capacità del dispositivo di generare stati intrecciati a lungo raggio. Questi test di riferimento ampliano l'utilità del protocollo GEM oltre l'analisi di fenomeni fisici di interesse. Nell'ambito del protocollo, avete intrecciato i qubit su tutto il dispositivo utilizzando circuiti di profondità costante. Questo risultato è possibile solo grazie all'utilizzo, da parte del protocollo, di misurazioni a metà percorso. In questo esperimento, lo stato intrecciato è stato misurato immediatamente, ma si potrebbe valutare la possibilità di approfondire l'analisi utilizzando questo stato in ulteriori operazioni di elaborazione quantistica.

Passi successivi

Suggerimenti

Se questo lavoro ti è sembrato interessante, potrebbero interessarti anche i seguenti contenuti:

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. Realizzazione della transizione di Nishimori al di là della soglia di errore per circuiti quantistici a profondità costante. arXiv:2309.02863 (2023).

[2]. Pacchetto software GEM Suite.

Questa pagina è stata utile?

Segnala un bug, un errore di battitura o richiedi contenuti su GitHub.