Conceptio › Archive › Google Patents

Google Patentsopen access

Validator and optimizer for quantum computing simulator — Red Hat, Inc. (US11354460B2)

Red Hat, Inc. · Google Patents

Google Patents · Patents · License: Open Access

patent, google patents, intellectual property, US11354460B2, Red Hat, Inc., Luigi Zuccarelli, en, 2022

ABSTRACT

Abstract

The disclosed techniques relate to validating and optimizing a quantum computing simulator. A quantum computing simulator executes a quantum executable file to obtain a first result. A second result is received from a quantum computer which also computes the quantum executable file. The hardware metadata associated with the quantum computer, and defining hardware conditions during a time in which the quantum executable file was executed to create the second result, is also received. In response to determining a difference between the first result and the second result, updated hardware metadata is created based on the received hardware metadata associated with the quantum computer. The quantum computing simulator performs a second execution of the quantum executable file based at least in part on the updated hardware metadata to obtain a third result.

Description

FIELD OF DISCLOSURE

The present disclosure generally relates to computer systems, in particular to validating and optimizing a quantum computing simulator.

BACKGROUND

Quantum computers perform computations utilizing quantum-mechanical phenomena, such as superposition and entanglement. Unlike classical computers that process data encoded in binary bits, each of which is always in one of two definite states (â0â or â1â), quantum computers process data in units of quantum bits (qubits) that can be in superpositions of states. âSuperpositionâ refers to the ability of each qubit to represent both a â1â and a â0â at the same time. The qubits in a superposition can be correlated with each other (referred to as âentanglementâ). That is, the state of a given qubit (whether it is a â1â or a â0â) can depend on the state of another qubit. A quantum computer with N qubits can be in a superposition of up to 2 N states simultaneously. Compared to the classical computers that can only be in one of these 2 N states at a particular time, quantum computers have higher compute power and may solve difficult problems that are intractable using the classical computers.

SUMMARY

A system of one or more computers can perform particular operations or actions by virtue of having software, firmware hardware, or a combination thereof installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions. One general aspect includes a method including: performing a first execution of a quantum executable file on a quantum computing simulator to obtain a first result; receiving a second result of the quantum executable file computed by a quantum computer; receiving hardware metadata associated with the quantum computer, the hardware metadata defining hardware conditions during a time in which the quantum executable file was executed to create the second result; in response to determining a difference between the first result and the second result, creating updated hardware metadata associated with the quantum computing simulator, the updated hardware metadata based on the received hardware metadata associated with the quantum computer; performing a second execution of the quantum executable file on the quantum computing simulator to obtain a third result, wherein the second execution is based at least in part on the updated hardware metadata.

One general aspect includes a computing system including: a non-transitory memory storing a code coverage module; one or more hardware processors coupled to the non-transitory memory and that execute instructions to cause the system to perform operations comprising: performing a first execution of a quantum executable file on a quantum computing simulator to obtain a first result; receiving a second result of the quantum executable file computed by a quantum computer; receiving hardware metadata associated with the quantum computer, the hardware metadata defining hardware conditions during a time in which the quantum executable file was executed to create the second result; in response to determining a difference between the first result and the second result, creating updated hardware metadata associated with the quantum computing simulator, the updated hardware metadata based on the received hardware metadata associated with the quantum computer; performing a second execution of the quantum executable file on the quantum computing simulator to obtain a third result, wherein the second execution is based at least in part on the updated hardware metadata.

One general aspect includes a non-transitory machine-readable medium having stored thereon machine-readable instructions executable to cause a machine to perform operations including: performing a first execution of a quantum executable file on a quantum computing simulator to obtain a first result; receiving a second result of the quantum executable file computed by a quantum computer; receiving hardware metadata associated with the quantum computer, the hardware metadata defining hardware conditions during a time in which the quantum executable file was executed to create the second result; in response to determining a difference between the first result and the second result, creating updated hardware metadata associated with the quantum computing simulator, the updated hardware metadata based on the received hardware metadata associated with the quantum computer; performing a second execution of the quantum executable file on the quantum computing simulator to obtain a third result, wherein the second execution is based at least in part on the updated hardware metadata.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an organizational diagram illustrating a system 100 to route a request to a node using a consistent hash function taking a session identifier and topology information as inputs, in accordance with various examples of the present disclosure.

FIG. 2 is a flow diagram illustrating a method 200 system to route a request to a node using a consistent hash function taking a session identifier and topology information as inputs, in accordance with various examples of the present disclosure.

FIG. 3 is an organizational diagram illustrating a system 300 for validating a quantum computing simulator result and recommending changes to the quantum executable file and the quantum computing simulator.

FIG. 4 is an organizational diagram illustrating a system 400 for processing and validating a quantum computing simulator result

DETAILED DESCRIPTION

This disclosure relates to computer systems, and more particularly to validating and optimizing a quantum computing simulator. Methods, systems, and instructions stored on computer-readable media for performing such validation and optimization are disclosed.

