Transição de fase de Nishimori

Estimativa de tempo de execução: 3 minutos em um processador Heron r2 (NOTA: Trata-se apenas de uma estimativa.) (O tempo de execução pode variar.)

Resultados do aprendizado

Após concluir este tutorial, os usuários devem esperar os seguintes resultados:

Compreender a transição de fase de Nishimori e como ela se manifesta como o surgimento de entrelaçamento de longo alcance no modelo de Ising com ligações aleatórias.
Implementar o protocolo de geração de entrelaçamento por medição (GEM) em hardware quântico, utilizando medições no meio do circuito e circuitos de profundidade constante.
Caracterize a transição por meio da extração da correlação de dois pontos e da variância normalizada da magnetização a partir dos dados experimentais.

Pré-requisitos

Recomendamos que você esteja familiarizado com os seguintes tópicos antes de seguir com este tutorial:

O guia sobre qubits de medição, em especial a seção sobre medição no meio do circuito, na qual o protocolo GEM se baseia.
Simulação exata e com ruído utilizando primitivas do Qiskit Aer, que é como a seção em pequena escala é executada.
Entrelaciamento de longo alcance com circuitos dinâmicos, um tutorial complementar que utiliza o mesmo paradigma de entrelaciamento baseado em medição.
Rede hexagonal pesada, a topologia de hardware do “ IBM® ” na qual a rede de plaquetas se baseia.

Segundo plano

Este tutorial demonstra como realizar uma transição de fase de Nishimori em um processador quântico. Este experimento foi descrito originalmente no artigo “Realizing the Nishimori transition across the error threshold for constant-depth quantum circuits ”.

A transição de fase de Nishimori refere-se à transição entre as fases ordenadas de curto e longo alcance no modelo de Ising com ligações aleatórias. Em um computador quântico, a fase ordenada de longo alcance se manifesta como um estado no qual os qubits estão entrelaçados em todo o dispositivo. Esse estado altamente entrelaçado é preparado por meio do protocolo de geração de entrelaçamento por medição (GEM). Ao utilizar medições no meio do circuito, o protocolo GEM é capaz de entrelaçar qubits em todo o dispositivo utilizando circuitos de profundidade constante. Este tutorial utiliza a implementação do protocolo GEM do pacote de software GEM Suite.

Requisitos

Antes de iniciar este tutorial, verifique se você tem os seguintes itens instalados:

Qiskit SDK v1.0 ou posterior, com suporte para visualização
Qiskit Runtime v0.22 ou posterior (pip install qiskit-ibm-runtime)
Qiskit Aer v0.14 ou versão posterior (pip install qiskit-aer)
GEM Suite (pip install gem-suite)

Instalação

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

Exemplo de simulador em pequena escala

AerSimulatorNesta seção, é apresentado passo a passo todo o fluxo de trabalho no noiseless. A rede de plaquetas é restrita a uma única plaqueta (12 qubits), de modo que a simulação permanece pequena e rápida, ao mesmo tempo em que abrange todas as etapas do protocolo GEM: medição no meio do circuito, varredura do ângulo de $R_{ZZ}$ , decodificação e análise da variância normalizada. Posteriormente, esse mesmo fluxo de trabalho é ampliado para várias plaquetas e para toda a rede em hardware real.

Passo 1: Mapear entradas clássicas para um problema quântico

O protocolo GEM opera em um processador quântico cuja conectividade entre qubits é descrita por uma rede. Os processadores “ IBM Quantum® ” atuais utilizam a rede hexagonal pesada. Os qubits no processador são agrupados em plaquetas, dependendo da célula unitária da rede que ocupam. Como um qubit pode ocorrer em mais de uma célula unitária, as plaquetas não são disjuntas. Na rede hexagonal densa, uma plaqueta contém 12 qubits. As próprias plaquetas também formam redes, nas quais duas plaquetas estão conectadas se compartilharem quaisquer qubits. Na rede hexagonal pesada, as plaquetas vizinhas compartilham três qubits.

No pacote de software GEM Suite, a classe fundamental para a implementação do protocolo GEM é PlaquetteLattice, que representa a rede de plaquetas (que é distinta da rede de hexágonos pesados). A PlaquetteLattice pode ser inicializada a partir de um mapa de acoplamento de qubits. Atualmente, apenas mapas de acoplamento do tipo “heavy-hex” são suportados.

A célula de código a seguir inicializa uma rede de plaquetas a partir do mapa de acoplamento de uma unidade de processamento quântico (QPU). A malha de placas nem sempre abrange todo o hardware. Por exemplo, ibm_torino possui 133 qubits no total, mas a maior rede de plaquetas que cabe no dispositivo utiliza apenas 125 deles, compreendendo 18 plaquetas; ibm_pittsburgh (156 qubits) também acomoda 144 qubits em 21 plaquetas. O mesmo padrão se aplica a outras QPUs com hexágonos pesados e números diferentes 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()))}")

