SimuQ: A Framework for Programming Quantum Hamiltonian Simulation with Analog Compilation

Quantum Hamiltonian simulation, which simulates the evolution of quantum systems and probes quantum phenomena, is one of the most promising applications of quantum computing. Recent experimental results suggest that Hamiltonian-oriented analog quantum simulation would be advantageous over circuit-oriented digital quantum simulation in the Noisy Intermediate-Scale Quantum (NISQ) machine era. However, programming analog quantum simulators is much more challenging due to the lack of a unified interface between hardware and software. In this paper, we design and implement SimuQ, the first framework for quantum Hamiltonian simulation that supports Hamiltonian programming and pulse-level compilation to heterogeneous analog quantum simulators. Specifically, in SimuQ, front-end users specify the target quantum system with Hamiltonian Modeling Language, and the Hamiltonian-level programmability of analog quantum simulators is specified through a new abstraction called the abstract analog instruction set (AAIS) and programmed in AAIS Specification Language by hardware providers. Through a solver-based compilation, SimuQ generates executable pulse schedules for real devices to simulate the evolution of desired quantum systems, which is demonstrated on superconducting (IBM), neutral-atom (QuEra), and trapped-ion (IonQ) quantum devices. Moreover, we demonstrate the advantages of exposing the Hamiltonian-level programmability of devices with native operations or interaction-based gates and establish a small benchmark of quantum simulation to evaluate SimuQ's compiler with the above analog quantum simulators.


INTRODUCTION 1.Background and Motivation
Developing appropriate abstraction is a critical step in designing programming languages that help bridge the domain users and the potentially complicated computing devices.Abstraction is a fundamental factor in the productivity of the underlying programming language.Prominent early examples of such include, e.g., FORTRAN [Backus 1978] and SIMULA [Nygaard and Dahl 1978], both of which provide high-level abstractions for modeling desirable operations for domain applications and have been proven enormous successes in history.
Conventionally, abstractions for quantum computing adopt (qubit-level) quantum circuits to describe procedures, a mathematically simple approach that works well as a mental tool for the theoretical study of quantum information and algorithms [Childs 2017;Nielsen and Chuang 2002].As a result, many quantum programming languages [Abhari et al. 2012;Green et al. 2013;Hietala et al. 2021;Paykin et al. 2017] have adopted quantum circuits as the only abstraction.Many quantum applications are implemented using these programming languages to generate quantum circuits, although only a few can be demonstrated on existing quantum devices.
Quantum Hamiltonian simulation (also called quantum simulation1 ) is arguably one of the most promising quantum applications.The evolution of a quantum system, starting from a quantum state represented by a high-dimensional complex vector | (0)⟩, obeys the Schrödinger equation: where  () is generally a time-dependent Hermitian matrix, also known as the Hamiltonian governing the system.Probing quantum phenomena from solutions of the Schrödinger equation is a promising approach to tackle many open problems in various domains, including quantum chemistry, high-energy physics, and condensed matter physics [Cao et al. 2019;Hofstetter and Qin 2018;Nachman et al. 2021].However, for an  qubit system, the dimension of both  () and | ()⟩ could be 2  , which makes its classical simulation exponentially difficult in general.Though mature software developments for classical simulation of quantum systems using methods like quantum Monte Carlo [Foulkes et al. 2001] and density-matrix renormalization groups [Schollwöck 2005[Schollwöck , 2011] ] succeed for restricted cases, many intermediate-size (∼100 sites) quantum systems of significance are still out of reach for classical computers.To address this issue, in his famous 1981 lecture, Feynman [1982] suggested employing a precisely controlled quantum system to simulate a target quantum system to avoid exponential complexity.Modern quantum technologies foster a variety of platforms to advance the realization of Feynman's proposal, for example, photonic systems [O'brien et al. 2009], superconducting circuits [Wendin 2017], semiconductor nanocrystals [Kloeffel and Loss 2013], neutral atom arrays [Saffman 2016], and trapped-ion arrays [Bruzewicz et al. 2019].Most of them are described by a Hamiltonian with continuous-time parameters characterizing the signals sent through controllable physics instruments like microwaves or magnetic fields.They are called analog quantum simulators.Only a few devices support a specific set of system evolutions with sophisticated pulse engineering, abstracted as a set of universal quantum gates [Kitaev 1997], hence called digital quantum computers.They include IBM's superconducting devices [Cross 2018] and IonQ's trapped-ion devices [Debnath et al. 2016].However, inherent noises on near-term digital quantum computers induce detrimental errors causing short coherence time (i.e., quantum states do not deteriorate to classical states within it) and preventing demonstrating large quantum applications with provable speedup.The solution through fault-tolerant quantum computing [Gottesman 2010] requires significantly lower gate implementation errors and better device connectivity, impractical in the NISQ era [Preskill 2018].
In the past decades, efficient quantum algorithms for quantum Hamiltonian simulation have been proposed [Childs 2010;Childs and Wiebe 2012;Lauvergnat et al. 2007;Lloyd 1996;Low and Chuang 2017].Implementing them follows a circuit-oriented scheme, where the quantum algorithms are designed and programmed as quantum circuits consisting of quantum gates abstracting the evolution of a fraction of sites in the quantum system.Then a quantum circuit compiler rewrites the circuits using a small set of quantum gates and translates each gate to pulses for specific devices.However, both programming and deploying algorithms in this scheme are highly non-trivial.In a seminal project, Childs et al. [2018] spent nearly two years programming a few major quantum simulation algorithms in Quipper [Green et al. 2013] due to tedious implementation details at the circuit level.Meanwhile, [Childs et al. 2018] shows that implementing algorithms via quantum circuits, even for a simple quantum system of medium sizes (around 100 qubits), requires an astronomical number of gates (around 10 10 before fault-tolerant encoding).Such circuits are far out of the reach of near-term quantum devices, which at most support a few thousand physical gates.The redundancies in programming and deploying algorithms via quantum circuit abstraction impede wide-range domain applications of quantum simulation.Developing better abstractions for quantum Hamiltonian simulation is highly desirable for productivity.
Motivated by the experimental success of simulation by designing and building specific precisely controlled quantum systems mimicking the Hamiltonian of target quantum systems [Ebadi et al. 2021;Gorshkov et al. 2010;Yang et al. 2020;Zohar et al. 2015], programming analog quantum simulators in a Hamiltonian-oriented scheme is a promising approach to quantum applications before fault-tolerant digital quantum computers are manufactured.Instead of programming quantum circuits implementing quantum simulation algorithms, Hamiltonian-oriented schemes directly program Hamiltonians of analog quantum simulators to synthesize an evolution equivalent to the desired quantum system evolution.Analog quantum simulators have native support for generating Hamiltonians, resulting in a succinct translation process to construct pulse schedules.Via Hamiltonian programming, complicated interactions that demand sophisticated quantum algorithms and large quantum circuits to simulate can be natively constructed and simulated on analog quantum simulators.We compare both schemes for quantum simulation in Figure 1 with further details.
By breaking the quantum circuit abstraction and exposing the Hamiltonian-level programmability of modern quantum devices, resource-efficient protocols can deliver reliable solutions to quantum applications [Shi et al. 2020] on NISQ devices, including various devices that do not support universal quantum gates, like QuEra's neutral atom devices.
For example, using the Hamiltonian-level programmability of IBM devices, an evolution governed by  () =  1  2 +  2  3 for time  = 1 (formal definitions in Section 2.1) can be simulated by a pulse schedule with two cross-resonance pulses [Malekakhlagh et al. 2020], as illustrated in Figure 1.Both are 280 nanoseconds long and approximately generate Hamiltonians  1  2 and  2  3 , respectively.Simultaneous execution of these pulses builds  () on the IBM device, and the eventual pulse schedule is 280 nanosecond long.As a comparison, the circuit-oriented scheme uses a circuit sequentially applying 4 CNOT gates (each requiring 264 nanoseconds to implement) with several single qubit gates to simulate  ().It generates a pulse schedule of length 1660 nanoseconds, around 6 times longer.More details of this example are in Section 5.2.Shortening pulse schedule duration is especially desirable because of IBM devices' short coherence time (around 100 microseconds).
Although Hamiltonian-oriented approaches for quantum simulation are beneficial, there is a lack of formal abstractions and supplementary software stacks.Prior works of analog quantum simulation following Hamiltonian-oriented schemes [Ebadi et al. 2021;Yang et al. 2020] manually construct device-specific configurations, which are tedious, error-prone, and demanding for hardware knowledge, hence not suitable for large-scale experiments.
We propose SimuQ with the first end-to-end automatic framework for quantum simulation on general analog quantum simulators, illustrated in Figure 2. As a result, domain experts can focus on describing the desired quantum simulation problems and leave their implementation and deployment to the automation of SimuQ.Our framework lays the foundation for large-scale applications of analog quantum simulators, paving the path for a wide range of novel and practical solutions to domain problems via quantum Hamiltonian simulation for common users.

