Methods, systems and kits for quantum-optimized cross-backend software development

Abstract

Methods, systems, and kits for quantum optimization cross-backend software development are provided. According to at least one aspect of the present embodiment, a method is provided for building a quantum optimization algorithm executable on quantum hardware. The method includes receiving an input including a user-defined problem and at least one predefined variational quantum algorithm (VQA) statement, and converting the received input into a workflow. The method also includes obtaining an abstract variational quantum algorithm (VQA) representation based on the workflow, creating a compiled, target-optimized backend-specific quantum circuit based on the abstract VQA representation, and returning a structured, contextual, and indexable output, the output including the optimization results and additional metadata.

Description

[Technical field]

[0001] This application claims priority from Singapore Patent Application No. 10202203429U, filed on April 4, 2022.

[0002] The present invention relates generally to computational optimization, and more particularly to methods, systems, and kits for quantum optimized cross-backend software development. [Background technology]

[0003] A digital or "classical computer" is a programmable device that processes bits of information according to logical rules. "Quantum computing" refers to processing information using a quantum mechanical system. A "quantum computer" can process quantum information and potentially solve problems faster than a conventional computer. To test the capabilities and advantages of quantum computers in the current classical computing environment, it is possible to use a classical computer to simulate the operation of a quantum computer of limited size. The term "simulator" refers to a classical computer that simulates a quantum computer.

[0004] Small-scale prototype quantum computers, called noisy intermediate quantum (NISQ) computers, are devices that can support tens to thousands of noisy qubits, where noisy means that the qubits are susceptible to errors caused by interactions with their environment.

[0005] In addition to simulators, NISQ computers are available for a variety of modalities and supporting platforms, including ion trap, superconducting chip, photonics and atom-based quantum computing systems, accessible either directly on the cloud or via commercial cloud providers such as AWS, Microsoft, Google and IBM. Additionally, quantum hardware manufacturers (e.g. IonQ, Honeywell and Rigetti) offer access to NISQ computers.

[0006] NISQ algorithms (NISQAs) are heuristic techniques used while offloading NISQ devices. Since fault tolerance is still many years away, the quantum community is exploring what applications NISQAs can solve. In particular, there is currently growing interest in a family of NISQAs known as variational quantum algorithms (VQAs). VQAs are hybrid quantum-classical optimization algorithms that evaluate an objective function (usually encoded by a parameterized quantum circuit) using quantum computations and then update the parameters of this function using classical optimization techniques. VQAs are good candidates to demonstrate that quantum computers can solve practical computational tasks better than classical computers (given a reasonable resource metric), a demonstration that has been called the quantum advantage.

[0007] Therefore, there is growing interest in academia, industry, and the developer community to create and test VQA for real-world applications. This means that there is an increasing need for quantum computing software that can support applications using VQA. Currently, there is an increasing use of software that supports the development and deployment of quantum computing (e.g., IBM Qiskit, AWS Braket, Google Cirq, Xanadu PennyLane, etc.), and many of these quantum computing software have libraries that make it easy to build and deploy quantum computing based on VQA.

[0008] The goal is to use quantum computers to solve optimization problems. However, building quantum algorithms is difficult and challenging. It requires deep knowledge of the underlying algorithms and a general understanding of quantum computers. What works on a 10-qubit backend may not work as well on a 100-qubit backend. These complexities make quantum computing inaccessible to many non-expert users.

[0009] Even in the VQA framework, the complexity of algorithm creation increases exponentially with the size of the problem, due to the large degree of freedom in the choice of components. Significant challenges exist in areas such as input definition (e.g., instances of the VQA problem statement must be formulated binomially, but there is no standardized way to do it), output standardization (the lack of standardized optimization problems and cross-backend standardized outputs amplifies the problem of generating and storing quantum computations in a long-term and reliable way), and composability and circuit definition (VQA is heuristic, so there is little guidance on the optimal choice of VQA components).

[0010] There are also challenges with VQA's simplicity (binary inputs can be extensive and cumbersome to treat as data), scalability (the number of possible modifications and variations is generally vast, and large quantum circuits may require selecting the optimal element from a large number of possible building blocks), extensibility (extensions to established VQAs, such as the recursive "Quantum Approximated Optimization Algorithm" (QAOA), typically outperform the basic one, but are complex to implement programmatically), and customizability (users may have their own components they would like to use in VQA, but currently it is difficult to add custom components to quantum workflows built with existing software libraries).

[0011] Finally, there are the financial costs of quantum computing and the issues and challenges of VQA integration. In terms of cost, running computations on quantum hardware is expensive and time-consuming. Budgeting is a real issue, and the lack of an automated way to estimate the financial costs of quantum computing exacerbates this problem. In terms of integration, the classical-quantum loop scales differently depending on the size of the quantum processing unit (QPU) and its underlying technology. A typical VQA run requires information to be exchanged between a quantum computer and a classical computer. Without optimizing the interaction of the two computational units, a VQA run can suffer from network issues (e.g., lost connectivity) and latency delays.

[0012] In the pursuit of quantum advantage, better ways to create accessible and scalable VQA workflows are needed. Therefore, methods, systems, and kits for quantum-optimized cross-backend software development need to be provided. In addition, high-level software libraries and toolboxes for building, optimizing, and testing quantum algorithms such as VQA and fault-tolerant quantum algorithms (FTQA) on NISQ devices are also essential. Additionally, other desirable features will become apparent from the following detailed description and the appended claims, taken in conjunction with the accompanying drawings and the background of this disclosure. Summary of the Invention

[0013] According to at least one aspect of the present embodiment, a method is provided for building a quantum optimization algorithm executable on quantum hardware. The method includes receiving an input including a user-defined problem and at least one predefined variational quantum algorithm (VQA) statement, and translating the received input into a workflow. The method also includes obtaining an abstract variational quantum algorithm (VQA) representation based on the workflow, creating a backend-specific quantum circuit based on the abstract VQA representation, and returning an output, the output including the optimization results and additional metadata.

[0014] According to another aspect of the present embodiment, a system for constructing a quantum optimization algorithm is provided. The system includes an input module and a workflow module. The input module receives an input model, the input model including a standardized version of a user-defined problem and at least one predefined variational quantum algorithm (VQA) statement. The workflow module is configured to take the input model as an input, convert the input model into a sequence of operations that define a workflow, obtain an abstract variational quantum algorithm (VQA) representation based on the workflow, and set up and execute a classical-quantum loop. The classical-quantum loop is configured to create and execute an explicit representation of a quantum circuit based on the abstract VQA representation, optimize parameterized variables of such circuit, break the loop when a satisfying learning condition is met, and return an output consisting of optimization results and metadata.

[0015] According to another aspect of the present embodiment, a set of tools designed to improve ease of use and performance in building quantum optimization algorithms is provided. The tools include a cost management tool for estimating costs associated with a given quantum computation (costs include financial costs, execution time, and other metrics associated with performing a given quantum computation), and an automated VQA, which is a system that receives a user-defined problem associated with a given quantum computation and evaluates optimal choices of parameters of a variational quantum algorithm statement for the user-defined problem. The tools also include a qubit routing tool for compiling the variational quantum algorithm expression with a back-end explicitly optimized quantum circuit. [Brief description of the drawings]

[0016] The accompanying drawings, in which like reference numerals refer to identical or functionally similar elements throughout the different views, and which, together with the following detailed description, are incorporated in and constitute a part of this specification, serve to illustrate various embodiments and to explain various principles and advantages in accordance with the present embodiments.

[0017] [Figure 1] FIG. 1 is a schematic diagram showing the functional elements and application programming interface (API) structure of a quantum approximate optimization algorithm (QAOA) workflow construction and execution system (hereinafter referred to as "OpenQAOA") according to this embodiment.

[0018] [Diagram 2] FIG. 2 is an explanatory diagram showing the anatomical structure of a workflow result of a result object of the OpenQAOA Core according to the present embodiment.

[0019] [Diagram 3] FIG. 3 is a block diagram illustrating the operation of the OpenQAOA resource estimation and profiling module enabler according to the present embodiment.

[0020] [Figure 4] FIG. 4 is a block diagram showing the operation of the benchmark module enabler of OpenQAOA according to this embodiment.

[0021] [Diagram 5] FIG. 5 is an exemplary representation of a general OpenQAOA workflow according to the present embodiment.

[0022] [Figure 6A] FIG. 6A shows a more detailed presentation of the general OpenQAOA workflow according to the present embodiment.

[0023] [Figure 6B] FIG. 6B shows a more detailed presentation of the general OpenQAOA workflow according to the present embodiment.

[0024] [Figure 6C] FIG. 6C shows a more detailed presentation of the general OpenQAOA workflow according to the present embodiment.

[0025] [Figure 6D] FIG. 6D shows a more detailed presentation of the general OpenQAOA workflow according to the present embodiment.

[0026] Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn with complete detail. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0027] The following detailed description is merely exemplary in nature and is not intended to limit the invention or the application and uses of the invention. Furthermore, there is no intention to be bound by any theory presented in the preceding Background of the Invention or the following Detailed Description. It is the intent of the present embodiment to provide a method, system, and kit for building and running quantum approximate optimization algorithm (QAOA) workflows, independent of implementation in any language. Thus, in accordance with the present embodiment, a cross-backend software development kit (SDK) for quantum optimization, called OpenQAOA, is proposed. The SDK is a modular library for building custom quantum algorithms for optimization applications. The SDK facilitates building and deploying variational quantum algorithm (VQA) workflows on multiple quantum computing systems or simulators by providing an application programming interface (API) for building and running quantum algorithms on multiple backends. The SDK creates algorithms that are ideally executable on any qubit-based universal quantum computing architecture. As such, users do not need extensive knowledge of quantum computing architectures or quantum algorithms.

[0028] VQA exploits the toolbox of classical optimization, a mathematical problem of choosing values ​​for a set of variables to minimize an objective function. VQA involves parametric quantum circuits, i.e. quantum circuits that depend on classical parameters, running on a NISQ computer while delegating the optimization of the parameters to a classical optimizer. The general framework of VQA includes three basic elements: the input to the VQA, the classical-quantum loop, and the output of the VQA. The input to the VQA is the problem statement, a quantum Ansatz (a variational quantum circuit that depends on the parameter θ), a parameterized cost function that measures the quality of the solution, or a set of additional training data that the optimization routine can use. The quantum circuit must also be compiled to run on the target quantum computer. The classical-quantum loop (CQL) is an estimation routine that calculates the cost function by measurements on the quantum computer (or on a simulator) and, more specifically, can include an optimization routine that updates the parameter θ to minimize the value of the cost function. The output of VQA can be, in the optimal case, a set of parameters that minimizes a cost function, a mapping from the minimized cost function to a solution of the problem, or all the metadata describing the classical-quantum loop.

[0029] There is growing interest in using VQA to solve classical problems in applied mathematics. Consider combinatorial optimization problems: they are ubiquitous in industry, but suffer from poor scaling with system size. Such problems are essentially "search problems," and thus may benefit from quadratic speedups of the Grover algorithm in the fault-tolerant domain. At the same time, circumstantial evidence suggests that applying VQA, such as quantum approximate optimization algorithms (QAOA), to classical optimization problems may provide a quantum advantage on NISQ devices.

