HY-483

- 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

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.posp := p + Δ * Edesired

2 / |Δ|2

For each edge (u, v) incident to vΔ := v.pos – u.posp := 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 jumpeach 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 = Σijkij[(xi – xj)2 + (yi – yj)2]

Coordinates can be defined by angle, as:xi = xa + ra * cos(θi)yi = ya + ra * cos(θi)

So, potential energy can be expressed by:

V = Σ(i, j) in Ekij [(xa + ra * cos(θi) – xβ – ρβ * cos(θj))2 +(ya + ra * cos(θi) – yβ – ρβ * cos(θj))2]

Circular Force-Directed

The previous expression is augmented to include repulsive forces:ρij = [(xa + ra * cos(θi) – xβ – rβ * cos(θj))2 +

(ya + ra * cos(θi) – yβ – rβ * cos(θj))2

V = Σ(I, j) in Ekijρij + Σ(I,j) in VxVgij / ρij

Finally, the force on each node is defined:

Fi = [ 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