HY Force-Directed Techniques - Circular Drawings Ανδρέου Δημήτρης

Graph Drawing A discipline for visually exhibiting graph properties  Symmetries  Clusters with high cohesion

Introduction to Force-Directed Paradigm

Some Common Aesthetic Criteria Few edge crossings (as few as practically possible) Few bends (if at all)  Ignored for now, discussing only straight line drawings Uniform edge lengths Uniform node distribution on the plane Connected nodes close to each other  These can be mutually exclusive!

Force-Directed Paradigm AKA Spring-Embedder. A model that usually includes:  Spring-like forces per edge end-points  Repulsive forces between nodes It can also include:  Force towards origin, or graph’s barycenter  Gravitational force between nodes  Mass-like properties in edges (as in nodes) (That would require bends, increasing complexity but enabling various interesting opportunities)  Etc.

Runtime Properties of Force-Directed Algorithm Which set of forces is modeled? When does the algorithm stop? How (in what order) are nodes’ location updated? Deterministic or randomized? How fast does the drawing converges, if at all? And as importantly: What constants are chosen?  (Unfortunately, constants choice has a major impact on the outcome of the algorithm, and cannot be chosen a-priori, without experimentation)

GEM (Graph Embedder) Algorithm (1994)

GEM Algorithm Forces: A spring per edge, repulsive forces between nodes, gravity Parameters:  Spring constant  node repulsion constant  gravity constant Furthermore: Temperature  Local and global, with an implied cooling scheduler

About Temperature Temperature is used to scale node movements  Nodes move faster when temperature is high, and slow down as they cool down Previous approaches employed a global cooling- scheduler  Global (only) Temperature performs a deterministic gradient descent to a local minimum  This unfortunately was slow Although time complexity cannot be expressed in terms of |N| or |E| GEM utilizes local (per node) temperature, that adapts to algorithm’s expectations about the node’s optimal position (more later)

GEM Algorithm

At initialization, a random placement of nodes would suffice, but they are placed one by one instead, to produce a better initial placement (improves performance) Nodes are chosen randomly, but exactly once per round  This improves results over iterating the nodes deterministically Node with many edges are given more inertia  Through a scaling factor Nodes memorize their last impulse (the significance of this will be demonstrated later)

Impulse Calculation Gravity towards barycenter  p := (barycenter – v.pos) * g * Φ(v) Random disturbance  p := p + δ (δ is a small random vector) For each node u in (V \ { v }) Δ := v.pos – u.pos p := p + Δ * E desired 2 / |Δ| 2 For each edge (u, v) incident to v Δ := v.pos – u.pos p := p – Δ * |Δ| 2 / (Ε desired 2 * Φ(u))

Temperature Adjustment After each step, a new temperature is calculated for the node If a node is a part of rotation or oscillation, its temperature is lowered If a node moves non-negligibly towards the direction it moved at the previous step, it is presumed that it moves to its optimum position  So temperature is increased, to accelerate the node’s movement Rotation and oscillation are defined in terms of one level memory (i.e. remembering only the last step)

Rotation and Oscillation detection

GEM Performance Good all-around performer Still in high use today Primarily used with integer arithmetic, for faster calculations (and hopefully, no degradation of results)

Examples (Note: Two-dimensional)

Examples (all still 2-D!) Although there is no notion of edge-crossings in the algorithm, planar graphs are often drawn cross-free. Often drawings are actually 3D projections on plane Left drawings appear more often than right counterparts (which have fewer crosses)

Remarks The efficiency of the algorithm stems from local temperature adaptations, which accelerate “correct” moves and slows down unclear moves It is fast and space-efficient (only an extra vector per node) to detect node rotations and oscillations Yet, it is very dependent on the choice of constants, and especially the opening angles by which to detect node moves

A Framework for User-Grouped Circular Drawings

Introduction Circular drawings are good in demonstrating the close relation of a group of nodes Applications of circular drawings include Telecommunications, computer networks, social network analysis, project management, etc.

Introduction If nodes in a particular circle convey the meaning that they form a group of some kind, wouldn’t circular drawings be a good tool to select and highlight arbitrary groups? Actually, most existing solutions cannot be used as such a tool  User cannot assign nodes in circles herself  There is the notable exception of GLT (Graph Layout Toolkit), but with its own limitations

Desired Solution User should be able to choose group of nodes, to be drawn circularly Groups should be laid out with low number of edge crossings Number of crossings between intra-group and inter-group edges should be low Fast layout

