Organize the visualization

[d1ssk]

Before submitting, please check the following:

• Make sure you have tests for the new code and that test passes (run tox)
• format added code by black -l 120 <filename>
• If applicable, add a line to the [unreleased] part of CHANGELOG.md, following keep-a-changelog.

Then, please fill in below:

Context (if applicable):

• With the current visualization method, the x-correction is always visualized as gflow. (This iss because of insufficient implementation of gflow_from_pattern)
• The visualization of graphs withowt information flow structure lacked visual clarity because the position of nodes was determined randomly.

Description of the change:

• The behavier of the visualization method is organized as follows.
  • When drawing from a graph:
    1. Apply find_flow, and if found, print "flow found" and visualize with visualize_w_flow.
    2. If no flow is found, apply find_gflow, and if found, print "no flow found gflow found" and visualize with visualize_w_gflow.
    3. If neither flow nor gflow is found, state that explicitly and visualize with visualize_wo_structure.
  • When drawing from a pattern:
    1. Retrieve xflow from the pattern and, together with layer obtained with get_layer, apply to flow checker. If determined to be a flow, further check if zflow, also obtained from the pattern, is consistent with that flow. If consistent, label as "flow" and visualize with visualize_w_flow.
    2. If the first step fails, apply xflow and l_k to gflow checker. If determined to be a gflow, perform a consistency check with zflow. If consistent, label as "gflow" and visualize with visualize_w_gflow.
    3. If both the first and second steps fail, state that explicitly and draw both xflow and zflow.
