2
$\begingroup$

This question is similar to some others I've come across, related to why a 4-qubit implementation of Grover's search yields such poor results when run on the IBM QC compared to the 3-qubit case (despite very good simulated results). The explanation always seems to be "well bigger circuit means more errors" which is fine, but I was hoping to get a better understanding of the expected error rate and why the results break down suddenly when going from 3 to 4 qubits.

I have 3-bit and 4-bit circuit implementations that each perform two iterations of the Grover operator. In the simulated results these find the marked state with 94.5% and 90.4% probability, respectively. When run on the "ibm_osaka" backend, the 3-bit circuit finds the marked state in 571/1024 shots, with every other outcome distributed pretty much evenly over the remaining states. When I run the 4-bit circuit however it only finds the marked state in 43/1024 shots, with many other outcomes actually having a higher frequency, but more or less evenly distributed across each of the 16 possible output states.

Per the suggestion in the question I linked above, I looked at the actual transpiled circuit for the target backend to see how many gates they're really using, and it's definitely a lot more than my original Composer version, the 3-bit version has 280 gates with a depth of 178, while the 4-bit version has 549 gates, with depth 355. The 4-bit version is definitely bigger, although not exponentially bigger, or in any way that makes it seem obvious to me why it would give such poor results.

I've looked at the reported error rates for ibm_osaka and I see things like median readout error of 2.190e-2, which I think means that in 1024 shots with 4 measurements per shots, I would expect about 89 failed readouts, which if they all happened on separate shots would give bad results for less 10% of them? Similarly the median reported error for the 'sx' gate is 2.670e-4. My transpiled circuit has 165 of these, which means in 1024 shots I would expect about 2.670e-4 * 165 * 1024 = 45 failures due to these gates? The transpiled circuit also has 261 'rz' gates, although the reported median error for this gate seems to be 0. Overall it seems like I should still only be seeing about 20% maximum error, which doesn't seem to explain the actual results I'm getting.

If my above error analysis is flawed I would really like to understand how to calculate the expected error correctly, or if somebody can think of another explanation for the results I'm seeing that would be welcome as well.

$\endgroup$
5
  • 2
    $\begingroup$ You also need to count your two-qubit gates, including SWAPS. These have errors much higher than anything else you've considered. $\endgroup$ Commented Aug 10 at 20:31
  • $\begingroup$ Hmm I do have 89 ECR gates which I see now are a kind of variation of CNOT? I had assume it was some kind of error correction feature that was being inserted in the transpiled circuit, not an actual gate. Just to double check, the reported error rates are a 0..1 probability the gate will produce an error, not a percentage? For instance if I have 89 ECR gates each with an 8.3e-3 error rate, that means there's an 89*8.3e-3 = 0.74 probability that one of these gates will fail per execution of the circuit, in order words 74% of shots will have at least one failure due to this gate type alone? $\endgroup$
    – eodabash
    Commented Aug 10 at 21:27
  • 1
    $\begingroup$ In the answer to the linked question, a figure shows that the two-qubit gate between 3 and 4 is much less reliable than two-qubit gates among 1,2,3. If so, the drop going from 3-qubit Grove to 4-qubit Grove would seem obvious. Maybe a similar situation happens here? $\endgroup$
    – aystack
    Commented Aug 11 at 8:39
  • 1
    $\begingroup$ @eodabash That error rate is at least the right order of magnitude for a 2-qubit gate on a superconducting processor. Although the math is the probability of at least one failure is $1-(1-p)^N$, where $N$ is the number of gates and $p$ is the error probability. Assuming the errors are independent and incoherent. But it's roughly what you said. $\endgroup$ Commented Aug 12 at 3:24
  • 1
    $\begingroup$ @eodabash this is why error correction is important! In principle those ECR gates are good enough to run error correction and actually get the right answer! (in practice it's hard to run error correction at scale, and also we don't have enough qubits to do error correction anyway). But the gates are noisy, and noise kills you pretty quickly if you don't fix it $\endgroup$ Commented Aug 12 at 3:29

0

Your Answer

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

Browse other questions tagged or ask your own question.