Intel Quantum Simulator: A cloud-ready high-performance simulator of quantum circuits

Gian Giacomo Guerreschi; Justin Hogaboam; Fabio Baruffa; Nicolas P. D. Sawaya

Source-linked AI summary

Intel Quantum Simulator: A cloud-ready high-performance simulator of quantum circuits

Gian Giacomo Guerreschi, Justin Hogaboam, Fabio Baruffa, Nicolas P. D. Sawaya

arXiv:2001.10554v2Jan 28, 2020quant-phcs.DCphysics.comp-ph

TL;DR

Quantum-circuit simulation remains important for studying algorithms and hardware errors because quantum hardware is still developing and many questions are impractical to answer analytically. This work presents an open-source IQS release that combines HPC state simulation with pooled parallel circuit execution, demonstrating its use for QAOA with particle swarm optimization and noise studies. The paper concludes that IQS supports large-qubit, parallel-device, and decoherence simulations across workstations, supercomputers, and cloud platforms.

Problem
Classical simulation is needed to study quantum algorithms, parameter choices, and hardware errors while quantum hardware remains immature and many relevant questions are impractical to answer analytically.
Method
IQS combines shared- and distributed-memory HPC execution with process groups that simulate separate quantum states or related circuits in parallel.
Results
IQS was used for large-scale simulations, parallel QAOA devices with particle swarm optimization, and noisy-circuit studies, with the appropriate particle count depending on available circuit evaluations.
Takeaways & Limitations
IQS provides an open-source simulator for large-qubit calculations, parallel quantum-device emulation, and stochastic studies of noise and decoherence on HPC and cloud platforms.

Abstract

from arXiv · show

Classical simulation of quantum computers will continue to play an essential role in the progress of quantum information science, both for numerical studies of quantum algorithms and for modeling noise and errors. Here we introduce the latest release of Intel Quantum Simulator (IQS), formerly known as qHiPSTER. The high-performance computing (HPC) capability of the software allows users to leverage the available hardware resources provided by supercomputers, as well as available public cloud computing infrastructure. To take advantage of the latter platform, together with the distributed simulation of each separate quantum state, IQS allows to subdivide the computational resources to simulate a pool of related circuits in parallel. We highlight the technical implementation of the distributed algorithm and details about the new pool functionality. We also include some basic benchmarks (up to 42 qubits) and performance results obtained using HPC infrastructure. Finally, we use IQS to emulate a scenario in which many quantum devices are running in parallel to implement the quantum approximate optimization algorithm, using particle swarm optimization as the classical subroutine. The results demonstrate that the hyperparameters of this classical optimization algorithm depends on the total number of quantum circuit simulations one has the bandwidth to perform. Intel Quantum Simulator has been released open-source with permissive licensing and is designed to simulate a large number of qubits, to emulate multiple quantum devices running in parallel, and/or to study the effects of decoherence and other hardware errors on calculation results.

I. INTRODUCTION

IQS addresses the need for classical quantum-circuit simulation by combining high-performance distributed computing with parallel simulation of circuit pools. The release extends an HPC simulator toward cloud use while supporting quantum-state initialization, evolution, measurement, and multiple operation modes.

I. INTRODUCTION: Classical simulation remains important for evaluating quantum algorithms and studying errors while quantum hardware is still developing.Numerical experiments help assess algorithm parameters, hyperparameters, robustness, hardware design, and gate compilation.
I. INTRODUCTION: Quantum-circuit simulation is generally hard because its computational cost grows exponentially with the number of qubits.Tensor-network and path-integral methods can scale more favorably for some circuits but remain exponential in the general case.
I. INTRODUCTION: IQS is a massively parallel simulator that preserves its HPC foundation while adding cloud-oriented resource grouping for parallel circuit simulations.The new release divides computational processes into groups, each storing and updating a distinct quantum state, while retaining MPI+OpenMP implementations.
I. INTRODUCTION: IQS is released open source with testing, installation support, tutorials, Python integration, Docker support, and intended backend integrations.The release aims to reduce installation and learning barriers while supporting standalone use or integration with quantum-computing frameworks.
I. INTRODUCTION: IQS supports single-state large-qubit simulations, pools of distributed or local states, and stochastic simulations of noise and decoherence.The pool functionality targets parallel circuit variants and error or decoherence studies.
I. INTRODUCTION: The software provides core operations for initializing, evolving, and measuring pure multi-qubit states using one- and two-qubit gates.Users can allocate a QubitRegister, initialize computational or other supported states, and apply standard or custom gates.

Distributed implementation

IQS distributes the 2^n-amplitude quantum state across processes and classifies qubits by whether gate operations require inter-process communication. One-qubit and controlled two-qubit gates use local updates when possible and communication schemes otherwise.

