2
$\begingroup$

I'm running this program (essentially a two bit random number generator) on ibmqx2 in IBM Q Experience. The backend matters. Other machines give unexpected results, but the graph looks different for other backends. So far ibmqx2 has been a good choice because a) it produces results that are far from the expected outcome and b) it produces results that are consistent run over run.

OPENQASM 2.0;
include "qelib1.inc";
gate nG0 ( param ) q  {
 h q;
}

qreg q[2];
creg c[2];

h q[0];
h q[1];
measure q[0] -> c[0];
measure q[1] -> c[1];

I always get results with the following shape. Note that "11" is a full ten points higher than "10". That happens almost every run. Any idea what's going on? enter image description here

Improve this question
$\endgroup$

2 Answers 2

Reset to default
4
$\begingroup$

It seems like the skew is indeed high on qubit 0. I ran a single Hadamard followed by measure on this qubit, and see about 13% skew. The other qubits on this device seem fine (less than 2% skew).

This is probably an error on the backend's discriminator (i.e. manifesting as high readout error). To see this, you can try applying readout error mitigation (code for this exists in Qiskit Ignis). When I do this, the skew is completely gone.

Q0 on ibmqx2

This will be fixed on the backend. Thanks for reporting.

Improve this answer
$\endgroup$
4
  • $\begingroup$ I'm not sure that qubit 0 by itself is the issue. When I do a single H gate followed by a measurement, I see pretty equal results. The original program still produces skewed results, though, and so does this even simpler version: OPENQASM 2.0; include "qelib1.inc"; qreg q[2]; creg c[1]; h q[0]; h q[1]; measure q[0] -> c[0]; $\endgroup$
    – balios
    Dec 26, 2019 at 21:24
  • $\begingroup$ Hmm that's not what I was seeing. I got the above histogram using only qubit 0. (h q[0]; measure q[0] -> c[0];) $\endgroup$
    – Ali Javadi
    Dec 27, 2019 at 6:34
  • $\begingroup$ Then that issue's better, but the multi-qubit version is still wildly wrong. And it's still only necessary to measure a single cubit, as in the simplified version above, it's just somehow crucial that the other has been prepared. $\endgroup$
    – balios
    Dec 27, 2019 at 8:13
  • $\begingroup$ Maybe I did it incorrectly, but I used the referenced Qiskit tools to create a noise filter based on ibmqx2 and then ran local simulations biased by that filter. The results were not consistent with our observed results. $\endgroup$
    – balios
    Dec 27, 2019 at 8:24
1
$\begingroup$

Each quantum processor has specific so-called error rate and a little bit different type of noise caused by specific conditions the processor runs in. Therefore, results produced by same circuits can be different on different quantum processors.

In your case, there is apparently a bias caused by some external factors specific for ibmqx2. You can try to run your program after ibmqx2 recalibration which occurs in regular intervals (ask IBM Q support when a next maintanance is planned). After that, results can be more correct, i.e. closer to uniform distribution.

Improve this answer
$\endgroup$
4
  • $\begingroup$ You're probably right, but the variance seems quite extravagant for the reported error rate. $\endgroup$
    – balios
    Dec 23, 2019 at 5:39
  • $\begingroup$ Yes, you are right too. I tried to run your program under my account on IBM Q. I will inform you about results. In the mean time, this thread is on disscusion of error rates: quantumcomputing.stackexchange.com/questions/9231/…. It might be interesting for you. $\endgroup$
    – Martin Vesely
    Dec 23, 2019 at 5:44
  • $\begingroup$ @balios: Just finished my simulation. My results are more or less same as yours. You had better to ask IBM Q support team as there is probably an issue on ibmqx2. $\endgroup$
    – Martin Vesely
    Dec 23, 2019 at 5:46
  • $\begingroup$ Thanks for checking. I'm going to leave this open for now in case IBM support wants to chime in. I'll close it if there's no more follow up. $\endgroup$
    – balios
    Dec 23, 2019 at 5:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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