Changes for page The Five Phases
Last modified by Alexander Schulz-Rosengarten on 2023/07/11 10:33
Summary
-
Page properties (1 modified, 0 added, 0 removed)
-
Objects (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -8,31 +8,22 @@ 8 8 9 9 The reversed edges have to be restored at some point. There's a processor for that, called ReversedEdgeRestorer. All implementations of phase one must include a dependency on that processor, to be included after phase 5. 10 10 11 -|=((( 12 -Preconditions 13 -)))|=(% class="nohighlight" %)(% class="nohighlight" %) 14 -((( 11 +=== Precondition === 12 + 15 15 * No node is assigned to a layer yet. 16 -))) 17 -|(% class="highlight" %)(% class="highlight" %) 18 -((( 19 -Postconditions 20 -)))|((( 14 + 15 +=== Postcondition === 16 + 21 21 * The graph is now cycle-free. Still, no node is assigned to a layer yet. 22 -))) 23 -|(% class="highlight" %)(% class="highlight" %) 24 -((( 25 -Remarks 26 -)))|((( 27 -* All implementations of phase one must include a dependency on the {{code language="none"}}ReversedEdgeRestorer{{/code}}, to be included after phase five. 28 -))) 29 -|(% class="highlight" %)(% class="highlight" %) 30 -((( 31 -Implementations 32 -)))|((( 33 -* {{code language="none"}}GreedyCycleBreaker{{/code}}. Uses a greedy approach to cycle-breaking. 34 -))) 35 35 19 +=== Remarks === 20 + 21 +* All implementations of phase one must include a dependency on the ReversedEdgeRestorer, to be included after phase 5. 22 + 23 +=== Current Implementations === 24 + 25 +* GreedyCycleBreaker. Uses a greedy approach to cycle-breaking. 26 + 36 36 == Phase 2: Layering == 37 37 38 38 The second phase assigns nodes to layers. (also called //ranks// in some papers) Nodes in the same layer are assigned the same x coordinate. (give or take) The problem to solve here is to assign each node x a layer i such that each successor of x is in a layer j>i. The only exception are self-loops, that may or may not be supported by later phases. ... ... @@ -41,68 +41,50 @@ 41 41 42 42 Note that nodes can have a property associated with them that constraints the layers they can be placed in. 43 43 44 -|=((( 45 -Preconditions 46 -)))|=(% class="nohighlight" %)(% class="nohighlight" %) 47 -((( 35 +=== Precondition === 36 + 48 48 * The graph is cycle-free. 49 49 * The nodes have not been layered yet. 50 -))) 51 -|(% class="highlight" %)(% class="highlight" %) 52 -((( 53 -Postconditions 54 -)))|((( 39 + 40 +=== Postcondition === 41 + 55 55 * The graph has a layering. 56 -))) 57 -|(% class="highlight" %)(% class="highlight" %) 58 -((( 59 -Remarks 60 -)))|((( 61 -* Implementations should usually include a dependency on the {{code language="none"}}LayerConstraintHandler{{/code}}, unless they already adhere to layer constraints themselves. 62 -))) 63 -|(% class="highlight" %)(% class="highlight" %) 64 -((( 65 -Implementations 66 -)))|((( 67 -* {{code language="none"}}LongestPathLayerer{{/code}}. Layers nodes according to the longest paths between them. Very simple, and doesn't usually give the best results. 68 -* {{code language="none"}}NetworkSimplexLayerer{{/code}}. A way more sophisticated algorithm whose results are usually very good. 69 -))) 70 70 44 +=== Remarks === 45 + 46 +* Implementations should usually include a dependency on the LayerConstraintHandler, unless they already adhere to layer constraints themselves. 47 + 48 +=== Current Implementations === 49 + 50 +* LongestPathLayerer. Layers nodes according to the longest paths between them. Very simple, but doesn't usually give the best results. 51 +* NetworkSimplexLayerer. A way more sophisticated algorithm whose results are usually very good. 52 + 71 71 == Phase 3: Crossing Reduction == 72 72 73 -The objective of phase 3 is to determine how the nodes in each layer should be ordered. The order determines the number of edge crossings, and thus is a critical step towards readable diagrams. Unfortunately, the problem is NP-hard even for only two layers. Did I just hear you say "heuristic"? The usual approach is to sweep through the pairs of layers from left to right and back, along the way applying some heuristic to minimize crossings between each pair of layers. The two most prominent and well-studied kinds of heuristics used here are the barycenter method and the median method. We have currently implemented the former. 55 +The objective of phase 3 is to determine how the nodes in each layer should be ordered. The order determines the number of edge crossings, and thus is a critical step towards readable diagrams. Unfortunately, the problem is NP-hard even for only two layers. Did I just hear you saying "heuristic"? The usual approach is to sweep through the pairs of layers from left to right and back, along the way applying some heuristic to minimize crossings between each pair of layers. The two most prominent and well-studied kinds of heuristics used here are the barycenter method and the median method. We have currently implemented the former. 74 74 75 75 Our crossing reduction implementations may or may not support the concepts of node successor constraints and layout groups. The former allows a node x to specify a node y!=x that may only appear after x. Layout groups are groups of nodes. Nodes belonging to different layout groups are not to be interleaved. 76 76 77 -|=((( 78 -Preconditions 79 -)))|=(% class="nohighlight" %)(% class="nohighlight" %) 80 -((( 59 +=== Precondition === 60 + 81 81 * The graph has a proper layering. (except for self-loops) 82 82 * An implementation may allow in-layer connections. 83 -* Usually, all nodes are required to have a least fixed port sides. 84 -))) 85 -|(% class="highlight" %)(% class="highlight" %) 86 -((( 87 -Postconditions 88 -)))|((( 63 +* Usually, all Nodes are required to have at least fixed port sides. 64 + 65 +=== Postcondition === 66 + 89 89 * The order of nodes in each layer is fixed. 90 90 * All nodes have a fixed port order. 91 -))) 92 -|(% class="highlight" %)(% class="highlight" %) 93 -((( 94 -Remarks 95 -)))|((( 96 -* If fixed port sides are required, the {{code language="none"}}PortPositionProcessor{{/code}} may be of use. 69 + 70 +=== Remarks === 71 + 72 +* If fixed port sides are required, the PortPositionProcessor may be of use. 97 97 * Support for in-layer connections may be required to be able to handle certain problems. (odd port sides, for instance) 98 -))) 99 -|(% class="highlight" %)(% class="highlight" %) 100 -((( 101 -Implementations 102 -)))|((( 103 -* {{code language="none"}}LayerSweepCrossingMinmizer{{/code}}. Does several sweeps across the layers, minimizing the crossings between each pair of layers using a barycenter heuristic. Supports node successor constraints and layout groups. Node successor constraints require one node to appear before another node. Layout groups specify sets of nodes whose nodes must not be interleaved. 104 -))) 105 105 75 +=== Current Implementations === 76 + 77 +* [[LayerSweepCrossingMinimizer>>doc:Layer Sweep Crossing Minimization]]. Does several sweeps across the layers, minimizing the crossings between each pair of layers using a barycenter heuristic. Supports node successor constraints and layout groups. Node successor constraints require one node to appear before another node. Layout groups specify sets of nodes whose nodes must not be interleaved. 78 + 106 106 == Phase 4: Node Placement == 107 107 108 108 So far, the coordinates of the nodes have not been touched. That's about to change in phase 4, which determines the y coordinate. While phase 3 has an impact on the number of edge crossings, phase 4 has an influence on the number of edge bends. Usually, some kind of heuristic is employed to yield a good y coordinate. ... ... @@ -109,79 +109,55 @@ 109 109 110 110 Our node placers may or may not support node margins. Node margins define the space occupied by ports, labels and such. The idea is to keep that space free from edges and other nodes. 111 111 112 -|=((( 113 -Preconditions 114 -)))|=(% class="nohighlight" %)(% class="nohighlight" %) 115 -((( 85 +=== Precondition === 86 + 116 116 * The graph has a proper layering. (except for self-loops) 117 117 * Node orders are fixed. 118 118 * Port positions are fixed. 119 119 * An implementation may allow in-layer connections. 120 120 * An implementation may require node margins to be set. 121 -))) 122 -|(% class="highlight" %)(% class="highlight" %) 123 -((( 124 -Postconditions 125 -)))|((( 92 + 93 +=== Postcondition === 94 + 126 126 * Each node is assigned a y coordinate such that no two nodes overlap. 127 127 * The height of each layer is set. 128 128 * The height of the graph is set to the maximal layer height. 129 -))) 130 -|(% class="highlight" %)(% class="highlight" %) 131 -((( 132 -Remarks 133 -)))|((( 98 + 99 +=== Remarks === 100 + 134 134 * Support for in-layer connections may be required to be able to handle certain problems. (odd port sides, for instance) 135 -* If node margins are supported, the {{code language="none"}}NodeMarginCalculator{{/code}} can compute them. 136 -* Port positions can be fixed by using the {{code language="none"}}PortPositionProcessor{{/code}}. 137 -))) 138 -|(% class="highlight" %)(% class="highlight" %) 139 -((( 140 -Implementations 141 -)))|((( 142 - 102 +* If node margins are supported, the NodeMarginCalculator can compute them. 103 +* Port positions can be fixed by using the PortPositionProcessor. 143 143 144 -{{code language="none"}} 145 -LinearSegmentsNodePlacer 146 -{{/code}} 105 +=== Current Implementations === 147 147 148 -. Builds linear segments of nodes that should have the same y coordinate and tries to respect those linear segments. Linear segments are placed according to a barycenter heuristic. 149 -))) 107 +* LinearSegmentsNodePlacer. Builds linear segments of nodes that should have the same y coordinate and tries to respect those linear segments. Linear segments are placed according to a barycenter heuristic. 150 150 151 151 == Phase 5: Edge Routing == 152 152 153 153 In the last phase, it's time to determine x coordinates for all nodes and route the edges. The routing may support very different kinds of features, such as support for odd port sides, (input ports that are on the node's right side) orthogonal edges, spline edges etc. Often times, the set of features supported by an edge router largely determines the intermediate processors used during the layout process. 154 154 155 -|=((( 156 -Preconditions 157 -)))|=(% class="nohighlight" %)(% class="nohighlight" %) 158 -((( 113 +=== Precondition === 114 + 159 159 * The graph has a proper layering. (except for self-loops) 160 160 * Nodes are assigned y coordinates. 161 161 * Layer heights are correctly set. 162 162 * An implementation may allow in-layer connections. 163 -))) 164 -|(% class="highlight" %)(% class="highlight" %) 165 -((( 166 -Postconditions 167 -)))|((( 119 + 120 +=== Postcondition === 121 + 168 168 * Nodes are assigned x coordinates. 169 169 * Layer widths are set. 170 170 * The graph's width is set. 171 171 * The bend points of all edges are set. 172 -))) 173 -|(% class="highlight" %)(% class="highlight" %) 174 -((( 175 -Remarks 176 -)))|((( 126 + 127 +=== Remarks === 128 + 177 177 None. 178 -))) 179 -|(% class="highlight" %)(% class="highlight" %) 180 -((( 181 -Implementations 182 -)))|((( 183 -* {{code language="none"}}ComplexSplineRouter{{/code}}. 184 -* {{code language="none"}}OrthogonalEdgeRouter{{/code}}. Routes edges orthogonally. Supports routing edges going into an eastern port around a node. Tries to minimize the width of the space between each pair of layers used for edge routing. 185 -* {{code language="none"}}PolylineEdgeRouter{{/code}}. 186 -* {{code language="none"}}impleSplineEdgeRouter{{/code}}. 187 -))) 130 + 131 +=== Current Implementations === 132 + 133 +* ComplexSplineRouter. TODO: Document. 134 +* OrthogonalEdgeRouter. Routes edges orthogonally. Supports routing edges going into an eastern port around a node. Tries to minimize the width of the space between each pair of layers used for edge routing. 135 +* PolylineEdgeRouter. TODO: Document. 136 +* SimpleSplineEdgeRouter. TODO: Document.
- Confluence.Code.ConfluencePageClass[0]
-
- Id
-
... ... @@ -1,1 +1,1 @@ 1 -8849 091 +884898 - URL
-
... ... @@ -1,1 +1,1 @@ 1 -https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/KIELER/pages/8849 09/The Five Phases1 +https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/KIELER/pages/884898/The Five Phases