- Notifications
You must be signed in to change notification settings - Fork18
Force-directed graph layout with Fruchterman-Reingold
License
olvb/nodesoup
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
Force-directed graph layout simulates forces to give motion to vertices and arrange them in a way that is visually pleasing and/or reveals structure. TheFruchterman-Reingold algorithm assigns a repelling force to vertices pair of the graph, effectively pushing apart vertices so they don't overlap, and a attraction force between each adjacent vertices pair, thus dragging closer connected vertices. The forces attenuate when the vertices get respectively further apart or closer, and a global temperature also serves as a simulated annealing, capping the maximum vertex displacement at each iteration. As the forces between each component and the temperature gradually diminish, the layout stabilizes.
Another method, theKamada Kawai algorithm, relies on the simulation of springs between each vertex, which strength is determined by the length of the shortest path between both vertices. The potential energy of each vertex, ie the sum of the energy of all its springs, is then computed. The goal being to reduce the global energy of the layout, each vertex is moved step-by-step until its potential energy is considered low-enough, using a Newton-Raphson algorithm.
This implementation of Fruchterman-Reingold starts by positioning all vertices on a circle as this appears to favor "unmangling" compared to random positions. The radius of the circle is alway 1.0, and all further computations are performed with floating point values, without knowledge of the canvas dimensions. In consequence, contrary to the original Fruchterman-Reingold algorithm, no bound checking is performed, and the layout can spread constraint-free. The final result is then scaled to fit into the canvas dimensions.
A Kamada-Kawai algorithm is also provided, mostly for comparison purpose. Its complexity makes it rather unsuitable for larger graphs.
Click for full-scale image
Fruchterman-Reingold | Kamada-Kawai | Graphviz |
---|---|---|
![]() | ![]() | ![]() |
x.xxs | x.xxs | x.xxs |
DOT file fromgraphs.grevian.org
Fruchterman-Reingold | Kamada-Kawai | Graphviz |
---|---|---|
![]() | ![]() | ![]() |
x.xxs | x.xxs | x.xxs |
DOT file fromgraphs.grevian.org
Fruchterman-Reingold | Kamada-Kawai | Graphviz |
---|---|---|
![]() | ![]() | ![]() |
x.xxs | x.xxs | x.xxs |
Fruchterman-Reingold | Kamada-Kawai | Graphviz |
---|---|---|
![]() | ![]() | ![]() |
x.xxs | x.xxs | x.xxs |
Fruchterman-Reingold | Graphviz |
---|---|
![]() | ![]() |
x.xxs | x.xxs |
GML file fromgephi based on dataset by M. E. J. Newman
It might take some twiddling with thek parameter (a constant used to compute attractive and repulsive forces between vertices), as well as of the number of iterations, in order to get a layout perfectly free of edge-crossing. A better solution could be to introduce a "fine-tuning" phase during which we slightly raise again the temperature (and possibly thek value?) so as to shake the layout a bit before cooling it down again.