At present, quantum computers are more expensive to build and to run than classical computers. To make quantum computing accessible to the large majority of users who do not have the means to build or own a quantum computer, large organizations and research institutes have begun to make their quantum computers available over the cloud. In addition, quantum simulators or emulators have also been introduced to help users learn about quantum computing. Essentially, quantum simulators are classical computers that attempt to mimic the functioning of a quantum computer. They may be used, for example, to teach students about the basics of quantum computing. Because quantum simulators run on classical computer hardware, users may safely experiment with different input algorithms in a quantum-like environment without consuming valuable quantum computing resources.

Yet, to date, little to no work has been performed to explain and validate the simulator's results against the actual quantum computer's results. The onus has been on a simulator developer or an end user to interpret any differences in the results, since traditionally, no explanation is given even if the results were to differ significantly. Thus, developers and users are often left to wonder whether the differences between the simulated and actual results were caused by an erroneous input file, an erroneous simulator, an erroneous quantum hardware, or some combination of the three. Because the input file is user-configurable, users often assume that inconsistent results are caused by the user's erroneous programming of the input file. While generally true, some users have instead discovered after hours of tweaking their input files to no avail, that it is the quantum simulator, and not the input file, that has been incorrect programmed.

Such enervating situations may be avoided by a validator service which validates the simulator's result and provides recommendations to the user or the developer to make appropriate changes to the input file or the simulator code to resolve or narrow the differences between the simulator's results and the quantum computer's results. Using such a validation service, a user may be saved from wasting time modifying and troubleshooting an otherwise error-free input file, and a developer may be saved from wasting time modifying and troubleshooting an otherwise error-free simulator.

For example, the validation service may look into the possibility that the difference in the results was caused by an erroneous input file. The validation service may test the quantum computing software using a control input file which had previously produced a simulator result that was consistent with the quantum computer's result. If upon retesting, the same input file produces significantly different simulator results as previous, but similar quantum computer results as previous, then the validator service may conclude that both the input file and the quantum computer are not at issue, but the simulator is. Conversely, if the input file produces similar results in the simulator, but different results in the quantum computer, then the validator service may conclude that both the input file and the quantum computing simulator are not at issue, but that the quantum computer is. Or, the validator service may conclude that the operating conditions of the quantum computer have changed, and the changed conditions have not been accounted for in the quantum computing simulator.

Thus, the validation service may consider multiple possibilities, and guide the developer in his or her troubleshooting efforts of the quantum simulator. For example, the validation service may recommend corrective actions to the developer based on whether the discrepancies in the simulated and actual results were caused by factors âextrinsicâ to the quantum simulator, such as the quantum simulator's failure to apply âhardware metadataââoperating conditions and operating errors representative of the actual conditions of the quantum computing hardwareâor if the discrepancies were a result of âintrinsicâ factors, such as the simulator's incorrect treatment of gate manipulations. The failure of a quantum computing simulator to account for âextrinsicâ factors may occur, for example, when a quantum simulator ignores a quantum computer's operating conditions when processing the QASM file, or when the quantum computing simulator takes the operating conditions into account but assumes conditions that are not actually representative of the operating conditions of the quantum computing hardware.

Often, simulators incorrectly assume optimum hardware metadata, or that the hardware metadata is unchanged from a previous simulation. However, in reality, quantum computers are extremely sensitive to real-world fluctuations in temperature, vibration, electromagnetic fields, etc., and even minute changes to these may affect a quantum computer's results. Thus, simulators should have the same sensitivity to hardware metadata, otherwise, the likelihood that a simulator's results would differ significantly from the quantum computer's may be substantial. As such, if a validator service determines that the hardware metadata have not been properly taken into account, a simulator developer may be guided to include the hardware metadata or adjust the corresponding algorithms in the simulator's code to better account for the hardware metadata. For example, the developer may be guided to apply different types or magnitudes of errors such as gate errors, readout errors, multiqubit errors, or other types of metadata that may affect a quantum computer's results.

Yet, if the differences are caused by âintrinsicâ factors, such as incorrect gate manipulations in the simulator's code, then including or adjusting hardware metadata may not lead to effective reconciliation of the differences in the results. In such cases, the recommended action may not be as simple as changing an error rate or a coherence value, but may require more extensive changes to the simulator's code. This is because incorrect gate manipulations or mis-emulations may arise, for example, from a developer's misunderstanding of the validity of certain quantum gate manipulations or permissible sequences of such gate manipulations. Thus, the validation service may recommend changing, for example, how certain combinations of gate manipulations are performed by the simulator by identifying relevant portions of the simulator's code corresponding to the erroneous gate manipulations.

Thus, it would be advantageous for a developer to know whether the differences in the results are caused by issues that are âextrinsicâ or âintrinsicâ to the quantum computing simulator, as such knowledge would allow the developer to determine what sorts of changes, if any, need to be made to the simulator's code. Additionally, informing the users that the simulator, and not the input file, is at fault would increase the users' confidence in the accuracy of the quantum computer's results, even if those results were to differ significantly from the simulator's. Moreover, users would not waste time, money, and effort unnecessarily tweaking and re-running their input files through costly quantum hardware to verify or reconcile simulator results, if the users are informed by the validator service that the simulator is erroneous. The disclosed techniques thus aid users and developers in interpreting differences in quantum simulator and quantum computer results, while providing actionable insights and helpful recommendations to developers to rectify the âextrinsicâ or âintrinsicâ portions of the simulator's code.