State distribution: IQS stores a quantum state of n qubits as 2^n complex amplitudes distributed across P=2^p processes, with each process holding 2^(n−p) amplitudes.When P is not a power of two, IQS uses an effective process count of 2^⌊log2(P)⌋.
Local and global qubits: Qubits with indices q<m=n−p are local and require no inter-process communication, whereas qubits with q≥m are global and require MPI communication.Even a local qubit’s complete state information remains distributed across all processes.
One-qubit gates: For a one-qubit gate, amplitudes connected by the target qubit are updated in pairs using the 2×2 unitary matrix U.When q<m, each connected pair resides in one process and can be updated locally.
Inter-process communication: For q≥m, IQS pairs amplitudes across processes indexed by p(i) and p(i+2^q)=p(i)+2^(q−m), requiring inter-process communication.The communication scheme exchanges local memory, performs the computation locally, and sends the updated information back.
Two-qubit gates: IQS also implements distributed controlled two-qubit gates, with communication determined by whether the control and target qubits are local or global and by their ordering.The controlled operation applies a one-qubit gate to the target when the control is in |1⟩.

Pool of multiple states

IQS introduces pools that divide processes into groups, each storing a quantum state, so related circuits can be simulated in parallel. The design improves resource use and supports repeated parameterized simulations and differentiated circuits.

Pool architecture: IQS pools divide MPI processes into groups, with each group storing a separate quantum state while retaining distributed MPI+OpenMP simulation within each group.A QubitRegister initializes one state in every group, and ApplyGate acts on every state in the pool.
Resource allocation: With 80 processes and 10 states, grouping processes into 10 groups of 8 distributes each state over 8 processes and applies each gate by default to every state.Alternatively, 10 separately declared states would each use 64 processes when the full process set is shared.
Parallel related circuits: Non-trivial pools can use available processes more effectively and naturally simulate closely related circuits in parallel.Circuits can be differentiated for each state when identical evolution would otherwise be redundant.
Applications: Variational quantum algorithms can assign different parameter values to repeated circuit simulations within the pool.The circuit structure is reused while parameters such as one-qubit rotation angles vary during optimization.

III. SCALING EXPERIMENTS

The scaling experiments benchmark IQS one-qubit operations on the SuperMUC-NG HPC system while varying problem size and computational resources. The system supports experiments up to 2048 nodes, 98,304 CPU cores, and 196 TB of memory.

Benchmark design: IQS sample codes benchmark one-qubit operations while varying the total number of qubits or the index of the operated qubit.These experiments are intended to analyze strong and weak scaling on HPC systems.
HPC platform: SuperMUC-NG provides 6,480 compute nodes, 311,040 CPU cores, and 719 TB of distributed memory, with each node containing two 24-core sockets and 96 GB shared memory.The reported experiments scale to 2048 nodes, corresponding to 98,304 CPU cores and 196 TB of total memory.
Experimental setting: The experiments use SuperMUC-NG, hosted by the Leibniz Supercomputing Center of the Bavarian Academy of Science.The system configuration supports the strong- and weak-scaling measurements reported in the following sections.

Strong scaling

Strong scaling evaluates fixed-size 32-qubit simulations as computational resources increase, using random one-qubit gates across the simulated qubits. Gate timing depends on the target qubit because later qubits require additional communication.

Experimental setup: For 32-qubit simulations, strong scaling fixes the problem size while increasing computational resources and measures random 2×2 one-qubit gates applied across all qubits.The analysis uses MPI and OpenMP resources on SuperMUC-NG.
Figure 4: Figure 4 measures strong scaling with 32 to 512 MPI processes, using two MPI tasks per node and 24 OpenMP threads per socket.The left panel plots one-qubit-gate time against the operated qubit for different process counts.
Communication behavior: Communication for earlier qubits is primarily intra-node, whereas later qubits require mostly inter-node MPI communication.This communication transition produces the observed peak behavior in the measurements.
Gate timing: Additional communication makes updating q=31 slower than updating q=0 in the strong-scaling measurements.The last qubit requires communication that the first qubit does not.

Weak scaling

IQS weak scaling remains scale-invariant from 32 to 42 qubits while supporting parallel simulation of related circuits. In the QAOA/Max-Cut application, the best PSO particle count depends on the available number of circuit evaluations.

Weak scaling: 32–42 qubit simulations using 4–4096 processes confirmed scale-invariant weak-scaling behavior on SuperMUC-NG.The largest job used 2048 nodes.
Weak scaling: At small qubit indices, one-qubit gate time stays constant across larger simulations, while larger-index differences mainly reflect communication overhead.The peak at qubit index 30 comes from communication between two sockets within a node.
Pool simulation: IQS distributes independent circuit states across process groups, enabling parallel simulation of many related quantum circuits.This pool functionality supports the parallel-device scenario used for the variational application.
QAOA with swarm particle optimization: The approximation ratio improves as total function evaluations increase, with results averaged over 300 random 18-qubit graph instances.The approximation ratio compares the QAOA objective with the exact Max-Cut solution, across particle counts from 4 to 64.
QAOA with swarm particle optimization: With about 500 evaluations, roughly 10–14 particles perform best, whereas the optimal particle count increases as the evaluation budget grows.More particles explore more parameter space but require more evaluations per swarm step; standard deviations substantially overlap across counts.