[0030] OpenQAOA is a scalable and efficient optimization-specific SDK that offers capabilities not available in current solutions. It is cross-platform and provides numerous parameterization and parameter initialization strategies, the ability to prepend initial states to computations or add states after VQA has completed, automatic and manual circuit construction (utilizing built-in workflows and workflow factories), a built-in circuit compilation module, VQA heuristics, resource estimation and profiling, a benchmarking module, an error mitigation module, a noise simulator, automatic VQA construction with automatic VQA, and a set of GUIs enabling visualization of circuits and results. Furthermore, OpenQAOA's functional (modular) design allows users to swap out components while only preserving I / O relationships. In effect, OpenQAOA provides an API for building quantum optimization workflows.

[0031] Compared to existing solutions for building and running QAOA computations, the two main advantages that OpenQAOA offers are scalability (referring to the ability to run large-scale QAOA computations while minimizing the resource footprint across all aspects of the workflow) and efficiency (referring to the fact that OpenQAOA's workflow and feature set maximally support users' productivity, thereby enabling them to conveniently and quickly achieve their goals). In the context of QAOA, there is a close relationship between scalability and efficiency, but they are also independent of each other. For example, even for small-scale QAOA experiments (where scale is not an issue), having predefined problem classes, meaningful and easily manageable formatted results, a predefined set of good algorithm settings, a collection of curated benchmark computations, and a "press play" type of option can significantly increase productivity.

[0032] Predefined problem classes allow users to easily specify optimization problems without the burden of knowing or providing a QUBO formulation. Results are returned in a manageable format that is meaningful to the user: the data is easily labeled so that the user can understand what it is, and the data is efficiently formatted and labeled so that it does not grow excessively in size.

[0033] A set of predefined and effective algorithm settings helps users get effective results quickly with minimal effort. For example, the default algorithm settings are those that are known to work well. Moreover, OpenQAOA provides a fast and diverse way to simulate QAOA classically under different conditions. Diversity here means that both noise-free and noisy computations can be simulated with a simple input syntax to specify the desired conditions. Also, collecting benchmark computations facilitates comparison with alternative algorithmic approaches and, when run on a real quantum computer, can infer useful information about the noise characteristics of the device. Finally, a "press play" type option allows building and easily launching multiple QAOA computations, including comparisons of different algorithmic settings.

[0034] For larger-scale QAOA computations on real quantum computers, the basic features and building blocks, such as circuit construction methods and result objects, must all remain efficient, but more complex elements, such as circuit compilation and error mitigation, are essential for top performance in large-scale QAOA.

[0035] Of course, to run even a small QAOA circuit on an actual quantum processing unit (QPU), we need to go through the steps of compiling the circuit (selecting qubits, mapping qubits, and routing qubits). At small scales, the choice of qubit routing schedule has little impact on the quality of the final computation, but at large scales this is no longer the case. For example, as the scale increases, not just any qubit routing schedule will do, and finding a good qubit routing schedule becomes important.

[0036] definition

[0037] In order to better understand the embodiments disclosed herein, several terms need to be defined.

[0038] A "qubit" is a two-level quantum system that represents the basic unit of quantum information.

[0039] A "gate-based quantum computer" is a quantum computing device that transforms input data according to a sequence of qubit initializations, unitary operations specified as sequences of gate operations, and qubit measurements.

[0040] We define a "quantum circuit" as a sequence of operations that includes qubit initialization, gate operations, and qubit measurements. A quantum circuit is a universal model that represents a quantum computation as a sequence of qubit initialization, quantum gates, and qubit measurements. A "quantum gate" is a logical operation that acts on any number of qubits. A "quantum algorithm" is a sequence of instructions that includes classical processing and quantum circuits. A workflow corresponds to a sequence of actual operations that perform the abstract steps of an algorithm.

[0041] A "noisy intermediate quantum (NISQ) computer" is a device that can support tens to thousands of noisy qubits. Noisy means that the qubits are susceptible to errors caused by interactions with the environment. "NISQ algorithms (NISQAs)" are heuristic techniques that offload parts of the computation to classical computers while still using NISQ devices. Companies use NISQ algorithms to conduct applied research and identify use cases that would benefit from quantum computing. Current state-of-the-art NISQ devices have already demonstrated "quantum supremacy," i.e., quantum computers outperform the best classical supercomputers for certain mathematical challenges.

[0042] Fault-tolerant quantum algorithms (FTQAs) require large-scale quantum computers that support active error correction for noise suppression. Theoretical analysis shows that FTQAs can achieve polynomial, and even exponential, speedups over classical computers for some practical problems.

[0043] A "Software Development Kit (SDK)" is a collection of software development tools organized into an installable package. The role of an SDK is to enable users to create software applications.

[0044] An SDK can take the form of an "Application Programming Interface (API)". An API is an interface of a piece of software that provides a service to another piece of software. APIs allow communication between applications. The document or standard that describes how to build and use such an interface is called an API specification. An API can consist of parts that act as tools or services available to programmers. A program or programmer who wants to use one of these parts calls that API part. The calls that make up an API are also called "subroutines", "methods", "requests" or "endpoints".

[0045] "Open Quantum Assembly Language (OpenQASM)" is an imperative programming language for describing quantum circuits, designed to serve as an "intermediate representation (IR)" for quantum instructions. Intermediate representations are data structures and code that compilers and virtual machines use internally to represent source code. The IR is designed to lend itself to further processing, such as optimization and translation. OpenQASM can describe universal quantum computing.

[0046] Quil is a quantum "instruction set architecture (ISA)" provided by Quantum Computing, Inc., Berkeley, California, USA. A quantum ISA is an abstract model of a quantum computer, specifying what instructions are physically allowed on the actual hardware.

[0047] In the following description of the preferred embodiment, a "backend" refers to a device capable of executing quantum algorithms. The backend can be a QPU (cloud access) accessible via the Internet from a hardware provider, a simulator accessible via the Internet, or it can reside on a local machine.

[0048] A "quantum hardware provider" is an entity (usually, but not limited to, a commercial entity) that builds and / or services QPUs over the Internet. All available QPUs are accessible through an external API. Examples of such providers include IBM (offering services through IBM Q), Rigetti (offering services through Quantum Cloud Services (QCS)), Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft's Azure (MA)), and IONQ (offering services through AWS, MA, and GCP). The term "quantum cloud" is used to describe the general ensemble of such quantum cloud services.

[0049] "Qiskit" is a Python open source SDK for working with OpenQASM and IBM Q quantum processors.

[0050] "PyQuil" is a Python library for quantum programming using the quantum instruction language Quil, developed by Rigetti Computing.

[0051] The "Braket" Python SDK is an open source library that provides a framework for interacting with quantum computing hardware devices through AWS.

[0052] raising a problem

[0053] The current goal of quantum computing research in academia, industry, and the developer community is to use quantum computers to solve optimization problems, but this task faces several challenges. First, building quantum algorithms is generally difficult because it requires deep knowledge of the underlying algorithms and a general understanding of quantum computing at the hardware and logic level. Different scales likely require different knowledge, so what works well on a 10-qubit backend, for example, may not work as well on a 100-qubit backend. This complexity makes quantum computers inaccessible to many non-expert users. Note that this complexity refers to both NISQA and FTQA.

[0054] As for VQA, we can express it as a finite sequence of actions and components. The input to the VQA includes a mathematical representation of the problem instance to be solved and a formal definition of meta-parameters that define the VQA. These meta-parameters consist of the number of qubits, the choice of parameterized circuits (i.e., Ansatz and their corresponding quantum gates), the characteristics of the backend, and the definition of the classical-quantum loop. To run the same VQA across different backends, we need to adopt a unified and abstract representation that can be understood and executed by any general-purpose quantum computing system.

[0055] Moreover, not a small part of these implementations may depend on the quantum backend. Moving across different backends (e.g., some backends may prioritize certain quantum gates or only support a subset of native quantum gates) may require significant changes to the overall logic of the circuit construction, as well as changing the underlying quantum instruction language (e.g., IBM uses OpenQASM, while Rigetti uses Quil). Moreover, specific hardware-dependent compilation steps (e.g., qubit selection, mapping, routing) are required before the circuit can be executed on a quantum computer. As a result, end users may have to rewrite large parts of their code multiple times, a process that is time-consuming and prone to coding bugs and errors.

[0056] Therefore, the first problem is that even within the framework of VQA, the complexity of creating algorithms rises with the size of the problem due to the wide degree of freedom in the choice of components, highlighting the following significant issues. First, there is the problem of input definition. In general, instances of problem statements that VQA can solve must be cast in a binomial formulation, and there is no standard way to do this. Second, there is a lack of simplicity in that binary inputs can be huge and cumbersome to treat as data. Furthermore, there is no standardization of outputs. The lack of standardization of optimization problems and cross-backend standardized outputs amplifies the problem of generating and archiving quantum computations in a long-term and reliable way.

[0057] Problems are also presented in terms of composability and circuit definition. Because VQA is heuristic, there is little guidance on the optimal choice of its components. Moreover, these choices can have a significant impact on the algorithm's performance. Therefore, a unified code base is needed where users can put all the pieces of VQA together. This problem leads to issues of scalability and extensibility. As quantum circuits grow in scale, selecting the optimal elements from the large number of possible components can become difficult, since the number of possible modifications and variations is huge. Similarly, extensions of established VQAs (such as recursive QAOA) generally outperform intrinsic ones and are more complex to implement programmatically, so choosing the right elements is key to success.

[0058] Even though we have our own components that we would like to use in VQA, adding custom components to a quantum workflow built with existing software libraries is difficult. In addition, computations using quantum hardware are expensive and time-consuming, which makes them a financial burden. There is no automated way to estimate the monetary cost of performing quantum computations, so budgeting is a real problem. Finally, the classical-quantum loop scales differently depending on the size of the QPU and its underlying technology. A typical VQA run requires information to be exchanged between a quantum computer and a classical computer. Therefore, without optimizing the interaction of the two computational units, a VQA run may suffer from network issues (e.g., loss of connectivity) and latency delays that lead to integration problems.

[0059] Therefore, the pursuit of quantum advantage requires good methods for building accessible and scalable VQA workflows. Therefore, high-level software libraries and toolboxes for building, optimizing, and testing VQA on NISQ devices are essential. However, these issues are not specific to VQA and apply to algorithms like FTQA as well.

[0060] solution

[0061] According to the present embodiment, a cross-backend software development kit (SDK) for quantum optimization is proposed. The exemplary SDK according to the present embodiment is a modular library for building custom quantum algorithms for optimization problems. The SDK provides composability, simplicity, efficiency, and scalability, and addresses all the problems and challenges discussed herein above.

[0062] The SDK according to the present embodiment assists the user in input description while providing cross-backend standardized output for optimization problems. Furthermore, the SDK according to the present embodiment includes an API with built-in workflows and workflow factories designed to assist novice and experienced users in constructing complex quantum algorithms for optimization. Furthermore, the SDK according to the present embodiment allows users to enhance the core algorithmic capabilities of the SDK with an extensive set of enablers aimed at providing efficiency and scalability, including a problem class module to facilitate input creation, a benchmark module to evaluate algorithm and device performance, a circuit compilation module to minimize resources required to execute QAOA circuits, a resource estimation and profiling module to help users evaluate the resources required to achieve their objectives, an error mitigation module to suppress noise on the device and improve the quality of the solution, and an auto-VQA module to design a generic VQA. Furthermore, the SDK according to the present embodiment allows users to visualize data related to the construction, execution, and results of the quantum computation of interest through its graphical API. Finally, the SDK according to the present embodiment is backend agnostic and can be integrated with multiple existing quantum computing systems. In simple terms, the SDK of the present embodiment exposes a set of APIs to end users to create and run quantum algorithms on multiple backends to solve optimization problems.