Challenges
We identify three main technical challenges in building a framework to compile quantum simulation problems on analog quantum simulators: modeling the target quantum system, characterizing analog quantum simulators, and automatic compilation.Modeling of quantum Hamiltonian simulation.The first challenge is the lack of a scalable and user-friendly modeling language for quantum simulation.Prior programming languages to model Hamiltonian systems are designed specifically for numerical classical simulations.They treat the sites in the quantum system as a 1-dimensional array for the convenience of constructing matrix-based mathematical objects.One of the most popular languages, QuTiP [Johansson et al. 2012], employs matrices of exponential sizes to represent the quantum system, resulting in poor scalability.Another inconvenience is caused by the mandatory 1-D array labeling of the sites, like in OpenFermion [McClean et al. 2020], Pauli IR [Li et al. 2022], and Qiskit Operator Flow [Aleksandrowicz et al. 2019].Many quantum systems of interest have complicated site arrangement structures, for example, a 3-dimensional lattice, forcing users to construct the encoding of sites in their system manually.Abstraction and programming of analog quantum simulators.The modeling of analog quantum simulators is much more challenging.Unlike the circuit model where the fundamental primitives are a finite number of one or two-qubit quantum gates, analog quantum simulators are usually described by continuous-time Hamiltonians on the devices with almost infinite degrees of freedom, which differ significantly among platforms [QuEra 2022;Semeghini et al. 2021;Silvério et al. 2022].Moreover, complicated pulse engineering using different technologies generates various Hamiltonians with specific hardware restrictions even for one device.Hence a unifying and portable abstraction is in urgent demand to capture the programmability of analog quantum simulators.Compilation of quantum simulations on analog quantum simulators.The third challenge is the lack of an automatic compilation procedure.In the circuit-oriented scheme, the primitive gates are small-dimensional matrices.Large quantum evolution could be compiled into these gates with analytical formula (e.g., the Solovay-Kitaev theorem [Kitaev 1997]).In the Hamiltonianoriented scheme, the goal of compilation is to synthesize pulse schedules for analog quantum simulators where the Hamiltonian governing the device evolution approximately composes the target Hamiltonian  ().This compilation process needs efficient streamlines for general analog quantum simulators of medium sizes (around 100 sites) and considers realistic hardware constraints.

Contributions
To the best of our knowledge, SimuQ is the first framework for programming and compiling quantum Hamiltonian simulations on heterogeneous analog quantum simulators.The framework tackles the above three challenges with three major components correspondingly: a new programming language for descriptions of quantum systems, a new abstraction and a corresponding programming language for characterizing the programmability of analog quantum simulators, and a compiler with several novel intermediate representations and compiler passes to deploy and execute solutions to the simulation problems on analog quantum simulators.Hamiltonian Modeling Language.Without a strong design need for numerical calculations, we propose Hamiltonian Modeling Language (HML), which employs a symbolic representation treating sites as first-class objects and depicts Hamiltonians as algebraic expressions constructed via operators on the sites.This leads to a succinct description that remains rich enough to express many interesting quantum many-body systems.Users can focus on describing complicated quantum systems without tediously handcrafting encoding, reducing the cost of experimenting with new algorithm design ideas.Many quantum systems are programmed in HML with a few lines of code, as illustrated in Section 5.4.Beyond this, developing novel Hamiltonian-oriented quantum algorithms [Leng et al. 2023] can benefit from HML because of the user-friendly description of the algorithms.Abstract analog instruction sets and AAIS Specification Language.Inspired by the underlying control of these Hamiltonians, we propose a new abstraction called Abstract analog instruction set (AAIS) to describe the functionality of heterogeneous analog devices.Precisely, we abstract different patterns of engineered pulses as parameterized analog instructions.We expose pieces of Hamiltonian in the AAIS, which are generated by analog pulses on fractions of the system and abstracted as instruction Hamiltonians induced by instruction executions.The Hamiltonian governing the evolution of the device at time  is then the summation of instruction Hamiltonians of the instruction executions covering time .
AAIS exposes the Hamiltonian-level programmability of analog quantum simulators that lies beyond circuit-level abstractions.This feature enables the programming of non-circuit-based controllable quantum devices and further exploits the capability of devices supporting quantum gates within the current hardware limits.Via Hamiltonian-level control, evolution can be simulated by a much shorter pulse duration and become more robust against device noises.AAIS provides a new formal computational model of quantum devices and unifies the functionality descriptions for different devices with different technologies, simplifying the transfer of quantum simulation solutions to quantum devices of multiple platforms.These descriptions also inform theorists on what Hamiltonian-oriented quantum algorithms are realizable on near-term devices.
We propose several AAISs for QuEra, IonQ, and IBM devices.In general, AAISs should be designed by the hardware providers to expose the Hamiltonian-level control of their devices.We propose and implement AAIS Specification Language (AAIS-SL), a domain-specific language for hardware providers to depict the device programmability.We showcase how to design and program AAISs in AAIS-SL for the mentioned devices in Section 3.2.3.SimuQ compiler.We propose the first compilation scheme for quantum simulation on analog quantum simulators with several new intermediate representations.We handle the synthesis of instruction executions as symbolic pattern matching inspired by the seminal work in classical analog compilation [Achour and Rinard 2020;Achour et al. 2016].The instruction executions are then translated to executable pulses by resolving conflicts and reconstructing pulses using device-dependent programming languages and pulse engineering.
To the best of our knowledge, there is no existing compilation framework for heterogeneous analog quantum simulators.Our compiler provides a feasibility demonstration of automatically compiling quantum Hamiltonian simulation on general analog quantum simulators.Although it might not be the ultimate solution, we believe our framework provides a natural and intuitive approach to the modeling and processing of necessary information in constructing executable pulses from simulation problems.The competence of our compiler is demonstrated in Section 5.4 by showing that it can efficiently and reliably generate executable pulses for various domain applications.Pulses generated by SimuQ are executed on real devices and produce reasonable results, which has rarely been demonstrated in previous compiler works for quantum computing due to the abundance of circuit-oriented descriptions.Users can easily transport their quantum simulation experiments among different platforms and devices with our portable design of the compilation framework.It also enables the possibility of benchmarking various quantum devices on significant domain problems solvable via quantum simulation.
In summary, our contributions include: • We design and implement Hamiltonian Modeling Language in Section 3.1, a succinct DSL for describing quantum Hamiltonian simulation.
-Programs in HML are short for many important quantum systems, as shown in Section 5.4.• We design Abstract Analog Instruction Set as a novel abstraction of Hamiltonian-level programmability of analog quantum simulators, as illustrated in Section 3.2.We also implement AAIS Specification Language for hardware providers to design and program AAISs.
-AAISs enable the programming of non-circuit-based quantum devices.
-Hamiltonian-level programming shortens pulse schedule duration and thus is more robust to device decoherence errors, with case studies detailed in Section 5.2 and Section 5.3.Pulser [Silvério et al. 2022] developed by hardware service providers.These interfaces are designed to represent the specific underlying quantum hardware rather than to provide a unified interface for all analog quantum simulators like AAIS.Computational quantum physics packages like QuTiP [Johansson et al. 2012] support modeling and numerical calculation of quantum simulation without any compilation to quantum devices.Software tools for quantum Hamiltonian simulation are discussed extensively for circuit models [Bassman et al. 2022;Li et al. 2022;Powers et al. 2021;Schmitz et al. 2021;Van Den Berg and Temme 2020], while the expressiveness of the circuit abstraction limits their exploitation of analog quantum simulators.SimuQ's solver-based compilation is inspired by the seminal work in classical analog compilation [Achour and Rinard 2020;Achour et al. 2016].However, the specific abstraction and compilation technique therein is less relevant as the nature of analog quantum devices is very different from classical ones.

RUNNING EXAMPLE
We present a realistic but simple example to motivate our framework and showcase the methodology of our approach.Many experiments simulating the Ising model on Rydberg atom arrays are conducted in the literature to probe quantum phenomena barely tractable numerically [Labuhn et al. 2016;Schauss 2018].We will introduce the mathematical description of these experiments and demonstrate how to automate the process with SimuQ's DSLs, new abstractions, and compiler.