FIG. 1 is an organizational diagram illustrating a system 100 for validating a quantum computing simulator result and updating hardware metadata of the quantum computing simulator, in accordance with various examples of the present disclosure.

The system 100 includes memory 102 and one or more hardware processors 104 . The memory 102 may be a non-transitory memory. The memory 102 may be structured to include at least one machine-readable storage medium on which is stored one or more set of instructions (e.g., software) including any one or more of the methodologies or functions described herein. The memory 102 may be structured to include one or more of a read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (DFRAM), double data rate (DDR SDRAM), or DRAM (RDRAM), and so forth, static memory (e.g., flash memory, static random access memory (SRAM), and so forth), and a data storage device (e.g., a hard disk drive (HDD), solid state drive (SSD), and so forth). Accordingly, any of the operations, steps, and actions of the methods described herein may be implemented using corresponding machine-readable instructions stored on or in the memory 102 that are executable by the hardware processor 104 .

In more detail regarding the hardware processor 104 , the hardware processor 104 is structured to include one or more general-purpose processing devices such as a microprocessor, central processing unit (CPU), and the like. More particularly, the <figure-callout id="104" label="hardware processor" filenames="US11354460-20220607-D00001

FIELD OF DISCLOSURE

The present disclosure generally relates to computer systems, in particular to validating and optimizing a quantum computing simulator.

BACKGROUND

SUMMARY

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 4 is an organizational diagram illustrating a system 400 for processing and validating a quantum computing simulator result

DETAILED DESCRIPTION

In more detail regarding the hardware processor 104 , the hardware processor 104 is structured to include one or more general-purpose processing devices such as a microprocessor, central processing unit (CPU), and the like. More particularly, the hardware processor 104 may include a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. In some examples, the hardware processor 104 is structured to include one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, and so forth. The hardware processor executes instructions for performing the operations, steps, and actions discussed herein.

The memory 102 is structured to store a first result 112 and a second result 114 . The first result 112 may be obtained by executing a quantum executable file 106 , such as an appropriately parsed quantum assembly language (QASM) input file, using a quantum computing simulator 108 A. The second result 114 may be obtained by executing the quantum executable file 106 using a quantum computer 110 , which may be located remotely from the system 100 but may still be accessible to the system 100 via a network such as the internet. The system 100 may include network interfaces, components, and protocols which the system 100 may use to communicate with the quantum computer 110 over the network. Additionally, the quantum computer 110 may include hardware metadata 116 . Hardware metadata 116 may include operating parameters or other parameters indicative of the operating conditions of the quantum computer 110 . For example, hardware metadata 116 may include a frequency, a coherence time, a gate error, a readout error, and a multiqubit error.

The quantum executable file 106 may include or encode a quantum algorithm such as a Turing complete algorithm. Such algorithms may be processed by a quantum computing simulator 108 A or a quantum computer 110 . The quantum executable file 106 may be stored on the system 100 , or if not stored on the system 100 , may be remotely accessible to the system 100 via a network. The system 100 may upload the quantum executable file 106 to the quantum computer 110 , if, for example, the quantum executable file 106 is locally stored on the system 100 but the quantum computer 110 is remotely located from the system 100 . The uploading may be via a user interface, such as a graphical user interface or a command line interface accessible via a website associated with the quantum computer 110 .

The quantum executable file 106 may be processed by the quantum computer 110 using quantum hardware. For example, the quantum computer 110 may execute the Turing complete algorithm included in the quantum executable file 106 to produce second result 114 . The second result 114 as generated by the quantum computer 110 may be in a .CSV (comma separated values) file format or any other file format. In some examples, the second result 114 is converted from its original format to another file format used by the quantum computing simulator 108 A or a validator service. In some examples, the .CSV file format of the first result 112 is converted to a JavaScript Object Notation (JSON) file format.

The quantum executable file 106 may also be processed by a quantum computing simulator 108 A. In some examples, prior to processing by the quantum computing simulator 108 A, the system 100 may pass the quantum executable file 106 through an interpreter, such as a QASM interpreter. However, in some examples, interpretation may not be required. The interpreter may be virtualized in a first virtual environment, such as a container, and include a quantum development kit, an operating system image, and a runtime. An example of a quantum development kit is QISKit, available from International Business Machine Corp. (IBM) of Armonk, N.Y. In some examples, the operating system image includes a REDHAT FEDORA LINUX image, available from Red Hat, Inc. of Raleigh, N.C. In some examples, the runtime includes a PYTHON runtime, available from the Python Software Foundation at www.python.org. In some examples, the container is a DOCKER container, available from Docker, Inc. of San Francisco, Calif. Other types of quantum development kits, operating systems, runtimes, and containers or virtual operating environments may be used. The interpreter interprets the quantum executable file 106 (e.g., a QASM file) and outputs a file in a format that can be processed by the quantum computing simulator 108 A. For example, the output file may be a JSON file. The output file is thus a representation of the quantum algorithm in a non-QASM format. In some examples, the output file includes the hardware metadata contained in the quantum executable file 106 and other metadata useful for further processing, e.g., qubit size, simulator target, etc.