[0063] The SDK according to the present embodiment allows users to compose quantum optimization algorithms / workflows. The word "compose" has a precise meaning. A quantum algorithm (e.g. QAOA) is a set of instructions for a specific set of classical and quantum components. These components can be thought of as processes decoupled from their concrete technical implementation and viewed in the context of their functional properties as abstract entities. For example, consider the classical optimizer used in VQA's CQL (Classical-Quantum Loop). Its abstract representation is a function that takes as input a parameterized cost function and a set of parameters, and outputs a new set of parameters aimed at reducing the cost function. This abstraction makes it irrelevant whether you use a local optimizer like Cobyla or a neural network trained on your own data.

[0064] In this sense, composability defines the ability of the SDK according to the present embodiment to provide a procedural and straightforward way to construct complex quantum optimization workflows, starting from abstract definitions of classical and quantum components. From a programming perspective, these complex workflows can be viewed as APIs. An important aspect of this design choice is the ability of end users to add or replace components as long as they meet the functional characteristics specified by the SDK.

[0065] The SDK according to the present embodiment abstracts the complexity of quantum optimization algorithms by providing users with two strategies: (a) a set of built-in workflows and a workflow factory (hereinafter, "Factory") for assembling workflows from scratch. In the Factory, users can access the source code to compose new workflows. This framework allows inexperienced users utilizing the SDK according to the present embodiment to execute QAOA algorithms through the SDK via built-in workflows by simply providing a mathematical description of the problem to be solved. The mathematical description, of course, needs to be cast into a binary form, and the SDK according to the present embodiment simplifies this task by providing a tool to cast the problem into a binary problem suitable for a quantum computer. Once the mathematical statement is ready, the SDK can automatically execute the built-in QAOA workflow according to the present embodiment using default settings, thereby removing the burden of prior knowledge of quantum algorithms or quantum backend physics. Users can also opt out of the default settings and modify the built-in workflows specified in the API documentation. For example, the classical optimizer of a classical-quantum loop can be changed by simply updating the workflow's method variables.

[0066] The built-in workflow of the SDK according to the present embodiment also includes extensions to the basic VQA. Users can directly call built-in entry points that identify these extensions. Furthermore, all built-in algorithms are fully customizable, allowing end users to replace and extend components as they wish.

[0067] In summary, the SDK according to the present embodiment advantageously addresses the existing problems of modularity and customizability, scalability and simplicity. With regard to modularity and customizability, each part of the quantum algorithm can be replaced, modified and customized according to the present embodiment. If the user has a custom optimizer, the user can add it to the algorithm in the factory. With regard to scalability, the same structure can be used with circuits consisting of thousands of qubits, and the tools provided by the SDK, such as circuit compilation and error mitigation, are aimed at addressing the performance issues associated with noise diffusion in large-scale QAOA calculations. With regard to simplicity, the SDK according to the present embodiment advantageously enables users without extensive experience in quantum computing to build and create quantum optimization algorithms that run on quantum computing systems of diverse architectures.

[0068] Moreover, the SDK according to the present embodiment is back-end agnostic, as described herein above: it is designed to assist end users in creating and running modular optimization algorithms on quantum hardware and classical simulators, allowing accurate computations to be performed on different quantum computers by changing only a few lines of code.

[0069] Turning to the method, system and kit for building and executing QAOA workflows according to the present embodiment (i.e., OpenQAOA), the basic purpose of OpenQAOA is that it is designed to enhance QAOA research and the execution of QAOA computations. The main advantages of OpenQAOA according to the present embodiment over current methods, systems and kits are efficiency, scalability, reproducibility and consistency, correctness and error reduction, algorithm flexibility, resource management and estimation, and visualization. The main features of OpenQAOA according to the present embodiment are automatic conversion of input statements into binary format, an API that allows the creation of quantum optimization workflows, built-in implementations of various VQAs including QAOA, R-QAOA, and G-QAOA; circuit ansatz, parameter initialization, and extension options for classical optimizers, creation of arbitrary VQAs through workflow factories, ability to add and prepend quantum states, support for multiple backends, and a set of standalone tools such as the OpenQAOA enabler 150 and the OpenQAOA GUI 185. Extensive options for circuit ansatz, parameter initialization, and classical optimizers include multiple circuit ansatz, extended, standard, and annealing parameterization strategies, original and Fourier-type, linear, random, and custom initialization strategies, and classical optimizers including the SciPy suite, Scikit-quant, custom gradient methods, and machine learning methods.Multiple backend support includes support for QPUs such as IBM Q, Rigetti, and IONQ, as well as simulators such as Vectorized (from Entropica Labs, Singapore) and Qiskit (from IBM, Armonk, NY, USA).

[0070] With reference to FIG. 1, reference number 100 denotes the functional elements and application programming interface (API) structure of OpenQAOA, a system for building and executing QAOA workflows according to the present embodiment. The main components of OpenQAOA belong to one of four categories: OpenQAOA Core 110, OpenQAOA Enabler 150, OpenQAOA Backend 170, and OpenQAOA Graphical User Interface (GUI) 185. The OpenQAOA Core 110 contains the basic elements required to manage user input, build circuits, dispatch them to the backend for execution, and return results. The OpenQAOA Enabler 150 contains additional modules to enhance multiple aspects of the workflow tasks of the QAOA practitioner and improve the performance of the algorithms executed. The OpenQAOA Backend 170 is a set of devices (actual quantum computers or simulators) on which the computations are executed. And the OpenQAOA GUI 185 is a visualization tool. Visualization is a powerful and valuable element in analyzing any algorithm and its performance aspects, and QAOA is no exception. The OpenQAOA GUI 185 allows the visualization of data generated at all stages of the OpenQAOA workflow.

[0071] The Open QAOA Core 110 includes functions such as input and workflow 115, core algorithm elements 120, dynamic circuit functions 125, predefined configurations 130, and result objects 135. The OpenQAOA Core 110 is connected to the OpenQAOA Enabler 150 through the Enabler API 140. The abstract nature of the OpenQAOA Enabler 150 allows the interface between the OpenQAOA Core 110 and various Plugins 160.

[0072] The OpenQAOA enabler 150 includes a problem class module 152 , a circuit compilation module 153 , an error mitigation module 154 , a resource estimation and profiling module 155 , an automatic VQA 156 , and a benchmarking module 158 .

[0073] The plugin 160 relies on a provider and is responsible for providing a provider compile 165 and providing the quantum circuit for execution on one or more of the providers in the OpenQAOA backend 170. The provider compile accesses a provider 173 via a provider API 172, which may be one or more of the following: vectorization core 174, IBM Q 176, AWS Braket 178, Microsoft Azure 180, and Rigetti quantum cloud services.

[0074] The OpenQAOA GUI 185 is connected to the OpenQAOA Core 110 via a graphical API 184 and includes a standard plotting module 186 , a circuit compilation visualizer 188 , a schematic visualizer 190 , and a save & load function 192 .

[0075] Given the importance of effective circuit compilation for running QAOA on a QPU, OpenQAOA has been explicitly designed with qubit selection, qubit mapping, and qubit routing in mind. OpenQAOA provides an interface through which dedicated compilation modules can be invoked, sending these compilation modules information about the optimization problem and the QPU to be used. OpenQAOA receives a specification of which physical qubits on the device to use ('qubit selection') and an initial mapping of logical qubits (those in the abstract description of the circuit to be implemented) to the selected physical qubits ('qubit mapping'). A schedule for inserting additional operations, including but not limited to SWAP gates that compensate for limited device connectivity, is also received to allow the desired computation to be performed ('qubit routing'). OpenQAOA uses these solutions to build circuits and place them on the specified QPU as part of the QAOA workflow.

[0076] All the aforementioned steps are clearly dependent on the device that performs the computation. However, having to rewrite these steps from scratch for each quantum processing unit would hardly allow for scalability and efficiency, as it would lead to code inefficiencies and maintainability issues. OpenQAOA overcomes this limitation by operating all these passes at the level of the OpenQAOA abstract circuit. The abstract circuit is an OpenQAOA representation of the entire algorithm, which is completely independent of the actual device used for the computation. This does not mean that the particularities of a given device are discarded, but on the contrary, it means that all devices are treated equally and therefore the compilation passes can be performed in a device-agnostic manner.

[0077] OpenQAOA has methods for simulating noiseless and noisy QAOA circuits, where a state vector or wavefunction simulator mimics the behavior of a noiseless quantum computer and returns the full output wavefunction. Such simulators include OpenQAOA's own vectorized simulator, as well as simulators provided by other open source quantum computing libraries.

[0078] A special simulator for calculating certain properties of the output of QAOA circuits, based on explicit formulas obtained from analytical analysis. As an example, in single-layer QAOA it is possible to obtain explicit formulas for important quantities such as expectation and correlation functions. Typically, this allows studying problems of larger size than is the case for classical state vector calculations. Such simulators are called "single-layer simulators" (SLS).

[0079] Several simulators are provided for noisy QAOA circuits. Full quantum master equation (ME) simulators solve the time evolution of the density matrix of the qubits used in the calculation in the presence of a specifiable noise process. Quantum Monte Carlo wave function (MCWF) simulators stochastically simulate individual "trajectories" of the system. MCWF simulators can obtain an approximation of the density matrix by averaging multiple trajectories, resulting in a significantly smaller memory footprint than ME simulators. Furthermore, individual trajectories can be used to study the effect of defects in a single experimental shot (such information would be washed out in the ME approach). Deterministic error wave function (DEWF) simulators allow specific errors to be placed at predefined locations in the circuit. DEWF differs from MCWF simulators in that MCWF errors occur stochastically in space (i.e., on which qubits) and in time (i.e., at which instant in the circuit). Effective error (EE) simulators calculate the effective error at the circuit output when a user-specified type of error occurs at any location in the QAOA circuit.

[0080] To simulate a quantum circuit composed of discrete operations as an equivalent time evolution problem, like ME and MCWF simulators, one must carefully specify the correspondence between the underlying gate set (discrete operations theoretically realizable on a quantum computer) and the Hamiltonian that generates the time evolution. Noise processes supported include, but are not limited to, a) state preparation and measurement (SPAM) noise, b) dephasing, c) depolarization, d) amplitude decay, and e) crosstalk errors such as the ZZ interaction that persists in some superconducting qubits.

[0081] The noise simulation module according to the present embodiment is a bridge between the world of noiseless simulation and the world of actual QPU computation, and can advantageously be used with the same underlying syntax of OpenQAOA (with or without additional input from the user to specify desired noise characteristics).

