[DISCUSSION] Support for transforming QASM to other IRs

[bachase]

In ucc-ft, we are prototyping a tool to check the fault tolerance of a quantum circuit that implements an aspect of an error correcting code. This example) is checking if circuit implementing state preparation for the surface code fault tolerant. ucc-ft relies internally on an existing Julia package to do the check. That package uses its own representation for quantum programs.

The current heavy lifting in ucc-ft is converting from QASM to this Julia representation (called qprog). It does so by customizing the printer visitor that is part of openqasm3 package.

The approach so far is a bit of a hack, so in opening this discussion, curious if this translating use case is one pyqasm supports/intends to support, or if not directly, if some components in pyqasm would be useful to build on top of.

Note that this QASM -> qprog approach might change over time if we decide to shift the implementation to python. In that case, symbolically executing the QASM could would be the next challenge.

[TheGupta2012]

Hi @bachase , thanks for opening the discussion.

1. I believe that pyqasm currently focusses on QASM and the complete coverage of its semantics. I think converting between representations is best suited for the qBraid-SDK (which is already closely integrated with pyqasm). While qBraid-SDK supports conversion of QASM to Python object representations (those of Qiskit, Cirq, etc.), I can very well envision adding a conversion node to our transpiler which does this conversion from QASM to the qprog repr and potentially using this in ucc-ft.

2. On reusability of the components, I believe the builder-visitor patterns could be used to develop the equivalent representation of the qprog AST (which I think you've already hacked together). You could also potentially unroll the QASM program before moving forward with the conversion (as we do in qbraid-qir). This helps reduce redundancy in the semantic analysis and makes validation a lot simpler.

[TheGupta2012]

Also, could you elaborate on what you mean by "symbolically executing the QASM could would be the next challenge" ?

[bachase]

Thanks for those pointers.

Also, could you elaborate on what you mean by "symbolically executing the QASM could would be the next challenge" ?

The method used in this checker builds on https://github.com/njuwfang/QuantumSE.jl, which models quantum states as "symbolic stabilizer states". These are sets of stabilizer generators, but with phases that involve symbolic binary variables that are a function of the quantum program being run. The Julia code does this symbolic execution of the qprog program type, updating the phases and the stabilizer states.

If (and its still an if), we were to remove the Julia+qprog dependency, we would need a way to do the same symbolic execution of the QASM directly. So e.g., given qasm instruction cx qubit[2], qubit[3], update the symbolic stabilizer state. This definitely feels outside the scope of qbraid or pyqasm, but similar to idea 2 above, perhaps there are software components that could be reused to build a QASM interpreter for this use case.