If interpretation was performed, the output file from the interpreter is fed into quantum computing simulator 108 A. If no interpretation was required, the quantum executable file 106 may be fed into the quantum computing simulator 108 A. In some examples, the quantum computing simulator 108 A is virtualized in a second virtual environment, such as a container. The second virtual environment may be the same as, or different from, the first virtual environment. However, in some examples, the quantum computing simulator 108 A is not virtualized. The second virtual environment may include a quantum simulator such as a C++ quantum simulator, an operating system image, and all supporting libraries required to support the running of the simulator based on the operating system image. Generally, a quantum simulator allows real quantum hardware, such as quantum computer 110 , to be simulated on classical computers. Thus, any type of quantum simulator, in addition to C++ quantum simulators, may be used. The quantum computing simulator 108 A processes the interpreted quantum executable file (if interpretation was required) or the quantum executable file 106 (if interpretation was not required) to generate a quantum simulator output file. The quantum simulator output file includes first result 112 , which may include a single result, for example, if the algorithm was executed once, or a set of results, for example, if the algorithm was executed more than once. If the first result 112 matches the second result 114 , then the system 100 may indicate that the algorithm in the quantum executable file 106 is capable of being run on the quantum computer 110 .

However, if the first result 112 does not match the second result 114 , i.e., there is a difference 118 between the first result 112 and the second result 114 , then the first result 112 and the second result 114 may be passed to a service or program, such as a validator service, to compare the first result 112 with the second result 114 . The validator service may be virtualized in a third virtual environment, such as a container. The third virtual environment may be the same as, or different from, the first and/or the second virtual environments. The third virtual environment may include a quantum development kit, an operating system image, a runtime, and the validator service. Thus, the first result 112 and the second result 114 may be fed into the third virtual environment for comparison. The validator service may first create a list of the differences between the first result 112 and the second result 114 . In some examples, the first result 112 and the second result 114 may be expressed as tuples of the observed quantum states and the counts of the observed states. Thus, the list of the differences may include one or more of such differing tuples.

Based on the comparison, the validator service may recommend changes to the gates corresponding to the differing tuples. For example, if a significant number of tuples differed only in the third qubit, then the validator service may recommend changes to the gates applied to the third qubit. The recommended gate changes may be made on the quantum executable file 106 , and the updated quantum executable file may be reprocessed by the quantum simulator 108 A to generate a third result 122 . The third result 122 may include a results set containing one or more tuples. The validator service may compare the third result 122 with the second result 114 , and determine that the third result 122 more closely matches with the second result 114 . In some examples, the third result 122 is also more efficiently generated than the second result 114 because of the recommended gate changes. For example, the validator service may have analyzed the gate sequences in the executable file 106 and recommended more efficient gate sequences that perform the same function. In some examples, the recommended gate sequences use fewer gates in the sequence or less computationally-intensive gates to perform the same function.

In some examples, the validator service also compares the hardware metadata (if any) applied by the quantum computing simulator 108 A against hardware metadata 116 of the quantum computer 110 . In some examples, the hardware metadata 116 includes the operating conditions, error rates, coherence times, frequencies, etc., of the quantum computer 110 while it was processing the quantum executable file 106 . If differences exist between the hardware metadata applied by the quantum computing simulator 108 A and the hardware metadata 116 of the quantum computer 110 , the validator service may create new or updated hardware metadata 120 based on the hardware metadata 116 . The quantum computing simulator 108 A may reprocess the quantum executable file 106 using the updated hardware metadata 120 . For ease of reference, a quantum computing simulator applying âoldâ hardware metadata may be referred to as quantum computing simulator 108 A, while a quantum computing simulator applying the updated hardware metadata 120 may be referred to as quantum computing simulator 108 B.

Thus, in generating the third result 122 , the quantum computing simulator 108 B may apply the updated hardware metadata 120 , such as a new or updated frequency, a new or updated coherence time, a new or updated gate error, a new or updated readout error, a new or updated multiqubit error, etc. In some examples, the third result 122 more closely matches with the second result 114 as a result of the updated hardware metadata 120 . In some examples, the third result 122 is computed more efficiently than the first result 112 . For instance, the third result 122 may be computed more efficiently than the first result 112 when computations using the updated hardware metadata 120 is less complex than using hardware metadata 116 . In some examples, the computations may be less complex because the hardware metadata 120 may include less parameters, and therefore fewer calculations may be performed.

The first, second, and third virtual environments may form a virtual ecosystem and may be backed by a continuous integration and delivery (CI/CD) service powered by Jenkins. The virtual ecosystem may be run on local machines or on an online platform such as RED HAT OPENSHIFT, available from Red Hat of Raleigh, N.C. The integration of the first, second, and third virtual environments through the pipeline means that once the quantum executable file 106 is loaded into the first virtual environment for interpretation, an automated chain of events is begun in that the output from the first virtual environment is fed into the second virtual environment for simulation, and the output of the simulation is fed into the third virtual environment for comparison by the validator service. By using application programming interfaces of the quantum computer, even the loading of the quantum executable file 106 into the quantum computer 110 may be automated, for example, by a scheduler. The output directory for the second result 114 generated by the quantum computer 110 may be monitored, such that second result 114 may be fed into the third virtual environment on detection of the results in the directory. Therefore, system 100 is a novel, fully automated development and test environment which bridges Classical and Quantum computing with optimizations at the simulator level.