[0082] In accordance with this embodiment, a "press play" function is provided that is derived from the basic OpenQAOA workflow. For a given input problem, the "press play" function provides the user with a simplified syntax for specifying multiple conditions under which QAOA (or its variants, such as R-QAOA) should be run. Such conditions can include algorithm settings, such as the number of QAOA layers, classical optimizer, and parameterization, as well as device settings, such as where to run the computation (e.g., noisy simulator, wavefunction simulator, QPU, etc.). For example, the following Python pseudocode shows how to invoke the "press play" function for the traveling salesperson problem:

[0083]

number

[0084] "Dynamic circuit functionality" refers to the ability to use mid-circuit measurements and feed-forward logic in a QAOA circuit, which is advantageously provided in OpenQAOA according to the present embodiment. "Dynamic circuit functionality" means that a quantum circuit can be modified on the fly during its execution, depending on the results of measurements made on the quantum circuit. Such "dynamic circuit functionality" can be particularly useful in QAOA workflows in the following exemplary setups: a) reduction in the number of qubits required to execute a problem, b) mixer operators that ensure that the exploration of the solution space is limited to a desired subspace, such as feasible solutions or solutions with certain properties or characteristics, and c) error detection that allows experiments in which errors are known to have occurred to be discarded from the results. The main advantage brought by the availability of "dynamic circuit functionality" in OpenQAOA is algorithmic flexibility. OpenQAOA users have the advantage of having more tools at their disposal when working on problems in QAOA, and, moreover, it is simple, efficient and reliable to use.

[0085] The Enabler Interface (EI) is responsible for the communication between the OpenQAOA Core 110 and the OpenQAOA Enabler 150: a) Prepares the necessary information and sends it to the modules in the OpenQAOA Enabler 150; b) Receives information from the OpenQAOA Enabler 150 and sends it to the components of the OpenQAOA Core 110. The EI consists of several interfaces, each responsible for communication with a module or component of the OpenQAOA Enabler 150, such as the circuit compilation interface for communicating with the circuit compilation module 153, the error mitigation interface for communicating with the error mitigation module 154, etc.

[0086] Below, we will describe the circuit compilation interface as an example of EI. The OpenQAOA core 110 is designed to work in conjunction with a module that performs circuit compilation (i.e., the circuit compilation module 153). Given standard OpenQAOA input data (data specifying the problem instance, and any algorithm settings) and the name of the target quantum computer (i.e., a specific device such as the Rigetti Aspen-M3), the OpenQAOA core 110 passes the relevant information to the circuit compilation module (CCM) 153. The CCM performs tasks including qubit selection, qubit mapping, qubit routing, and any necessary post-processing of the results of these steps. This results in a circuit that includes the required additional operations (e.g., SWAP operations in the case of a superconducting quantum computer) and allows the circuit to be executed on the target device.

[0087] Circuit compilation may result in changes to the original qubit labels. For example, qubit routing may change logical indices in the circuit description even if the qubits remain physically unmoved. This means that QAOA circuits must be carefully constructed to ensure that variational parameters are passed to the correct gate operations as intended, and that measurements are performed on the correct set of qubits. In accordance with the present embodiment, OpenQAOA can manage all of these details automatically, removing a significant burden from the user.

[0088] The set of methods and functions in the OpenQAOA Core 110 dealing with circuit compilation, called the Circuit Compilation Interface (CCI), is responsible for a) preparing and dispatching all necessary information about the problem and the target device to the CCM 153, and b) retrieving the solution from the CCM 153 and managing the details of measurements, parameter-to-gate assignments, and similar necessary tasks during the execution of the QAOA computation. The CCI provides workflow efficiency benefits because it requires the user to perform a significant amount of otherwise tedious and error-prone work. Furthermore, in conjunction with the CCM 153, the CCI can address one of the main scalability problems of QAOA, namely, the problem of effectively running arbitrary QAOA computations on devices with limited qubit connectivity.

[0089] Algorithms in the QAOA family have a wide range of associated algorithm settings (hyperparameters) that the user must provide to fully specify the computation to be performed. For example, the number of QAOA layers, the initial values ​​of the variational parameters, the parametrization (i.e., the relationships that must hold between the variational parameters in the circuit), and the classical optimizer to use (which itself can have its own hyperparameters to choose from). Users face a significant challenge when they need to narrow down to a specific choice for all of these algorithm settings, since it is far from obvious which hyperparameter settings will be most effective. This problem is exacerbated by the diversity of problems one wishes to solve and the fact that combinations of hyperparameters may interact in nontrivial ways.

[0090] There are two approaches to address this difficulty. The first approach is to exploit knowledge and experience accumulated through past experiments. For example, ramp initialization of QAOA variational parameters, where the initial values ​​of the parameters are set similarly to a quantum annealing schedule characterized by a linear function. This approach has been shown empirically to be superior on average to approaches that give random initial values ​​to the QAOA parameters. The second approach is to exploit analytically provable features of QAOA. An example of this is the phenomenon of parameter "clustering", where it can be shown that optimal parameters for problem instances in a particular class cluster around certain values. After solving one problem in the class, the obtained optimal parameters can be used as a good initialization for another problem instance drawn from the same class.

[0091] In accordance with the present embodiment, OpenQAOA's predefined settings 130 are a collection of specifiable defaults and choices for many of the hyperparameters of the QAOA workflow, drawing from the two approaches discussed above. The predefined settings 130 improve the efficiency of the workflow by removing the time-consuming burden of selecting hyperparameters and providing settings that have been verified in some way to provide higher quality solutions than settings that would otherwise be chosen randomly.

[0092] Referring to FIG. 2, a diagram 200 is shown illustrating the anatomy of a workflow result of a result object 135 of the OpenQAOA Core 110 according to the present embodiment.

[0093] The results of an OpenQAOA computation are stored in a suitable format (e.g., JSON) according to the present embodiment and are characterized by two first level keys, shown in diagram 200 as "Header" 210 and "Data" 250. "Header" 210 contains data useful for indexing records, for example in an SQL database. "Data" 250 contains arbitrary (not necessarily structured) data, which can be considered as a data dump from the execution of the algorithm. Importantly, the data in "Header" 210 is the link to store the computation data with its context. Finally, note that the metadata component 215 of "Header" 210 can contain key-value pairs extracted from elements of "Data" 250 if the end user wishes.

[0094] Given the size of currently available quantum computers and the price of their use, the number of quantum computers performing QAOA calculations is typically around 100 at most. The number of shots for each circuit is typically on the order of a few thousand (less than 10,000), and the number of optimizer iterations is typically around 100 at most. If we assume that the quantum computing provider 173 (Figure 1) returns a list of results from each shot as an array of 0s and 1s (one value for each qubit measured), with the above numbers, the size of the received data is not particularly inconvenient. For example, consider the following scenario (scenario 1): 1000 shots per circuit, 100 optimizer iterations, 2 function evaluations per iteration (e.g. using simultaneous perturbation stochastic approximation (SPSA) as optimizer), 100 qubits. Overall, this results in about 20 million 1s and 0s of data output, which is manageable in terms of data footprint, amounting to megabytes at most.

[0095] In the future, when quantum computers with thousands of qubits emerge and the cost of quantum computers drops, it is quite possible that we will be able to comfortably run thousands of iterations of the optimizer and thousands of shots of QAOA calculations per circuit. Consider the following example scenario (Scenario 2): 100000 shots per circuit, 1000 iterations of the optimizer, 2 function evaluations per iteration using SPSA, and 1000 qubits. The data footprint of Scenario 2 will be four orders of magnitude larger than that of Scenario 1. In other words, the user will receive raw data of 200 billion 1s and 0s (in some format). This could amount to gigabytes of storage, which can be inconvenient to work with and expensive to store. One could argue that the above argument may be exaggerated, since practitioners do not routinely store all the results they take. On the other hand, there may be plausible practicality in storing such data for purposes such as software and hardware debugging, research, and analysis with machine learning algorithms. The raw data may turn out to be useful in ways not currently understood or envisioned.

[0096] OpenQAOA addresses this problem by allowing users to serialize results into conceptually independent chunks that can be indexed, compressed, and archived separately. Users are free to define the atomic result of a given experiment. An atomic result represents the smallest, contextual block of data into which the user wishes to serialize the experiment / computation. Importantly, an atomic result must have one property: it must contain all the metadata necessary to interpret the rest of the stored data. This means that at any point in the future, the user can load any serialized chunk of data and recreate the original result. The actual size of the atomic result is thus arbitrary. For example, one way to achieve the desired result is to split the result object into two key-value pairs: a header key (e.g., header 210) contains the indexable, searchable portion of the stored data, and a data key (e.g., data 250) contains the raw data corresponding to the atomic result.

[0097] The raw data 250 can be compressed and then archived to minimize the data footprint by using conventional compression algorithms, while the headers 210 can be populated, for example, into a standard relational database to allow quick and efficient searching of the resulting stored and compressed data portions.

[0098] The OpenQAOA result object (RO) 135 (illustrated in FIG. 200) contains data on the results of the computation, metadata on the algorithm settings and backends used, as well as any context information provided by the user. There are several particularly noteworthy objectives of the RO 135 and the advantages they bring. The first objective of the RO 135 is to achieve optimal data compression, such as minimizing the memory footprint, while still allowing full reconstruction of all the information required for the experiment. The data reduction and compression method of the RO is particularly important for users who perform a large number of computations and / or who perform computations using a large number of qubits. In such situations, a large amount of raw data is generated, which can lead to poor workability and high storage costs. The RO 135 thus contributes to the advantageous scalability offered by OpenQAOA when addressing large workflows according to the present embodiment.

[0099] A second purpose of RO135 is to provide a log of the optimization history, allowing the performance of the algorithm to be tracked through iterations, allowing users to easily access information that is useful during the research and prototyping phase, and contributing to a more efficient workflow in accordance with the present embodiment.

[0100] The third objective of RO135 is to provide an unambiguous map (e.g., as a dictionary) between the binary variables defined in the problem statement and the results of the QAOA computation. This can be optionally extended to named variable groups in problems built into OpenQAOA (e.g., problems in the Problem Classes module 152). For example, for a knapsack problem, the binary variables of the solution can be annotated as "decision variables" and "slack variables". These features can also contribute to the efficiency of the overall workflow, as they make the data easier to interpret.

[0101] A fourth purpose of RO135 is to allow users to add context to their data: in this way, identifiers from a backend provider, such as a job ID, can be connected to identifiers relevant to the user, such as the algorithm settings used or the project name.

[0102] More generally, the focus on labeling data with result objects 135 according to the present embodiment and the ability to reconstruct the complete data is intended to ensure experimental reproducibility and adherence to best practices.

[0103] Returning to the discussion of the OpenQAOA enabler 150 in schematic 100, the first module is the problem class module 152. The problem statement is the only input parameter that the user needs to specify (default options exist for all other input variables). In this regard, the user has two options. First, the user can explicitly give a binomial or Ising formulation of the problem. Of course, in this case, the user needs to know the required formulation and how to specify it in a format that OpenQAOA accepts. Second, the user can select a problem from a set of built-in classes in OpenQAOA. These selectable problem classes can be selected from within the Problem Class Module (PCM) 152. These problems include the most common optimization problems such as the traveling salesman (TSP) problem, the bin packing problem, the knapsack problem, the number partitioning problem, and the job shop scheduling problem. The user only needs to specify the data corresponding to the problem instance, e.g., a matrix of distances between cities for the TSP problem, or a list of object weights and values ​​for the knapsack problem. If the SDK does not have a built-in class for a particular problem, users can extend PCM 152 to build a new class for the particular problem they are interested in. The newly defined problem statement class can then be used within the SDK / OpenQAOA.

