Add option max_block_width to CollectLinearFunctions and CollectClifford passes

[alexanderivrii]

Summary

This PR adds a new argument max_block_width to the class BlockCollector and to the transpiler passes CollectLinearFunctions and CollectCliffords that are based on this class. This argument enforces block collection strategies to restrict the maximum number of qubits over which a block of nodes is defined.

This option is similar to the option max_block_size in the CollectMultiQBlocks transpiler pass (though naming-wise, I am calling this "width" instead of "size", which is how it should be using the terminology of DAGCircuit and QuantumCircuit).

The implementation is based on the adaptation of BlockCollector in AI resynthesis passes (including a small cleanup for updating the frontier nodes).

Details and comments

Somewhat related to the PR, here is a more refined difference between BlockCollector and CollectMultiQBlocks:

1. BlockCollector allows to only collect nodes that match a given "filter function" and treat other nodes as "should not be collected", while CollectMultiQBlocks collects all nodes (in particular, CollectMultiQBlocks cannot be used to only collect say Clifford gates within in a larger circuit).

2. BlockCollector can collect nodes exploiting commutativity of nodes within the DAG; CollectMultiQBlocks does not have this functionality. BlockCollector has other options that CollectMultiQBlocks does not have.

3. Both can now collect nodes "forward-wise" from the inputs towards the ouputs of a circuit, and backward-wise from the outputs towards the inputs.

4. Both BlockCollector and CollectMultiQBlocks are greedy, however CollectMultiQBlocks is smarter, in the following way. BlockCollector greedily collects one block at a time, greedily trying to add nodes into the block being collected. In particular it may create "disconnected" blocks . On the other hand, CollectMultiQBlocks (with the implementation based on the disjoint set union data structure) produces connected blocks by construction.

[qiskit-bot]

One or more of the following people are relevant to this code:

• @Qiskit/terra-core

[coveralls]

Pull Request Test Coverage Report for Build 12991606884

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 19 of 19 (100.0%) changed or added relevant lines in 1 file are covered.
• 1284 unchanged lines in 46 files lost coverage.
• Overall coverage increased (+0.01%) to 88.944%

---

Files with Coverage Reduction	New Missed Lines	%
crates/circuit/src/lib.rs	1	94.64%
crates/accelerate/src/basis/basis_translator/basis_search.rs	1	99.3%
qiskit/synthesis/linear/linear_depth_lnn.py	1	90.91%
crates/accelerate/src/remove_identity_equiv.rs	1	95.45%
crates/qasm3/src/build.rs	1	72.24%
crates/accelerate/src/barrier_before_final_measurement.rs	1	98.65%
crates/accelerate/src/check_map.rs	1	98.39%
crates/accelerate/src/isometry.rs	1	99.65%
crates/accelerate/src/unitary_synthesis.rs	2	93.09%
crates/qasm3/src/lib.rs	2	87.88%

Totals
Change from base Build 12765737818:	0.01%
Covered Lines:	79567
Relevant Lines:	89457

---

💛 - Coveralls

[ShellyGarion]

LGTM. I only have some minor comments on the tests.

[ShellyGarion]

what happens if you take this circuit:

        circuit = QuantumCircuit(5)
        circuit.cx(0, 1)
        circuit.cx(3, 4)
        circuit.cx(1, 3)
        circuit.cx(2, 4)

with max_block_width=4?
do you get 3 blocks [0,1,3], [3,4],[2,4] or 2 block [0,1][1,2,3,4]?
do we care about this?

[alexanderivrii]

what happens if you take this circuit:

    circuit = QuantumCircuit(5)
    circuit.cx(0, 1)
    circuit.cx(3, 4)
    circuit.cx(1, 3)
    circuit.cx(2, 4)

with max_block_width=4?
do you get 3 blocks [0,1,3], [3,4],[2,4] or 2 block [0,1][1,2,3,4]?
do we care about this?

In general, the problem of "optimally" dividing a circuit into blocks is "hard" (and in fact NP-hard for suitable notions of "optimality"). In practice, which blocks get collected depends on the order in which the nodes are processed and on other options given to BlockCollector (like exploiting commutativity between nodes or collecting from the back of the circuit). So the result is generally not unique. In fact, for the example above, with the default options, we would collect the first 3 gates into one block, and the remaining gate into the second block, and with collect_from_back=True, we would collect the last 3 gates into one block, and the first gate into the second block.

I would say we should care about this when we think about resynthesis, as collecting different blocks gives rise to different resynthesis opportunities.

[ShellyGarion]

LGTM. Thanks @alexanderivrii