FIG. 2 is a flow diagram illustrating a method 200 to validate a quantum computing simulator result and to update hardware metadata of the quantum computing simulator, in accordance with various examples of the present disclosure. Method 200 may be performed by executing computer-readable instructions that are stored in memory 102 using one or more hardware processors 104 described with respect to FIG. 1 . Additional actions may be provided before, during, and after the steps of method 200 , and some of the actions described may be replaced, eliminated and/or re-ordered for other examples of the method 200 . For example, method 200 may be performed in conjunction with

systems

100 , 300 , and 400 described with respect to FIGS. 1, 3, and 4 .

At action 202 , a first execution of a quantum executable file is performed on a quantum computing simulator to obtain a first result. As described with respect to FIG. 1 , the quantum computing simulator may be virtualized in an environment such as a container. The quantum computing simulator virtual environment may include a C++ quantum simulator, an operating system image, and all supporting libraries required to run the C++ quantum simulator. The quantum computing simulator container may output a JSON file which includes a results set. This results set may be referred to as the first result.

In some examples, the quantum executable file may include a Turing complete algorithm. In some examples, the quantum computing simulator may be a C++ quantum simulator. Thus, in some examples, a quantum executable file which includes a Turing complete algorithm may be fed into or processed by a C++ quantum simulator. However, in some examples, the quantum executable file which may be a QASM file, may not be immediately processable by the quantum simulator. Thus, in some examples, prior to processing the quantum executable file by the quantum computing simulator, the quantum executable file is interpreted using an interpreter described with respect to FIG. 1 . The interpreted quantum executable file may then be fed into a quantum computing simulator, which may be written in or be compatible with other programming languages including: Collaborative Application Markup Language (CAML), Objective CAML (OCaml), F #, JAVA, JAVASCRIPT, JULIA, MAPLE, MATHEMATICA, MAXIMA, MATLAB, OCTAVE, .NET, PERL/PHP, PYTHON, RUST, Scheme, Haskell, LISP, and Meta Language (ML).

In some examples, a command line interface or a graphical user interface (GUI) is provided to the user to allow the user to interact with the quantum computing simulator. In some examples, the quantum computing simulator may be located remotely from the system 100 and interaction with the quantum computing simulator may be performed across a network. For example, an online-based or cloud-based quantum computing simulator may still be accessible to the system 100 via the internet. In some examples, the quantum computing simulator may be local or locally accessible to the system 100 over a bus or local network.

At action 204 , a second result of the execution of the quantum executable file is obtained by processing the quantum executable file using a quantum computer. The quantum executable file that is executed by the quantum computer contains the same algorithm as the quantum executable file that was executed by the quantum computing simulator at action 202 . In some examples, the quantum executable file that is executed by the quantum computer may differ in form but not function from the quantum executable file that was executed by the quantum computing simulator at action 202 . For example, the quantum executable file may be formatted differently or be written in a different programming language for the quantum computing simulator as for the quantum computer. However, the quantum algorithm that is executed by the quantum computing simulator and the quantum computer are the same. Like the quantum computing simulator, the quantum computer may be locally- or remotely-located. Correspondingly, the second result may be received across local or network interfaces. One example of a quantum computer is the IBM Q quantum computer, a cloud-based quantum computer accessible via the internet at the IBM Q EXPERIENCE website. Quantum computers are also available from D-Wave Systems Inc. of Burnaby, British Columbia, Canada.

In some examples, the second result, i.e., the result generated by the quantum computer, may be included in file formats suitable for storage in databases or other data structures. For example, the second result may be included in a .CSV file output by the quantum computer after executing the quantum executable file. Thus, the second result may be delimited by commas or other suitable characters, and may be expressed or capable of being expressed in rows and columns. In some examples, the second result is converted from one file format to another (e.g., .CSV to JSON). The conversion may be performed using suitable converters, such as a .CSV to JSON converter.

At action 206 , the hardware metadata associated with the quantum computer is received. As earlier described, the hardware metadata may include parameters that impact the performance of the quantum computing hardware, such as frequencies, coherence times, error rates, etc. In some examples, the hardware metadata is received together with, or may be a part of, the second result. For example, the hardware metadata may be stored in the same file or data structure as the second result. In some examples, the hardware metadata may be stored in a different file or data structure as the second result. In some examples, the hardware metadata may be captured in one or more rows of a .CSV file, and the values corresponding to different parameters may be offset by commas. In some examples, the hardware metadata defines or includes the hardware conditions while the quantum computer was executing the quantum executable file to create the second result. In some examples, the average hardware conditions during the execution of the quantum executable file are taken as the hardware metadata of the quantum computer. In some examples, the most optimal hardware conditions during the execution of the quantum executable file are taken as the hardware metadata of the quantum computer. In some examples, the least optimal hardware conditions during the execution of the quantum executable file are taken as the hardware metadata of the quantum computer.