[0104] PCM152 promotes workflow efficiency. By removing the burden of providing a binary or Ising formulation of the problem, users save time and effort. OpenQAOA problems can be formulated directly from data relevant to the problem instance, e.g., a matrix of relative city locations for a TSP. Furthermore, custom problem classes can be easily added, extending the usefulness of PCM152 to suit users' specific requirements.

[0105] PCM152 also ensures consistency and reproducibility of workflows. Using PCM152 can ensure that the same mathematical rules are employed when performing computations of the same problem class. Furthermore, using PCM152 can reduce the chance of making errors (correctness) compared to manually setting up problems of the supported classes. Specific examples where these considerations are relevant include converting between Ising and QUBO forms of problems, handling constant energy shift terms in cost / objective functions, and mapping problems to a representation that is used consistently throughout the computation. All these benefits are relevant for single-user workflows as well as for multi-user collaborative workflows.

[0106] The Circuit Compilation Module (CCM) 153 is responsible for qubit selection, qubit mapping, qubit routing, and subsequent post-processing steps as described above in this specification. The CCM 153 consists of a library of algorithms designed to tackle these problems, and receives input from and sends output to the Circuit Compilation Interface.

[0107] The minimum input information required for CCM153 consists of a problem statement, such as an Ising or QUBO Hamiltonian in a suitable representation, and the device on which the computation will be performed (e.g., one of the provider devices 174). Additional options can also be provided, such as specifying the algorithm to be used for compilation and their associated settings. CCM153 has two broad goals. The first goal of CCM153 is to provide the information necessary for the OpenQAOA core 110 to build a circuit that is executable on the target device (i.e., a circuit that respects the connectivity of the device). In addition to the aforementioned points, the second goal of CCM153 is to optimize the circuit to minimize noise spread. This can be achieved by targeting several metrics, such as minimizing the number of SWAP operations required to route qubits, selecting a set of qubits with the highest fidelity of quantum gates, minimizing the depth of the quantum circuit, or any combination of these metrics or other similar metrics.

[0108] CCM153 returns to CCI all the information necessary to build a circuit that can run on the specified hardware device. Thus, CCM153 proves to be an essential component of OpenQAOA for scalability, since effective circuit compilation is essential for large-scale QAOA computations.

[0109] Error mitigation techniques can help improve the quality of results obtained from the QPU, especially at the expense of obtaining larger amounts of data or running longer circuits. Such techniques become more practically attractive as the cost of quantum computing falls, and may become an essential part of the QAOA workflow. OpenQAOA's Error Mitigation Module (EMM)154 is designed to bring the benefits of error mitigation to the QAOA workflow. Error mitigation techniques are diverse in how they work and where in the workflow they must be applied. For example, there are techniques that modify the target QAOA circuit by inserting additional gates or operations. Examples of such techniques are zero-noise extrapolation and dynamic decoupling. These techniques must be applied before the circuit is sent to the backend170 for execution. Techniques in this category may require the construction of multiple different circuits from the target circuit. For example, there are methods that use randomized compilation or twirling.

[0110] Also, there are techniques that do not modify the target QAOA circuit, but require additional calibration or reference circuits to be built and run. In either case, EMM154 can be called first to build the added or modified circuit, then after the circuit has been run, EMM154 can be called a second time to post-process the results, if required by the technique used.

[0111] At a minimum, EMM 154 receives as input from an enabler interface (more specifically, an error mitigation interface) a specification of the target QAOA circuitry and the error mitigation techniques to be used. Additional inputs include configuration related to the error mitigation techniques and a description of any target backend related data that may be required. EMM 154 can access this data by communicating with the provider's system or it can be explicitly specified by the user.

[0112] The EMM 154 returns different information to the OpenQAOA Core 110 through the error mitigation interface at different stages of the workflow. For example, after a first call, the EMM 154 may return a modified circuit for the OpenQAOA Core 110 to dispatch to the backend 170. After a second call for data pre-processing, the EMM 154 returns information to update or augment the result object 135 in the OpenQAOA Core 110.

[0113] EMM154 enhances OpenQAOA by providing features that significantly improve QAOA performance. Users can now invoke powerful techniques with minimal effort or required knowledge. Furthermore, error mitigation is essential for the scalability of QAOA, especially when dealing with large-scale computations.

[0114] The Resource Estimator and Profiling Module (REPM) 155 provides the user with information to run the OpenQAOA-built circuit on a specific target backend. This is to help the user evaluate the resources required to achieve their goal. Referring to FIG. 3, a block diagram 300 shows the operational connectivity of the REPM 155 according to the present embodiment. The REPM 155 receives as input the quantum circuit built by the OpenQAOA core module 110 and the name of the target device (a selected one of the providers 173) on which it should be executed. The use of the circuit compilation interface in the circuit building step is beneficial as it allows the REPM 155 to provide a more accurate estimate of the various resource requirements.

[0115] Examples of information that may be calculated and returned by REPM 155 include the estimated execution cost (i.e., financial estimate 305) for a specified number of optimizer iterations and shots taken. This requires that REPM 155 has access to provider pricing information for the targeted device. Such information may be accessed, for example, via an API call to the provider's system 310, if available, or may be specified directly by the user.

[0116] Information that may be calculated and returned by REPM 155 also includes the estimated execution time of the circuit (i.e., time estimates 315). This requires that REPM 155 have access to the provider's gate execution times. Again, these are accessed via API calls to the provider's system 310 or passed in by the user.

[0117] Information that may be computed and returned by REPM 155 may also include a comparison of the estimated circuit execution time to the coherence time(s) of the qubits being used, and / or some statistical characteristics of the set of coherence times (e.g., time estimates 315). The necessary information may be provided to REPM 155 as described in the previous points.

[0118] Information that may be computed and returned by REPM 155 also includes estimates of the probability of different numbers of errors occurring in the circuit (i.e., error estimates 320). For example, given data (which may be derived from randomized benchmarks, cycle benchmarks, tomography, or other suitable methods) characterizing the error rates of one-qubit and two-qubit gates in a target device, the probability P 1Q (m). Similarly, the probability of m two-qubit errors occurring P 2Q It is also possible to calculate (m). Such calculations are estimates, and errors are assumed to occur independently of each other.

[0119] REPM 155 can also provide resource estimates when the circuit is intended to be executed in a fault-tolerant manner (i.e., fault-tolerant estimate 325). For example, given a logic-level QAOA circuit generated by OpenQAOA core 110 (not generated in conjunction with a CCI this time), along with device information (e.g., gate execution time, base error rate) and details of a quantum error correction scheme, REPM 155 can estimate quantities such as the number of physical qubits required, the execution time of the circuit, and the number of different types of gates.

[0120] REPM155 provides OpenQAOA with valuable capabilities for computational workflows: by estimating resources and analyzing data related to the execution of algorithms on specific devices, users can make informed decisions about where and how to run computations, and REPM155 is designed to facilitate this.

[0121] Auto VQA 156 is another module provided by the enabler 150 according to the present embodiment, which can help the user to create a VQA that fits the specific problem at hand. In general, VQA is not provided as a one-size-fits-all algorithm, but needs to be tuned and modified according to the specific situation at hand. The user passes the input statement to Auto VQA 156 and receives a ranked selection of different available parameters (circuit ansatz, parameterization, optimizer, etc.) according to the present embodiment. The ranking is obtained by combining statistical techniques on the input using machine learning classifiers built from a historical set of previous computations, and a proprietary rule-based system. These techniques include a) statistical analysis of the problem, b) comparison of the problem instance with the machine learning approach to past problem instances, and c) a rule-based system based on technical understanding of the VQA. Comparison of the problem instance with the machine learning approach to past problem instances clusters problem types and selects the optimal components of the quantum algorithm, for example, by using machine learning on past data to predict the most effective optimizer. Auto-VQA156 then ranks the different components and suggests which to use. Auto-VQA156 addresses the scalability issue by avoiding brute force prototyping.

[0122] OpenQAOA provides a module, the benchmark module 158, that contains methods for benchmarking QAOA under various conditions. Benchmarking is an essential element for designing and evaluating the performance of any algorithm and the environment in which it runs. The benchmark module (BM) 158 of OpenQAOA is designed to facilitate and enhance the benchmark workflow of QAOA. Referring to FIG. 4, a block diagram 400 illustrates the operation of the benchmark module 158 according to the present embodiment. The role of the BM 158 is to leverage functionality within the OpenQAOA core 110 (and subsequently the enablers 150, providers 173, and workflows 410) to track metrics 402, experiments 404, problems 406, devices 408, and other benchmark data of interest. The experiments 404 included in the BM 158 are designed to expose important aspects of the QAOA algorithm and the devices 408 used to run it. The benchmarking module 158 can then access static characteristics of the device 418 (such as quantum volume or Q-score) as well as dynamically use them as a key component in the compilation step of QAOA. For example, information obtained through the benchmarking module 158 can be used to select the circuit compilation 420 or error mitigation technique 154 that is optimal for the noise witnessed.

[0123] QAOA can be run with noise in a controlled manner on a suitable classical simulator, as described above in this specification. When running QAOA on a QPU, it is subject to the noise processes of the device, which cannot be accurately characterized in an efficient way. It is therefore interesting to have a set of standardized problem-centric benchmarks that show the performance of a given device 408.

[0124] Examples of experiments 404 (computations) in BM155 include, but are not limited to, parameter landscape sweeps involving unweighted Max-Cut problems on k-regular graphs, and analytical expressions. Parameter landscape sweeps for problems that are theoretically analyzable with or without noise are examples of experiments 404 in BM158. For example, using standard parametrisation, the canonical problem of unweighted Max-Cut on a Ring of Disagrees for a single QAOA layer has an optimal solution that does not depend on the size of the problem (i.e., the angles γ and β of the QAOA circuit that provides the optimal solution do not depend on the size of the ring). When running this computation on an actual QPU, the extent to which the performance deviates from the expected results as the user varies the problem size can provide an indication of whether the device is suitable for running large-scale quantum computations. A variation of this experiment runs an unweighted Max-Cut problem on a k-regular graph (k is an integer). For any k, as the number of nodes in the graph goes to infinity, the optimal solution (i.e., the angles γ and β) also become independent of the problem size.

[0125] In a few limited and simple cases, analytical formulas can be obtained for the performance of QAOA in the presence of noise, an example being the BM158 experiment 404. The conditions under which these results are obtained typically correspond to fundamental Pauli noise processes. For example, the Max-Cut of Ring of Disagrees parameter sweep experiment (as described earlier in this specification) can characterize the noise present on a given quantum computer by reference to analytical calculations that assume a particular noise process. These experiments 404 can be performed quickly and cheaply, as they do not require actual optimization and are performed with known fixed parameters.

[0126] BM158 also includes publicly available experiments related to QAOA and benchmarking the devices that run it, including Quantum Volume, Q-Score, and the QED-C QAOA benchmark algorithm.

[0127] BM158 provides advantages to users in several ways. First, experiments 404 are specifically designed to reveal useful metrics or characteristics of QAOA or the device on which it is running. Users can easily run experiments 404 with minimal effort, and the information obtained can be used to inform possible next steps, such as deciding which QPU to use for a broader set of experiments in a project. In other words, actionable information is obtained efficiently.

