QPE Circuit test on Quantum Computer ('ibmq_16_melbourne')

After several atempts, I cannot mitigate the error when running the code on a NISQ, via the qiskit library (more specifically on the 'ibmq_16_melbourne').

I've already mapped the connected qubits and simplified my circuit to the basic gates accepted by the backend.

The code is as it follows:

from qiskit import *
from qiskit.circuit.library.standard_gates import HGate
from qiskit.visualization import plot_histogram

def qft_dagger(qc, n):
"""n-qubit QFTdagger the first n qubits in circ"""
# Don't forget the Swaps!
for qubit in range(n//2):
qc.swap(qubit, n-qubit-1)
for j in range(n):
for m in range(j):
qc.cp(-math.pi/float(2**(j-m)), m, j)
qc.h(j)

provider = IBMQ.get_provider('ibm-q')
#backend = Aer.get_backend('qasm_simulator')
shots = 8192

#INFO CIRC
nCountingQ = 3
w = 3.8

#LISTS

tempo = []
eigenvalues = []
allCircs = []

#DEF TEMPO
t0 = 0
tmax = 2
nrInvervalos = 70
deltaT = tmax/nrInvervalos
t = t0

qr = QuantumRegister(4,'qr')
cr = ClassicalRegister(3,'cr')
#CICLO

while t<tmax:

circ = QuantumCircuit(qr,cr)
theta = 2*w*t
for i in range(nCountingQ):
circ.h(i)

#UNITARY
repetitions = 1
for counting_qubit in range(nCountingQ):
for i in range(repetitions):
circ.rz(theta/2,nCountingQ)
circ.cx(counting_qubit,nCountingQ)
circ.rz(-theta/2,nCountingQ)
circ.cx(counting_qubit,nCountingQ)
repetitions *= 2

#QFT
qft_dagger(circ,nCountingQ)

#MEASUREMENT
for i in range(nCountingQ):
circ.measure(i,i)
#ATUALIZAR TEMPOS
tempo.append(t)
t+=deltaT

allCircs.append(circ)

And I execute the code with the following command:

job = execute(allCircs, backend = backend, shots = shots, initial_layout={qr:4, qr:9, qr:11, qr:10})

Finally, I process the data with a weighted average:

#print(x)
for key,value in x.items():
key = int(key,2)

The results I should've be obtaining are: But what I'm consistently obtaining is (extremely random): Unfortunaly, I couldn't find the correct information to help me mitigate this specific errors

• You can try to perform error mitigation on your circuit... this might help a tiny bit but I wouldn't expect much or any improvement given the type of circuits you are dealing with. Your circuits when transpile into the hardware is just too long... errors will accumulate to the point that whatever your read out is just noise :) May 31 '21 at 19:26
• Thats also an observation I had in account. Whats funny is that even with just 2 controll qubits for the QPE, it still shows this results... May 31 '21 at 21:48
• remember that the those controlled operations when decomposed into native gates create a longer circuit. May 31 '21 at 23:42
• Did you have a look at your circuit after it has been transpiled and mapped to the qubits? Based on the Quantum Volume (which is only 8 for Melbourne) you can estimate whether your circuit should work. Also you can drop the swaps in the QFT if you apply it upside down and reverse the bits in the measurement :) Does the expected result come from using a simulator instead of a backend? Jun 1 '21 at 6:22
• @KAJ226 Fortunatly I decomposed the Controled Rz gates I used into a Rz + Cnot, whose are the ones accepted by the backend Jun 1 '21 at 9:14

The question of how we mitigate this error is actually a bit wrong to ask at this point because we also need to start looking at the $$T_{2}$$ time of the qubits on which our circuit is being executed.
Imagine that the coherence time of the device is $$100 \mu s$$ and average gate time is $$1 \mu s$$. If you have the depth of your circuit as > 100, the qubits decohere and that is why you are getting random results. I don't really think there is anything we could do to mitigate the errors as the device does not stay quantum beyond a certain point.
At least that is what I could make of it! This is my simulation result for the iterative QPE on ibmq_casablanca as the precision increased to beyond 3 qubits :) 