Cloud-based quantum computing is the invocation of quantum emulators, simulators or processors through the cloud. Increasingly, cloud services are being looked on as the method for providing access to quantum processing.
Cloud-based quantum computing can be used in several contexts, such as:
- Teaching: teachers can use cloud-based quantum computing to help their students better understand quantum mechanics, as well as implement and test quantum algorithms;
- Research: scientists can use cloud-based quantum resources to test quantum information theories,perform experiments, …
Major actors are prepping their solutions. We introduced in previous posts Microsoft’s Quantum Development Kit and Q#, capable of processing on a simulator up to 32 qubits locally and up to 40 qubits on the Azure Cloud. Microsoft is aiming at cloud services based on real life topological quantum computers available (hopefully) in a close future.
We introduced the Strawberry Field software platform for continuous variable quantum optical circuits in our previous post on photonic quantum computing.
In this post, we will have a look at Big Blue‘s solutions: IBM Q > Experience is a cloud-based platform that gives users access to a set of actual quantum processors.
Open QASM
The Open Quantum Assembly Language (or Open QASM) is an intermediate representation for quantum instructions. Its source code was released as part of IBM’s Quantum Information Software Kit (QISKit) for use with their IBM Q Experience cloud quantum computing platform. It is a simple language for describing acyclic quantum circuits composed of single or mutliple qubits and single or multiple quantum gates.
IBM’s model of program execution does not allow fully general classical computations in the loop with quantum computations because qubits remain coherent for a limited time. Quantum programs are broken into distinct circuits whose quantum outputs cannot be carried over into the next circuit.
Classical computation is done between quantum circuit execution. Indeed, generally speaking, quantum programs require a coordination between the quantum and classical parts of the computation. Let’s identify the different phases needed to process such a general quantum program:
- Compilation: this offline phase takes place on a classical computer. The input is a source code describing a quantum algorithm. The output is a combined quantum/classical program expressed using a high level Intermediate Representation (IR);
- Circuit generation: this online phase takes place on a classical computer (as some interaction with the quantum computer may occur). The input is a quantum/classical program expressed using a high level IR. The output is a collection of quantum circuits together with associated classical control instructions and classical object code needed at run-time. The output of circuit generation is expressed using a quantum circuit IR.
- Execution: the execution phase takes place on a quantum computer in real-time environment. The input comes from the previous phase and is processed by a high-level controller (a virtual machine) into a stream of real-time instructions in a low-level format that corresponds to physical operations. The output of circuit execution is a collection of processed measurement results.
- Post-processing: this last phase takes place on a classical computer all real-time processing is complete. The output is intermediate results for further circuit generation and/or the final result of the quantum computation.
The syntax of the human-readable form of Open QASM has elements of C and assembly languages. Open QASM generic grammar goes as follows:
Namely, Open QASM language statements are:
| Statement | Description |
| OPENQASM 2.0; | Denote a file in Open QASM format |
| creg name[size]; | Declare a named register of qubits |
| creg name[size]; | Declare a named register of bits |
| include “filename”; | Open and parse another source file |
| gate name(params) qargs { body } | Declare a unitary gate |
| opaque name(params) qargs; | Declare an opaque gate |
| // comment text | Comment a line of text |
| U(theta,phi,lambda) qubit|qreg; | Apply built-in single qubit gate(s) |
| CX qubit|qreg,qubit|qreg; | Apply built-in CNOT gate(s) |
| measure qubit|qreg -> bit|creg; | Make measurement(s) in Z basis |
| reset qubit|qreg; | Prepare qubit(s) in |0i |
| gatename(params) qargs; | Apply a user-defined unitary gate |
| if(creg==int) qop; | Conditionally apply quantum operation |
| barrier qargs; | Prevent transformations across this source line |
Based on these statements, the Quantum Experience standard header (“qelib1.inc”) defines common gates such as Hadamard, Pauli X,Y,Z, Rotation X,Y,Z, Toffoli, etc. A typical Open QASM quantum teleportation algorithm reads :
Detailed description of the language is available in IBM’s 2017 paper [PDF} and on GitHub.
QISKit
IBM’s Quantum Information Software Kit (QISKit) is an open-source quantum computing framework, sitting on top of Open QASM, which sits on top of the hardware. Its goal is to be accessible to people with many backgrounds: quantum researchers and other scientists, teachers, developers, and general tech enthusiasts.
QISKit is a collection of software for working with short depth quantum circuits and building near term applications and experiments on quantum computers. In QISKit, a quantum program is an array of quantum circuits. The program workflow consists of three stages:
- Build allows you to make different quantum circuits that represent the problem you are solving.
- Compile allows you to rewrite them to run on different backends (simulators or real quantum chips)
- Run launches the jobs. After the jobs have been run, the data is collected.
QISKit consists of four foundational ‘elements’:
- Terra: QISKit Terra, the ‘earth’ element, is the foundation on which the rest of the software lies. It provides the foundational roots for our software stack. Within Terra is a set of tools for composing quantum programs at the level of circuits and pulses, optimizing them for the constraints of a particular physical quantum processor, and managing the batched execution of experiments on remote-access backends. Terra is available on GitHub.
- Aqua: QISKit Aqua, the ‘water’ element, is the element of life. To make quantum computing live up to its expectations, one needs to find real-world applications. Aqua is where algorithms for noisy intermediate-scale quantum computers are built. These algorithms can be used to build applications for quantum computing. It is accessible to domain experts in chemistry, optimization or AI, who want to explore the benefits of using quantum computers as accelerators for specific computational tasks, without needing to worry about how to translate the problem into the language of quantum machines. Aqua is available on GitHub.
- Ignis: QISKit Ignis, the ‘fire’ element, is dedicated to fighting noise and errors. This includes better characterization of errors, improving gates, and computing in the presence of noise. Ignis is meant for those who want to design quantum error correction codes, or who wish to study ways to characterize errors through methods such as tomography, or even to find a better way for using gates by exploring dynamical decoupling and optimal control. At the time of writing, Ignis is not yet released (though part of the code is included into Terra libraries).
- Aer: QISKit Aer, the ‘air’ element, permeates all Qiskit elements. To speed up development of quantum computers one needs better simulators, emulators and debuggers. Aer is not yet released. It will help us understand the limits of classical processors by demonstrating to what extent they can mimic quantum computation.
QISKit’s documentation is available online.
Quantum Composer
The Quantum Composer sits on top of QISKit. It is a graphic user interface designed to allow users to construct various quantum algorithms or run other quantum experiments. Users may see the results of their quantum algorithms by either running it on a real quantum processor and using “units” or by using a simulator.
Algorithms developed in the Quantum Composer are referred to as a “quantum score”. In such a quantum score, just as with music, time progresses from left to right. Each line represents a qubit (as well as what happens to that qubit over time). A quantum circuit begins by preparing the qubits in well-defined states (
Quantum gates are represented by square boxes on the score. Once the score is populated with the required gates, the quantum algorithm can be ran either on a simulator or on a real quantum processor. Each circuit must end with a measurement gate in order to run the experiment:
As an example, a simple bit-flip X gate is represented below both on the Bloch sphere and on the quantum score:
Likewise, a Hadamard gate would be:
For a typical quantum state superposition, one would have use both gates :
And the resulting measurements would read:
For multi-qubit gates, it is possible to add lines on the quantum score (a CNOT gate for example):
The Open QASM code corresponding to each score is accessible right from the composer and can be edited. Conversely Open QASM code can be visualized as quantum score from the composer:
Available qubit processors
At the time of writing, transmon qubit processors, located at the IBM Research headquarters at the Thomas J. Watson Research Center can be used as backend:
- IBM Q5 computers Tenerife and Yorktown (5-qubit processors);
- IBM Q16 computer Rueschlikon (16-qubit processor)
In the following screenshot, a score for Grover’s algorithm (N=2) has been written down. The corresponding Open QASM code can be ran on IBM Q5 Tenerife (Yorktown being down for maintenance at the time of writing):
Note: to speedup the writing process, a few paragraphs and illustrations of this post were extracted from IBM’s Q > Experience documentation.