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:
https://github.com/Qiskit-Extensions/circuit-knitting-toolbox/blob/98af06eba28222123d8bac79213fa586805bc8b9/circuit_knitting/cutting/cutting_decomposition.py#L212-L218
The label suffix is then used to identify instructions that are part of the same QPDBasis when generating the experiments:
https://github.com/Qiskit-Extensions/circuit-knitting-toolbox/blob/98af06eba28222123d8bac79213fa586805bc8b9/circuit_knitting/cutting/cutting_experiments.py#L195-L197
however, the cutting-for-depth workflow (i.e., where the circuit does not separable into multiple pieces) rejects SingleQubitQPDGates:
https://github.com/Qiskit-Extensions/circuit-knitting-toolbox/blob/98af06eba28222123d8bac79213fa586805bc8b9/circuit_knitting/cutting/cutting_experiments.py#L237-L239
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.
Right now, the
cut_gatesfunction, which is used in the cutting-for-depth workflow (tutorial 2), returns a circuit withTwoQubitQPDGates. At a minimum, we should make it possible to work withSingleQubitQPDGates in a cutting-for-depth workflow (see the motivation, below). It might even make sense to havecut_gatesreturn a circuit withSingleQubitQPDGates instead ofTwoQubitQPDGates, 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. Inpartition_problem, label suffixes are attached to eachSingleQubitQPDGateso a later step of the workflow can determine matching pairs ofSingleQubitQPDGates:https://github.com/Qiskit-Extensions/circuit-knitting-toolbox/blob/98af06eba28222123d8bac79213fa586805bc8b9/circuit_knitting/cutting/cutting_decomposition.py#L212-L218
The label suffix is then used to identify instructions that are part of the same
QPDBasiswhen generating the experiments:https://github.com/Qiskit-Extensions/circuit-knitting-toolbox/blob/98af06eba28222123d8bac79213fa586805bc8b9/circuit_knitting/cutting/cutting_experiments.py#L195-L197
however, the cutting-for-depth workflow (i.e., where the circuit does not separable into multiple pieces) rejects
SingleQubitQPDGates:https://github.com/Qiskit-Extensions/circuit-knitting-toolbox/blob/98af06eba28222123d8bac79213fa586805bc8b9/circuit_knitting/cutting/cutting_experiments.py#L237-L239
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 passTwoQubitQPDGates through the transpiler, since one instead needs to modify the target to add all-to-all connectivity ofTwoQubitQPDGates. 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.