Você pode visualizar a rede de plaquetas gerando um diagrama de sua representação gráfica. No diagrama, as plaquetas são representadas por hexágonos rotulados, e duas plaquetas são conectadas por uma borda se compartilharem qubits.

plaquette_lattice.draw_plaquettes()

Output:

Você pode recuperar informações sobre plaquetas individuais, como os qubits que elas contêm, usando o método 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])

Você também pode produzir um diagrama dos qubits subjacentes que formam a rede de plaquetas.

plaquette_lattice.draw_qubits()

Output:

Além dos rótulos dos qubits e das bordas que indicam quais qubits estão conectados, o diagrama contém três informações adicionais que são relevantes para o protocolo GEM:

Cada qubit é sombreado (cinza) ou não sombreado. Os qubits sombreados são qubits de "local" que representam os locais do modelo de Ising, e os qubits não sombreados são qubits de "ligação" usados para mediar as interações entre os qubits de local.
Cada qubit de local é rotulado como (A) ou (B), indicando uma das duas funções que um qubit de local pode desempenhar no protocolo GEM (as funções são explicadas posteriormente).
Cada aresta é colorida com uma das seis cores, dividindo assim as arestas em seis grupos. Essa divisão determina como as portas de dois qubits podem ser paralelizadas, bem como os diferentes padrões de agendamento que provavelmente resultarão em diferentes níveis de erro em um processador quântico sujeito a ruído. Como as arestas de um grupo são disjuntas, é possível aplicar uma camada de portas de dois qubits nessas arestas simultaneamente. De fato, é possível dividir as seis cores em três grupos de duas cores, de modo que a união de cada grupo de duas cores continue sendo disjunta. Portanto, são necessárias apenas três camadas de portas de dois qubits para ativar cada borda. Existem 12 maneiras de dividir as seis cores dessa forma, e cada uma dessas divisões resulta em uma programação de portas de três camadas diferente.

Agora que você criou uma rede de plaquetas, o próximo passo é inicializar um GemExperiment objeto, passando tanto a rede de plaquetas quanto o backend no qual você pretende executar o experimento. A GemExperiment classe gerencia a implementação propriamente dita do protocolo GEM, incluindo a geração de circuitos, o envio de tarefas e a análise dos dados. A célula de código a seguir inicializa a classe de experimento, restringindo a rede de plaquetas a uma única plaqueta (12 qubits), o que mantém a simulação pequena e rápida. A rede completa de plaquetas é utilizada posteriormente, na hora de fazer a transição para o hardware real.

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

Um circuito de protocolo GEM é construído usando as seguintes etapas:

Prepare o estado $|+\rangle$ aplicando uma porta Hadamard a cada qubit.
Aplique uma porta “ $R_{ZZ}$ ” entre cada par de qubits conectados. Você pode fazer isso usando três camadas de portas. Cada porta “ $R_{ZZ}$ ” atua sobre um qubit de local e um qubit de ligação. Se o qubit de local for identificado com (B), o ângulo é fixado em $\frac{\pi}{2}$ . Se o qubit de local for identificado com (A), o ângulo pode variar, gerando circuitos diferentes. Por padrão, o intervalo de ângulos é definido como 21 pontos igualmente espaçados entre $0$ e $\frac{\pi}{2}$ , inclusive.
Meça cada qubit de ligação na base de Pauli $X$ . Como os qubits são medidos na base de Pauli $Z$ , é possível fazer isso aplicando uma porta de Hadamard antes de medir o qubit.

Observe que o documento citado na introdução deste tutorial usa uma convenção diferente para o ângulo $R_{ZZ}$ , que difere da convenção usada neste tutorial por um fator de 2.

Na terceira etapa, apenas os qubits de ligação são medidos. Para compreender em que estado os qubits de site permanecem, é esclarecedor considerar o caso em que o ângulo de $R_{ZZ}$ o aplicado aos qubits de site (A) na segunda etapa seja igual a $\frac{\pi}{2}$ . Nesse caso, os qubits de site permanecem em um estado altamente entrelaçado, semelhante ao estado GHZ,

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

Devido à aleatoriedade nos resultados das medições, o estado real dos qubits do sistema pode ser um estado diferente com ordem de longo alcance, por exemplo, $\lvert 00110 \rangle + \lvert 11001 \rangle$ . No entanto, o estado GHZ pode ser recuperado por meio da aplicação de uma operação de decodificação baseada nos resultados das medições. Quando o ângulo “ $R_{ZZ}$ ” é reduzido a partir de $\frac{\pi}{2}$ , a ordem de longo alcance ainda pode ser recuperada até um ângulo crítico, que, na ausência de ruído, é aproximadamente $0.3 \pi$ . Abaixo desse ângulo, o estado resultante não apresenta mais entrelaçamento de longo alcance. Essa transição entre a presença e a ausência de ordem de longo alcance é a transição de fase de Nishimori.

Na descrição acima, os qubits do sistema não foram medidos, e a operação de decodificação pode ser realizada por meio da aplicação de portas quânticas. No experimento, tal como implementado no pacote GEM, os qubits do local são de fato medidos, e a operação de decodificação é aplicada em uma etapa clássica de pós-processamento.

Na descrição acima, a operação de decodificação pode ser realizada por meio da aplicação de portas quânticas aos qubits do local, a fim de recuperar o estado quântico. No entanto, se o objetivo for medir imediatamente o estado (por exemplo, para fins de caracterização), é possível medir os qubits de sítio juntamente com os qubits de ligação e aplicar a operação de decodificação em uma etapa clássica de pós-processamento.

Além de depender do ângulo de $R_{ZZ}$ , na etapa dois — que, por padrão, varia entre 21 valores —, o circuito do protocolo GEM também depende do padrão de agendamento utilizado para implementar as três camadas de portas de $R_{ZZ}$ . Conforme discutido anteriormente, existem 12 desses padrões de programação. Portanto, o número total de circuitos no experimento é $21 \times 12 = 252$ o.

Os circuitos do experimento podem ser gerados usando o circuits método da GemExperiment classe.

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

Output:

Total number of circuits: 252

Para os fins deste tutorial, basta considerar apenas um único padrão de agendamento. A célula de código a seguir restringe o experimento ao primeiro padrão de agendamento. Como resultado, o experimento tem apenas 21 circuitos, um para cada ângulo de $R_{ZZ}$ varrido.

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

A célula de código a seguir desenha um diagrama do circuito no índice 5. Para reduzir o tamanho do diagrama, as portas de medição no final do circuito foram removidas.

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

Etapa 2: Otimizar o problema para execução em hardware quântico

A transpilagem de circuitos quânticos para execução em hardware geralmente envolve várias etapas. Normalmente, as etapas que exigem maior carga computacional são a escolha do layout dos qubits, o roteamento das portas de dois qubits para se adequarem à conectividade dos qubits do hardware e a otimização do circuito para minimizar o número de portas e a profundidade. No protocolo GEM, as etapas de layout e roteamento são desnecessárias, pois a conectividade do hardware já está incorporada ao projeto do protocolo. Os circuitos já possuem um layout de qubits, e as portas de dois qubits já estão mapeadas nas conexões nativas. Além disso, para preservar a estrutura do circuito à medida que o ângulo $R_{ZZ}$ é alterado, deve-se realizar apenas uma otimização muito básica do circuito.

A classe GemExperiment transpila circuitos de forma transparente ao executar o experimento. Os estágios de layout e roteamento já são substituídos por padrão para não fazer nada, e a otimização do circuito é realizada em um nível que otimiza apenas portas de um único qubit. No entanto, você pode substituir ou passar opções adicionais usando o método set_transpile_options . Para fins de visualização, a célula de código a seguir transpila manualmente o circuito exibido anteriormente e desenha o circuito transpilado.

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

Passo 3: Execute usando Qiskit primitives

Para executar os circuitos do protocolo GEM no hardware, chame o método run do objeto GemExperiment . Você pode especificar o número de fotos que deseja amostrar de cada circuito. O método run retorna um objeto ExperimentData que você deve salvar em uma variável. Observe que o método run somente envia trabalhos sem esperar que eles terminem, portanto, é uma chamada sem bloqueio.

exp_data = gem_exp.run(shots=10_000)

Para aguardar os resultados, chame o método block_for_results do objeto ExperimentData . Essa chamada fará com que o interpretador fique suspenso até que os trabalhos sejam concluídos.

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

Etapa 4: Pós-processamento e retorno do resultado no formato clássico desejado

Em um ângulo de $R_{ZZ}$ de $\frac{\pi}{2}$ , o estado decodificado seria o estado GHZ na ausência de ruído. A ordem de longo alcance do estado GHZ pode ser visualizada plotando a magnetização das cadeias de bits medidas. A magnetização $M$ é definida como a soma dos operadores de Pauli $Z$ de um único qubit,

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

onde $N$ é o número de qubits do sistema. Seu valor, para uma sequência de bits, é igual à diferença entre o número de zeros e o número de uns. A medição do estado GHZ resulta, com igual probabilidade, no estado de zeros ou no estado de uns; portanto, a magnetização estaria em $+N$ na metade do tempo e em $-N$ na outra metade do tempo. Na presença de erros causados por ruído, outros valores também apareceriam, mas, se o ruído não for muito intenso, a distribuição ainda atingiria seu pico próximo a $+N$ e $-N$ .

Para as cadeias de bits brutas antes da decodificação, a distribuição da magnetização seria equivalente à de cadeias de bits uniformemente aleatórias, na ausência de ruído.

A célula de código a seguir representa a magnetização das cadeias de bits brutas e as cadeias de bits decodificadas no ângulo $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")

Output:

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

Para caracterizar com mais rigor a ordem de longo alcance, você pode examinar a correlação média de dois pontos $f$ , definida como

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

Um valor mais alto indica um grau maior de emaranhamento. A classe GemExperiment calcula automaticamente esse valor para as cadeias de bits decodificadas como parte do processamento dos dados experimentais. Ele armazena uma figura que pode ser acessada pelo método figure da classe de dados do experimento. Nesse caso, o nome da figura é two_point_correlation.

exp_data.figure("two_point_correlation")

Output:

Para determinar o ponto crítico da transição de fase de Nishimori, você pode observar a variação normalizada de $M^2 / N$ , definida como

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

que quantifica a quantidade de flutuação na magnetização ao quadrado. Esse valor é maximizado no ponto crítico da transição de fase de Nishimori. Na ausência de ruído, o ponto crítico ocorre aproximadamente em $0.3 \pi$ . Na presença de ruído, o ponto crítico é deslocado para cima, mas a transição de fase ainda é observada, desde que o ponto crítico ocorra abaixo de $0.5 \pi$ .

exp_data.figure("normalized_variance")

Output:

Exemplo de hardware em grande escala

Depois de validar o protocolo em um simulador, agora você pode ampliar a escala do experimento e executá-lo no hardware quântico real selecionado na seção “Configuração ”. Este exemplo utiliza dois problemas de maior dimensão:

Seis plaquetas (cerca de 49 qubits) : uma série de tamanho médio que já mostra o deslocamento para a direita do ponto crítico sob ruído de hardware.
A malha completa de plaquetas : todas as plaquetas que a topologia “heavy-hex” do dispositivo suporta (por exemplo, 18 plaquetas / 125 qubits em ibm_torino ou 21 plaquetas / 144 qubits em ibm_pittsburgh), entrelaçando qubits em todo o dispositivo com circuitos de profundidade constante.

A célula de código única abaixo é autônoma: ela constrói a rede de plaquetas a partir do mapa de acoplamento do backend e executa ambos os experimentos; portanto, esta seção pode ser executada após as células de configuração, sem a necessidade de executar primeiro a seção em pequena escala.

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

Observe que, dependendo do nível de ruído do backend utilizado, as curvas de variância normalizada em tamanhos maiores podem não apresentar um pico nítido dentro da faixa de ângulo varrida. Nas simulações acima, o pico foi empurrado até o valor de $0.5 \pi$ , que corresponde à borda direita do intervalo de variação (conforme os relatórios critical_angle = 0.5000 de análise tanto para as simulações com seis plaquetas quanto para as de rede completa). Isso significa que o ruído do hardware deslocou o ponto crítico para (ou um pouco além) do limite do intervalo de ângulos fisicamente significativo do protocolo; portanto, a transição ocorre no limite do que essa varredura é capaz de resolver.

Conclusão

Neste tutorial, você realizou uma transição de fase de Nishimori em um processador quântico utilizando o protocolo GEM. As métricas que você analisou durante o pós-processamento — em particular, a correlação de dois pontos e a variância normalizada — servem como parâmetros de referência para avaliar a capacidade do dispositivo de gerar estados entrelaçados de longo alcance. Esses testes de desempenho ampliam a utilidade do protocolo GEM para além da investigação de fenômenos físicos interessantes. Como parte do protocolo, você entrelaçou qubits em todo o dispositivo utilizando circuitos de profundidade constante. Essa conquista só é possível graças ao uso de medições no meio do circuito pelo protocolo. Nesta experiência, o estado entrelaçado foi medido imediatamente, mas considere a possibilidade de aprofundar a pesquisa utilizando esse estado em outros processos quânticos.

Próximas etapas

Recomendações

Se você achou este trabalho interessante, talvez se interesse pelo material a seguir:

Referências

[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. Realização da transição de Nishimori além do limiar de erros para circuitos quânticos de profundidade constante. arXiv:2309.02863 (2023).

[2] Pacote de software GEM Suite.

Esta página foi útil?

Relate um bug, erro de digitação ou solicite conteúdo no GitHub.