Critical Assertion in replace_TK2_2CX fails

[nquetschlich]

When applying FullPeepholeOptimise to a quantum circuit with a quantum phase estimation part using a large number of measurement qubits (and therefore very small phase rotations), a critical assertion in replace_TK2_2CX (CircUtils.cpp in line 238) fails:

[2022-12-01 14:34:12] [tket] [critical] Assertion 'equiv_0(params[2], 4, 1e-6)' (/Users/runner/.conan/data/tket/1.0.31/tket/stable/build/<...>/Circuit/CircUtils.cpp : replace_TK2_2CX : 238) failed. Aborting.

I am using the FullPeepholeOptimise in a script to generate many quantum circuits and in that case the resulting std::abort() from the failed assertion is quite unfortunate, because I cannot treat/catch it.

The following code can be used to reproduce the result (python v3.9, pytket v1.9.0):

from qiskit.circuit.library import PhaseEstimation, PhaseGate
import numpy as np
from qiskit import QuantumCircuit, transpile
from pytket.extensions.qiskit import qiskit_to_tk
from pytket.passes import FullPeepholeOptimise, auto_rebase_pass
from pytket import OpType

u = PhaseGate(np.pi)
qc = PhaseEstimation(num_evaluation_qubits=30, unitary=u)
openqasm_gates = ["u3", "u2", "u1", "cx", "id", "u0", "u", "p", "x", "y", "z", "h", "s", "sdg", "t", "tdg", "rx", "ry", "rz", "sx", "sxdg", "cz", "cy", "swap", "ch", "ccx", "cswap", "crx", "cry", "crz", "cu1", "cp", "cu3", "csx", "cu",  "rxx", "rzz", "rccx", "rc3x", "c3x", "c3sqrtx", "c4x" ]
qc = transpile(qc, basis_gates=openqasm_gates)
qc_tket = qiskit_to_tk(qc)

ionq_rebase = auto_rebase_pass({OpType.Rz, OpType.Ry, OpType.Rx, OpType.XXPhase})
ionq_rebase.apply(qc_tket)

FullPeepholeOptimise().apply(qc_tket)

I converted the qiskit quantum circuit to contain only openQASM 2.0 gates such that any custom gates are avoided when qiskit_to_tk is applied and transpile it to the IonQ native gate set using pytket. If I skip the rebase step, the assert does not fail.

Maybe a higher tolerance within the replace_TK2_2CX assertion statement could solve the problem?

[CalMacCQ]

Hi, thank you for raising an issue for this.

Can I ask which OS you are using? This may be a platform dependent issue as I do not get the assertion failure when I run your code snippet on my mac.

[nquetschlich]

Hi, thank you for raising an issue for this.

Can I ask which OS you are using? This may be a platform dependent issue as I do not get the assertion failure when I run your code snippet on my mac.

Hi, thank you very much for your fast response. I actually do also use a mac with MacOs 13.0.1. Not sure if it helps, but I use pytket-qiskit v0.31.0, qiskit-terra v0.22.2 and qiskit v0.39.2.

[CalMacCQ]

Hi,

I am not sure of the exact reason for the assertion failure in this case as I can't reproduce the error. I suspect it comes from small parameter values in the phase estimation circuit.

I think we should investigate this behaviour further. After discussing this I think we will remove this assertion in a future release and make it warning instead.

Its possible to change the target gateset of the FullPeepholeOptimise to target TK2 gates by using

FullPeepholeOptimise(target_2qb_gate=OpType.TK2).apply(qc_tket)

Do you still get the error message if you target TK2 gates? I think this may bypass the replace_TK2_2CX .

[nquetschlich]

Hi,

for me there was a threshold regarding num_evaluation_qubits from which the error started to appear - maybe increasing it e.g., to 50, would also trigger the error in your setup.

Thanks for that suggestion, it avoids the error message. Would you be able to give an estimate in how far the added parameter affects the resulting optimization quality?

[CalMacCQ]

Hi,

I would have thought that increasing the number of evaluation qubits may reproduce the error as well. However I can increase the number up to 90 without seeing the issue which surprised me.

Regarding targetting TK2 vs CX....

If I run your original code snippet targeting CX gates with FullPeepholeOptimise I get a circuit with
#total gates = 1968
#CX gates = 861
CX depth = 117

If Instead I target TK2 gates with the same example I get the following

#total gates = 1017
#TK2 gates = 445
TK2 depth = 67

The improvement in gate count/depth with TK2 is expected as it is a parameterised gate and therefore more expressive than CX.

As for which one is better I suppose it depends on the emulator/device that you're using. TK2 gates were added as an intermediate step to target the Quantinuum device gate set whereas CX gates are native to IBM devices.