• When visualizing graphs without flow, the output nodes are placed in the right and the input nodes left. Other nodes are placed btween them based the connections in the graph.
• Change the implementation so that the graph edges and flow arrows are always depicted seperately. (In the previous method, arrows sometimes meant graph edge was there as well)
• Remove redundunt parts in verify_flow() and verify_gflow (see discussion in #117)

Related issue:

118

also see that checks (github actions) pass. If lint check keeps failing, try installing black==22.8.0 as behavior seems to vary across versions.

[d1ssk]

some examples

[shinich1]

I have a related (but not directly about the commits made here) comment: https://github.com/TeamGraphix/graphix/blob/be854f70a5f06859d2d794eee5b57a8dc89b6f4e/graphix/visualization.py#L100-L103 It looks like by default we do not search for gflow when calling pattern.draw_graph but still say gflow found. If I'm not mistaken, gflow_from_pattern returns gflow-like structure even if there's no gflow in the graph.

What would you say about sorting out this part a little, such that

• instead of using gflow_from_pattern by default, we prioritise searching for gflow.
• if neither flow nor gflow found, we go for visualize_wo_structure by default.
• Add an option to visualize with gflow_from_pattern in case no flow or gflow found. print no flow or gflow found. set use_quasi_gflow=True to visualize with the correction structure of the pattern. or something similar (suggestion welcome).
• print no flow or gflow found. visualizing with quasi-gflow constructed from pattern. in this case, because there's no gflow in strict sense

cc: @masa10-f

[d1ssk]

My plan is as follows:

• When drawing from a graph:

  1. Apply find_flow, and if found, print "flow found" and visualize with visualize_w_flow.
  2. If no flow is found, apply find_gflow, and if found, print "no flow found gflow found" and visualize with visualize_w_gflow.
  3. If neither flow nor gflow is found, state that explicitly and visualize with visualize_wo_structure.

• When drawing from a pattern:

  1. Retrieve xflow from the pattern and, together with layer obtained with get_layer, apply to flow checker. If determined to be a flow, further check if zflow, also obtained from the pattern, is consistent with that flow. If consistent, label as "flow" and visualize with visualize_w_flow.
  2. If the first step fails, apply xflow and l_k to gflow checker. If determined to be a gflow, perform a consistency check with zflow. If consistent, label as "gflow" and visualize with visualize_w_gflow.
  3. If both the first and second steps fail, state that explicitly and draw both xflow and zflow. (Method not implemented yet)

Here, xflow and zflow refer to collections of correction signals of X and Z, respectively, within the pattern.

[d1ssk]

These images show examples of visualization outcomes. The visualization approach for flow/gflow remains largely unchanged, except for a modification in the arrow style for flow. The detection of flow/gflow within patterns has become rigorous. In cases without flow/gflow, the nodes are neatly arranged. Moreover, when visualizing from a pattern, both xflow and zflow are also depicted.

[d1ssk]

The flow_from_pattern and gflow_from_pattern methods consistently produced accurate results when testing patterns generated from graphs using generator.py. However, I observed that most patterns transpiled from circuits are not consistent with flow or gflow, resulting in that most visualizations within the examples are with red and green arrows. (I added flow_from_pattern argument in draw_graph so that we can get the previous result when setting it False)

I suspect that the majority of patterns derived from circuits is in Pauli flow structure rather than flow or gflow. I plan to develop a pauliflow_from_pattern method in PR #117 to investigate this hypothesis.

[masa10-f]

However, I observed that most patterns transpiled from circuits do not flow or gflow.

Can you show an example of flow-absent pattern transpiled from circuit? Generally, pattern from circuit must have flow, so it sounds strange to me...

[masa10-f]

Or, you visualized a pattern after shift_signals ? It can change the original flow into gflow or Pauli flow. Can you visualize a pattern after standardize but before shift_signals ?

[d1ssk]

Like this. Actually it's obvious from figure that the correction flow structure is not flow. The graph itself "has" flow structure of course, but the pattern sequence is not consistent with that. I checked that xflow and zflow here is consistent with pattern.seq.

I haven't thoroughly checked the implementation of the transpiler yet, and perhaps this is because some default optimization in the transpiler?

[masa10-f]

Thanks!

this is because some default optimization in the transpiler?

I agree with you. For example, the following code is Ry gate, but feedforward structure is different from flow.

It seems that we should have pauliflow_from_pattern to visualize a pattern in practical use.

  def _ry_command(self, input_node: int, ancilla: Sequence[int], angle: float):
      """MBQC commands for Y rotation gate

      Parameters
      ---------
      input_node : int
          input node index
      ancilla : list of four ints
          ancilla node indices to be added to graph
      angle : float
          rotation angle in radian

      Returns
      ---------
      out_node : int
          control node on graph after the gate
      commands : list
          list of MBQC commands
      """
      assert len(ancilla) == 4
      seq = [["N", ancilla[0]], ["N", ancilla[1]]]  # assign new qubit labels
      seq.extend([["N", ancilla[2]], ["N", ancilla[3]]])
      seq.append(["E", (input_node, ancilla[0])])
      seq.append(["E", (ancilla[0], ancilla[1])])
      seq.append(["E", (ancilla[1], ancilla[2])])
      seq.append(["E", (ancilla[2], ancilla[3])])
      seq.append(["M", input_node, "XY", 0.5, [], []])
      seq.append(["M", ancilla[0], "XY", -1 * angle / np.pi, [input_node], []])
      seq.append(["M", ancilla[1], "XY", -0.5, [input_node], []])
      seq.append(["M", ancilla[2], "XY", 0, [], []])
      seq.append(["X", ancilla[3], [ancilla[0], ancilla[2]]])
      seq.append(["Z", ancilla[3], [ancilla[0], ancilla[1]]])
      return ancilla[3], seq

[d1ssk]

Thanks! I'm not familiar with transpile algorithm yet and might be mistaken, but do you think it's possible to first construct a pattern without correction assuming that all the measurement outcome is 0, and after that, modify the commands to integrate corrections according to flow or gflow of the graph? If so, I guess it's even possible to get minimal-correction pattern.

[shinich1]

@d1ssk Nice work!! I think a dedicated example or tutorial page would be nice to show the range of visualizer capability. I am happy to write it up once the discussion above are resolved, or if you're keen feel free to add one.

unrelated note - we should update the documentation page for more modern look and it needs better-organized tutorial/API ref. will think about this later and create an issue.

[masa10-f]

do you think it's possible to first construct a pattern without correction assuming that all the measurement outcome is 0, and after that, modify the commands to integrate corrections according to flow or gflow of the graph?

Yes, it's possible. But, I heard that currently perform_pauli_measurments violates it somehow. So, we might have to address this problem when implementing it. Or, it would be more natural to express a correction-less pattern in graph. I believe it would make better UI to separate measurement-error correction(flow or signals) from Unitary embedding(angle, planes, and graph structures).

[d1ssk]

@shinich1 This discussion is not directly related to this PR and I will tackle it in other PR. Could you please go ahead to make the documentation page? Thanks.

[shinich1]

@d1ssk could you write a few lines in the changelog? also the xflow and zflow etc legends are cut off when showing in the gallery, see here. Perhaps @nabe98 could help with this?

after these are fixed, let us squash and merge.