Add new layout methods #438
Comments
mtreinish
added
enhancement
Previously the plot_gate_map() family of visualization functions only worked with a fixed hard coded list of number of qubits. The function made the assumption if the backend had a matching number of qubits it was an IBM backend that had the same number of qubits (and fell into a fixed connectivity topology) and would use the manually set graph layout to visualize the function. This was problematic because it didn't actually work for any backend, and if a backend had the same number of qubits as an IBM backend but a different connectivity it would use a potentially nonoptimal layout. This also required us to update the hard coded list whenever a new IBM backend was released to support visualizing them. Additionally the functions only worked with BackendV1 and BaseBackend based backends and would fail if a BackendV2 object were passed to the function. This commit address these issues by making 4 key changes to the function, first it adds a new qubit_coordinates kwarg to all the methods which if specifed can be used to manually specify a graph layout to use for the visualization. The second is that the hardcoded list for layouts are only used if it's an IBM backend (or a fake backend) so that we're using them where appropriate (the 127q layout for ibm_washington is also added). The third change is that if a graph layout isn't provided and it's not an ibm backend with a hardcoded entry, retworkx's spring_layout() function is used to create a layout. In the future we can use a more appropriate planar_layout() function after its available in retworkx (see Qiskit/rustworkx#438 ). Finally the last change is that BackendV2 support is added to the function to make sure we're able to use the visualization function regardless of what type of backend is passed in.
* Make plot_gate_map generic for any backend Previously the plot_gate_map() family of visualization functions only worked with a fixed hard coded list of number of qubits. The function made the assumption if the backend had a matching number of qubits it was an IBM backend that had the same number of qubits (and fell into a fixed connectivity topology) and would use the manually set graph layout to visualize the function. This was problematic because it didn't actually work for any backend, and if a backend had the same number of qubits as an IBM backend but a different connectivity it would use a potentially nonoptimal layout. This also required us to update the hard coded list whenever a new IBM backend was released to support visualizing them. Additionally the functions only worked with BackendV1 and BaseBackend based backends and would fail if a BackendV2 object were passed to the function. This commit address these issues by making 4 key changes to the function, first it adds a new qubit_coordinates kwarg to all the methods which if specifed can be used to manually specify a graph layout to use for the visualization. The second is that the hardcoded list for layouts are only used if it's an IBM backend (or a fake backend) so that we're using them where appropriate (the 127q layout for ibm_washington is also added). The third change is that if a graph layout isn't provided and it's not an ibm backend with a hardcoded entry, retworkx's spring_layout() function is used to create a layout. In the future we can use a more appropriate planar_layout() function after its available in retworkx (see Qiskit/rustworkx#438 ). Finally the last change is that BackendV2 support is added to the function to make sure we're able to use the visualization function regardless of what type of backend is passed in. * Add missing kwargs * Fix import cycle * Remove stray debug prints * Inline function causing import cycle * Update 127q ibm layout to be consistent with others * Tweak spring_layout() usage and coordinate system conversion * Fix lint * Only use hardcoded layouts if qubit_coordinates is not set This commit updates the logic around when we use the default hard coded graph layouts for ibm backends. Previously there was a bug in the if condition which would cause the hard coded layout to be unconditionally used for an ibm backend, even if the user specified their own layout. This fixes this by only using the hard coded layouts when qubit_coordinates is not set. * Apply suggestions from code review Co-authored-by: Kevin Hartman <[email protected]> * Fix negative value offset correction in plot_gate_map() Previously the offset detection was looking for values < 0 which was needlessly triggering an offset loop for values >=0 and < 1. We only need to correct for negative values if there are any negative values in the 2d coordinates being used for the graph layout. * Remove unnecessary continue * Update docstring to say qubit_coordinates is explicitly optional * Fix lint Co-authored-by: Kevin Hartman <[email protected]> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
|
Add Planar Layout to retworkx The goal of this PR is to add a planar layout option to the other existing layout options in retworkx using the Rust language. A planar layout should provide better visualization of coupling maps in the gate_map module than existing options. A planar graph can be displayed in the plane with no edges that intersect except at a node. As an example, a complete 4-node graph is planar since one of the diagonals can be placed outside the square, resulting in no intersecting edges. A complete 5-node graph is not planar.
Creating planar layouts in the general case is a complex problem and has been the subject of research over several decades. The process follows these steps.
Step 1 has been submitted as PR #475 by @georgios-ts and is awaiting review. Step 2 is about 60% complete and should be done within the next 2 weeks. Step 3 will follow. |
|
kamada_kawai_layout is very usefull to draw a heavy-hex coupling map. |
What is the expected enhancement?
Right now retworkx has several layout methods available: https://qiskit.org/documentation/retworkx/api.html#layout-functions
but there are some other common examples (like a planar layout and kamada kawai) missing. We should expand the available layout functions so that they can be leveraged with the drawers. We can look at what networkx offers for this functionality to get some good examples: https://networkx.org/documentation/stable/reference/drawing.html#module-networkx.drawing.layout
The text was updated successfully, but these errors were encountered: