Skip to content

AWS iQuHACK 2024 In-Person Challenge

Notifications You must be signed in to change notification settings

RyanYunruiYang/2024_AWS

 
 

Repository files navigation

iQuHack 2024_AWS Challenge: End-to-end Novel Optimization of Qiskit's Compiler

Team MAICG. Anand John, Evan Kim, Sean Koke, Ryan Yang.

The AWS iQuHACK 2024 In-Person Challenge: For this year's Amazon Braket challenge, we invite you to implement a noise-aware compilation scheme using the Braket SDK which improves the performance of Braket devices. Basically, you're remapping input quantum circuits to make the best use of available qubits, based on which are noisiest.

Overview

The goal of the Amazon Braket challenge was to implement noise-aware quantum compilation with the Braket SDK. This was achieved by taking in as input abstract quantum circuits and converting these initializations and gates on logical qubits into initalizations and low-level gates onto pairs of hardware qubits. The overall system is organized as follows:

  • Motivation: Setup of the problem and hardware
  • Part 1: Fidelity Estimation
  • Part 2: Optimization of the circuit using estimated fidelities.
  • Evaluation: 12 Implemented Quantum Circuits

Local Image

Hardware: The IonQ Processor

Both QuEra's Acquila and IonQ's Harmony computer. QuEra Aquila is a specialized hardware, with a physical array of ultracold Rb atoms.

Part 1: Fidelity Estimation

This subsection's task is as follows: given a set of qubits, estimate the fidelity of each pair of qubits as precisely as possible.

The general solution is to set up and run circuits where the intended value is known, and one can infer properties of the decoherence through the deviation between the observed results and the theoretical result. Assuming that two-qubit gates dominate both time and reliability cost, to achieve this in optimal time, we use the largest possible circuits with a depth of 1, of the form:

Local Image

Observe that each round, this achieves the maximal $\lfloor \frac{n}{2} \rfloor$ two-qubit operations. Recall that in IonQ, the gates are all-to-all. This differs from more constricted systems, and any complete fidelity estimation must then examine all $\binom{n}{2}$ pairs.

To achieve this, MAICG observes that this problem is, in fact, analagous to the classical problem of tournament round-robin scheduling. This can be achieved with the Schurig Round-Robin algorithm:

Local Image

With this round-robin schedule, for each round with a game X-Y, we implement a Hadamard gate on $X$ and then a CNOT with control X and target Y. We then evaluated this system against simulations, and discovered that the ground truth values used to instantiate the model were in fact learned correctly, suggesting that our estimation system will also be able to compute all $\binom{n}{2}$ fidelity values in the real IonQ system correctly as well as in optimal round-length.

Part 2: Compilation Optimization

There is significant literature on quantum computing compiler infrastructure. Qiskit's NoiseAdaptiveLayout default compiler is based on the paper Murali, 2019. After closely analyzing the system, whose source code can be found here. We closely analyzed the system, and discovered several areas for improvement, based on breaking down their compiler:

Local Image

2.1: Initial Qubit Mapping: GreedySwap

The Qiskit compiler uses the following two heuristics for estabilishing the initial mapping:

  • The GreedyV heuristic: Ranks the number of times each logical qubit is involved in a CNOT, and the quality of each hardware qubit, and assigns the ith most used logical qubit to be implemented by the ith best hardware qubit seeks to minimize communication distance by considering qubits in descending order of degree*
  • GreedyE: Ranks each pair of logical qubits by the number of times a CNOT is called between them, and assign these to the pairs of hardware qubits with the best two-qubit fidelity.

Local Image

We formalize the problem as follows. We observe we are given one graph $U$ which is a weighted graph representing the number of CNOT calls, and the graph $F$ which is a weighted graph with weights corresponding to fidelities. We then try to find the vertex permutation which minimizes $\sum_{E} U.E * \ln(F.E)$.

Within published benchmarks, GreedyE empirically outperforms GreedyV: Local Image

However, we observe that GreedyE can have arbitrarily bad behavior, for example with graphs resembling the following: Local Image

We observe that, in general, both GreedyE and GreedyV leave possible optimization on the table. This is because GreedyV only has visibility into the single-qubit fidelity of each qubit, and GreedyE doesn't have visibility into single-qubit fidelity and is a suboptimal greedy algorithm. GreedyV's drawbacks are significantly more difficult as the dominating decoherence factor is two-qubit fidelity. In general, we observe that it is unlikely that a greedy algorithm can one-shot optimize this combinatorial problem.

Our approaches:

  • Approach 1: Bruteforce all $n!$ methods
  • Approach 2: GNN
  • Approach 3: GreedySwap!

We focus on GreedySwap, which greedily improves upon a given mapping. We choose to initialize at the GreedyE configuration. To do this, we

  • Begin with the GreedyE configuration
  • Repeatedly choose a random pair of logical qubits $i$ and $j$. Check if the estimated total fidelity increases or decreases if the two hardware qubits assigned to $i$ and $j$ are swapped.

Implementing and Testing on 12 Quantum Circuits

Algorithms we tested on. To test the quality of our compilation, we first ran each algorithm on a circuit with no simulated noise and calculated the result’s normalized overlap with the result of the circuit with the simulated noise. Below is a table of our summarized results from the 12 algorithms.

We implemented a suite of algorithms to test the following 12 algorithms: https://en.wikipedia.org/wiki/Bernstein%E2%80%93Vazirani_algorithm

About

AWS iQuHACK 2024 In-Person Challenge

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Jupyter Notebook 90.5%
  • Python 9.5%