1
$\begingroup$

I want to run this simple test on the IBM quantum computer ibmq_lima, but it complains about the measurement. As you can see, there is one "measure". The weird part is that it works if I change the "U" gate to "u3" gate. But, the "U" is a valid gate according to the OpenQASM 2.0 spec!

OPENQASM 2.0;
include "qelib1.inc";

qreg q[1];
creg c[1];

h q[0];
U(1,2,3) q[0];
measure q[0] -> c[0];
$\endgroup$
3
$\begingroup$

TL;DR There is a bug in the composer (already reported to the composer developers) that do no aliases U and u (neither CX and cx). You can use Qiskit, either locally or in the IBM Quantum Lab to read this totally valid QASM.

qasm = """
OPENQASM 2.0;
include "qelib1.inc";

qreg q[1];
creg c[1];

h q[0];
u(1,2,3) q[0];
measure q[0] -> c[0]; 
"""

circuit = QuantumCircuit.from_qasm_str(qasm)
circuit.draw('mpl')

enter image description here

Qiskit does have the aliasing U/u and CX/cx. For example, you can transpile and works as expected:

transpile(circuit, basis_gates=['u', 'h'], optimization_level=0).draw()

enter image description here


Some background

The U gate is defined in the OpenQASM 2.0 specification, together with CX, as an abstract gate. U and CX are a universal basis and all the other gates can be defined as a combination of them.

However, they are not meant to be used directly and the composer does not list them as available gates:

available gates

"But if it is right there! the last one is a clear U" you are probably saying. And you are not wrong. As explained by @KAJ226, gates are usually detonated with capital letters and non-abstract QASM gates use small-case. As a consequence, the confusion.

$\endgroup$
1
$\begingroup$

It should have been a lower case u instead. That is, something like this:

OPENQASM 2.0;
include "qelib1.inc";

qreg q[1];
creg c[1];

h q[0];
u(1,2,3) q[0];
measure q[0] -> c[0]; 

It should be noted that this is not just for the $U$ gate but other gates as well. They should be in lower case. For instance, the Hadamard gate usually denoted as $H$,but its implementation is h. Similarly, $RX, RY, RZ, CX$ have implementation as rx,ry,rz,cx. $U_1, U_2, U_3$ have implementation as u1, u2, u3.

$\endgroup$
4
  • $\begingroup$ Thanks for the answer. But, I cannot accept it because it is ambiguous. Your "it" means IBM parser or the OpenQASM spec? The spec clearly indicates the "U" must be used, so IBM violates the spec. If "it" means the spec, its authors should correct the spec; if "it" means IBM parser, IBM should fix the parser. $\endgroup$ – Emscripten Fan Mar 20 at 21:08
  • $\begingroup$ Actually, it's not a parser error, but the lack of representation in the composer. The bug is that the composer should "alias" u and U (and cx/CX). You are right that yours is valid QASM. Qiskit in the IBM Quantum Lab will read it without any problems. $\endgroup$ – luciano Mar 21 at 21:34
  • $\begingroup$ For other users, I mark the answer as "Accepted" because the comment of @luciano has answered the question directly. $\endgroup$ – Emscripten Fan Mar 22 at 1:02
  • 1
    $\begingroup$ Let me give it shape of an answer in that case, so it is clear for future use. $\endgroup$ – luciano Mar 22 at 9:54

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.