Getting Started with Qiskit¶

Here, we provide an overview of working with Qiskit. The fundamental package of Qiskit is Terra that provides the basic building blocks necessary to program quantum computers. The fundamental unit of Qiskit is the quantum circuit. A basic workflow using Qiskit consists of two stages: Build and Execute. Build allows you to make different quantum circuits that represent the problem you are solving, and Execute that allows you to run them on different backends. After the jobs have been run, the data is collected and postprocessed depending on the desired output.

Table of contents¶

1. Circuit Basics

2. Visualize Circuits

3. Simulating Circuits With Aer

4. Running on IBM Q Devices

Circuit Basics ¶

Building the circuit¶

The basic element needed for your first program is the QuantumCircuit. We begin by creating a QuantumCircuit comprised of three qubits.

After you create the circuit with its registers, you can add gates ("operations") to manipulate the registers. As you proceed through the tutorials you will find more gates and circuits; below is an example of a quantum circuit that makes a three-qubit GHZ state

To create such a state, we start with a three-qubit quantum register. By default, each qubit in the register is initialized to $|0\rangle$. To make the GHZ state, we apply the following gates:

• A Hadamard gate $H$ on qubit 0, which puts it into the superposition state $\left(|0\rangle+|1\rangle\right)/\sqrt{2}$.
• A controlled-Not operation ($C_{X}$) between qubit 0 and qubit 1.
• A controlled-Not operation between qubit 0 and qubit 2.

On an ideal quantum computer, the state produced by running this circuit would be the GHZ state above.

In Qiskit, operations can be added to the circuit one by one, as shown below.

Visualize Circuit ¶

You can visualize your circuit using Qiskit QuantumCircuit.draw(), which plots the circuit in the form found in many textbooks.

In this circuit, the qubits are put in order, with qubit zero at the top and qubit two at the bottom. The circuit is read left to right (meaning that gates that are applied earlier in the circuit show up further to the left).

[default]
circuit_drawer = mpl

Simulating circuits using Qiskit Aer ¶

Qiskit Aer is our package for simulating quantum circuits. It provides many different backends for doing a simulation. There is also a basic, Python only, implementation called BasicAer in Terra that can be used as a drop-in replacement for Aer in the examples below.

Statevector backend¶

The most common backend in Qiskit Aer is the statevector_simulator. This simulator returns the quantum state, which is a complex vector of dimensions $2^n$, where $n$ is the number of qubits (so be careful using this as it will quickly get too large to run on your machine).

To run the above circuit using the statevector simulator, first you need to import Aer and then set the backend to statevector_simulator.

Now that we have chosen the backend, it's time to compile and run the quantum circuit. In Qiskit we provide the execute function for this. execute returns a job object that encapsulates information about the job submitted to the backend.

When you run a program, a job object is made that has the following two useful methods: job.status() and job.result(), which return the status of the job and a result object, respectively.

The results object contains the data and Qiskit provides the method result.get_statevector(circ) to return the state vector for the quantum circuit.

Qiskit also provides a visualization toolbox to allow you to view these results.

Below, we use the visualization function to plot the real and imaginary components of the state density matrix \rho.

Unitary backend¶

Qiskit Aer also includes a unitary_simulator that works provided all the elements in the circuit are unitary operations. This backend calculates the $2^n \times 2^n$ matrix representing the gates in the quantum circuit.

OpenQASM backend¶

The simulators above are useful because they provide information about the state output by the ideal circuit and the matrix representation of the circuit. However, a real experiment terminates by measuring each qubit (usually in the computational $|0\rangle, |1\rangle$ basis). Without measurement, we cannot gain information about the state. Measurements cause the quantum system to collapse into classical bits.

For example, suppose we make independent measurements on each qubit of the three-qubit GHZ state $$|\psi\rangle = |000\rangle +|111\rangle)/\sqrt{2},$$ and let $xyz$ denote the bitstring that results. Recall that, under the qubit labeling used by Qiskit, $x$ would correspond to the outcome on qubit 2, $y$ to the outcome on qubit 1, and $z$ to the outcome on qubit 0.

Recall the probability of obtaining outcome $xyz$ is given by $$\mathrm{Pr}(xyz) = |\langle xyz | \psi \rangle |^{2}$$ and as such for the GHZ state probability of obtaining 000 or 111 are both 1/2.

To simulate a circuit that includes measurement, we need to add measurements to the original circuit above, and use a different Aer backend.

This circuit adds a classical register, and three measurements that are used to map the outcome of qubits to the classical bits.

To simulate this circuit, we use the qasm_simulator in Qiskit Aer. Each run of this circuit will yield either the bitstring 000 or 111. To build up statistics about the distribution of the bitstrings (to, e.g., estimate $\mathrm{Pr}(000)$), we need to repeat the circuit many times. The number of times the circuit is repeated can be specified in the execute function, via the shots keyword.

Once you have a result object, you can access the counts via the function get_counts(circuit). This gives you the aggregated binary outcomes of the circuit you submitted.

Approximately 50 percent of the time, the output bitstring is 000. Qiskit also provides a function plot_histogram, which allows you to view the outcomes.

The estimated outcome probabilities $\mathrm{Pr}(000)$ and $\mathrm{Pr}(111)$ are computed by taking the aggregate counts and dividing by the number of shots (times the circuit was repeated). Try changing the shots keyword in the execute function and see how the estimated probabilities change.

Running circuits from the IBM Q account ¶

To faciliate access to real quantum computing hardware, we have provided a simple API interface. To access IBM Q devices, you'll need an API token. You can generate, or view, your API token here (create an account if you don't already have one).

Your IBM Q account lets you run your circuit on real devices or on our cloud simulator. Basic account usage can be seen in the examples below. For more detailed instructions on using the IBM Q account, see Part 3: The IBMQ Account.

After generating your API token, call: IBMQ.save_account('MY_TOKEN').

This will store your IBM Q credentials in a local file. Unless your registration information has changed, you only need to do this once. You may now load your accounts by calling,

Once your account has been loaded, you have one or more providers available to you

Each provider gives access to a selection of services (e.g. Backends) that is authorized by your account. To see the backends available to a given provider, first select the provider by hub, group, project, or a combination thereof:

the ask the provider to list its backends:

Running circuits on real devices¶

Today's quantum information processors are small and noisy, but are advancing at a fast pace. They provide a great opportunity to explore what noisy, intermediate-scale quantum (NISQ) computers can do.

Let us now grab a backend from the provider on which to run our quantum circuit:

To run the circuit on the given device we use execute. Sometimes the devices are busy with jobs from other users. Your job is added to the list of pending jobs called the queue, and executed in this queue order. To monitor the status of our job through the process, we can use the job_monitor

job_exp has a .result() method that lets us get the results from running our circuit.

Like before, the counts from the execution can be obtained using get_counts(qc)

Simulating circuits using the IBM Q cloud simulator¶

The IBM Q provider also comes with a remote optimized simulator called ibmq_qasm_simulator. This remote simulator is capable of simulating up to 32 qubits. It can be used the same way as the remote real backends.

Retrieving a previously run job¶

If your experiment takes longer to run then you have time to wait around, or if you simply want to retrieve old jobs, the IBM Q backends allow you to do that. First you would need to note your job's ID:

Given a job ID, that job object can be later reconstructed from the backend using retrieve_job:

and then the results can be obtained from the new job object.