[0128] Second, a calibrated bank of rigorously tested and vetted experiments 404 ensures consistency and reproducibility across users or groups of users, reducing the chance of error.

[0129] OpenQAOA provides an extensive set of simulators, or backends 170, that simulate the behavior of quantum computers. The simulators according to the present embodiment are designed to allow users to investigate the performance of QAOA under various research situations. For example, state vector or wave function simulators mimic the behavior of a noise-free quantum computer and return the complete output wave function. Master equation and quantum Monte Carlo wave function simulators mimic the behavior of a quantum computer in the presence of known noise processes acting continuously on the system. Error-based simulators (such as EE and DEWF simulators) focus on the effects of noise occurring at specific locations of the quantum circuit. Specialized simulators for calculating specific characteristics of the output of QAOA circuits are also based on explicit formulas derived from analytical analysis (e.g., single-layer simulator (SLS)).

[0130] A suite of simulators allows users to thoroughly explore the performance of QAOA and the impact of noise. Consistency, reproducibility and accuracy are achieved by standardizing the implementation of different types of simulators. Building simulators, especially those that incorporate noise, requires significant expertise, care and testing to ensure correct operation. Furthermore, to allow different types of simulators to provide complementary insights into the same research problem, the mathematical and scientific conventions used must be consistent across the simulator family.

[0131] Workflow efficiencies come from being able to call the user's base code with minimal changes by accessing multiple different simulator types. As an example, the following Python pseudocode shows the general syntax that can be used (note, however, that OpenQAOA is not limited to being implemented in Python):

[0132]

number

[0133] Standard Plotting Module (SPM) 186 facilitates the visualization of standard data provided in array or matrix type data structures. SPM 186 is the workhorse for creating charts, plots and illustrations of numerical and categorical data obtained during or in preparation for calculations. It can also be used to visualize graph data, in the sense of structures with a set of nodes and edges.

[0134] For example, one can use SMP186 to plot the history of a cost function across all optimizer iterations of a QAOA computation, plot the scaling of QAOA performance as a function of parameters such as number of layers or problem size, plot information derived from computations performed by REPM155, plot and annotate graph structures consisting of nodes and edges, etc. For example, one might want to visualize the output of a computation defined on a graph, where the nodes and edges of the graph are colored to indicate the solution.

[0135] Circuit Schematic Visualizer (CDV) 190 can visualize quantum circuits in a standard representation: CDV 190 generates an image of a series of wires, each of which represents a quantum bit and on which gate operations are performed.

[0136] Circuit Compilation Visualiser (CCV)188 is a special feature that makes it easier to visualize how a target circuit will be compiled into a desired backend. The results of qubit selection, qubit mapping, and qubit routing are generally not intuitive to humans and can be difficult for users to inspect in detail. CCV188 provides many different ways to view the results of such circuit compilation steps, potentially helping users identify patterns and develop better intuition about these issues in general. Some examples of how CCV188 achieves such goals are:

[0137] As a first example, given one or more qubit selection maps (i.e., a specification of which qubits on a target device should be actively used to perform a target computation), an illustration of the device can be annotated with the selected qubits. When multiple selection maps are compared, numerical data quantifying the quality of each selection map can also be included in the visualization.

[0138] As a second example, given a qubit routing schedule (e.g., a list of sequences of SWAP operations that must be performed), CCV188 supports several visualization methods. First, each physical qubit is represented by a wire, similar to the standard representation of a quantum circuit, with time flowing from left to right. When two qubits are swapped, their wires cross each other. By crossing the wires in this way at the relevant instants in the circuit, a complete visualization of the routing schedule can be constructed. Effectively, this constitutes a visualization of the QAOA circuit in a standard representation, using the standard representation of the SWAP gate and with all other gates removed. In other words, the standard circuit diagram is stripped down to show only the SWAP operations. Next, a graph representation of the target device is constructed to reflect its true connectivity (a "device graph"). Each node in the graph represents a physical qubit, and if a pair of nodes is connected by an edge, a SWAP operation is performed between them. An animation is created consisting of a series of frames representing each instant of the circuit. In each frame, the device graph diagram is annotated with the location of the SWAP operation that takes place at the corresponding circuit instant. Alternatively, each node in the device graph may be labeled, for example, with a number indicating the logical qubit that corresponds to each physical qubit. When a SWAP operation is performed, the logical qubit indices are permuted, which is reflected as the diagram moves from frame to frame. That is, when a SWAP operation is performed, the numbers in the graph that represent the logical qubit indices are swapped.

[0139] Graphics generated by the GUI can be saved in Save-and-Load 192 using standard commands executed directly within the GUI. Similarly, previously generated graphics can be loaded in Save-and-Load 192. Experimental data in the OpenQAOA Results Object can also be loaded in Save-and-Load 192 for convenient examination.

[0140] FIG. 5 shows an exemplary representation 500 of a general OpenQAOA workflow according to the present embodiment. The OpenQAOA core 110 is responsible for both connecting to the enabler layer 150 and plugins 160 through APIs and for running the hybrid classical-quantum loop 510 that drives the actual QAOA. From the workflow module 502, the OpenQAOA core 110 receives the workflow and utilizes the problem class module 152 to create the problem statement of the workflow. More specifically, the user provides input data, some of the input is derived from the problem class module 152 (i.e., the Hamiltonian that ends up being a list of terms and weights), and other parts are the algorithm settings, the compilation procedure to be used (or anything else called by the enabler 150), and the specification of back-end details. The input is passed to the sub-modules of the OpenQAOA core 110. The workflow module 502 is responsible for orchestrating the execution of the entire algorithm, and the workflow module 502 also connects to the enabler module 150 and the provider module 174. It is important to note that in accordance with the present embodiment, a user may choose not to select a predefined workflow in the workflow module 502, but may instead build their own workflow through the workflow factory module.

[0141] From the OpenQAOA core 110, an abstract QAOA circuit 504 is generated using enablers such as a circuit compilation module 153 and an error mitigation module 154. The core functionality of OpenQAOA according to this embodiment is defined as a device-independent module, i.e. it represents code abstracted from details that depend on a particular target quantum computer. The code that depends on a particular target quantum computer is contained in the enabler module 150 or the OpenQAOA plugin 160.

[0142] The OpenQAOA enabler 150 is always connected to the elements of the OpenQAOA core 110 via the API 140. The enabler may be effectively called before a workflow (e.g., the problem class module 152 as shown in figure 500), during a workflow (e.g., the circuit compilation module 153 and the error mitigation module 154 as shown in figure 500), separately from a workflow (e.g., the resource estimation and profiling module 155 and the automatic VQA 156), or included in many workflows (e.g., the benchmarking module 158). The circuit compilation module 153 is mandatory for the execution of any workflow, as it is necessary for the generation of the abstract QAOA circuit 504. The compilation steps of qubit selection, mapping, and routing are performed on the abstract QAOA circuit 504. After performing these compilation steps, the output is an abstract description of the original circuit, committed to a specific subset of qubits on the target device and taking into account the device connectivity limitations. However, at this stage it is still not a fully executable circuit, but rather the abstract QAOA circuit 504. The provider plugin 506 performs the task of translating the abstract QAOA circuit 504 into a fully executable circuit characterized by a set of physical pulse operations (microwave, optical frequencies, etc.) or similar operations specific to the physical platform of the provider's technology. The circuit compilation functionality is split into two parts: a device-independent part identified as the circuit compilation module 153 located within the enabler 150 (FIG. 1), and the provider compilation 506, which is device-dependent and part of the plugin / provider classification (i.e., plugin 160 (FIG. 1)).

[0143] The abstract QAOA circuit 504 is compiled into a selected provider by provider compilation 506 and fed into a hybrid classical-quantum loop 510. Within the hybrid classical-quantum loop 510, the compiled circuit is run 520 on a simulator or on a QPU and the variational parameters are optimized by classical optimization 522. If stopping criteria 524 are met, results and a log 530 are output. If stopping criteria 524 are not met, new parameters 526 are fed into the compiled circuit and the circuit is run again 520.

[0144] Diagram 500 illustrates how the core algorithmic elements of OpenQAOA interact and connect to both the enabler layer and the plugin / provider layer. Figures 6A, 6B, 6C, and 6D together illustrate a computational workflow diagram 600 (shown as 600a, 600b, 600c, and 600d) according to the present embodiment, showing a more detailed breakdown of how information flows between the elements of the OpenQAOA core 110 and the enabler 150 and plugin 160 / provider components 174. While diagram 100 (Figure 1) illustrates the hierarchy of dependencies of the different components of OpenQAOA according to the present embodiment, diagram 600 illustrates the computational workflow of how information flows between the different components of OpenQAOA according to the present embodiment. As described herein above, core 110 provides the most basic and fundamental routines and functionality required to perform QAOA computations, and core 110 is independent of the backend 170 on which the computations are performed. The enabler 150 and GUI 185 rely on previous tasks performed by the core 110, receive information from the core 110, and perform actions using that information. And the backend 170 requires prior use of both the core 110 and the enabler 150, which is required for circuit compilation 153 if none exists.

[0145] Diagram 600 reflects more closely the information flow between components during the computation, with solid lines representing required data flows and dashed lines representing optional data flows. While schematic 100 represents a hierarchical structure, in a real QAOA computation, information flows back and forth between different OpenQAOA elements, such as core 110, enabler 150, and backend 170, in a non-linear way. For example, after executing a circuit in backend 170 and obtaining data from it, the data is returned to core 110. If an error mitigation method is specified, a call is made at this stage to error mitigation module 154 in enabler 150 to post-process the data before returning this updated data to core 110. Then, in core 110, a classical optimizer is executed, which updates the variational parameters. A new quantum circuit is then constructed and passed to backend 170, and a loop is established until a termination criterion is met.

[0146] A second example showing that the flow of information is important is during the computation with R-QAOA, a modified version of the basic QAOA. In this case, after processing the data in the core 110 obtained from the backend 170, the optimization problem to be solved is changed from the initial problem (but related to it). Therefore, before the new circuit is executed in the backend 170, it needs to be built in the core 110 and then compiled by the compilation module 153. Diagram 600 (FIGS. 6A, 6B, 6C and 6D) depicts the non-linear flow of computation using different components of the core 110, the enabler 150, the backend 170 and possibly the GUI 185.

[0147] OpenQAOA according to the present embodiment is a reference implementation of a multi-backend SDK for variational quantum algorithms (solutions). OpenQAOA can be divided into two distinct parts: a core algorithm component consisting of a set of internal APIs responsible for building the optimization workflow, and a set of validation and visualization components that can be integrated with the workflow (e.g., a compilation module 153 and an error mitigation module 154) or as standalone tools (e.g., a benchmarking module 158 or a resource estimation and profiling module 155).

[0148] The most basic VQA that OpenQAOA according to the present embodiment can implement is QAOA. QAOA is a general algorithm for finding approximate solutions to combinatorial optimization problems. Since its introduction in 2014, QAOA has attracted particular attention because it can be run on NISQ devices and because QAOA is expected to feature a relative speedup compared to state-of-the-art classical optimization algorithms. Although it is possible to identify a standard QAOA in the protocol first introduced, it is now appropriate to speak of a family of QAOA algorithms. Within the QAOA algorithm family, there are many modifications and extensions of the standard QAOA algorithm. However, since a set of structural features can be defined, a QAOA instance is given by a fixed-structure parametric quantum circuit whose parameters are learned by an optimization algorithm that evaluates the quantum circuit on a simulator or on a quantum device.

