Add tape to graph conversion for circuit cutting

[anthayes92]

Context:
A key aspect of circuit cutting will be to allow users to request automatic cut locations, this relies on graph partitioning algorithms which requires a specific multigraph representation of circuits.

Description of the Change:
Add a tape-to-graph method to the qcut.compiler

Benefits:
Enables conversion of tapes to custom graph representations

Possible Drawbacks:
Some potential overlap with work already done for qml.CircuitGraph (whose representation of wires as edges is not sufficient for graph partitioning needs)

Related GitHub Issues:

[codecov]

Codecov Report

Merging #2107 (43d04a8) into master (d09598c) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #2107   +/-   ##
=======================================
  Coverage   99.20%   99.20%           
=======================================
  Files         230      231    +1     
  Lines       17718    17745   +27     
=======================================
+ Hits        17577    17604   +27     
  Misses        141      141           

Impacted Files	Coverage Δ
pennylane/transforms/qcut.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d09598c...43d04a8. Read the comment docs.

[zeyueN]

Already enumerated, no need to manually increment right? same below.

[anthayes92]

I think this can be removed but we need to keep an increment below for when it moves from converting operators to converting measurements and observables

[zeyueN]

I do think it makes sense to give users more control when they wish not to do the expansion. But from the automatic cutting perspective, defaulting to doing the expansion makes sense.

[anthayes92]

Hey @maliasadi this is the tape to graph converter mentioned in the PL meeting. It is currently using networkx, would be great to get your thought on a retworkx implementation.

A couple of thoughts from our side:

1. We require a MultiDiGraph representation, the rx equivalent seems to be PyDiGraph(..., multigraph=True) but perhaps there is another option?
2. It's not immediately clear how we can include our custom attributes when adding nodes to a graph in rx, e,g currently we have graph.add_node(m_, order=order)
3. What are the benefits of using rx over nx? Since we are only converting tapes to graphs the speedup that rx offers doesn't seem to be of much consequence but perhaps we're missing something!

[maliasadi]

Hey @anthayes92. Thanks for sharing! Checking the code, I don't think that there is anything here nx offers and rx doesn't; however, I agree on this that the performance may be independent of the final choice.

We require a MultiDiGraph representation, the rx equivalent seems to be PyDiGraph(..., multigraph=True) but perhaps there is another option?

You're right! The equivalence of MultiDiGraph is PyDiGraph in rx. You can check circuit_graph.py for example.

It's not immediately clear how we can include our custom attributes when adding nodes to a graph in rx, e,g currently we have graph.add_node(m_, order=order)

In rx, graph attributes can be defined as callback functions (to return statically typed data from node/edge). A good example from here: In nx, we have

import networkx as nx

graph = nx.MultiDiGraph()
graph.add_edges_from([(0, 1, {'weight': 1}), (0, 2, {'weight': 2}),
                      (1, 3, {'weight': 2}), (3, 0, {'weight': 3})])
dist_matrix = nx.floyd_warshall_numpy(graph, weight='weight')

while in rx, you may write it as,

import retworkx as rx

graph = rx.PyDiGraph()
graph.extend_from weighted_edge_list(
    [(0, 1, {'weight': 1}), (0, 2, {'weight': 2}),
     (1, 3, {'weight': 2}), (3, 0, {'weight': 3})])
dist_matrix = rx.digraph_floyd_warshall_numpy(
    graph, weight_fn=lambda edge: edge[weight])

What are the benefits of using rx over nx?

As far as I dig, constructing a graph and updating nodes/edges using the rx Python interface shouldn't add any noticeable performance; however, when it comes to the use of graph algorithms or generators, your rx code will be by far faster and performant than your nx. (check PR #1791 for benchmark)

[zeyueN]

@anthayes92 I could be a bit out of the loop, but this seems interesting. Just wondering what kind of graph algorithms are we looking to run on the qcut DAGs that can benefit from rx, or even nx?

[anthayes92]

Thanks for the useful insight @maliasadi! It looks like this is certainly possible to do this with rx but as @zeyueN has pointed out, the question is whether it is necessary. Since PL is moving toward rx there is some motivation there however the need for a graph structure that is well suited to graph partitioning algorithms should be the priority here.

@zeyueN will this current conversion of tape to dag be of use for a dedicated dag class? i.e
tape -> nx.dag -> class DAG

If not then perhaps this conversion might only be used for manual circuit cutting.

[zeyueN]

For the DAG class, I was thinking more along the lines of wrapping nx.dag inside it: either by making it an attribute, e.g. self.dag, or, directly inheriting from MultiDiGraph. This way, we can define our own syntax sugars for getting things like list(g.edges(data=True)) as well as manual/auto cut functions. In other words, the tape_to_graph function can be the __init__() of the class.

But ultimately I guess this comes down to how much of these do we want to expose to users, and is having access to the vanilla nx graph dag important to users.

[josh146]

