[DRAFT] Unitary Layer RB

[dcmckayibm]

Added a new class to do layer fidelity with an arbitrary set of 2Q unitary circuits for the entangling layer. Example usage:

rzz_gate_lst = []

for i in range(10):

    qc = QuantumCircuit(2)
    qc.rzz(np.pi/2/10*(i+1),0,1)
    print(np.pi/2/10*(i+1))

    rzz_gate_lst.append(qc.to_instruction())


rb_obj = LayerFidelityUnitary(physical_qubits = [0,1,2,3], 
                              two_qubit_layers = [[[0,1],[2,3]]], 
                              two_qubit_gates=rzz_gate_lst, 
                              lengths = [2,10,100], backend=backend, num_samples=1, seed=1, layer_barrier=False)

[wshanks]

Looks pretty good!

[wshanks]

Is this a to do or are we dropping validation? It should be easy to add the check if we are keeping this.

[dcmckayibm]

Is there an easy way to check these gate instructions are in the right basis set already. Actually I noticed something that might throw a wrench in your comment passing in an RZZGate object directly

[wshanks]

The Qiskit documentation for definition describes it as "Return definition in terms of other basic gates". For RZZ, it is in terms of CX and RZ. Elsewhere the documentation says that the transpiler uses the definition to reason about basis gate equivalence. So I think what you highlight is okay -- the gates just have definitions in terms for CX to help with transpilation.

We can check that the gates are in the target by doing target.instruction_suported(g.name, qargs), similar to the one qubit case below but looping over the pairs in two_qubit_layers instead of the individual physical qubits. (We could also pass parameters to instruction_supported but there is not much point now. There is no support for ranges of valid parameters so all angles will still give True).

[wshanks]

Hmm, looking at your other comment on gate vs instruction, I see that you are thinking of the case of submitting an arbitrary circuit which will be a unitary that could be benchmarked, while I am thinking in terms of a single named gate, like rzz. For the abitrary circuit, we would need to check that the target supports all of its instructions (assuming we would not want to transpile it).

[wshanks]

to_instruction actually returns an Instruction rather than a CircuitInstruction. Instruction is an abstract instruction that can be applied and CircuitInstruction is a specific application (it includes the qubits to apply the instruction on). Could we just make the type Gate though? That is a subclass of Instruction.

[dcmckayibm]

Ah ok, that probably makes more sense. And then it would be from a circuit using .to_gate()?

[dcmckayibm]

It wouldn't change any other code I assume?

[wshanks]

I don't think it would change other code. If we only supported a named gate and not the output of QuantumCircuit.to_instruction/QuantumCircuit.to_gate, I think we could take out the change to clifford_utils.py where a special case for instructions with names starting with "circuit" was added. I think that is falling into the case of adding internal instructions one by one instead of just data.append like it could if RZZGate was passed directly.

[wshanks]

We could do from qiskit.circuit.library import RZZGate and two_qubit_gates=[RZZGate(0.5)] here.

[dcmckayibm]

I guess this was more illustrative of how it would be done in a general case?

[wshanks]

One question is which is the general case -- passing a list of individual Qiskit gates or passing a list of gates that are derived from circuits and contain multiple instructions?