At action 208 , updated hardware metadata is created. In some examples, the updated hardware metadata is created in response to a determination of a difference between the first result and the second result. In some examples, the updated hardware metadata is created in response to a determination of a difference between the hardware metadata used by the quantum computing simulator and the hardware metadata used by the quantum computer. In some examples, the hardware metadata used by the quantum computing simulator is updated based on the received hardware metadata associated with the quantum computer, such as the received hardware metadata of action 206 . For example, it may be determined that the coherence time used in the quantum computing simulator is different than the coherence time of the quantum computer when the quantum computer was executing the quantum executable file. Thus, updated hardware metadata may be created by replacing the quantum computing simulator's coherence time with the quantum computer's coherence time. In some examples, the updated hardware metadata may be created by introducing new parameters into the set of hardware metadata used by the quantum computing simulator to generate the first result. For example, if the quantum computing simulator did not take into account multiqubit errors in generating the first result, but multiqubit errors were in fact present when the quantum computer generated the second result, then updated metadata hardware with the multiqubit errors may be created.

In some examples, a validator service is used to compare the hardware metadata used by the quantum computing simulator (if any) with the received hardware metadata associated with the quantum computer. In some examples, the validator service is provisioned in a virtual environment, such as a container. The virtual environment may include a quantum development kit, an operating system image, a runtime, and the validator service. Thus, in some examples, the hardware metadata associated with the quantum computing simulator and the hardware metadata associated with the quantum computer may be compared in a virtual environment. Nevertheless, where the validator service is not virtualized the comparison may be performed in a non-virtualized environment.

Changes to the hardware metadata used by the quantum computing simulator may be recommended, for example by a validator service, based on the comparison of the hardware metadata. In some examples, the recommended changes to the hardware metadata require further authorization before the changes are implemented. Such authorization may be provided by a user. In some examples, the validator service may automatically update the quantum computing simulator's hardware metadata without awaiting user authorization. For example, if the simulator uses a separate hardware metadata file to load hardware metadata into the simulator for execution, then the validator service may automatically update the separate hardware metadata file. If the simulator parses hardware metadata from the quantum executable file, the validator service may update the hardware metadata in the quantum executable file.

In some examples, the validator service includes a version control system that is able to generate differences or âcliffsâ between two files, such as a diff between a first result file and a second result file, or a diff between a first hardware metadata file and a second hardware metadata file. The validator service may create different versions of the updated hardware metadata file in the version control system, and use the version control system's change log functions to record the differences between the various versions. In some examples, the updated hardware metadata file may be a JSON file or other file format compatible for processing by the quantum computing simulator.

In some examples where the updated hardware metadata includes new or different parameters, the validator service may recommend changes to the quantum computing simulator's code to factor in the new p

CLAIMS

Claims ( 20 )

What is claimed is:

1. A method comprising:

performing a first execution of a quantum executable file on a quantum computing simulator to obtain a first result;

receiving a second result of the quantum executable file computed by a quantum computer;

receiving hardware metadata associated with the quantum computer, the hardware metadata defining hardware conditions during a time in which the quantum executable file was executed to create the second result;

in response to determining a difference between the first result and the second result, creating updated hardware metadata associated with the quantum computing simulator, the updated hardware metadata based on the received hardware metadata associated with the quantum computer; and

performing a second execution of the quantum executable file on the quantum computing simulator to obtain a third result, wherein the second execution is based at least in part on the updated hardware metadata.

2. The method of claim 1 , further comprising:

determining that the difference between the first result and the second result exceeds a predetermined value.

3. The method of claim 1 , further comprising:

in response to the determining a difference between the first result and the second result, determining a difference in quantum gate manipulation between the quantum computer and the quantum computing simulator; and

recommending a change to the quantum gate manipulation of the quantum computing simulator.

4. The method of claim 3 , further comprising:

modifying the quantum gate manipulation of the quantum computing simulator based on the recommending, and wherein the second execution is further based at least in part on the modified quantum gate manipulation.

5. The method of claim 4 , wherein the updated hardware metadata or modified quantum gate manipulation are optimized to use fewer computational resources.

6. The method of claim 1 , wherein the second result is repackaged to exclude the hardware metadata associated with the quantum computer.

7. The method of claim 6 , wherein the determining the difference between the first result and the second result includes determining a difference between the first result and the repackaged second result.

8. The method of claim 1 , wherein the determining the difference between the first result and the second result includes determining a difference between hardware metadata associated with the quantum computing simulator and the received hardware metadata associated with the quantum computer.

9. The method of claim 1 , further comprising formatting the first result and the second result as text with object notation before the determining the difference between the first result and the second result.

10. The method of claim 1 , further comprising applying a map reduce function on the first result and the second result before the determining the difference between the first result and the second result.

11. The method of claim 10 , wherein the determining the difference between the first result and the second result includes determining a difference between the map-reduced first result and the map-reduced second result.

