Why are IBM QE backend results different from the qasm simulator for a simple quantum circuit?

Question

I have looked at other questions that ask pretty much the same thing such as this and from what I gathered the significant difference in simulation and actual results is due to decoherence and compounding quantum noise effects especially due to the depth/complexity of the quantum circuit, however in my case the circuit is relatively simple and has only 3 Qubits.

The circuit that I am running is exactly the same as the Coding with Qiskit Episode 6 Tutorial, however I decreased the length of the secret number string from 6 to 3 to decrease circuit complexity as I had even worse results with length 6. My understanding is that the qasm_simulator produces the expected theoretical results of an ideal quantum computer, however when I ran the 6 length string on the IBM QE backend ibmq_16_melbourne I didn't even get a single count for the ONLY theoretically expected result, for example if the secret number is num='101010' then the qasm_simulator correctly returned num with a single shot whereas the IBM QE backend returned everything but num even with a few dozen shots. When I lowered the string length to 3, I at least got num returned in the results but it wasn't significant and had a probability similar to the rest of the counts.

I would imagine that the issue is not with the quantum computer due to the simplicity of the quantum circuit, meaning that I must be doing something wrong.

Answer 1

Indeed your understanding is correct about the simulator and the idea of the ideal quantum computer, when you run a circuit on the simulator, you don't have any noise involved by default, but you will if you run on real backends, that is why you have better results on the simulator. One way to try and reduce the noise of real backends is to try error mitigation techniques, you can find the qiskit tuto here: https://qiskit.org/textbook/ch-quantum-hardware/measurement-error-mitigation.html
I also tried to run the code you pointed out in your question on other IBM devices, specifically I tried '1011' on ibmq_vigo and it gives better results than ibmq_16_melbourne, so don't hesitate to change the backend you're working on! Also, to get more precise results, you can try to increase the number of shots on real backends. I hope this helps :)

Answer 2

For running on melbourne, try increasing the optimization_level parameter to 3 (the maximum level). Between creating your circuit and running on a device, the circuit needs to be 'transpiled' into the set of gates and operations available on the device, and extra gates added to get around connectivity issues. We can see the difference in circuits using:

melb = provider.get_backend('ibmq_16_melbourne')
tcircuit_melb = transpile(circuit, melb, optimization_level=1) #change this
tcircuit_melb.draw()

(note that transpiled circuits can vary). Secondly, the barriers are used a visual aid, but they also stop the transpiler collapsing gates (a further optimisation). If you remove the barriers and re-transpile, the difference in results is quite dramatic. Here are my results for the string 110 on melbourne:

{'000': 50, '010': 11, '101': 5, '100': 824, '110': 134}

These results are innaccurate but do not seem like random errors, which makes me think there could be some other problem with melbourne at this moment in time. The results from Vigo are as expected though:

{'111': 9, '000': 4, '011': 2, '010': 27, '101': 1, '100': 18, '110': 963}