Missing gates in native gate set for Rigetti backend

[vishal-ph]

The following method of class ForestBackend rebases the quantum circuits for Rigetti devices. However, the supported native gate set does not include the parameterized CPHASE and RiSWAP (a.k.a XY-interaction) gates that are native to Rigetti devices, resulting in sub-optimal gate decompositions.

class ForestBackend(Backend):

        ...

        def rebase_pass(self) -> BasePass:
        return auto_rebase_pass({OpType.CZ, OpType.Rz, OpType.Rx})

Is there a plan to include these gates in the future? Thanks

[cqc-melf]

Thank you for this request. We will add this to our list and we will try to do improvements on this in the next weeks.

[vishal-ph]

@cqc-melf, thanks! I was wondering if there's a quick fix for the time being. For example, is it possible that I can define a custom rebase pass by including the OpType.CRz in the gate set? So that the get_compiled_circuit() leaves the CRz gates untouched in the circuit? P.S. I am assuming that the Rigetti CPHASE gate is the OpType.CRz gate in pytket.

[cqc-melf]

I am not 100% sure what the CPHASE gate is, you can compare the unitary with the unitary of CRz (which is a controlled Rz(\alpha) ) listed at: https://cqcl.github.io/tket/pytket/api/optype.html

[cqc-melf]

You can use self defined passes for the rebase and run a self selected set of passes which is not changing the gate set for during the optimisation after that. If you want to submit this circuit to the device you can still use the backend of this extension, but you should disable the check of the requirements, because that would change the gate set again. (Set the valid_check to false in the process_circuits function. ). If you have more questions, please let me know and I am happy to help.

[cqc-melf]

Just wanted to check: did you mean the ISWAP gate or something else? https://pyquil-docs.rigetti.com/en/v3.3.2/apidocs/pyquil.gates.html?highlight=iswap#pyquil.gates.ISWAP

I have not found a gate called RiSWAP in the rigetti documentation?

[vishal-ph]

@cqc-melf, thanks for the ideas. I will try to implement your suggestions and play around a bit to see if this works for what I want. Regarding, RiSWAP, I meant to convey the message that it is a parameterized iSWAP gate. I believe Rigetti calls it the XY gate. You can find the documentation here https://pyquil-docs.rigetti.com/en/v2.28.0/apidocs/autogen/pyquil.gates.XY.html (In PyTket language, I am referring to OpType.PhasedISWAP)

[cqc-melf]

Thank you, that is what I wanted to know.

I have tried to find a list with all the supported native gates for the rigetti devices, but I have not found that. Can you point me to where you have found that? I wanted to make sure that I not only add the gates you have listed but all that are currently available.

[vishal-ph]

The way we generate the list of natively supported gates, is by accessing the device and extracting the connectivity map of the QPU with the following lines of code. You could give this a try and let me know!

from pyquil import get_qc

shots = 10000
rewiring = 'PRAGMA INITIAL_REWIRING "NAIVE"'
as_qvm = False

name = "Aspen-M-2" # Aspen-11
qvm = get_qc(name, as_qvm=as_qvm, execution_timeout = 500, compiler_timeout=100)
G = qvm.qubit_topology()

compiler_isa = qvm.quantum_processor.to_compiler_isa()
compiler_isa.edges

Thanks

[CalMacCQ]

From my understanding the CPhase gate is equivalent to the CU1 gate in pytket. CU1 is equivalent to a CRz up to a global phase.

As pointed out by @vishal-ph the XY gate can be implemented ad a PhasedISwap operation.

I think it should be reasonably easy to handle these gates.

@cqc-melf anything I've missed here?

[CalMacCQ]

I think this could be resolved by appropriate changes to the ForestBackend.rebase_pass .

If I understand the above the backend now supports (CPhase aka CU1) and (RiSWAP aka PhasedISwap). Given that these are parametrised gates I think the solution is to come up with a way to implement TKET's internal TK2 gate in terms of {Rx, Rz, CU1, PhasedISwap, CZ}.

Once we have such a replacement in hand we either create a RebaseCustom or add it to TKET's library of known decompositions so that it can be accessed via auto_rebase_pass

Not that once we incorporate such a rebase into the default_compilation_pass we should modify FullPeepholeOptimise to target the OpType.TK2 instead of the default OpType.CX.

We may also need to remove the post-routing CliffordSimp pass as this goes via CX. Maybe we could change it to target TK2 as well.

Is there anything we should be aware of regarding the cost of the new parameterised gates in terms of fidelity?

[cqc-melf]

I have set up a PR for adding the gate to the target gate set, but I gave not updated the default compilation, because it is not required in there. So if you want to, you can add the gate to your circuit and apply passes on the circuit that are not changing the gateset. If there is a good reason to always compile to the XY gateset, we could add a new rebase pass as CalMacCQ suggested.