Convergence of noisy simulations

IQS uses ensembles of stochastic circuit simulations to estimate noisy expectation values for QAOA. For the studied 16-qubit Max-Cut instance, convergence required hundreds of ensemble states, while optimized parameters converged faster than random initialization.

Optimized circuit parameters reached convergence more quickly than randomly selected parameters.
The experiment simulated QAOA for Max-Cut on 3-regular graphs with 16 qubits, depth p = 4, T1 = 500Tg, and T2 = T1/2.Each ensemble state was generated by simulating the circuit with noise gates according to the compiled schedule.
The ensemble average converges to the noisy expectation value rather than the ideal noiseless result.
Hundreds of stochastic states were required for convergence with the optimized QAOA parameters used in the 16-qubit Max-Cut example.Different random-number streams showed the same averaging procedure converging toward the noisy expectation value.

V. CONCLUSION AND OUTLOOK

IQS supports high-performance quantum-circuit simulation across workstations, supercomputers, and cloud platforms. Its three operating modes cover maximum-qubit simulation, parallel circuit pools, and stochastic ensembles for modeling noise and decoherence.

IQS provides three operating modes: maximum-qubit simulation, parallel simulation of circuit pools, and stochastic ensembles for noise and decoherence.
The study combined 42-qubit SuperMUC-NG simulations, PSO-based QAOA experiments, and stochastic convergence studies for systems of dimension 2^16.The convergence study used hundreds of stochastic circuit ensembles and reported lower memory overhead than density-matrix methods.
IQS is suitable for cloud applications because its parallel workloads can use tens of thousands of nodes without being limited by communication bandwidth or latency.
The simulator can operate standalone or serve as a backend for other quantum simulation software, whether simulating one large state or many smaller states.

Appendix A: Installation

IQS is built as a C++ static library with optional distributed and Python components. Installation uses CMake, with MPI required for the distributed version and standard dependencies documented for compilation.

IQS builds a static C++ library and example or unit-test executables through an out-of-source CMake process.
The required distributed-communication dependency is MPICH3, while MKL and PyBind11 are optional components for random-number generation and Python bindings.
The source code is publicly hosted in the Intel Quantum Simulator GitHub repository and can be cloned before building.
The single-node build disables MPI, whereas the distributed build enables MPI and requires at least MPICH version 3.1.

Appendix B: Python bindings

IQS provides Python bindings for its single-node implementation to support integration with Python-based numerical and quantum-computing tools.

The single-node IQS build creates a Python library exposing the simulator’s classes and methods.

Appendix C: Docker file

IQS supports cloud-based multi-node deployment through containerized environments while retaining its HPC simulation capability. Its Docker setup packages the software dependencies, but the number of simulable qubits remains limited by available memory.

Resource boundary: The number of qubits IQS can simulate is constrained by the memory available for the quantum state vector.Cloud nodes can increase available memory, but this remains the direct resource boundary for simulation size.
Cloud deployment: IQS can use temporary cloud clusters whose nodes provide more aggregate memory than a single laptop or workstation.Cluster orchestration tools can allocate and run container instances across the nodes.
Container setup: The provided Dockerfile builds an image containing the software packages and host operating system needed to build and execute IQS.The container also provides a pre-built environment when researchers lack the required operating system version and development tools.
Container setup: Multi-node cloud execution requires converting the Docker image into a Singularity image because native Docker restricts SSH use.The Singularity conversion works around this restriction for inter-node communication.

Appendix D: Parallel simulations of a pool of states

IQS parallelizes a pool of noisy circuit simulations by partitioning MPI processes into groups, then averaging their outputs. The example applies stochastic noise to a 10-qubit sequential circuit and computes an incoherent pool average.

Pool simulation: IQS simulates a 10-qubit dissipative and decoherent system by repeating the circuit with stochastic noise gates and averaging the resulting states.The noise model is characterized by T1 and T2 timescales.
Parallel execution: MPI processes are partitioned into one group per pool state, allowing separate circuit simulations to run across the pool.The example obtains the pool-state count from the MPI communicator and updates the communication environment accordingly.
Circuit setup: A sequential circuit applies X rotations from qubit 0 through qubit 9, with noise gates before and after each rotation according to the duration schedule.All pool states share the randomly chosen rotation angles, while stochastic noise is generated per state.
Output aggregation: The simulation measures qubit 0's probability of |1> and divides the incoherent sum across all pool states by the number of pool states.IQS supports local, state-shared, and pool-shared random-number streams for coordinating these simulations.