Algorithmic toolset CIRCULAR-biconnected  Input: Biconnected graph  Output: Single-Circle layout CIRCULAR-Nonbiconnected  Input: Non biconnected (general) graph  Output: Single-Circle layout CIRCULAR-withRadial  Input: Non biconnected (general) graph  Output: Multiple embedding circles, which correspond to nodes of the block-cutpoint tree

A Brief Review: CIRCULAR-biconnected Minimizing edge crossings (circular drawings included) is NP-complete The algorithm tends to place  edges towards the outside of the embedding circle  nodes near their neighbors It does so by traversing the nodes in a wave and reducing pair edges *  (Edge that its nodes have a common neighbor) Then DFS the resulting graph, and place the longest path continuously on the circle, and merge rest of the nodes Circular diagram by GLT Same graph by CIRCULAR-biconnected

A Brief Review: CIRCULAR-biconnected Time complexity: O(m) If a zero-crossing drawing exist, this algorithm will find it  Outer-planar graphs 15% to 30% fewer edge crossings, compared to GLT

A Brief Review: CIRCULAR- Nonbiconnected Block-cutpoint tree is computed This tree can be ordered by DFS and placed onto a circle, crossing free Then, a variant of CIRCULAR- biconnected is used to layout the nodes of each block, on an arc An issue is in which block to place cut nodes (several solutions exist, not discussed)

A Brief Review: CIRCULAR- Nonbiconnected Arc is different to a circle in that it has endpoints, so a biconnected component must break somewhere in order to fit onto an arc  An articulation point of the block is chosen Time Complexity: O(m) Property: nodes of each biconnected component appear consecutively  Except for strict articulation points So, biconnectivity of components is still displayable, even on a single circle

A Brief Review: CIRCULAR-withRadial A graph is decomposed into biconnected components Then, the block-cutpoint tree is laid out using a radial layout technique Then, each biconnected component is laid out with a variant of CIRCULAR-biconnected  Not a full description of the algorithm Time complexity: O(m)

Back to User-Grouped Circular Drawings: Algorithm Outline

What is missing to make it work With the previous algorithms, it is possible to nicely layout each group, and layout the superstructure as well, with a basic force- directed scheme The problem is seamlessly merging intra-group considerations with inter-group ones Problematic case: Intra- group/Inter-group edge crossings

Circular Force-Directed: The missing component We need a force-directed algorithm, that takes the almost- final drawing that CIRCULAR-withRadial produces, and reduce inter-group/intra-group crossings. Can’t simply use a basic force-directed algorithm: nodes need to appear on their circle’s circumference Important: nodes are allowed to jump each other in the process  That allows the circular drawings of previous algorithms to change, but their importance is minor compared to overall graph readability

Circular Force-Directed Hooke’s law calculates potential energy as: V = Σ ij k ij [(x i – x j ) 2 + (y i – y j ) 2 ] Coordinates can be defined by angle, as: x i = x a + r a * cos(θ i ) y i = y a + r a * cos(θ i ) So, potential energy can be expressed by: V = Σ (i, j) in E k ij [(x a + r a * cos(θ i ) – x β – ρ β * cos(θ j )) 2 +(y a + r a * cos(θ i ) – y β – ρ β * cos(θ j )) 2 ]

Circular Force-Directed The previous expression is augmented to include repulsive forces: ρ ij = [(x a + r a * cos(θ i ) – x β – r β * cos(θ j )) 2 + (y a + r a * cos(θ i ) – y β – r β * cos(θ j )) 2 V = Σ (I, j) in E k ij ρ ij + Σ (I,j) in VxV g ij / ρ ij Finally, the force on each node is defined: F i = [ V(θ i + ε, θ j ) – V(θ ι – ε, θ j ) / 2ε where ε a very small constant

Final Algorithm

Sample Result Note that after the application of circular force- directed algorithm, nodes are not in discrete positions  Perhaps this is not ideal, but easily fixable  Although fixing it may imply further complications

Remarks This work introduces an interesting variant of force-directed technique, built on a positional constraint. It strikes a balance between in-circle layout optimality, and overall result A very useful technique, overall

References A Fast Adaptive Layout Algorithm for Undirected Graphs  Arne Frick, Andreas Ludwig, Heiko Mehldau A Framework for User-Grouped Circular Drawings  Janet Six, Ioannis Tollis