[0149] Referring to FIG. 6, the first step in creating a VQA using OpenQAOA is the creation of the input, which is done in input 602. Input 602 consists of two parts: problem statement 604 and VQA statement 606. Problem statement 604 is the only input parameter that the user must specify, since it is a required dependency of VQA statement 606. The user may have two options: either the user selects a built-in class of the problem from the problem class module 152, or the user provides a binary formulation of the user's problem. OpenQAOA according to the present embodiment provides a set of built-in types of well-known optimization problems (such as the traveling salesperson problem and the number partitioning problem) in the problem class module 152 to simplify the construction of input 602. If the SDK does not include a built-in class for a particular problem, the user can extend the problem class and build a new class for the particular problem of interest. The newly defined problem statement class can be used within the SDK. Problem statement 604 determines the minimum number of qubits required by the VQA by considering how many unique variables are specified.

[0150] The VQA statement 606 specifies the definition parameters of the VQA 608. The parameters are JSON-compatible data primitives (i.e., integers, floats, strings, Booleans, etc.) and include the circuit ansatz properties 610, the variational parameters 612, the backend 614, and the optimizer 616. The circuit ansatz properties 610 include the total number of qubits, the cost Hamiltonian, and the mixer Hamiltonian, which in turn specify the circuit ansatz and the circuit parameters (e.g., the number of layers). Of course, the cost Hamiltonian depends on the problem statement 604. The variational parameters 612 are a set of fields that specify the variational parameterization of the circuit. The variational parameters 612 include the choice of parameterization and the parameter initialization strategy. These variational parameters are optimized in a classical-quantum loop.

[0151] The backend 614 must provide the backend name and authentication information (for QPU or cloud-based simulators) and the location of the backend (e.g., local or cloud provider name), along with any additional information required by the backend (e.g., number of measurements). The backend 614 can also be a simulator. The optimizer is a classical-quantum loop.

[0152] OpenQAOA according to the present embodiment provides built-in methods to create both the problem 604 and the VQA statement 606, meaning that the user does not need to write either from scratch. The SDK provides an API to convert the problem 604 and the VQA statement 606 from JSON-compatible data primitives into code that the backend 614 can execute. This conversion is important in the design of the optimization SDK because it ensures consistency at the level of the mathematical statement of the optimization problem and provides a standardized way to build quantum optimization algorithms.

[0153] The SDK's internal API is used to build workflows to solve optimization problems. Through the API, users can follow two routes: use built-in workflows 618 or create workflows from scratch in the workflow factory 620. The built-in workflows 618 are ready-to-use implementations of quantum algorithms (QAOA, R-QAOA (Recursive QAOA), Greedy QAOA) with minimal user intervention. These workflows take the problem statement 604 and the VQA statement 606 as input, convert the underlying algorithms into executable workflows, and return as output the optimization results, including all relevant metadata from all algorithmic aspects used (e.g., metadata from simulation / quantum computer and classical-quantum loop optimization). The built-in workflows 618 have a default set of parameters. Thus, a user just getting started with variational quantum algorithms only needs to select the problem statement 604 and the desired VQA workflow. Extensive customization is also possible for the built-in workflows 618, allowing the user to specify selected properties of the VQA statement 606. The user can choose between circuit analysis 610, parameterization and initialization strategies 612, classical optimizer 616, and backend 614. For example, for the initialization strategy, the user can choose from predefined schemes or select a custom option that provides an arbitrary set of circuit gate parameters.

[0154] In the Factory 620, the user can modify the entire workflow. The source code of the built-in workflows 618 is available to the user in the Factory 620, allowing the user to change the order of operations or introduce different logical structures. Technically, all workflow components are defined only in terms of input / output relationships. This design allows parts to be replaced as long as the I / O connections are satisfied.

[0155] The SDK's API, whether using built-in workflows 618 or factories 620, converts the input into a back-end agnostic representation of the VQA computation. The agnostic attribute allows for a VQA structure that is completely independent of a specific practical implementation. The abstract VQA representation 622 is an abstract definition of the input, the structure of the VQA circuit, and the CQL.

[0156] Defining QAOA as the most basic VQA that OpenQAOA can implement, the built-in workflow also allows building non-trivial extensions of QAOA. Two examples of such extensions are Recursive-QAOA (R-QAOA) and Greedy-QAOA (G-QAOA). R-QAOA is an algorithm that runs QAOA recursively to solve an optimization problem. At each recursion step, a new small instance of QAOA is generated. The output statistics of QAOA at each stage are used to impose a constraint (or constraints) on the system, allowing to remove one (or several) qubits from the problem statement. Once the problem size is small enough, the problem is solved exactly by classical methods. The solution to the original problem is retrieved by backtracking through the constraints imposed at each step, using the exact solution computed at the end of the recursion.

[0157] G-QAOA is an improvement over QAOA, where each layer is optimized independently. The algorithm starts by specifying a circuit with one layer, namely p=1. This circuit goes through a classical-quantum loop, optimizing the parameters related to this layer. Once the parameters of p=1 are optimized, a new circuit is defined. This new circuit corresponds to the p=2 circuit, where all parameters belonging to the p=1 layer are fixed and the classical optimizer loop optimizes only the p=2 parameters. This procedure is repeated for all layers.

[0158] The Core Algorithm component of OpenQAOA receives the definition of the abstract VQA representation 622 and proceeds to create a backend specific quantum circuit and execute it in the Classical-Quantum Loop (CQL) 630. The Classical-Quantum Loop (CQL) 630 receives the abstract VQA representation 622. The orchestration and classical optimization 368 of the CQL itself is part of the Core Algorithm component. The CQL 630 includes the execution of the quantum circuit on a QPU or simulator. These are part of the Plugins 160 and Providers 170. If a quantum backend is used, the CQL 630 also needs to connect to the quantum cloud to send and receive information.

[0159] To create the circuit, OpenQAOA uses information from the VQA statement 606. In OpenQAOA, a circuit Ansatz 610 is a fixed set of quantum gates that are repeated p times. Each repetition p is a layer of the circuit. The user can specify the variables p. The Ansatz 610 is VQA specific because VQA determines the gate set of the Ansatz. For QAOA, the set of gates includes driver gates (associated with a cost Hamiltonian) and mixer gates (associated with a mixer Hamiltonian). The driver gates construct a QAOA evolutionary operator that encodes the cost function of the problem statement 604, which is then minimized by VQA. The user selects the mixer gates by choosing among a set of pre-fixed mixer gate structures or by specifying an arbitrary mixing strategy. The names mixer and driver follow conventional QAOA scientific literature. Circuit Ansatz 610 essentially stores back-end agnostic instructions for building a layer of VQA on top of the final quantum circuit.

[0160] Variational parameters (or parameters 612) specify the variational parametrization of the quantum circuit. The user has full control over the parameterization strategy. For example, they can assign the same value to all parameters 612 on a particular part of the circuit ansatz 610 (as in traditional QAOA parametrization). In OpenQAOA, the user first selects the type of parametrization and then selects the corresponding strategy. Different kinds of parametrization are supported in OpenQAOA, including extended parameterization, where, given a circuit ansatz, each gate is specified with the same parameter; standard parameterization, where, given a circuit ansatz, each gate in the mixer gate set is parameterized with one value and each gate in the driver gate set is similarly parameterized; and annealing, where the parameters are constructed using a user-specified annealing schedule. If the type is Extended or Standard, the user can choose between two different strategies: the Original strategy, whose parameters correspond to the original parameterization, or the Fourier strategy, whose parameters are the sine / cosine transform of the original parameterization.

[0161] Once the parameterization is fixed, the parameters 612 need to be initialized. The OpenQAOA SDK according to the present embodiment provides a set of built-in initialization strategies, including but not limited to a linear initialization strategy, where parameters are initialized linearly over p layers, similar to a linear quantum annealing schedule, a random initialization strategy, where parameters are initialized randomly, and a custom initialization strategy that allows the user to provide values ​​as a list.

[0162] All this information (i.e., the circuit ansatz 610 and variational parameters 612, the problem statement 604, and the algorithm 608) defines a backend-agnostic representation 622 of the quantum circuit for VQA. OpenQAOA further refines this representation 622 to obtain an optimally compiled abstract circuit. This abstract circuit is the input to a classical-quantum loop 630 to create a variational quantum algorithm targeting different backends and simulators.

[0163] Turning now to the Classical-Quantum Loop (CQL) 630, OpenQAOA according to the present embodiment executes the circuit according to certain steps in the CQL 630 to optimize the variational parameters. First, the Backend-Agnostic Representation is converted to a backend-specific circuit by the Circuit Builder 632 and sent to the desired backend device 636 via an external API call 634. The role of the QPU is to evaluate the circuit and return an output dictionary of states and relative counts to the SDK. Note that if a local simulator is used for evaluation, the external API call 634 may not be necessary. A cost function 637 is estimated from the measurements and minimized using a VQA classical optimizer 638. The classical optimizer 638 then creates a set of new parameters 639. The new set of parameters 639 is used to update the parameterized circuit 632, and the new circuit is sent to the backend device 636 which evaluates the new parameterized circuit. The classical optimization routine 638 executes the CQL 630 according to its internal rules, and the loop stops when the optimization is finished. Once the optimization is finished, OpenQAOA returns the result 640 to the user.

[0164] The circuit builder 632 converts the abstract VQA representation into an explicit quantum circuit representation that is compatible with the backend of interest. The circuit builder 632 creates parameterized circuits in a backend-dependent manner and initializes gates of the parameterized circuits according to an initialization strategy. The circuit builder 632 also updates parameters during CQL 630 and connects to an external API 634 to run the quantum circuit on a cloud-based quantum computing provider 636.

[0165] In accordance with this embodiment, the OpenQAOA backend 636 can utilize IBM Q devices (through Qiskit), AWS devices, and all gate-based devices supported by AWS Bracket (through the AWS Braket SDK), all gate-based devices supported by Rigetti's QCS (through PyQuil), Microsoft Azure, and Azure Quantum (through the Azure SDK), all devices that accept QASM2.0 and QASM3.0, all available devices that accept the quantum intermediate representation QIR, and also local simulators based on IBM's Qiskit and the Vectorized simulator, a QAOA simulator developed by Entropica Labs in Singapore.

[0166] The classical optimizer 636 uses the results of the quantum computation to obtain a cost value 637 for a particular choice of parameters. Any function that satisfies the input-output relations in CQL 630 is in principle a valid optimizer. OpenQAOA supports a wide range of optimizers (which can be extended by the user). Supported optimizers include Scipy optimizers (wrappers around all optimizers available through the scipy library), custom gradient optimizers (a set of gradient optimizers written by Entropica Labs extending the Scipy library), machine learning optimizers (reinforcement learning agents trained by Entropica Labs), and PennyLane optimizers (wrappers around all optimizers available through the PennyLane library). Custom gradient optimizers include the vanilla gradient descent optimizer, the Newton optimizer, the mean square root propagation optimizer, the natural gradient descent optimizer, and the joint perturbation stochastic approximation optimizer.