12. The method of claim 1 , wherein the updated hardware metadata associated with the quantum computing simulator includes data selected from the group consisting of: a frequency; a coherence time; a gate error; a readout error; and a multiqubit error.

13. A system comprising:

a non-transitory memory storing a code coverage module;

one or more hardware processors coupled to the non-transitory memory and that execute instructions to cause the system to perform operations comprising:

performing a first execution of a quantum executable file on a quantum computing simulator to obtain a first result;

receiving a second result of the quantum executable file computed by a quantum computer;

receiving hardware metadata associated with the quantum computer, the hardware metadata defining operating conditions of the quantum computer while executing the quantum executable file to generate the second result;

in response to determining a difference between the first result and the second result, creating updated hardware metadata associated with the quantum computing simulator based on the received hardware metadata associated with the quantum computer; and

performing a second execution of the quantum executable file on the quantum computing simulator based at least in part on the updated hardware metadata to obtain a third result.

14. The system of claim 13 , further comprising:

determining that the difference between the first result and the second result exceeds a predetermined value.

15. The system of claim 13 , further comprising:

recommending a change to the quantum gate manipulation of the quantum computing simulator.

16. The system of claim 15 , further comprising:

17. The system of claim 16 , wherein the updated hardware metadata or modified quantum gate manipulation are optimized to use fewer computational resources.

18. A non-transitory machine-readable medium having stored thereon machine-readable instructions executable to cause a machine to perform operations comprising:

performing a first execution of a quantum executable file on a quantum computing simulator to obtain a first result;

performing a second execution of the quantum executable file on a quantum computer to obtain a second result, wherein the second result includes hardware metadata associated with the quantum computer during the second execution;

in response to determining a difference between the first result and the second result, updating hardware metadata associated with the quantum computing simulator based on the hardware metadata associated with the quantum computer; and

performing a third execution of the quantum executable file on the quantum computing simulator with the updated hardware metadata to obtain a third result.

19. The non-transitory machine-readable medium of claim 18 , wherein the determining the difference between the first result and the second result includes determining a difference between the hardware metadata associated with the quantum computing simulator and the hardware metadata associated with the quantum computer.

20. The non-transitory machine-readable medium of claim 19 , wherein the hardware metadata associated with the quantum computing simulator and the hardware metadata associated with the quantum computer is map reduced before the determining the difference between the hardware metadata associated with the quantum computing simulator and the hardware metadata associated with the quantum computer.

US16/162,049

2018-10-16

Validator and optimizer for quantum computing simulator

Active

2040-12-18

US11354460B2

( en )

Priority Applications (1)

Application Number

Priority Date

Filing Date

Title

US16/162,049

US11354460B2

( en )

2018-10-16

Validator and optimizer for quantum computing simulator

Applications Claiming Priority (1)

Application Number

Priority Date

Filing Date

Title

US16/162,049

US11354460B2

( en )

2018-10-16

Validator and optimizer for quantum computing simulator

Publications (2)

Publication Number

Publication Date

US20200117764A1

US20200117764A1 ( en )

2020-04-16

US11354460B2

true

US11354460B2 ( en )

2022-06-07

Family

ID=70162011

Family Applications (1)

Application Number

Title

Priority Date

Filing Date

US16/162,049

Active

2040-12-18

US11354460B2

( en )

2018-10-16

Validator and optimizer for quantum computing simulator

Country Status (1)

Country

Link

( 1 )

US11354460B2

( en )

Cited By (2)

* Cited by examiner, â Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US20220308923A1

( en )

2019-07-31

2022-09-29

Red Hat, Inc.

Rule-driven service management using entangled qubits in quantum computing systems

US20220351062A1

( en )

2021-04-29

2022-11-03

Red Hat, Inc.

Generating quantum service definitions from executing quantum services

Families Citing this family (19)

* Cited by examiner, â Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US11580433B2

( en )

2019-03-09

2023-02-14

International Business Machines Corporation

Validating and estimating runtime for quantum algorithms

US11620569B2

( en )

2019-04-26

2023-04-04

International Business Machines Corporation

Machine learning quantum algorithm validator

US11314535B2

( en )

2019-06-21

2022-04-26

International Business Machines Corporation

Quantum data result streaming

US12530222B1

( en )

2020-02-10

2026-01-20

Rigetti & Co, Llc

Workload orchestration in hybrid quantum/classical computing systems

US11507397B2

( en )

2020-11-05

2022-11-22

Jpmorgan Chase Bank, N.A.

Systems and methods for zero-footprint and safe execution of quantum computing programs

US11836108B2

( en )

2021-01-25

2023-12-05

Red Hat, Inc.

Performing file differential operations on quantum files in a state of superposition

CN114912620B

( en )

2021-02-07

2025-06-13

æ¬æºéåè®¡ç®ç§æï¼åè¥ï¼è¡ä»½æéå¬å¸

Quantum computer operating system, quantum computer and readable storage medium

US11693694B2

( en )

2021-03-29

2023-07-04

Red Hat, Inc.

Migrating quantum services from quantum computing devices to quantum simulators

CN113609066B

( en )

2021-06-25

2024-04-12

æ·±å³å¤§å¦