Quantum Preliminaries
Quantum systems consist of sites representing physics objects like atoms, mathematically described by qubits.A qubit (or quantum bit) is the analogue of a classical bit in quantum computation.It is a two-level quantum-mechanical system described by the Hilbert space C 2 .The classical bits "0" and "1" are represented by the qubit states |0⟩ = 1 0 and |1⟩ = 0 1 , and linear combinations of |0⟩ and |1⟩ are also valid states, forming a superpostition of quantum states.An -qubit state is a unit vector in the Kronecker tensor product ⊗ of  single-qubit Hilbert spaces, i.e., H = ⊗  =1 C 2 C 2  , whose dimension is exponential in .For an  by  matrix  and a  by  matrix , their Kronecker product is an  by  matrix where ( ⊗ )  +,+ =  ,  , .The complex conjugate transpose of | ⟩ is denoted as ⟨ | = | ⟩ † ( † is the Hermitian conjugate).Therefore, the inner product of  and  could be written as ⟨ | ⟩.We let Tr{ } denote the matrix trace of .
The time evolution of quantum states is specified by a Hermitian matrix function  () over the corresponding Hilbert space, known as the time-dependent Hamiltonian of the quantum system.Typical single-site Hamiltonians include the famous Pauli matrices:  (2.1.3) If the system evolves from time 0 with initial state | (0)⟩ , the state at time  is | ()⟩ =  () | (0)⟩ .
We provide basic physics intuitions of Hamiltonian operations.Hermitian operators correspond to physics effects like the influences of magnetic fields.Scalar multiplication (e.g., 2 •  ) changes the effect strength.Additions of operators (e.g.,  1 +  2 ) represent simultaneous physics effects, e.g., the superposition of forces.Multiplications of operators (e.g.,  1  2 ) represent the interactions across different sites, e.g., the hopping of atoms between different sites.
A quantum measurement extracts classical information from quantum systems.When measuring state |⟩, with probability | ⟨ |⟩ | 2 , we obtain a classical bit-string  and the quantum state |⟩ collapses to a classical state

Quantum Simulation of Ising Model
To understand the dynamics and properties of quantum systems, physicists have endless needs to simulate quantum systems.For example, an Ising model is mathematically expressed as where   , ℎ  ∈ R.This is a significant statistical mechanical model in the study of phase transitions of magnetic systems [Chakrabarti et al. 2008], with a simple example in Figure 3a.In physics, a qubit of an Ising model represents the magnetic dipole moment of an atomic spin.    represents the interaction between spins  and , and   represents the tendency of align direction agreement between them.  represents the effect of an external magnetic field interacting with the spins, and ℎ  represents its strength.The evolution of a quantum system under Ising models with different parameter regimes of   and ℎ  may characterize the magnetism of materials.However, its simulation generally requires exponential computations for classical computers because of the exponential dimension of the Hilbert space.Instead, we consider its simulation with analog quantum simulators.Nowadays, many controllable quantum systems may be utilized for quantum simulation, and one of the most promising platforms is Rydberg atom arrays [Saffman 2016], where neutral atoms are cooled and precisely controlled by laser beams.
In this section, we focus on the Ising model simulation using Rydberg atom devices, whose large-scale experimental demonstrations are repeated in many laboratories [Bernien et al. 2017;Ebadi et al. 2021;Labuhn et al. 2016;Schauss 2018].In these demonstrations, experimentalists configure their quantum systems in a task-specific manner.The following illustration showcases these procedures, which are mostly done by manual parameter tuning.This procedure is analogous to the early-day development of classical computers before automated compilers appeared.We consider a 3-qubit system of the Ising model evolving for time  under illustrated in Figure 3a.We want to reproduce the evolution under  Ising on an ideal Rydberg device, a simplified Rydberg atom array, illustrated in Figure 3b.Mathematically, the device evolution is governed by  Rydberg ( x, Δ, Ω, φ, ) where x, Δ, Ω, φ are configurable parameters whose details are introduced later, and  is the time variable whose unit is microseconds.The goal of quantum simulation is to reproduce the evolution of  Ising on the device by finding a configuration for x, Δ, Ω, φ satisfying  Rydberg ( x, Δ, Ω, φ, ) =  Ising , assuming the device evolution time is  ms.An ideal Rydberg device contains  atoms (viewed as qubits) and  laser beams addressing each atom.The positions of the atoms can be configured arbitrarily on a 1-D line.We denote their coordinates as vector x (unit: ) and assume they will not move.A Van der Waals force acts between each pair of atoms, whose effect is described by a time-independent Hamiltonian (2.2.3) Here  6 ≈ 5.42 × 10 6 MHz • m 6 is a real physics constant and n = ( −  )/2 is the number operator of qubit .For each atom, there is a local laser beam addressing it.It contains three configurable real-function parameters Δ (), Ω (), and φ  () (unit: MHz) representing the detuning, amplitude, and phase of laser, which can be configured freely over time.It generates an effect described by Then the collective Hamiltonian governing the evolution is the summation of effects of Van der Waals forces  (  )  and lasers  (  ) laser , (2.2.5) A manual way to find a device configuration is to match the coefficients of product Hamiltonians in  Ising by configuring the parameters.Note that    +1 of  Ising is a 2-qubit interaction which only comes from  (  )  .We configure x  accordingly by setting x  = (  −1)×10.52so that  (  ( +1) Note by setting x  , the system has unwanted We then configure the local laser beams to create the   terms in  Ising and compensate the unwanted   terms in  (  ) by setting Δ1 () ≡ Δ3 () ≡ 2.032, Δ2 () ≡ 4, Ω () ≡ 2 and φ  ≡ 0. We can confirm our synthesis by checking  Ising −  Rydberg ( x, Δ, Ω, φ, ) = −0.016 1  3 + 2.016 .Since 2.016 has no measurable effects on the evolved state by quantum information analysis, The error term is −0.016 1  3 , which is small compared to  Ising .

Automated Compilation by SimuQ
SimuQ provides automation to the above procedure for analog quantum simulators by establishing a workflow via new abstractions, intermediate representations, and compilation passes designed explicitly for analog compilation of quantum simulation.We illustrate how to program and compile  Ising on the ideal Rydberg device in SimuQ, with a glimpse of our new abstractions.
Programming an Ising evolution.Firstly, we program  Ising in HML with an implementation in Python as in Figure 4a.The first step is to declare a quantum system Ising (Line 1) and three sites (qubit) belonging to it (Line 2-3).By storing the sites in a list, we refer to the -th site of the system by q [ j ] .Then we construct  Ising 's terms one by one and store them in h (Line 4-8).Here we program the terms as an expression containing operators on the sites, e.g.,   as q [ j ] .X and    +1 as q [ j ] .Z * q [ j + 1 ] .Z.We then let the system evolve under h for time T (Line 9).
Characterizing ideal Rydberg devices.We propose a Rydberg AAIS to characterize the programmability of ideal Rydberg devices.An implementation is in Figure 4b.
The program starts with declaring the quantum device (Line 1) and its sites (Line 2).We can construct the number operators n and store them in n (Line 3).
We propose analog instructions to characterize the effects produced and configured on the device over time.An instruction execution generates an instruction Hamiltonian that adds up to the total Hamiltonian governing the system.In the Rydberg AAIS, we design instructions   to model the effects of the laser beam pulse signals (Line 5).Executing   generates an instruction Hamiltonian , where Δ  , Ω  , and   are local variables belonging to   (Line 6-9).When executing   , one may specify a valuation ì  and execution starting and ending time   ,   to induce a Hamiltonian   ( ì ) on the device in time interval [  ,   ).Instructions can be executed simultaneously to create an evolution under their collective effects, mathematically expressed as a summation of instruction Hamiltonians.For example, we can simultaneously switch on the laser beams addressing atoms 1 and 2 with configuration ì  1 and ì  2 and switch off others, generating a Hamiltonian ).Besides the instructions executed over time, analog quantum simulators may also have inherent effects, like the atom-atom interactions in the Rydberg atom devices.We declare a system Hamiltonian with global variables for them.Let   be the global variables representing the position of the atoms (Line 10).Then collective Van  where   contains the active instruction executions at time  and their variable valuations.
Synethsizing  Ising on ideal Rydberg devices.The SimuQ compiler automatically synthesizes a target Hamiltonian with an AAIS and generates executable pulses for devices.We go through the compilation steps on a 3-atom ideal Rydberg device, creating a configuration satisfying   () =  Ising .
(a) An evolution governed by  Ising (2.2.2) programmed in HML.Here  = 3 is the number of sites. = 1 is the evolution time.
. On the left is the equation system to synthesize  Ising using the AAIS for the ideal Rydberg device.
On the right is an approximate solution to it.It can be further interpreted as a pulse schedule in Bloqade.
The first step is to find a site layout between the Hilbert space of  Ising and the Hilbert space of ideal Rydberg devices.A trivial layout that maps the -th site of  Ising to the -th atom of the ideal Rydberg device suffices since the atoms are homogeneous.
For simplicity, here we assume the on-device evolution time is the target evolution time .We then synthesize  Ising by matching the coefficients of its product Hamiltonians.For a product Hamiltonian , let  [] be the coefficient of  in Hamiltonian  and   [] be the coefficient function of  in   .We take product Hamiltonian  1 as an example, whose coefficient is We want a set of instruction executions letting the coefficient of  1 be 0. Since instruction  1 is optionally executed, an indicator variable  1 ∈ {0, 1} is declared to represent whether  1 is executed.Then we establish an equation (2.3.3) In general, we declare   ∈ {0, 1} for each instruction   and establish an equation system by enumerating every  to match all coefficients of product Hamiltonians in  Ising .Figure 5 shows other established equations, and the full equation system is in Appendix A.
We employ a numerical solver to search for a solution to the non-linear mixed binary equation system.An approximate solution to the equation system is displayed in Figure 5.We interpret the solution as an instruction schedule: it specifies a collection of instruction executions according to the solutions to   and local variables.The solution in Figure 5 can then be interpreted: set the positions of atoms at  = [0, 10.52, 21.04], set laser beams configuration (Δ(), Ω(),  ()) ≡ (2.032, 2, 0) for atom 1 and 3 and (Δ(), Ω(),  ()) ≡ (4, 2, 0) for atom 2, and evolve the system for  ms.These configurations can be translated to a Bloqade or Braket program to execute on QuEra devices.
With the above procedure, we successfully simulate the evolution under  Ising on the ideal Rydberg device with the help of SimuQ.In practice, hardware providers design AAIS and implement the analog instructions for their specific devices.Front-end users only need to program  Ising and employ SimuQ to generate executable code to send to backend devices.SimuQ breaks the knowledge barriers for frontend users to exploit analog quantum simulators easily.The following sections will explicate SimuQ components and technical details.
Fig. 6.Syntax and denotational semantics of HML.Here Site contains system sites.ℎ  translates to the Hermitian matrix described by .  is a Hermitian matrix where operator  applies to site  and  applies to other sites.Function eval evaluates scalar expression  to a real number.