[0167] Optimizers update parameters according to different strategies. An important distinction is between local and global optimizers, which highlights the modularity advantage of OpenQAOA according to the present embodiment. Local and global optimization algorithms may adopt different strategies to find a solution to a minimization / maximization problem. Local optimizers are generally bound to a specific search space region, whereas global optimizers try to find an optimal solution by considering a much larger part of the search space. Usually, local optimizers can find a better solution if there is a solution within the region being explored, while global optimizers are better at finding a suitable region.

[0168] A possible strategy to improve optimization performance is to employ two different optimizers. For example, assuming a total of N optimization steps for CQL630, the first N / 2 iterations can be performed with a global optimizer (to identify good regions of the space) and the remaining N / 2 steps can be performed with a local optimizer. In this embodiment, OpenQAOA allows users to quickly write a hybrid optimizer that is responsible for stacking two different optimizers. The only requirement for this hybrid optimizer is that it conforms to the general input-output relationship of the optimizer class.

[0169] After VQA is performed via OpenQAOA according to the present embodiment, the user receives output 645 at the end of CQL 630. This output is a python dictionary containing the solution to the optimization problem. The solution is extracted from the final probability distribution of the quantum computation (note that the quantum computer returns a list of strings and the number of observations / counts for each string). The solution includes the k most probable bit strings (where k is a user-specified positive integer) and their associated probabilities / counts. Output 645 also includes a dictionary containing a mapping of binary variables defined in problem statement 602 to the results of the VQA computation. Additionally, output 645 includes metadata from classical-quantum loop 630, metadata from the backend, and metadata about the SDK itself. The metadata from CQL 630 includes the optimization history and optimal parameter set of classical optimizer 638. For the QPU, the metadata from the backend is a result object provided by the hardware provider. The metadata about the SDK includes information such as version, run time, and run length.

[0170] OpenQAOA according to the present embodiment can then convert the results dictionary 645 into a JSON formatted file 650 to simplify cross-language and cross-platform (AWS, Rigetti Quantum Cloud Services, IBM Q, etc.) piping of the SDK results. The actual format of the output is given by diagram 200 in FIG. 2. The SDK also provides a second output type available to the user upon request in the form of metadata. This output represents a quantum circuit and can be returned in an open quantum assembly language like OpenQASM, allowing piping of VQA within a larger quantum / classical computation. This means that the user can use OpenQAOA as a tool to optimize specific parts of a broader algorithm, rather than using it as a standalone software.

[0171] The advantage of having a fixed and structured output given by a header key (e.g., Header 210) containing the indexable and searchable portion of the stored data, and a data key (e.g., Data 250) containing the raw data corresponding to the atomic results, is that it allows implicit creation of a database for VQA. Given the cost of running computations on quantum hardware, it is paramount to assign consistent and searchable output for computations performed by different people or by the same person at different times. Standardization of the output, and a set of predefined helper functions that aid in archiving the results, are key enablers of OpenQAOA. In particular, the ability to build structured datasets is a fundamental aspect of OpenQAOA extensions and one of the essential foundations that enable machine learning algorithms built for VQA.

[0172] In addition to the functional components of the OpenQAOA process according to the present embodiment, additional functions and components that are not part of the core algorithmic components of OpenQAOA may alternatively be utilized (paths to these components are shown by dashed lines in Figures 6A, 6B, 6C, and 6D).

[0173] Qubit Routing 660 is an algorithmic subroutine (solver) built into OpenQAOA and is structurally part of the Circuit Compilation module 153 of the Enabler 150. Qubit Routing 660 inputs the original abstract circuit and a description of the target NISQ device (topology, gate error rate, natural gate set) and outputs a valid abstract VQA representation 622 that implements a logically equivalent circuit that ideally minimizes noise during execution on the NISQ device. In effect, Qubit Routing 660 generates a new circuit by finding an optimal circuit equivalent that fits the topology constraints of the real hardware and reduces the noise level of the original gate choices. For example, reducing the number of two-qubit gates (such as the SWAP gate) is a way to reduce the noise introduced into a quantum computation.

[0174] Qubit routing 660 integrates the VQA backend agnostic abstract representation 622 with CQL 630. Thus, qubit routing 660 outputs a separate VQA abstract representation object. By design, qubit routing 660 can operate as a standalone software library that directly queries the quantum cloud to obtain additional information such as the noise profile of the quantum gates. The Cost Management Tool (CMT) 665 is part of the resource estimation and profiling module 155 of the enabler 150 and is responsible for profiling the VQA algorithms and evaluating the costs associated with their execution on available backends. The CMT 665 can estimate the economic cost, the time required, and the number of circuit evaluations. The input for the CMT 665 is the abstract description 622 of the circuit provided by the OpenQAOA SDK, and the user's backend credentials. The CMT 665 then uses the cached results to estimate the prices and properties of available backends or sends direct API requests to different cloud providers to get their current availability and information.

[0175] Given the abstract VQA representation 622, the CMT 665 returns a dataset containing a cost breakdown 667 of the desired combination of parameterizations, optimizers, and determined backends. The available combinations can be specified explicitly by the end user or selected via some pre-configured options. For example, a user can create a MaxCut problem statement on QAOA and ask the Cost Management Tool 665 to return a cost breakdown for four different optimizer choices for quantum backends served by AWS and IMBQ. The Cost Management Tool 665 also estimates the time required to run the computation on the QPU, so the user can reserve computation time accordingly.

[0176] Automated VQA 156 is a software tool that, given a particular problem statement 602, performs an analysis to determine the optimal choice of parameterization and optimizer, along with heuristics that will improve the quality of the optimization results. Automated VQA 156 essentially mimics the work process of a user with sufficient experience in VQA prototyping. An important role in prototyping is played by the statistical analysis of the problem statement 602. For example, characteristics such as the standard deviation or distribution of weights of the problem statement's parameters may require a different parameterization choice or a different optimization strategy.

[0177] In its basic form, Automated VQA 156 takes a problem statement 602 as input and outputs a ranked list of candidate built-in workflows. These statistical techniques are used in Automated VQA 156 in two ways: as tree-based hard-coded rules, or as machine learning models. Hard-coded rules start by computing a set of statistical properties of the problem input and then deterministically select candidate components. Machine learning models, on the other hand, use unsupervised classifiers to label the inputs and supervised learning models to assign ranks to possible combinations of parameterizations and optimizers.

[0178] It can thus be seen that the present embodiment provides a method, system, and kit for quantum optimization cross-backend software development. OpenQAOA according to the present embodiment is a scalable and efficient optimization-specific SDK that is cross-platform, provides numerous parameterization and parameter initialization strategies, provides the ability to prepend initial states to a computation or append states after VQA is completed, and provides a set of GUIs that enable automatic and manual circuit construction (utilizing built-in workflows and workflow factories), built-in circuit compilation, VQA heuristics, resource estimation and profiling, benchmarking, error mitigation, and improved visualization of circuits and results. Furthermore, OpenQAOA according to the present embodiment allows users to quickly and seamlessly estimate the costs associated with running different workflows on different backends, and the functional (modular) design of OpenQAOA allows users to swap out components while only preserving I / O relationships.

[0179] Although exemplary embodiments have been set forth in the foregoing detailed description of the present embodiments, it should be understood that numerous variations exist. Moreover, it should be understood that the exemplary embodiments are merely illustrative and are not intended to limit the scope, applicability, operation, or configuration of the present invention in any way. Rather, the foregoing detailed description provides those skilled in the art with a convenient road map for implementing exemplary embodiments of the present invention, and it should be understood that various changes may be made in the function and arrangement of steps and methods of operation described in the exemplary embodiments without departing from the scope of the present invention as set forth in the appended claims.

Claims

1. 1. A method for constructing a quantum optimization algorithm executable on quantum hardware, comprising: receiving input consisting of a user-defined problem and at least one predefined variational quantum algorithm (VQA) statement; Converting the received input into a workflow; Obtaining an abstract variational quantum algorithm (VQA) representation based on the workflow; Create a backend-specific quantum circuit based on the abstract VQA representation and return an output, where the output consists of optimization results and additional metadata. method.

2. 1. A system for constructing a quantum optimization algorithm, the system comprising: an input module for obtaining an input model; wherein the input model includes a standardized version of a user-defined problem and at least one predefined variational quantum algorithm (VQA) statement; a workflow module that receives the input model as an input; The workflow module includes: translating the input model into a sequence of operations that define a workflow; Obtaining an abstract variational quantum algorithm (VQA) representation based on the workflow; A classical-quantum loop is set up and run, The classical-quantum loop creating and executing an explicit representation of the quantum circuit based on the abstract VQA representation; Optimizing the parameterized variables of such circuits, Once a satisfactory training condition is met, the loop is interrupted. Returns output consisting of optimization results and metadata, system.

3. A set of tools designed to improve the ease of use and performance of quantum optimization algorithms, said tools comprising: a cost management tool that estimates costs associated with a given quantum computation; wherein the costs include financial costs, execution times, and other metrics associated with performing a given quantum computation; an automated VQA, a system that receives a user-defined problem associated with the given quantum computation and evaluates an optimal selection of parameters of a variational quantum algorithm statement for the user-defined problem; A qubit routing tool that compiles variational quantum algorithm expressions with explicitly optimized quantum circuits on the backend. A group of tools that include:

4. 1. A system for building and executing algorithms of the QAOA family, comprising: an input module for obtaining an input; wherein the input includes a standardized version of a user-defined optimization problem and a specification of a QAOA setting; a workflow module that receives the input model; The workflow module includes: Transforming the input into a sequence of operations that defines an abstract workflow independent of the target device on which computations are performed; Set up and run a classical-quantum loop, The classical-quantum loop Creating and executing an explicit representation of a quantum circuit based on the abstract QAOA representation; Optimize the parameterized variables of such a circuit, interrupting the loop when satisfactory training conditions are met, Returning output containing the optimization results and associated metadata; system.

5. 5. The system of claim 4, wherein the input module includes a bank of common optimization problems, each problem capable of being called according to its standard name to reduce user input burden.

6. 5. The system of claim 4, wherein the input module supports the specification of multiple QAOA settings and subsequently enables the creation of multiple corresponding workflows.

7. 5. The system of claim 4, wherein the input module supports specification of a device on which a computation will be performed (a "backend") along with associated properties or characteristics of the backend.

8. 8. The system of claim 7, wherein the workflow module includes an interface for deploying quantum circuits to backend devices including cloud or on-premise quantum computers and remote or local simulators of quantum computing.

9. 9. The system of claim 8, wherein the input module includes a bank of predefined QAOA calculations, each of which can be called by a unique reference, for the purpose of benchmarking the performance of the available backends.

10. 8. The system of claim 7, wherein the workflow module includes an interface to additional modules for selection, mapping and routing of quantum bits.

11. 5. The system of claim 4, wherein the workflow module includes an interface to additional external modules for error mitigation purposes.

12. 5. The system of claim 4, wherein the output of the workflow module (something specific related to a result object).

13. 5. The system of claim 4, wherein the input module supports specification of, and the workflow module supports the use of, dynamic quantum circuit functions such as mid-circuit measurements and feedforward operations.

Images