Full text
CERN Openlab Report 2024 Speeding-up simulations of quantum algorithms for material science August 2024 AUTHOR: Gehad Ahmed The American University in Cairo SUPERVISORS: Dr. Michele Grossi Carla Rieger INDUSTRY SUPERVISOR (Intel Labs): Dr. Gian Giacomo Guerreschi Page 1/9
CERN Openlab Report 2024 Abstract Due to its intrinsic quantum mechanical nature, applications in chemistry and material science are among the strongest candidates for algorithmic quantum advantage. This project focuses on the simulation of chemistry molecules to assess and benchmark the Intel Quantum SDK. Our methodology involves working with a set of Hamiltonians to investigate the compilation and computational running time in dependence on Hamiltonian complexity. The benchmarks reveal an approximately linear relation between the locality of the Hamiltonian and the running time, notable differences in performance, and resource utilization between the two tested versions of the Intel SDK, whereas the updated version exhibited significant improvement in compilation time. The complete code used in this analysis is available for reference1. 1 Introduction Cutting-edge quantum computing algorithms leverage the principles of quantum mechanics to process information. Unlike classical computers, which use bits as the smallest unit of data represented either by 0 or 1, quantum computers are based on quantum bits or qubits. Qubits have the unique property of being allowed to be in multiple states simultaneously, a so-called superposition state. Moreover, qubits can be entangled, meaning the state of one can be highly correlated to the state of another. The former allows quantum computers to perform calculations in parallel, offering the potential to solve certain types of problems, such as factorizing large numbers or searching an unstructured database, faster than any known classical algorithm run on classical hardware. In this project, we use Intel’s Quantum SDK, a comprehensive toolkit designed to facilitate the development and simulation of quantum circuits using classical computing infrastructure. The SDK provides an environment to create and test quantum algorithms without requiring access to a physical quantum computer as long as the computational problem does not exceed the classical hardware constraints. Figure 1 presents an overview of the Intel Quantum SDK, which consists of multiple layers. Simulating quantum algorithms on classical hardware offers several advantages since it allows for the testing and development of quantum algorithms in a more controlled and cost-effective manner than what is currently possible with state-of-the-art quantum hardware. Such simulation provides crucial insights into the performance and potential issues of quantum algorithms under various conditions. Additionally, they accelerate the research and development process in quantum computing by allowing for the refinement of algorithms and techniques without immediate reliance on quantum hardware. This approach is particularly valuable for system sizes that are still feasible to simulate classically, circumventing the high costs and limited accessibility of physical quantum computers. Our aim in this project is to evaluate the performance of the Intel Quantum SDK over different examples of quantum circuits with different sizes while also comparing Intel Quantum SDK v1.1.0 and v1.1.1. This involves simulating the dynamics of a physical system described by a Hamiltonian, as detailed in Section 3.1. The time evolution of the quantum system, governed by the Hamiltonian, is described by the Schr¨odinger equation, which results in a unitary operator encapsulating this evolution. This unitary operator is then transformed into a quantum circuit, which is executed on a classical machine using the Intel Quantum SDK. 2 Related Work In recent years, rapid advancements have been made in quantum technologies for practical computation and simulation. Smelyanskiy et al. [2] introduce qHiPSTER: The Quantum High-Performance Software Testing Environment developed by Intel, which is currently capable of simulating up to 40 qubits on the TOP500 supercomputing systems. The paper presents various optimization methods for the quantum simulator, including vectorization, multi-threading, cache blocking through gate fusion, and overlapping computation with communication. A few years later, Guerreschi et al. [3] describe improvements to qHiPSTER, with benchmarks demonstrating the capability to simulate up to 42 qubits. These optimizations utilize public cloud computing infrastructure and involve subdividing the required tasks to run a pool of related circuits in parallel. Additionally, the goal of this updated version is to facilitate its use either as a standalone program or as a backend to other quantum computing frameworks. 1https://github.com/carlasophie/summer_student_project Page 2/9
CERN Openlab Report 2024 Figure 1: The full stack of the Intel Quantum SDK [1]. 3 Methodology In this section, we outline the steps taken to evaluate the Intel Quantum SDK and benchmark its performance across two versions: v1.1.0 and v1.1.1. The first step in performing an analysis using a quantum simulator is to define appropriate test instances. For this study, we utilize a variety of quantum circuits of differing sizes in order to simulate the dynamics of physical systems described by a Hamiltonian. The details of the Hamiltonians used in this analysis are provided in Section 3.1. In Section 3.2, we discuss the concept of Hamiltonian locality and the analyses conducted to better understand the dynamics of the chosen Hamiltonians. Following this, Section 3.3 outlines the process of translating the Hamiltonians into quantum circuits by decomposing them into quantum gates. Finally, Section 3.4 details the implementation steps, including how we start from a given Hamiltonian, generate the corresponding quantum circuit, and execute it on the Intel Quantum SDK based on Python scripts. 3.1 Hamiltonians for Quantum Simulation We aim to evaluate the efficacy of the Intel Quantum SDK by benchmarking two of its most recent versions, v1.1.1 and v1.1.0, against each other. To achieve this, we begin by selecting distinct sets of Hamiltonians: 1. Hamiltonians derived from molecular systems available on PennyLane, such as the hydroxide ion (OH-) [4] and ethyne (C2H2) [5]. These Hamiltonians capture the physical interactions within the molecules, serving as real-world examples of quantum systems. The molecular Hamiltonians are particularly valuable for benchmarking because they represent tangible physical systems, making the results of simulations more interpretable and relevant to practical applications. The molecular structures of OH-and C2H2are shown respectively in Figure 2. 2. Randomly generated Hamiltonians were also employed in our experiments. The use of random Hamiltonians allows us to systematically control and fix specific variables while varying others, which is crucial for benchmarking. This approach provides the flexibility to work with smaller Hamiltonians, helping to test and validate on a smaller scale before scaling up to more complex systems. Page 3/9
CERN Openlab Report 2024 Figure 2: Molecular structures of OH-[4] and C2H2[5]. Due to the constraints imposed by available resources and computational time, our analysis is confined to systems of up to 30 qubits. 3.2 Locality in Hamiltonians To understand the representation of the OH-and C2H2molecules’ Hamiltonian, we investigate the relationship between the maximum locality of all terms in the Hamiltonian and the number of terms they contain. 3.2.1 Understanding Locality in Hamiltonians A Hamiltonian is composed of multiple terms, each representing different interactions or components of the system’s energy. The locality [6] of a single term of a Hamiltonian is defined as the number of qubits on which it acts non-trivially (e.g., Pauli rotations). Here specifically, we refer to the fact that the Jordan Wigner transformation was used to obtain a sum of tensor products of Pauli operators acting on qubits [4]. For example, if a term involves non-trivial (i.e., non-identity) operations on three qubits, its locality is three. The locality of the Hamiltonian is then defined as the maximum locality across all of its terms. 3.2.2 Experiments and Findings In the case of the OH-molecule, the system is simulated by a Hamiltonian using 12 qubits and consisting of 631 terms in its linear combination of Pauli operators [4]. We start with a Hamiltonian that has a maximum locality of 12. This means that the most complex interaction term in the Hamiltonian involves all the 12 qubits. Our goal is to examine how reducing the maximum allowed locality would affect the total number of terms in the Hamiltonian. To do this, we systematically remove terms with a locality greater than a specified threshold, beginning with the highest locality (12) and progressively decreasing the threshold. After each step, we record the number of remaining terms in the Hamiltonian. Similarly, we perform the same process for the C2H2molecule, which is simulated by a Hamiltonian using 24 qubits and consisting of 6401 terms [5]. As presented in Figure 3, we deduce that the majority of terms in both Hamiltonian have even localities, with a smaller subset of terms exhibiting odd localities. This observation can be explained by the nature of the interactions within the molecule, which are predominantly two-body interactions. In quantum chemistry, two-body interactions typically result in terms that involve an even number of qubits. These interactions correspond to the physical interactions between pairs of electrons and nuclei within the molecule. 3.3 From Hamiltonians to Quantum Circuits After selecting the Hamiltonians, we work on transforming these Hamiltonians into quantum circuits. The transformation starts by encoding the Hamiltonian into a quantum circuit, where each term is represented by a corresponding sequence of quantum gates. In our case, the Hamiltonians are expressed as a sum of tensor products of Pauli matrices (σx, σy, σz) and the identity matrix. Each term, representing a specific quantum interaction or field effect, can be associated with a specific quantum gate or a sequence of gates: •Single-qubit terms like σx,σy, or σzare directly mapped to X, Y, and Z gates, respectively. •Two-qubit interactions, such as σx⊗σxor σz⊗σz, are implemented using gate sequences that include two-qubit entangling gates like CNOT, supplemented by single-qubit gates before and/or after the entangling gate to achieve the desired interaction. Page 4/9
CERN Openlab Report 2024 (a) Relationship between the number of terms in the OH-Hamiltonian and the locality threshold. (b) Relationship between the number of terms in the C2H2Hamiltonian and the locality threshold. Figure 3: Both figures show that the majority of terms in both Hamiltonians have even localities. Following the structured approach detailed in the tutorial2, we numerically map each of the Hamiltonians to its corresponding quantum circuit. 3.4 Integration with Intel Quantum SDK The Intel Quantum SDK poses unique challenges for quantum circuit development due to its specific requirements regarding circuit definition during compilation. The SDK necessitates that the entire structure of the quantum circuit, except for the gate parameters, be predefined at compilation time. This constraint limits the flexibility for dynamic circuit generation based on runtime data, such as the contents of a file containing Hamiltonian definitions. To overcome this limitation, we have developed a methodology that utilizes Python scripts to pre-process and translate Hamiltonian data into a complete quantum circuit description in C++. Here we describe the process step-by-step: 1. Hamiltonian Parsing: A Python script reads the input file containing a specific Hamiltonian, with a format varying depending on the source of the Hamiltonian. This file specifies the quantum interactions and terms that describe the system’s behavior. The script then transforms these descriptions into a common format, specifically a SparsePauliOp3from Qiskit [7]. This standardized format facilitates a common representation of all Hamiltonians independently of the Hamiltonian source. 2. Circuit Transformation: The script then processes these terms to map them into a sequence of quantum gates. This transformation involves interpreting each term of the Hamiltonian to its corresponding quantum gate equivalent, which is suitable for the implementation in the Intel Quantum SDK. 3. C++ Code Generation: Once the circuit is defined, the Python script generates a C++ file embedding the entire quantum circuit structure as required by the SDK. This file includes all the necessary gate definitions and their sequence, explicitly laid out to meet the SDK’s compilation prerequisites. 4. Compilation: The generated C++ file can then be directly compiled using the Intel Quantum SDK, producing an executable that simulates the quantum circuit derived from the original Hamiltonian. This method ensures that even complex quantum systems can be simulated despite the SDK’s static circuit definition requirements. 2https://github.com/DavitKhach/quantum-algorithms-tutorials/blob/master/Hamiltonian_simulation.ipynb 3https://docs.quantum.ibm.com/api/qiskit/qiskit.quantum_info.SparsePauliOp Page 5/9
CERN Openlab Report 2024 4 Results The computational experiments are conducted on two environments: a CERN machine and the Intel Cloud environment4. The specifications of the CERN machine are summarized in Table 1. Specification Details CPU Intel(R) Xeon(R) Platinum 8360Y @ 2.40GHz Cores 72 Physical Cores (144 Threads) RAM 256 GB Table 1: Specifications of the CERN Machine. 4.1 Compilation and Running Time Analysis with a 22-Qubit Hamiltonian Figure 4: Linear relationship between running time and locality for a 22-qubit Hamiltonian with 50 terms, analyzed five runs per data point to calculate the mean and error margin given by the standard deviation. To test the running time and explore the relationship between the computational running time and the locality of the Hamiltonian, we use a random Hamiltonian of a 22-qubit system with 50 individual terms in its sum. In this experiment, the locality of the Hamiltonian varies from 2 to 22. Each step represents an increase in the complexity of the Hamiltonian, as a higher locality implies a larger number of qubits involved in non-trivial operations for each term. To ensure the robustness of the results, we conducted each step of the experiment five times, calculating the mean running time and establishing error margins to assess variability and reliability in the findings. The experiment is conducted on two versions of the Intel Quantum SDK: v1.1.0 and v1.1.1. The analysis reveals a linear relationship between the running time and the locality of the Hamiltonian, as shown in Figure 4. Additionally, the newer SDK version (v1.1.1) significantly reduces compilation time compared to the older version, demonstrating improved efficiency. 4.2 Compilation and Running Time Analysis with the OH-Molecule In this study, we explore the impact of a change in the maximum locality in the Hamiltonian of an OHmolecule on the running/compilation time. Experiments are initially conducted within the Intel Cloud environment, with the Intel Quantum SDK pre-installed. However, we observe that the compilation times are inconsistent, likely influenced by the shared nature of the cloud computing resources. This variability is illustrated in Figure 5a, where the error bars, representing the variability of compilation times for identical circuits run at different times, are significantly large. This indicates a lack of reproducibility in the results under these conditions. Thus, we change the computation environment in order to achieve reproducible and consistent time measurements. Hence, we replicate the experiments using an internal machine at CERN, where the specifications are summarized in Table 1. The findings from this setup show more consistent compilation times. We note that while the compilation times generally increase with the locality, they also depend on the number of terms in the Hamiltonian. Specifically, for localities where the number of terms is similar, the compilation times are close to each other. 4https://console.cloud.intel.com/training Page 6/9
CERN Openlab Report 2024 Additionally, we run a comparison on the CERN machine between Intel Quantum SDK versions v1.1.0 and v1.1.1. As shown in Figure 5b, the compilation time is significantly reduced in the newer version compared to the older one. (a) Comparison of compilation and running times between the CERN machine and the Intel Cloud environment using the Intel Quantum SDK v1.1.0. The CERN machine demonstrates faster compilation times with lower variability, indicating more consistent and reliable performance. (b) Analysis of experiments conducted exclusively on the CERN machine comparing both versions of the Intel Quantum SDK. Compilation times drop drastically from v1.1.0, where it grows with the increase in the locality and number of terms, while in v1.1.1, it is almost negligible. Figure 5: Comparative analysis of the impact of locality on compilation and running times between the Intel Cloud environment and the CERN internal machine, based on five runs per data point to calculate the mean and error margin given by the standard deviation. The data show lower error margins and reduced variability on the CERN machine, highlighting its improved stability in performance. 4.3 Compilation and Running Time Analysis with the C2H2Molecule (a) Comparison of the compilation times for the C2H2 molecule using Intel Quantum SDK v1.1.1 and v1.1.0, highlighting a drastic improvement in compilation time in the newer version, while the running time remains consistent. (b) Analysis of the compilation and running times for the C2H2molecule using Intel Quantum SDK v1.1.1, demonstrating that compilation time is almost negligible compared to the running time. Figure 6: Comparison of compilation and running times for the C2H2molecule across Intel Quantum SDK versions v1.1.0 and v1.1.1. All data points are based on five independent runs to calculate the mean and error margins represented by the standard deviation. Page 7/9
CERN Openlab Report 2024 To further analyze the actual speedup provided by Intel Quantum SDK v1.1.1 compared to v1.1.0 (conducted over the CERN machine), we conduct experiments using a more complex Hamiltonian of the C2H2 molecule. As shown in Figure 6, the compilation time in the new version drops drastically. For example, when the locality threshold is set to 18, the compilation time decreases from over 12 hours in v1.1.0 to approximately 32 seconds in v1.1.1. This significant improvement makes the compilation time across the entire experiment for all locality thresholds mostly negligible compared to the running time, as demonstrated in Figure 6b. We also note that the missing locality thresholds in this experiment are due to the identical number of terms between consecutive thresholds in certain cases, such as between 10 and 11. Specifically, there were no terms with locality 11, making it unnecessary to conduct repeated experiments under identical conditions without any variation in the Hamiltonian structure. 5 Conclusion The benchmarking conducted in this study has yielded useful insights into the performance of the Intel Quantum SDK. The comparison between the two versions of the Intel Quantum SDK, v1.1.0 and v1.1.1, has revealed significant improvements in the newer release. Our experiments, involving both random and physically representative Hamiltonians, have demonstrated a clear linear relationship between the locality of a Hamiltonian system and its computational running time. This relationship shows the increasing complexity and computational demands as the system’s quantum interaction complexity escalates. Furthermore, the results show a significant enhancement in the performance of the newer Intel Quantum SDK version, where compilation time has become largely negligible compared to the running time. The two tested environments given by the Intel Cloud and the CERN machine exhibited notable differences in performance and resource utilization relevant to our benchmarking study. We focused on the CERN machine to obtain consistent timing results. This difference is due to the varying number of concurrent processes running on each platform, as the CERN machine is more “shielded” from external workloads. These variations in resource availability and isolation are particularly relevant for benchmarking, as larger and more stable computational resources enable the execution of more complex quantum simulations. Moving forward, the project will focus on implementing and benchmarking multi-qubit rotations, aiming to reduce the computational cost associated with simulating Hamiltonian time evolutions further. The next phase will involve conducting comprehensive benchmarks with respect to multi-qubit rotations. This comparison aims to quantify any speedup achieved through the new implementation within the Intel Quantum SDK, enhancing the efficiency and effectiveness of quantum chemistry computations. Acknowledgment We would like to thank Oriel Kiss for the fruitful discussions. Page 8/9
CERN Openlab Report 2024 References [1] Intel,Intel releases quantum software development kit version 1.0.url: https://www.intel.com/ content/www/us/en/newsroom/news/intel-releases-quantum-sdk.html. [2] M. Smelyanskiy, N. P. Sawaya and A. Aspuru-Guzik,qhipster: The quantum high performance software testing environment, arXiv preprint arXiv:1601.07195 (2016). [3] G. G. Guerreschi, J. Hogaboam, F. Baruffa and N. P. Sawaya,Intel quantum simulator: A cloud-ready high-performance simulator of quantum circuits, Quantum Science and Technology 5(2020), p. 034007. [4] U. Azad,Pennylane quantum chemistry datasets.https://pennylane.ai/datasets/oh-anion, 2023. [5] U. Azad,Pennylane quantum chemistry datasets.https://pennylane.ai/datasets/c2h2-molecule, 2023. [6] A. Bluhm, M. C. Caro and A. Oufkir,Hamiltonian property testing, arXiv preprint arXiv:2403.02968 (2024). [7] Q. D. Team,Qiskit: An open-source framework for quantum computing, 2023. Accessed: 2025-01-23. url: https://qiskit.org/. Page 9/9