5
$\begingroup$

What is the meaning of the topology graphs of IBM's quantum computers? How should it be interpreted? For example, how should I understand the following graph?enter image description here

$\endgroup$
10
$\begingroup$

The graph shows you how the physical qubits are connected together on the real device you will be using. For example, on the graph you put, qubit 0 has a physical connection to qubit 1 and qubit 14 on the quantum device but is not connected to qubit 12.

This graph is really important when Qiskit tries to map a circuit to the quantum device because it shows how qubits are connected and this is a huge step in transforming circuits to run in devices. For example, since 0 and 1 are connected, it will have no problem executing a C-NOT between the two. But if you wish to do the same between 0 and 12, this will be harder because of the lack of connection.

The process of rewriting circuits is what we call transpilation. Without it, we won't be able to run circuits on quantum devices. You should check the link I just put, it explains it quite well! All in all, the main objective of this is to transform your circuit so it matches the device you are using, and the topology of the qubits (the graph) plays quite a important role in this.

If you have any question regarding this, feel free to ask! I hope this helps :)

$\endgroup$
6
$\begingroup$

To add onto Lena answer.

The plot topology graph of the device represents the qubit layout of the hardware. The qubits on IBM hardware are fixed. They don't move around as trapped-ion qubits built by Honeywell system. Hence, IBM hardware doesn't have what you would call all-to-all connectivity between qubits. Note that IBM uses superconducting transmon qubit rather than trapped ions qubits.

When you design a quantum circuit, you don't usually don't think about the specific hardware specifications. That is, you would rather put your focus on designing a circuit to do the task at hand rather than thinking about what the qubit layout is on the QPU and the native gates that can be executed on the QPU. Once you finished designing your circuit, and want to execute it on a specific QPU, then you need to find an equivalent circuit to the circuit that you came up with, that can be executed on that specific QPU. This is known as the transpilation process. Fortunately, Qiskit do this automatically for you. Furthermore, you can also specify the level of optimization during this transpilation process.

For example, let's suppose that the following quantum circuit solve that problem that you are interested in:

enter image description here

and you want to execute this on ibmq_vigo which has the following specifications:

  1. qubit layout:

enter image description here

  1. Basis gates (the gates that can be executed on hardware):

    CX, ID, RZ, SX, X (This just changed actually, it used to be U1,U2,U3,CX )

First, we must note that the Hadamard gate can't be implement directly on ibmq_vigo since it is not part of the native gate. So it need to be decomposed into RZ and SX gates.

Second, we should note that qubit $q_0$ is not connected to $q_4$ in the above qubit layout. But we do have a $CX$ gate between $q_0$ and $q_4$ hence there must be some overhead swapping operations need to be done for us to be able to execute the above circuit on the hardware.

But as I said before, IBM do this transpilation for you automatically, so you don't have to worry about it. And they do it at different level of optimization. At the lowest level, that is, you just map the your circuit $q_0$ to the device qubit number $0$, and your circuit $q_1$ to the device qubit number $1$, and so on, then you would have a transpiled circuit like:

enter image description here

Note how you don't see the Hadamard gate $H$ being executed but rather a sequence of $RZ$ and $SX$ gates putting together... again this is because the QPU ibmq_vigo doesn't have $H$ as the native gate.


This is all good, but you might look at your circuit, and say to yourself: well... since $q_0$ and $q_4$ need to have to an entangled gate, $CX$, and the other qubits only have single qubit rotation ($X$ gate). Why don't we map qubit $q_0$ of the circuit to qubit number $0$ on the QPU, but now mapping qubit $q_4$ of the circuit to qubit number $1$ of the device, and qubit $q_1$ of the circuit to qubit number $2$ of the device and etc. This will reduce the overhead. This is a higher level of optimization, and it is a default option in Qiskit (I believe). So doing what I just said above will give is the following circuit:

enter image description here

Note how much simpler it is now compare to the our first transpiled circuit. This is why having a good transpilation process is really important and one that is very critical in this NISQ (Noisy Intermediate-Scale Quantum) era.


If you are interested in recreating the above circuits, and their respective transpiled version, here is the code to do so in Qiskit. I executed them in the IBMQ Lab environment.



Importing Qiskit packages:

import matplotlib.pyplot as plt
%matplotlib inline
# Importing standard Qiskit libraries
from qiskit import QuantumCircuit, execute, Aer, IBMQ
from qiskit.compiler import transpile, assemble
from qiskit.tools.jupyter import *
from qiskit.visualization import *
from iqx import *
from qiskit.visualization import plot_histogram, plot_gate_map, plot_circuit_layout
provider = IBMQ.load_account()

Creating the original circuit and draw it out:

qreg_q1 = QuantumRegister(5, 'q')
creg_c = ClassicalRegister(5, 'c' )
qc = QuantumCircuit(qreg_q1)
qc.h(0)
for i in [1,2,3,4]:
    qc.x(i)
qc.cx(0,4)
qc.draw('mpl', style = {'name': 'bw'}, scale = 1, initial_state = True,plot_barriers = False) 

Pick ibmq_vigo as our QPU to transpile the original circuit to, also transpile it naively (lowest level of optimization): (This is create that humongous long circuit we saw earlier)

hardware_backend = provider.get_backend('ibmq_vigo')
transpiled_qc_lvl0 = transpile(qc, backend = hardware_backend , optimization_level=0)
transpiled_qc_lvl0.draw('mpl', style = {'name': 'bw'}, scale = 0.6, initial_state = True,plot_barriers = False) 

Transpile the original circuit with highest level of optimization: (This spit out the shorter/much more compact transpiled circuit that we saw earlier. Not we just change the optimization_level from 0 to 3.)

transpiled_qc_lvl3 = transpile(qc, backend = hardware_backend , optimization_level=3)
transpiled_qc_lvl3.draw('mpl', style = {'name': 'bw'}, scale = 0.75, initial_state = True,plot_barriers = False) 
$\endgroup$
2
  • $\begingroup$ Thanks a lot for the amazing answer @KAJ226! Regarding the call to "transpile" Did I understand correctly? - If I am not calling it, Would it be called automatically with a default optimization level? $\endgroup$
    – AL_P
    Jan 9 at 5:37
  • 1
    $\begingroup$ Yes. That is correct. If you don't specify it, then Qiskit will use level 1. That is the default. The levels are: 0 =no optimization; 1 = light optimization, 2 = heavy optimization, 3 = even heavier optimization $\endgroup$
    – KAJ226
    Jan 9 at 6:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.