@anthayes92 @zeyueN, a quick flyby comment, but my understanding for building the multi digraph was that two graph algorithms needed to be applied:

• Graph partitioning
• Extracting weakly connected graph fragments.

While the graph construction will likely not be any more performant using RX, my understanding is that, once the graph is constructed, applying these two graph algorithms will be much more performant in RX than NX?

[josh146]

Though I'm cautious to put too much work into this while we have an existing CircuitGraph class that wraps nx.DiGraph (not multi). The end state might be the functionality we have here merges with the established PL CircuitGraph.

💯

[zeyueN]

@josh146 The graph partitioning is going to be handled with a more "heavyduty" library kahypar (optional dependency) which uses its own graph representation. But yes the "extracting weakly connected fragments" could be more performant, especially for manually placed cuts like Tom mentioned.

[anthayes92]

Hye @josh146, thanks for weighing in! Yes for the manual cutting case we will need an algorithm to find the weakly connected components (and possibly for the automated cutting case?) and certainly a graph partitioning algo for the automated case.

The big question is whether using rx will give any advantage for graph partitioning - we have been prototyping using kayhpar for this fairly specialised partitioning and not using any rx native algos (in fact I'm not aware of any built in rx graph partitioning algos, though there are some built in to nx).

Since kayhypar expects graphs to be of a specific format, it doesn't seem to make sense to use rx and also motivates creating our own kahypar-friendly DAG class (as Zeyue suggested) for the automated cutting.

[maliasadi]

Thanks for the useful insight @maliasadi! It looks like this is certainly possible to do this with rx but as @zeyueN has pointed out, the question is whether it is necessary. Since PL is moving toward rx there is some motivation there however the need for a graph structure that is well suited to graph partitioning algorithms should be the priority here.

I want to say if you get an up and running nx implementation, getting rx support should be quite easy as we already dug into this for circuit_graph and qaoa in PL. So, as you mentioned, we can go on with nx if the main use case is to construct/update graphs and talk about this more some other time. 🚀

[zeyueN]

After having played with the dags a bit, I think it does have everything I need for auto wire cuts. One minor comment, it feels like having a dedicated dag class could make things a bit easier to work with (instead of working directly with the networkx graph whose interface is a bit awkward, especially when accessing custom attributes).

[trbromley]

Could make this _add_operator_node since it looks like more of an internal function

[trbromley]

The only heavy functionality we'd use from NX/RX is in this line, i.e., pulling apart the graph into its disconnected components. This could also be done as part of the automatic cut placement, but it seemed easier to directly use the NX version (which also accounts for if a user does just manual placement and doesn't want to call the automatic placement workflow).

For the DAG class, I was thinking more along the lines of wrapping nx.dag inside it...

I think that'd be great, especially inheriting from MultiDiGraph. Though I'm cautious to put too much work into this while we have an existing CircuitGraph class that wraps nx.DiGraph (not multi). The end state might be the functionality we have here merges with the established PL CircuitGraph.

[trbromley]

In this PR I think we can leave out adding this function to the transforms docstrings and wait until all of the functionality for circuit cutting is available. However, it'd be good to have the full docstrings added to each function as we go, so that we just need to make them visible in the docstrings without having to write them. So here we should add a docstring for tape_to_graph.

[anthayes92]

There's a couple of things that have surfaced as "todo when XYZ has been merged". This makes me wonder if there's a good tool for reminders in this scenario. It seems the only GH reminder tool is slack messages for PRs that need reviewing

[trbromley]

I'm in favour of dropping expansion here and having users either: (i) expand the tape themselves before calling this fn, (ii) providing a custom expand_fn when using the cut_circuit transform.

[anthayes92]

Sounds good, I've removed the state prep decomposition and tests

[trbromley]

Thanks @anthayes92 this looks great! Just a few comments/suggestions but once they're sorted this is good to merge.

[trbromley]

Could we use add_operator_node for this (and lines 63 - 37)?

[anthayes92]

Added thanks!

[trbromley]

🤔 so we have to treat the last edge differently because of MeasurementProcess?

[anthayes92]

That was the idea however after rethinking it it makes more sense to compare this with tape.measurements[0] from the original tape rather than tape.observables[0]

[trbromley]

Suggested change

	assert (edge[0], edge[1]) == (expected_edge[0], expected_edge[1])
	assert edge == expected_edge

Could this work if we add the label in expected_edge_connections?

[anthayes92]

nice, added!

[trbromley]

I think you can also go data="wire" and you'll get just the wire data.

[anthayes92]

As in g.edges(data="wire") ? this didn't work for me 🤔 I also tried g.edges.data("wire") with no luck

[trbromley]

Could add a test with a tape that contains two measurements. One meas could be a tensor product and the other not.

[anthayes92]

Added thanks!

[trbromley]

Thanks @anthayes92!

[trbromley]

The return type could be optional in this case 🙂