Multi-core RISCV-CPU simulator based on Rust

US12223239B2

( en )

2021-06-28

2025-02-11

Red Hat, Inc.

Simulating operating conditions of quantum computing devices

US11823011B2

( en )

2021-07-28

2023-11-21

Red Hat, Inc.

Analyzing execution of quantum services using quantum computing devices and quantum simulators

JP7658849B2

( en )

2021-08-17

2025-04-08

æ ªå¼ä¼ç¤¾æ¥ç«è£½ä½æ

Quantum computer system and method for operating the quantum computer system

US12524700B2

( en )

2022-01-27

2026-01-13

Red Hat, Inc.

Generating validated quantum function invocations

US11995485B2

( en )

2022-05-12

2024-05-28

Red Hat, Inc.

Automatically switching between quantum services and classical services based on detected events

US20240020561A1

( en )

2022-07-13

2024-01-18

Red Hat, Inc.

Quantum simulator network for simulating a quantum service

US12197315B2

( en )

2022-07-14

2025-01-14

Red Hat, Inc.

Software testing using a quantum computer system

US12585975B2

( en )

2022-08-17

2026-03-24

Red Hat, LLC

State maps for quantum computing

US20240104415A1

( en )

2022-09-26

2024-03-28

CogniFrame Inc

System and method for improving the efficiency of inputs to quantum computational devices

US20240232670A9

( en )

2022-10-24

2024-07-11

Red Hat, Inc.

Production to staging isolation zone creation

Citations (7)

* Cited by examiner, â Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US20070239366A1

( en )

2004-06-05

2007-10-11

Hilton Jeremy P

Hybrid classical-quantum computer architecture for molecular modeling

US20090031308A1

( en )

2007-07-23

2009-01-29

International Business Mashines Corporation

Method And Apparatus For Executing Multiple Simulations on a Supercomputer

US8832165B2

( en )

2007-12-12

2014-09-09

Lockheed Martin Corporation

Computer systems and methods for quantum verification and validation

US20170351967A1

( en )

2016-06-02

2017-12-07

Google Inc.

Training quantum evolutions using sublogical controls

CN107683460A

( en )

2015-05-05

2018-02-09

A QUANTON representation for simulating quantum-like computing on conventional processors

US20190042677A1

( en )

2018-05-05

2019-02-07

Anne MATSUURA

Apparatus and method for quantum computing performance simulation

US20190220782A1

( en )

2018-01-18

2019-07-18

International Business Machines Corporation

Simplified quantum programming

2018

2018-10-16

US16/162,049

patent/US11354460B2/en

active

Active

Patent Citations (7)

* Cited by examiner, â Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US20070239366A1

( en )

2004-06-05

2007-10-11

Hilton Jeremy P

Hybrid classical-quantum computer architecture for molecular modeling

US20090031308A1

( en )

2007-07-23

2009-01-29

International Business Mashines Corporation

Method And Apparatus For Executing Multiple Simulations on a Supercomputer

US8832165B2

( en )

2007-12-12

2014-09-09

Lockheed Martin Corporation

Computer systems and methods for quantum verification and validation

CN107683460A

( en )

2015-05-05

2018-02-09

A QUANTON representation for simulating quantum-like computing on conventional processors

US20170351967A1

( en )

2016-06-02

2017-12-07

Google Inc.

Training quantum evolutions using sublogical controls

US20190220782A1

( en )

2018-01-18

2019-07-18

International Business Machines Corporation

Simplified quantum programming

US20190042677A1

( en )

2018-05-05

2019-02-07

Anne MATSUURA

Apparatus and method for quantum computing performance simulation

Non-Patent Citations (6)

* Cited by examiner, â Cited by third party

Title

A C++ Quantum Circuit Simulator with Realistic Noise Oct. 16, 2018.

Classical Drivers and Machines Dec. 10, 2017.

Klusch, Matthias et al., " Programming and Simulation of Quantum Search Agents ", 2007, IEEE. (Year: 2007).

Lanzagorta, Marco et al., " Hybrid Quantum-Classical Computing with Applications to Computer Graphics ", Jul. 31, 2005, ACM Siggraph, ACM. (Year: 2005).

Programming and Simulation of Quantum Search Agents Nov. 2007.

Simulation of Grover's Algorithm Quantum Search in a Classical Computer Dec. 9, 2010.

Cited By (4)

* Cited by examiner, â Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US20220308923A1

( en )

2019-07-31

2022-09-29

Red Hat, Inc.

Rule-driven service management using entangled qubits in quantum computing systems

US12056523B2

( en )

2019-07-31

2024-08-06

Red Hat, Inc.

Rule-driven service management using entangled qubits in quantum computing systems

US20220351062A1

( en )

2021-04-29

2022-11-03

Red Hat, Inc.

Generating quantum service definitions from executing quantum services

US12204986B2

( en )

2021-04-29

2025-01-21

Red Hat, Inc.

Generating quantum service definitions from executing quantum services

Also Published As

Publication number

Publication date

US20200117764A1

( en )

2020-04-16

Validator and optimizer for quantum computing simulator — Red Hat, Inc. (US11354460B2)

Related documents