DOMAIN-SPECIFIC LANGUAGES
SimuQ is the first framework to tackle quantum simulation with Hamiltonian-level compilation to analog quantum simulators.It includes a collection of novel abstractions and domain-specific languages (DSL).We propose two DSLs in SimuQ: Hamiltonian Modeling Language (HML) for front-end users to depict their target quantum systems and AAIS Specification Language (AAIS-SL) to specify analog abstract instruction sets (AAISs) of analog quantum simulators.

Hamiltonian Modeling Language
HML is a DSL designed to describe the physical structure of many-body quantum systems that introduces many abstractions, including quantum sites and site-based representations of Hamiltonians.We implement this language in Python, with its abstract syntax and denotational semantics formally defined in Figure 6.
Abstract Syntax of HML.The first-class objects in HML are sites of quantum systems.A site is an abstraction for any quantized 2-level physical entity, like atoms with two energy levels, whose mathematical description is a qubit.In HML, site identifiers are collected in a set Site, each representing a site of the system.Four operators, , ,  , and  , are defined to represent the Pauli operators, and they are site operators.We denote the  operator of qubit  as . and other operators similarly.
A time-independent Hamiltonian is effectively a Hermitian matrix programmed by algebraic expressions.The basic elements are site operators ..Expressions for Hermitian are constructed using site operators and scalar expressions, consisting of common matrix operations and scalar operations.An evolution  in HML is a sequence of pairs (, ), representing a sequential evolution where each segment is governed by a time-independent Hamiltonian ℎ  and for time .
Remark 3.1.Beyond sites representing qubits, sites representing fermionic and bosonic modes can be defined together with their annihilation and creation operators.These are characterized by different types of sites in our implementation.Each type of site contains specific site operators, and the operator algebras are symbolically implemented.We omit formal discussions of them in this paper for simplicity.
Remark 3.2.HML can generally deal with Hamiltonians with continuous-time coefficients by introducing an additional identifier  in scalars.We choose sequences of time-independent evolution for numerical convenience in the compilation stage and leave this possibility for the future.
Semantics of HML.The denotational semantics of a program  in HML is interpreted as a unitary matrix by ⟦⟧ in Figure 6b.We let ℎ  translate program  into Hermitian matrices by evaluating the expressions.Then ⟦⟧ is the product of unitary matrices  −ℎ  , each representing the solution to the Schrödinger equation under  () = ℎ  for time duration .This is the solution to the Schrödinger equation governed by the piecewise-constant Hamiltonian programmed in .
Implementation of HML.We implement HML in Python to ensure accessibility to physicists and other common users.For a quantum system, we store the sites in a list.A product Hamiltonian  is then stored as a list of site operators using the same order of the site list.We also employ a Python dictionary to store a time-independent Hamiltonian  where the key-value pairs are made of a product Hamiltonian  and its coefficient denoted by We only store those  with non-zero  [] to compactly store Hamiltonians.For example,  Ising in Section 2.3 is represented by a dictionary { 1  2 : 1,  2  3 : 1,  1 : 1,  2 : 1,  3 : 1} .
To deal with the algebraic operations of Hermitian matrices, we symbolically implement an algebraic group for site operators (the Pauli group), and then Hermitian expressions are evaluated accordingly.For example,  1 +  2 is effectively implemented by enumerating  appearing in the keys of  1 's and  2 's dictionary, and construct ( Another example is multiplication, where  1 •  2 is implemented by enumerating   in   's dictionary keys.Since the site operators of different sites commute and those of the same sites are in a finite group,  1 •  2 is a product Hamiltonian  with an additional scalar multiplier  (i.e., ( Then we represent the evolution  as a list of tuples (, ) encompassing Hermitian matrix  and the evolution time  of an evolution segment.
Input Discretization Error.In many-body physics systems, Hamiltonians are commonly continuous, taking form  tar () =  =1   ()  .In HML, these Hamiltonians are discretized into a series of piecewise time-independent Hamiltonians in the input.Let the evolution duration be  and the discretization number be .We discretize  tar () over time steps {  }  =1 where 0 <  1 < ... <   <  and use the left endpoint of each interval as its approximation.Formally,  tar () is approximated by where 1 [, ) is the indicator function of set [, ).We assume ∥  ∥ = 1 where ∥•∥ is the spectral norm of matrices,   () are piecewise -Lipschitz functions, and {  }  =1 include all partitioning points of the piecewise Lipschitz coefficients   ().Then we can derive the error bound induced by discretization by the following lemma.Lemma 3.1 ([Nielsen and Chuang 2002]).The difference between the unitary  ( ) of evolution under  tar () for duration  and the unitary Ũ ( ) of evolution under H () is bounded by (3.1.2)Here  1 > 0 is a constant,  is the discretization number,  is the number of terms in  tar (), and  is the Lipschitz constant for   ().
This lemma shows that when we increase the discretization number , the evolution error in the approximation can be arbitrarily small, justifying the discretization.The proof is routine in quantum information and hence omitted.

Abstract Analog Instruction
Set.An AAIS conveys the functionality of an analog quantum simulator in the form of instructions and system Hamiltonians, including necessary device information for synthesizing target quantum systems.
We present the AAIS design and their physics correspondences in Table 1.An analog instruction  of an AAIS contains configurable parameters ì  and generates an instruction Hamiltonian   (ì ) on the device when executed.These parameters are local variables of , modeling the device parameters ∈ Para.Herm. :: Additionally, a system Hamiltonian  sys (ì  glob ) with a similar form of (3.2.1) applies an always-on effect on the device.A vector ì  glob of time-independent configurable parameters, called global variables, belongs to it.These global variables are configured before executing any instructions and stay unchanged during the execution.

AAIS Specification Language.
To specify AAISs with programs, we propose and implement AAIS-SL and present its abstract syntax and denotational semantics in Figure 7.
Abstract Syntax of AAIS-SL.To characterize the Hamiltonians of instructions, sites are declared with identifiers stored in a set Site, and site operators are defined as objects of sites by default.
Compared to HML, the major difference in the syntax is variables.Two types of variables whose identifiers are stored in Var  and Var  represent global variables and local variables, respectively.They are terms in parameterized scalars and consist of parameterized Hermitians.Then an AAIS for a device is effectively a collection of instruction Hamiltonians as parameterized Hermitian matrices, along with the system Hamiltonian.
Denotational Semantics of AAIS-SL.We interpret an AAIS  characterizing a device as a list of instructions along with the system Hamiltonian.Similar to the HML semantics, we employ a translation ℎ for expressions  to obtain parameterized Hermitians.Function eval evaluates a parameterized scalar expression  as a real function taking a valuation of variables and outputting a real number.Hence ℎ translates parameterized Hermitian expressions to Hamiltonians in the form of (3.2.1).Without ambiguity, we use {|| }(ì ) to represent the instruction Hamiltonian of .
Implementation of AAIS-SL.We also provide a Python implementation of AAIS-SL.We store sites and Hermitian matrices similarly to the implementation of HML.The difference is that instead of storing real numbers as coefficients, we store Python functions taking global variable and local variable valuations as inputs.We build function algebraic operations (i.e., ( 1 +  2 ) () =  1 () +  2 () and ( 1 •  2 ) () =  1 () •  2 ()) to deal with expressions and establish the parameterized Hermitian matrix expressions.As described in Figure 7, an AAIS is effectively represented by a system Hamiltonian and a list of instruction Hamiltonians.

Examples of AAIS.
Through AAISs, we provide a general framework to characterize the programmability of analog quantum simulators.Here we show how we design AAISs for QuEra, IonQ, and IBM devices.The design of AAIS abstraction pursues a balance between expressiveness and implementation hardness on real devices: to simulate more complicated quantum systems, more complicated instructions are needed, requiring more advanced technologies in their implementation.
Rydberg AAIS.The Rydberg AAIS designed for ideal Rydberg atom devices is introduced in Section 2.3.However, current QuEra devices do not support local laser addressing, meaning only a global laser interacts with every atom simultaneously.We use a variant for QuEra devices, called the global Rydberg AAIS, where there is only one instruction  with the instruction Hamiltonian Heisenberg AAIS.The IonQ and IBM devices, though using different platforms, share similar capabilities for constructing interactions.For both platforms, the Heisenberg AAIS is designed and implemented, which contains 1-site instructions  , and 2-site instructions  ,, for ,  ∈ {1, ..., } and  ∈ {,  ,  }, where  is the number of sites.Each instruction possesses one local variable, and their instruction Hamiltonians are: Here, the 1-site instructions  , are defined for every site in the system, and the 2-site instructions  ,, are only defined when ( , ) ∈  for an undirected connectivity graph  representing the connectivity of the detailed device.For ion trap devices,  is a complete graph with an edge between each site pair.Superconducting devices typically have limited connectivity, and we let  be the connectivity graph of the IBM devices.The Heisenberg AAIS can simulate a family of Heisenberg models [Auerbach 1998] covering the Ising models.A variant of the Heisenberg AAIS called the 2-Pauli AAIS extends the 2-site interactions to     interactions for ,  ∈ {,  ,  }, is capable of simulating more quantum systems, and is realizable on IonQ and IBM devices with specific connectivity.
IBM-Native AAIS.Besides the Heisenberg AAIS, for the IBM devices, we can also model their native effects in an IBM-native AAIS.Its 2-site instructions are  ,, for ( , ) ∈  where where   ,   ,   , and    are device-dependent constants.Instruction  ,, and  ,, can be simultaneously executed on IBM devices because of platform features.However, since it contains multiple terms with limited freedom of control, only a few quantum systems can be directly simulated by the IBM-native AAIS.For the systems that can be simulated, a much shorter pulse duration can be produced.A more detailed analysis is in Section 5.2.

INTERMEDIATE REPRESENTATIONS AND COMPILATION
Compiling a target quantum system to an analog quantum simulator is computationally hard in most cases, especially when we aim at a general framework.In this section, we build the first compiler for quantum simulation on general analog quantum simulators and several novel intermediate representations to conquer various challenges in the overall compilation.
The overall compilation workflow is presented in Figure 8.Since this is the first exploration of compilation to heterogeneous analog quantum simulators, our proposal intuitively decomposes the

Pulse Translator
Target System problem into several natural sub-problems that are rarely encountered in prior works and applies straightforward solutions to each step.Much space for optimizing our workflow within the scope of our approach is left for future work, which is discussed in Section 6.

Instruction Schedules and Hamiltonian Synthesizer
The first intermediate representation is instruction schedules that describe the execution of instructions on the device.We will also introduce a Hamiltonian synthesizer to create an instruction schedule that simulates a target quantum system.We use a more succinct representation of the instruction schedules generated by our Hamiltonian synthesizer.We characterize the set of instruction executions as a list S = [(  ,   )]  =1 where   = {(  , ì   )}  .S denotes a sequential evolution of simultaneous instruction executions in   for time duration   .Let   =  ≤    and assume  0 = 0.The absolute starting and ending time of instruction execution (  , ì   ) ∈   are then   −1 and   .Mathematically, the Hamiltonian  () governing the evolution of the device at time  ∈ As a solution to the Schrödinger equation, the execution of instruction schedule (S, ì ) results in an evolution of the device described by a unitary matrix 4.1.2Quantum Simulation by Executing Instruction Schedules.We formally define the task of compiling quantum simulations to a quantum device described by an AAIS.Consider a target quantum system described by a Hamiltonian  tar () and evolution time interval [0, ).Compilation of a quantum simulation asks for a site layout  and an instruction schedule (S, ì ).A site layout  is an injective mapping from each site in the target system to a site in the device system.We call the Hilbert space of the sites mapped to by  the layout subspace of the device Hilbert space.A layout  induces a mapping L from the target system's Hilbert space to the layout subspace.When limiting L ( ) in the layout subspace where  is a Hermitian matrix in the target Hilbert space, one can relabel the sites of L ( ) according to  −1 and recover  .When  () is a time-dependent Hamiltonian of the target Hilbert space, we write L ( ) as a Hamiltonian of the device Hilbert space satisfying L ( ) () = L ( ()).Let the execution of the instruction schedule (S, ì ) produce a unitary matrix  and let the evolution under L ( tar ) for time interval [0, ) be L ( tar ).We say that a site layout  and the instruction schedule (S, ì ) simulate  tar( ) if  approximates L ( tar ).
4.1.3Hamiltonian Synthesizer.Since HML discretizes continuous Hamiltonians with small errors, in this step, we consider a target quantum system described by a sequence of evolution under  tar, for time duration   indexed by  ∈ {1, ...,  }.We want to synthesize an instruction schedule simulating the target quantum system on a device described by an AAIS  = [ 1 ; ...;   ;  sys ].
Our Hamiltonian synthesizer follows a three-step loop: (1) propose a site layout ; (2) build a coefficient equation system; (3) solve the mixed-binary equation system.If the solver does not find an approximate solution, we repeat this process until a timeout condition is met.
Site layout proposer.The first step of the synthesizer loop proposes a site layout  and later steps check its feasibility.To the best of our knowledge, although layout synthesis for quantum circuits is thoroughly studied [Tan and Cong 2020], there is no prior work on the layout synthesis for Hamiltonian-oriented quantum computing.The main difference between them is the unavailability of swap gates for many analog quantum devices, i.e., QuEra's Rydberg atom arrays.
We employ a search with pruning as a general solution to a layout proposer.The pruning strategy is to abort the search when there exists a product Hamiltonian  and  where  tar, [] ≠ 0 and L () does not have a non-zero coefficient expression in any   and  sys .This abort condition can be met halfway through the search.For a partial layout  (where several sites are not assigned in  yet) and a product Hamiltonian , we can map it to a product Hamiltonian L () of the device with holes on several sites.When searching for L () in an AAIS, holes can match any site operator.If none is found, the current search branch is aborted.
After proposing a layout, we proceed to steps (2) and (3) to check its feasibility.If rejected, the above search process returns and to search branches to propose another layout.If all possibilities are not feasible, the compiler will report no solution and fail the process.
Coefficient equation builder.We synthesize instruction executions by a system of mixed-binary non-linear equations to match coefficients of product Hamiltonian in the target quantum system.
Given a site layout , a set of equations is constructed to match the coefficients in  tar, for every 1 ≤  ≤  .We create time variables   to represent the evolution time for instruction executions synthesizing evolution of  tar, for time   , with constraints   > 0. For instruction   in the AAIS, we create an indicator variable  , ∈ {0, 1} to indicate whether   is selected to be executed in the synthesis of  Then we establish a coefficient equation for each product Hamiltonian  to match  tar, : Here the left-hand-side calculates the summed effects of  from each instruction and the system Hamiltonian and the right-hand-side calculates the effect of  in the target quantum system.There are typically many trivial equations in this system having 0 on both sides since only a few  appear in either  tar, or {|  | } with respect to the exponentially many possible combinations of site operators.We propose Algorithm 1 to find all non-trivial equations.This algorithm starts with a list  containing all the product Hamiltonians with non-zero coefficients in  sys and L ( tar, ).It then enumerates the list  and establishes coefficient equations for each  by enumerating

AAIS Equations
Fig. 9.An example illustrating the equation builder.
2 is searched for in AAIS, where  1 and  2 are found and used in equation for  2 .10.An example of Trotterization from an instruction schedule to a block schedule, with a conflict graph and its grouping.
instructions   in AAIS.During this process, it may encounter instruction Hamiltonians {|  | } who contain product Hamiltonians  ′ that never appears in .These product Hamiltonians may lead to non-trivial equations, so we add them to .An example of this procedure is illustrated in Figure 9.
Mixed equation solver.The established coefficient equation system is mixed-binary and non-linear.A solver is applied to obtain approximate solutions which correspond to instruction schedules.
We provide several options for the solver.The first is dReal [Gao et al. 2013] based on -complete decision procedures, which supports real variables, binary variables, and algebraic functions in HML and AAIS-SL.It performs well when the coefficient expressions are close to linear (the Heisenberg AAIS), while poorly when highly non-linear (the Rydberg AAIS).
As another option, we construct a least-squares-based solver.This solver uses a relaxationrounding scheme.We apply a continuous relaxation to loosen the value range of indicator variables from  , ∈ {0, 1} to ŝ, ∈ [0, 1], substitute ŝ, for  , in the equation system, and solve the equation system by least-squares methods via an implementation in SciPy [Virtanen et al. 2020].We then round the indicator variables  , according to the solution.The criterion sets  , to 1 if there is     , [] (ì  , ) ŝ, >  for a pre-defined tolerance parameter , and sets to 0 otherwise.This criterion evaluates how much error the solution will induce if we set  , to 0. We then solve the equation system again to obtain a more precise solution.
The solver generates an approximate solution with error , defined by If  <  where  is a pre-defined tolerance, the solution is accepted.Otherwise, we return to step (1) to generate another layout and check feasibility.An accepted solution induces an instruction schedule (S = {(  ,   )}, ì ) where   = {(  , ì  , ) :  , = 1}.
4.1.4Error Induced by Hamiltonian Synthesizer.Now we bound the error in the evolution induced by the approximation in the equation solving of the Hamiltonian synthesizer since our solver generates approximate numerical solutions.Let Û ( ) be the unitary of executing generated instruction schedule (S, ì ), and Ũ ′ ( ) = L ( Ũ ( )) be the unitary of the evolution of the discretized target system after site layout mapping L. We can conclude the error induced by the Hamiltonian synthesizer is bounded by tolerance  in the equation solving and the proof is routine and omitted.Lemma 4.1 ([Nielsen and Chuang 2002]).The error of evolution induced by equation solving is bounded by a constant  2 > 0 and error bound  with the following inequality: (4.1.5)Remark 4.1.In general, compiling a target system is computationally hard.Finding a site layout for machines with specific topology can be as hard as the sub-graph isomorphism problem, an NPcomplete problem.Besides, since the design of AAIS does not pose strict restrictions on the expressions, pathological functions may emerge in the coefficients, which complicates the equation-solving process.Our solutions to these problems may not be optimal but are intuitive, feasible, and efficient enough for most cases (also refer to Section 5 for detailed case studies).

Block Schedules and Conflict Resolver
Instruction schedules are oversimplified descriptions of what can be executed on the devices.Mainly, there are two realistic restrictions not captured by instruction schedules.First, some instructions on real devices can not be executed simultaneously.For example, on an IonQ device,  1,2,  cannot be simultaneously executed with  1,2, since they use the same interaction process with different bases.Second, instruction execution implementations may take longer than the scheduled execution time.We propose a flexible generalization to the instruction schedules called block schedules and implement a conflict resolver to compile generated instruction schedules to block schedules.

Block Schedules.
A block schedule is a temporal graph whose vertices are blocks of instruction executions, together with the valuation of the global variables.An instruction block  contains a collection of instruction executions whose evolution duration is .The block schedule is then a directed acyclic graph where an edge (  →   ) is a restriction: instructions in   should start simultaneously after instruction executions in   end.Instruction schedules generated by our Hamiltonian synthesizer are special cases of block schedules where the temporal graph forms a chain and blocks are the collections of instruction executions.
When executing a block schedule, we first decide the execution order  : ( 1 , ...,   ) of the blocks and then evolve the system by  sequentially.Let the   contain {( , , ì  , )}  with evolution time   .The evolution will generate a unitary transformation Our next step is to generate a block schedule where instructions in each block are simultaneously executable and approximate the execution of the instruction schedule.

Instruction Decorations.
In general, the conflict relation of instructions forms a graph  : (  ,   ) ∈  means that   and   cannot be executed simultaneously.To ease the description of  , we introduce decorations to instructions to specify properties like categories of instructions.More decorations can be added based on the detailed hardware restrictions accordingly.
Signal Lines.Physical pulses are sent to devices through signal carriers like electronic wires or arbitrary waveform generators (AWG).A natural conflict is that if two instructions require the same signal carrier, they cannot be executed simultaneously.We abstract the concept of signal carriers as signal lines and assign each instruction  to a signal line denoted by ().If (  ) = (  ), instructions   ,   conflict with each other.
Nativeness.Another aspect leading to conflicts is whether instruction implementations employ compound pulses to approximate an effective Hamiltonian.For example, IBM devices generate  ,, by direct microwave controls of a cross-resonance pulse [Malekakhlagh et al. 2020].Hence the IBM-native AAIS for IBM devices has  ,, as native instructions: they can be simultaneously executed with other native instructions.To effectively realize  ,, , a compound sequence of microwaves including two cross-resonance pulses is applied to approximate a     interaction [Alexander et al. 2020].Simultaneously applying other pulses on site  or  will break the approximation.Hence  ,, are derived instructions in the IBM-native AAIS.
Let inf( ) be the sites on which Hamiltonian  acts non-trivially (when limited on these sites,  is not identity).We assume that implementing a derived instruction  only affects inf ({|| }).Then a derived instruction  1 conflicts with

Conflict Resolver via
Trotterization.Given a conflict graph and an instruction schedule (, ì ), we implement a conflict resolver to generate a block schedule without conflicts in each block.
A well-studied technique in quantum information to simulate summed Hamiltonians in quantum simulation is Trotterization.Let Hamiltonian  =  =1   where  Hamiltonians evolve the system simultaneously.We assume we have a device supporting evolving single   for any duration , realizing unitary matrix  −  , while there is no evolution under  =1   .Trotterization (also known as the product formula algorithm) [Lloyd 1996] makes use of the Lie-Trotter formula (4.2.2) By choosing a large  , the above formula shows that we can approximate the evolution under  for time  by repeating for  times a sequential evolution for  ∈ {1, ..., } under   for time / .Each segment of evolution realizes a unitary transformation  − ( / )  as in the formula.First, we consider the case where  sys = 0.Each (  ,   ) in S is considered independently.Let   = {(  , ì   )}  and the conflict graph of these instructions be  .To accommodate Trotterization in a conflict resolver, we first categorize the instructions into groups without conflict.The grouping is effectively a coloring of vertices in  where no edge connects monochromatic vertices.We employ a greedy graph coloring algorithm from NetworkX [Hagberg et al. 2008]  Additionally, we deal with the cases where the system Hamiltonian  sys is non-zero.Let L be the maximal coloring number  in the above process.We assume that there exists ì  L such that  sys ( ì  L ) =  sys ( ì )/ L. Some devices may not support this assumption, but it is rarely used since only a few devices with non-zero system Hamiltonian have conflicting instructions.We then augment the number of groups to L for each (  ,   ) ∈ S by adding empty sets in groupings.Now we create a block schedule with ì  L and a temporal graph constructed on the augmented groupings.Executing this block schedule approximates the execution of the given instruction schedule.

Error
Induced by Conflict Resolver.The Trotterization resolves conflicts while also introducing errors.We denote the instruction schedule where  = {({( , , ì  , )}  ,   )}  =1 and its evolution as Û ( ).For segment  of evolution in , we assume the grouping is {   }   =1 and the evolution by executing the block schedule as Ū ( ).As implied by this lemma, in ideal cases, increasing the Trotterization number reduces the induced error to arbitrarily small.However, it also increases the total number of instruction executions.Due to the non-negligible error accumulations in each instruction execution on devices, there is a trade-off over the Trotterization number  depending on the real-time parameters of the device, where we leave the freedom to user specification.
Optimization techniques for Trotterization are also well-developed in theory [Childs et al. 2021], and we discuss their implementation in Appendix B.

Signal Line Schedules and Scheduler
The eventual output of SimuQ contains the pulses sent through signal carriers for devices to execute.We propose another intermediate representation, called a signal line schedule, to depict the concrete instruction executions sent through each signal line abstracted in Section 4.2.2 before generating platform-dependent executable pulses.For signal line , it contains a list of instruction executions (, ì ,   ,   ) with absolute starting and ending times and satisfying () = .
To obtain a signal line schedule, we build a scheduler to traverse the temporal graph of the block schedule via a topological sort and generate a valid execution order of block schedules.It employs a first-arrive-first-serve principle for each signal line.The scheduler first extracts information about how long implementing each instruction execution takes from real devices.Next, it arranges instruction executions on the signal lines at the earliest possible starting time obeying the order.Remark 4.2.The scheduling process may be independently configured and optimized, and the scheduler may use other criteria to determine the traversal order of instruction blocks or the alignment of blocks within the scheduled order as long as the hardware permits.This freedom in the scheduling process may be leveraged to reduce cross-talk [Murali et al. 2020] between the blocks or save small implementation overheads.We illustrate only a basic strategy and leave the exploitation for the future.

Pulse Schedules and Pulse Translator
In its final stage, the SimuQ compiler translates a signal line schedule into a pulse schedule using hardware providers' domain languages and APIs.
We extract the pulse shapes from the devices for each platform to implement instruction executions.We substitute the instruction execution on each signal line for pulse shapes configured by the valuations of local variables via the format specified by a pulse-enabled quantum device provider.

Translation to Hardware
APIs.There are few pulse-enabled quantum device providers, and programming pulses is a challenging endeavor that requires extensive platform knowledge of various hardware and software engineering considerations.We demonstrate the effectiveness of SimuQ using QuEra, IBM, and IonQ devices.
QuEra's Rydberg atom devices.Two APIs to QuEra devices are supported by SimuQ for the global Rydberg AAIS: Bloqade [QuEra 2022] programs and Amazon Braket programs.We set the atom positions according to the valuation of global variables and laser configurations as piecewise constant functions according to the valuations of local variables.Since the detuning Δ and amplitude Ω generate linear effects, piecewise linear laser configurations are also supported as an option.For Amazon Braket programs, Ω() should start and end at amplitude 0, so we add short (0.1ms) time intervals to the pulses' beginning and end with linear ramping.We also scale the pulse schedules to a total length of around 3.5ms to fit in the 4ms duration limit of the device.
IBM's superconducting devices.For IBM devices, SimuQ can generate Qiskit Pulse programs for the Heisenberg AAIS and the IBM-native AAIS.For single-site instructions, the IBM device supports implementations of native  and  instructions and derived  instructions.We build up DRAG pulses [Motzoi et al. 2009] to realize  and  instructions and free Z rotations [McKay et al. 2017] to realize  instructions, which are standard superconducting device techniques.Two-qubit instructions in the Heisenberg AAIS are realized through the     interactions created by echoed cross resonance pulses [Malekakhlagh et al. 2020] together with single-qubit evolution to change bases.We follow Earnest et al. [2021] and realize interaction-based gate implementations, whose benefits are further explained in Section 5.3.Additionally, we extract cross-resonance pulses from Qiskit and compose pulses to realize native  ,, in the IBM-native AAIS.
IonQ's trapped-ion devices.SimuQ supports both IonQ cloud and Qiskit circuit programs for IonQ devices with the Heisenberg AAIS.Unlike QuEra and IBM devices, IonQ does not provide pulse-level programmability for their ion trap devices.However, we can still exploit their native gate set to generate a quantum circuit with precise control of the execution on their devices.With the support of partially entangling Mølmer-Sørenson gate [Sørensen and Mølmer 2000], we can implement instructions of the Heisenberg AAIS with higher fidelity.More details are explained in our case studies in Section 5.3.  () (pulses) for signal line , generating the effective Hamiltonian   () physically.For example, instruction execution (, ì ,   ,   ) for signal line  in the signal line schedule should be translated into pulses ì   () that effectively generate   () = {|| }( ì ) for   ≤  <   .Collectively, the Hamiltonian on the device is  dev () =  sys +    (), and the semantics of executing a pulse schedule is the unitary evolution under  dev ().Yet, the implementation of instructions on real devices may be imperfect.We assume that there is a implementation error threshold Δ such that the on-device Ȟ () and Ȟsys satisfies max , Ȟ () −   () ≤ Δ and Ȟsys −  sys ≤ Δ, forming on-device evolution under Ȟdev () = Ȟsys +  Ȟ ().Since the signal line scheduler does not alter the semantics of block schedules, we bound the implementation error on the device.Lemma 4.3 ([Nielsen and Chuang 2002]).The difference between the unitary Ǔ ( ) on the device and the unitary Ū ( ) of executing the block schedule generated by the conflict resolver is bounded by where  3 > 0 is a constant,  is the number of signal lines and system Hamiltonians, and Γ = max    is the maximal number of groups in the conflict resolver.
With a faithful implementation of instructions on real devices, the pulse translator produces negligible errors.The proof is routine in quantum information and is therefore omitted.We remark that other forms of device errors (e.g., high-energy space leakage) can be analyzed similarly.

Semantics Preservation of SimuQ Compiler
If compilation succeeds, the SimuQ compiler generates executable pulse schedules from programmed quantum systems with bounded errors.We conclude the approximate semantics preservation theorem of the SimuQ compilation process using Lemma 3.1, Lemma 4.1, Lemma 4.2, and Lemma 4.3.Theorem 4.4 (Semantics Preservation).Given a Hamiltonian  tar () =  =1   ()  where   is piecewise -Lipschitz and ∥  ∥ = 1, if the compilation succeeds, SimuQ generates a site layout  and an executable pulse schedule.Let the unitary  ( ) represent the evolution under  tar () for duration [0, ] and Ǔ ( ) for the evolution executing the pulse schedule on the device.We have Here,  is the evolution time, L is the site layout mapping of layout ,  1 ,  2 ,  3 are constants,  is discretization number,  is the error threshold in Hamiltonian synthesizer,  is the Trotterization number, Δ is the instruction implementation error threshold,  is the number of signal lines and system Hamiltonians on the device, and Λ and Γ depend on the Trotterization strategy in the compilation.
Tuning , ,  and improving the implementation to decrease  can reduce errors induced by the SimuQ compiler to arbitrarily small.The evolution under  tar is hence simulated on the device.

CASE STUDIES
We conduct several case studies highlighting SimuQ's portability and the advantages of Hamiltonianoriented compilation, including native instructions and interaction-based gates.We also establish a small benchmark of quantum simulation to evaluate the SimuQ compiler performance.

Multiple-Platform Compatability
We compile and execute the Ising model on multiple supported devices of SimuQ.The following experiments show the portability of SimuQ on heterogeneous analog quantum simulators.We only need to program the target quantum systems once and apply the SimuQ compiler to generate code for different platforms and deploy and execute them on multiple real devices.
We focus on the simulation of the Ising model introduced in Section 2.2.We demonstrate two instances: a 6-site cycle and a 6-site chain, mathematically depicted by The target quantum system is to simulate  cycle and  chain for  = 1.When Trotterization is utilized, we set the Trotterization number to be 4, which is empirically selected based on experiment results.SimuQ successfully compiles  cycle on QuEra devices using the global Rydberg AAIS, both  cycle and  chain on IonQ devices using the Heisenberg AAIS, and  chain on IBM devices using the Heisenberg AAIS.We send the generated code to execute on corresponding devices.Since QuEra devices do not support state tomography, we evaluate the results on these platforms by a metric based on measurements supported by all devices in our experiments.We obtain the frequency of reading a bit-string  in a measurement instantly after the simulation finishes as a distribution P exp [] and numerically calculate the ground truth distribution P GT [] of obtaining .We utilize the total variation distance  (P exp , P GT ) = 1 2  ∈ {0,1} 6 |P exp [] − P GT [] | to evaluates the errors.We present the classical simulation of devices and real device execution results in Figure 11.
The minor errors in the classical simulations indicate the correctness of our framework.In ideal cases, the errors are induced by uncancellable non-neighboring     interactions and short ramping times for the global Rydberg AAIS and by Trotterization errors for the Heisenberg AAIS.The real device execution results show higher errors than classical simulation because of device noises, while they are valid quantum simulation results.The errors on the IBM device are non-monotone, likely because the large state preparation and measurement errors affect more heavily the cases where the states deviate only a little from the initial state.
SimuQ fails to compile  chain on QuEra devices since it requires different local detuning parameters for different sites, which current QuEra devices and the global Rydberg AAIS do not support.It also fails to compile  cycle on IBM devices since there is no 6-vertex cycle in IBM devices.

Hamiltonian-Oriented Compilation with Native Instructions
The most significant benefit of enabling Hamiltonian-level programming is to gain fine-grained and multi-site control via native operations.Near-term quantum devices have short coherence times: quantum states will deteriorate and lose their quantumness quickly.Generating shorter pulses to achieve the same effects is one of the crucial tasks for compilers of modern quantum devices.In this case study, we showcase the advantage in the lengths of pulse schedules enabled by Hamiltonian-oriented compilation using the IBM-native AAIS.
Our target quantum system evolves under  2 =  1  2 +  2  3 for time  = 1, a small 3-site system.The IBM-native AAIS contains two native instructions  1,2, and  3,2, with  1  2 and  2  3 interactions respectively.Following Greenaway et al. [2022], the simultaneous execution of them can be realized by simultaneously applying two cross-resonance pulses on IBM devices.By automatically compensating the other terms in SimuQ with native instructions  2, and derived instructions  1, and  2, (their effects commute with  1,2, and  3,2, so no Trotterization is needed), the uncancellable remains are  1  2 interactions and  2  3 interactions.Fortunately, they can be reduced to one magnitude smaller than  1  2 and  2  3 interactions when selecting a relatively large Ω, and are considered small errors in the compilation.The pulse schedule to realize  2 , displayed in Figure 12, is around 280ns long.
2 can also be compiled on IBM devices by a circuit-based compilation with the help of Qiskit.It first decomposes the simulation into a circuit with two gates   1  2 (2)  2  3 (2) where      ( ) =  − ( /2)    .It then invokes Qiskit's transpiler to decompose each      ( ) into two CNOT gates and several single qubit gates and generates a Qiskit pulse schedule, which is displayed in Figure 13 and is around 1660ns long.This is around six times longer than the pulse schedule generated by SimuQ using the IBM-native AAIS.

Hamiltonian-Oriented Compilation with Interaction-based Gates
For some devices that lack the support of simultaneous instruction executions by native operations, we can still exploit the capability of realizing gates based on evolving interaction for various time    periods.By interaction-based gates, we refer to quantum gates of form   () =  − , where the time duration of the pulse shapes implementing them is strongly correlated with .These gates are common on platforms supporting universal gates like IBM devices and IonQ devices but are not exploited in their provided compiler due to the hardness in calibration.Under the conventional circuit-oriented compilation where quantum programs are compiled to a gate set with fixed number 2-qubit gates (typically, only CNOT gates), interaction-based gates are decomposed using multiple 2-qubit gates for the convenience of calibration, like      ( ) gates that are decomposed using 2 CNOT gates by Qiskit and translated to a pulse schedule of long and fixed duration.Although interaction-based gates cannot be simultaneously applied on devices when overlapping sites exist, exploiting them can still significantly reduce the duration of generated pulse schedules and increase the fidelity of simulations as observed in [Earnest et al. 2021;Stenger et al. 2021].
In this section, we implement the quantum approximate optimization algorithm (QAOA) in SimuQ and execute it on IBM and IonQ devices.The QAOA algorithm is a classical-quantum Hamiltonian-oriented algorithm designed to solve combinatorial problems.We omit the algorithm analysis and refer interested readers to [Farhi et al. 2014].We consider the quantum part of a typical case of the QAOA algorithm, where the target quantum system evolves under a length- sequence of alternative evolution between  1 and  2 where

588
Table 3.A benchmark of quantum simulation problems.We program and compile the models in SimuQ to obtain pulse schedules for QuEra and IBM devices and quantum circuits for IonQ devices.We record the compilation time (comp.time), the pulse duration (P.D.), and the 2-qubit gate count for the generated circuits.
No. sol.represents cases where the SimuQ compiler reports no solution because of hardware constraints, such as limited interactions of QuEra devices and machine topology for IBM devices.Time out is reported when the compilation takes more than an hour, which happens in the search for a 64-qubit cycle on IBM devices.
Pulse schedule duration for IBM devices using SimuQ and Qiskit to compile is reported.On average, Qiskit's default compilation passes generate 29.3 times longer pulse schedules than the SimuQ compiler over cases successfully compiled.We also report the number of partially entangling Mølmer-Sørenson gates when compiling on IonQ's devices to indicate the total duration.

CONCLUSION AND FUTURE DIRECTIONS
The domain-specific language SimuQ described in this paper is the first framework to consider quantum simulation and compilation to multiple platforms of analog quantum simulators.We propose HML for front-end users to program their target quantum systems intuitively.We also design abstract analog instruction sets to depict the programmability of analog quantum simulators and the AAIS-SL to program them.Furthermore, the SimuQ compiler is the first compiler to generate pulse schedules of analog quantum simulators for desired quantum simulation.
Since this is the first feasibility demonstration of programming analog quantum simulators, there is much optimization space for our compiler.First, since different devices have different properties crucial to the compiler's efficiency, we can develop compilation passes specifically for each platform.Second, this paper employs a brute-force search with heuristics to find a site layout where more pruning techniques are desired.Third, The hand-crafted mixed-binary equation solver can also be optimized according to the structure of the problem.Furthermore, with a better understanding of hardware, we can design more powerful AAISs.Lastly, we can add more compilation techniques like [Clinton et al. 2021] to synthesize product Haimltonians not appearing directly in the given AAIS with a combination of instruction executions.

Fig. 2 .
Fig. 2. The framework of SimuQ.Here abstract analog instruction sets are designed and programmed by hardware developers based on the capability of their analog quantum simulators.

Fig. 3 .
Fig.3.Illustrations of the target quantum system and the analog quantum simulator in our running example.

Fig. 4 .
Fig. 4. Examples of HML and AAIS specification language implemented in Python.
4.4.2Semantics of Pulse Schedules and Errors in Instruction Implementation.Abstractly, a pulse schedule includes a time-dependent function ì

Fig. 11 .
Fig. 11.The simulation errors of the 6-site Ising models on multiple platforms.Ideal results are obtained by compiling with SimuQ and executing on noiseless simulators.

Table 1 .
b) Semantics of AAIS programs.Fig.7. Abstract syntax and denotational semantics of AAIS-SL.Here Site contains the sites of the device.Var  and Var  contain the local and global variables correspondingly.eval() evaluates  as a real function.Comparison among physics concepts, Rydberg devices instances, and AAIS abstraction designs.
that can change over time.The instruction Hamiltonian   (ì ) takes the following form where   (ì ) is a real function depending on the local variables ì : In later cases when the absolute starting time and ending time are unimportant, we also use duration   =   −   in instruction executions.An instruction schedule includes a valuation ì  to the global variables and a set of instruction executions {(  , ì   ,  , ,  , )}.At the time , the instruction executions satisfying  , ≤  <  , generate effects on the device.Executing the instruction schedule evolves the device, governed by: 4.1.1Instruction Schedules.An instruction execution (, ì ,   ,   ) specifies an instruction , a valuation ì  ↦ → ì  of 's local variables, and evolution starting time   and ending time   .It applies a Hamiltonian   ( ì ) to the device during [  ,   ).: , ≤ < ,    ( ì   ).(4.1.1) tar, .Assuming that   has local variables ì   of dimension |ì   |, we create |ì   | new equation system variables stored in a vector ì  , .For global variables, we create a vector ì  of dimension |ì  glob | of the AAIS, which is independent of .In total, we have created |ì  glob | +   |ì   | +  real variables for global variables, local variables, and time variables respectively, and   indicator variables.