Qasms with composite gates don't load

[dcmckayibm]

Here is the qasm string

'OPENQASM 2.0;\ninclude "qelib1.inc";\ngate r q { h q; s q; h q; s q; }\ngate rinv q {sdg q; h q; sdg q; h q; }\ngate sinv q {s q; z q;}\nqreg q[3];\ncreg c[3];\nrinv q[0];\ncx q[1], q[2];\nr q[1];\nrinv q[2];\ncx q[0], q[2];\nrinv q[0];\nr q[2];\ncx q[0], q[1];\nrinv q[1];\ny q[0];\nbarrier q[0], q[1], q[2];\nr q[1];\ncx q[0], q[1];\nrinv q[2];\nr q[0];\ncx q[0], q[2];\nr q[2];\nrinv q[1];\ncx q[1], q[2];\nr q[0];\nx q[0];\nz q[1];\nmeasure q[0] -> c[0];\nmeasure q[1] -> c[1];\nmeasure q[2] -> c[2];'

If I run from_qasm_str

I get

QiskitError: 'unknown operation for ast node name rinv'

Informations

• Qiskit Terra version:
• Python version:
• Operating system:

What is the current behavior?

Steps to reproduce the problem

What is the expected behavior?

Suggested solutions

[jaygambetta]

yeah, this will not work. We give you an alternative way to do it soon.

[jaygambetta]

oops im sorry. This needs to be fixed. @1ucian0 can you look at this.

[1ucian0]

This is part of a bigger problem that we have with composite gates, I think.

[ardeleanasm]

Is there an alternative way to do it?

[1ucian0]

Smaller program to reproduce the problem:

QuantumCircuit.from_qasm_str('OPENQASM 2.0;\ninclude "qelib1.inc";\ngate rinv q {sdg q; h q; sdg q; h q; }\nqreg q[3];\nrinv q[2];')

@ajavadia , is there any alternative way?

[1ucian0]

Now that composite gates are fixed... I will try to attack this issue... which me luck 🤞

[itoko]

@1ucian0 Thank you for tackling this issue. Any progress for non-opaque gates? I've encountered the following error when loading qasm file with custom gates and found this issue.

qiskit.exceptions.QiskitError: 'Custom non-opaque gates are not supported by as_to_dag module'

[1ucian0]

The problem is that we dont have an easy way to bind variables at DAG level. We are planing to refactoring the DAG, so I'm not fully sure if its worthy. What do you think @kdk ?

[msegado]

What's the current timeline to add this functionality back in? I just upgraded some production code from Qiskit 0.6.x (ancient, I know) and am trying to determine whether I'll need to create a workaround or whether I should just wait for a fix to land. Thanks!

Re. implementation: wouldn't it make more sense to just do AST -> circuit directly rather than AST -> DAG -> circuit? The only place ast_to_dag is used in Qiskit is in conjunction with dag_to_circuit to create a circuit from QASM, and going to a circuit directly would allow you to leverage their existing machinery for custom instructions, variable binding, etc. Maintaining backwards compatibility would also be easy (at least for users not importing AstInterpreter directly):

def ast_to_dag(ast):
    return circuit_to_dag(ast_to_circuit(ast))

[francabrera]

this issue is also affecting the IBM Quantum Experience composer users (some have complained on the Slack channel) since the transpiling process using Qiskit fails when running a OpenQASM with "subroutines" (custom gates) in any of the cloud backends.

[jwoehr]

My nuqasm2 compiles any subroutine to circuit by simply unrolling it on the spot as it attempts to make a circuit. They could toss that in the backend, even if the team doesn't want to use it in mainline Qiskit.