Make cutting-for-depth compatible with SingleQPDGates in the workflow

[garrison]

Right now, the cut_gates function, which is used in the cutting-for-depth workflow (tutorial 2), returns a circuit with TwoQubitQPDGates. At a minimum, we should make it possible to work with SingleQubitQPDGates in a cutting-for-depth workflow (see the motivation, below). It might even make sense to have cut_gates return a circuit with SingleQubitQPDGates instead of TwoQubitQPDGates, but we'd have to consider whether there would be any down-side to this approach.

Background

The cutting-for-width workflow (tutorial 1) is already phrased in terms of circuits with SingleQubitQPDGates. In partition_problem, label suffixes are attached to each SingleQubitQPDGate so a later step of the workflow can determine matching pairs of SingleQubitQPDGates:

circuit-knitting-toolbox/circuit_knitting/cutting/cutting_decomposition.py

Lines 212 to 218 in 98af06e

	bases = []
	i = 0
	for inst in qpd_circuit.data:
	if isinstance(inst.operation, TwoQubitQPDGate):
	bases.append(inst.operation.basis)
	inst.operation.label = f"{inst.operation.label}_{i}"
	i += 1

The label suffix is then used to identify instructions that are part of the same QPDBasis when generating the experiments:

circuit-knitting-toolbox/circuit_knitting/cutting/cutting_experiments.py

Lines 195 to 197 in 98af06e

	if isinstance(inst.operation, SingleQubitQPDGate):
	try:
	decomp_id = int(inst.operation.label.split("_")[-1])

however, the cutting-for-depth workflow (i.e., where the circuit does not separable into multiple pieces) rejects SingleQubitQPDGates:

circuit-knitting-toolbox/circuit_knitting/cutting/cutting_experiments.py

Lines 237 to 239 in 98af06e

	raise ValueError(
	"SingleQubitQPDGates are not supported in unseparable circuits."
	)

Motivation

It is possible to pass SingleQubitQPDGates through the transpiler, as demonstrated in #303 (original test) and #573 (docs). However, it's much trickier to pass TwoQubitQPDGates through the transpiler, since one instead needs to modify the target to add all-to-all connectivity of TwoQubitQPDGates. I haven't actually tried this, but I'm not wild about it for some reason.

The immediate goal of solving this issue is to remove caveat mentioned at the top of the how-to guide introduced in #573 .

Stretch goal

As we are refactoring to make this possible, it might be nice to think about how we could design it such that someone could perform cutting-for-width and cutting-for-depth in the same, hybrid workflow. That is, some of the cuts separate the circuit into distinct partitions, but not others.