Topology-based layouts
NetPanorama provides a range of network layouts by integrating with several existing libraries:
- d3-force
- Cytoscape.js and its plugins (see the documentation and this blog post for details)
- cola.js/WebCoLa (GitHub)
- Tulip (for details of available Layout algorithms, see the documentation)
- Graphviz
It also provides its own implementation of a BioFabric layout.
Most of these libraries run in the browser.
The exception is Tulip, a C++ framework. A Python wrapper around this provides an HTTP API: networks are sent by a POST request, and the node positions are returned.
The format of NetPanorama specifications for topological layouts matches the API of the underlying libraries fairly closely.
An example layout:
{
"name": "le-mis-layout",
"network": "le-mis-network",
"type": "d3-force",
"normalizeX": [
0,
500
],
"normalizeY": [
0,
500
],
"forces": [
{
"force": "radial",
"radius": 100,
"strength": 0.5
},
{
"force": "link"
},
{
"force": "nbody"
}
]
}
Many of the layout algorithms accepts parameters that adjust the results.
As well as global parameters, some allow particular values to be set for each node or edge (for example, a node charge or a link strength). Such values can be set in several ways:
- you can specify that the same constant value should be used for all nodes or edges (e.g.,
"radius": { 12 }) - you can specify that for each node or edge, the value of the parameter should be set to the value of a specific named field (e.g.,
"radius": {"field": "degree"}) - you can specify that for each node or edge, the value of the parameter should be obtained by evaluating an expression (e.g.,
"radius": {"expression": "datum.degree"})
TODO: what about a scale?
D3-Force
Compute a force-directed layout using d3-force.
| Attribute | Type | Description |
|---|---|---|
| type | "d3-force" | |
| iterations? | number | The number of iterations to perform. |
| alpha? | number | Initial value of the alpha value (default 1). |
| alphaMin? | number | Value of alpha at which the simulation should stop (default 0.001). |
| alphaTarget? | number | Set the target alpha value (default 0). |
| velocityDecay? | number | Set the velocity decay factor (default 0.4). |
| forces? | SingleForce[] | List of forces to be applied during the simulation. |
Forces
Center
"The centering force translates nodes uniformly so that the mean position of all nodes (the center of mass if all nodes have equal weight) is at the given position ⟨x,y⟩. This force modifies the positions of nodes on each application; it does not modify velocities, as doing so would typically cause the nodes to overshoot and oscillate around the desired center. This force helps keeps nodes in the center of the viewport, and unlike the positioning force, it does not distort their relative positions."
| Attribute | Type | Description |
|---|---|---|
| force | "center" | |
| x? | number | The x-coordinate of the centering position. |
| y? | number | The y-coordinate of the centering position. |
| strength | number | the centering force’s strength. A reduced strength of e.g. 0.05 softens the movements on interactive graphs in which new nodes enter or exit the graphDefault: 1 |
Collide
"The collision force treats nodes as circles with a given radius, rather than points, and prevents nodes from overlapping. More formally, two nodes a and b are separated so that the distance between a and b is at least radius(a) + radius(b). To reduce jitter, this is by default a “soft” constraint with a configurable strength and iteration count."
| Attribute | Type | Description |
|---|---|---|
| force | "collide" | |
| radius? | LiteralOrFieldOrExpression | "The radius of each node"Default: 1 |
| strength? | number | The force strength: a number in the range [0,1].Default 1 |
| iterations? | number | the number of iterations per application.Increasing the number of iterations greatly increases the rigidity of the constraint and avoids partial overlap of nodes, but also increases the runtime cost to evaluate the force.Default: 1 |
N-Body
"The many-body (or n-body) force applies mutually amongst all nodes. It can be used to simulate gravity (attraction) if the strength is positive, or electrostatic charge (repulsion) if the strength is negative. This implementation uses quadtrees and the Barnes–Hut approximation to greatly improve performance; the accuracy can be customized using the theta parameter. Unlike links, which only affect two linked nodes, the charge force is global: every node affects every other node, even if they are on disconnected subgraphs."
| Attribute | Type | Description |
|---|---|---|
| force | "nbody" | |
| strength? | number | "A positive value causes nodes to attract each other, similar to gravity, while a negative value causes nodes to repel each other, similar to electrostatic charge"Default: -20 |
| theta? | number | "To accelerate computation, this force implements the Barnes–Hut approximation which takes O(n log n) per application where n is the number of nodes.For each application, a quadtree stores the current node positions; then for each node, the combined force of all other nodes on the given node is computed.For a cluster of nodes that is far away, the charge force can be approximated by treating the cluster as a single, larger node.The theta parameter determines the accuracy of the approximation: if the ratio w / l of the width w of the quadtree cell to the distance l from the node to the cell’s center of mass is less than theta, all nodes in the given cell are treated as a single node rather than individually."Default: 0.9 |
| distanceMin? | number | "the minimum distance between nodes over which this force is considered.A minimum distance establishes an upper bound on the strength of the force between two nearby nodes, avoiding instability.In particular, it avoids an infinitely-strong force if two nodes are exactly coincident; in this case, the direction of the force is random"Default: 1 |
| distanceMax | number | "maximum distance between nodes over which this force is considered. If distance is not specified, returns the current maximum distance, which defaults to infinity.Specifying a finite maximum distance improves performance and produces a more localized layout"Default: infinity |
X
A positioning force along the x-axis.
| Attribute | Type | Description |
|---|---|---|
| force | "x" | |
| x | LiteralOrFieldOrExpression | The target x-coordinate. |
| strength? | number | "The strength determines how much to increment the node’s x-velocity: (x - node.x) × strength.For example, a value of 0.1 indicates that the node should move a tenth of the way from its current x-position to the target x-position with each application.Higher values moves nodes more quickly to the target position, often at the expense of other forces or constraints. A value outside the range [0,1] is not recommended."Default: 0.1 |
Y
A positioning force along the y-axis.
| Attribute | Type | Description |
|---|---|---|
| force | "y" | |
| y | LiteralOrFieldOrExpression | The target y-coordinate. |
| strength? | number | "The strength determines how much to increment the node’s y-velocity: (y - node.y) × strength.For example, a value of 0.1 indicates that the node should move a tenth of the way from its current x-position to the target x-position with each application.Higher values moves nodes more quickly to the target position, often at the expense of other forces or constraints. A value outside the range [0,1] is not recommended."Default: 0.1 |
Link
"The link force pushes linked nodes together or apart according to the desired link distance. The strength of the force is proportional to the difference between the linked nodes’ distance and the target distance, similar to a spring force."
| Attribute | Type | Description |
|---|---|---|
| force | "link" | |
| // links | NetworkLink[] | "If links is specified, sets the array of links associated with this force, recomputes the distance and strength parameters for each link, and returns this force.Each link is an object with the following properties:source - the link’s source node; see simulation.nodestarget - the link’s target node; see simulation.nodesindex - the zero-based index into links, assigned by this method"Default: [] |
| // id | string // field | "If links is specified, sets the array of links associated with this force, recomputes the distance and strength parameters for each link, and returns this force.Each link is an object with the following properties:source - the link’s source node; see simulation.nodestarget - the link’s target node; see simulation.nodesindex - the zero-based index into links, assigned by this method"Default: [] |
| distance? | LiteralOrFieldOrExpression | "Target link distance"Default: 30 |
| strength? | LiteralOrFieldOrExpression | Strength of this force.Default: 1 / Math.min(count(link.source), count(link.target)) |
| iterations? | number | "number of iterations per application.Increasing the number of iterations greatly increases the rigidity of the constraint and is useful for complex structures such as lattices, but also increases the runtime cost to evaluate the force."Default: 1 |
Radial
"A positioning force towards a circle of the specified radius"
| Attribute | Type | Description |
|---|---|---|
| force | "radial" | |
| radius | LiteralOrFieldOrExpression | The circle radius |
| strength? | number | "The strength determines how much to increment the node’s x- and y-velocity.For example, a value of 0.1 indicates that the node should move a tenth of the way from its current position to the closest point on the circle with each application.Higher values moves nodes more quickly to the target position, often at the expense of other forces or constraints. A value outside the range [0,1] is not recommended."Default: 0.1 |
| x? | number | The x-coordinate of the circle centre. Default: 0 |
| y? | number | The y-coordinate of the circle centre. Default: 0 |
WebCoLa
Use WebCoLa/cola.js tp apply the CoLA layout algorithm. For further details, see https://ialab.it.monash.edu/webcola/doc/classes/_layout_.layout.html
| Attribute | Type | Description |
|---|---|---|
| type | "webcola" | |
| linkDistance? | number | "The automatic layout will compute layout that tries to keep links (AKA edges) as close as possible to this length" |
| constraints? | ColaConstraint[] | "list of constraints of various types" |
| avoidOverlap? | boolean | "if true, the layout will not permit overlaps of the node bounding boxes (defined by the width and height properties on nodes)" |
| defaultNodeSize? | number | "Default size (assume nodes are square so both width and height) to use in packing if node width/height are not specified." |
| handleDisconnected? | boolean | "if true, the final step of the start method will be to nicely pack connected components of the graph.works best if start() is called with a reasonable number of iterations specified and each node has a bounding box (defined by the width and height properties on nodes)." |
| convergenceThreshold? | number | "if true, the final step of the start method will be to nicely pack connected components of the graph.works best if start() is called with a reasonable number of iterations specified and each node has a bounding box (defined by the width and height properties on nodes)." |
| flowLayout? | { axis: "x" "y", minSeparation: number } | "causes constraints to be generated such that directed graphs are laid out either from left-to-right or top-to-bottom.a separation constraint is generated in the selected axis for each edge that is not involved in a cycle (part of a strongly connected component)" |
| jaccardLinkLength? | number | "compute an ideal length for each link based on the graph structure around that link.you can use this (for example) to create extra space around hub-nodes in dense graphs.In particular this calculation is based on the "symmetric difference" in the neighbour sets of the source and target:i.e. if neighbours of source is a and neighbours of target are b then calculation is: |
| symmetricDiffLinkLength? | number | "compute an ideal length for each link based on the graph structure around that link.you can use this (for example) to create extra space around hub-nodes in dense graphs.In particular this calculation is based on the "symmetric difference" in the neighbour sets of the source and target:i.e. if neighbours of source is a and neighbours of target are b then calculation is: |
| numStepsUnconstrained? | number |
Cola constraints
A ColaConstraint is either a ColaInequalityConstraint or a ColaAlignmentConstraint:
ColaInequalityConstraint:
| Attribute | Type | Description |
|---|---|---|
| axis | "x" or "y" | The axis along which the constraint applies. |
| left | number | Index of node 1 |
| right | number | Index of node 2 |
| gap | number | Minimum separation along specified axis (or exact separation, if equality is true). |
| equality? | boolean | If equality is true, then this is an equality constraint |
ColaAlignmentConstraint:
| Attribute | Type | Description |
|---|---|---|
| type | "alignment" | |
| axis | "x" or "y" | The axis along which the constraint applies. |
| offsets | NodeAndOffset[] | Offsets of each node from the alignment line. |
NodeAndOffset:
| Attribute | Type | Description |
|---|---|---|
| node | string | Index of node. |
| offset | string | Offset from alignment line. |
| offset | string | Offset from alignment line. |
SetCoLa
SetCoLa provides a domain-specific language to more concisely express a set of constraints: a SetCoLa specification is used to generate a set of constraints that is supplied to WebCoLa to perform a layout.
SetCoLa is described in a 2018 EuroVis paper.
See examples: Kruger foodweb and small tree.
Tulip
Use a layout algorithm implemented by the Tulip framework.
To use these methods, you will need to run an instance of the Tulip network layout service, which provides a HTTP(S) API, and passes requests to Tulip.
This service provides a list of the available algorithms and the options they accept at /help.
| Attribute | Type | Description |
|---|---|---|
| algorithm | string | The name of the layout algorithm to use. |
| server? | string | The address of the Tulip layout server (default is http://localhost:8080) |
| options? | { [field: string]: string or number} | Additional options to provide |
Cytoscape.js
| Attribute | Type | Description |
|---|---|---|
| type | "cytoscape" | |
| animate? | false | |
| avoidOverlap? | boolean | If true, prevents node overlap. |
| avoidOverlapPadding? | number | "extra spacing around nodes when avoidOverlap is true" |
Grid
"The grid layout puts nodes in a well-spaced grid."
| Attribute | Type | Description |
|---|---|---|
| algorithm | "grid" | |
| rows? | number | "Force number of rows in the grid"Default: undefined |
| cols? | number | "force num of columns in the grid"Default: undefined |
Circle
"The circle layout puts nodes in a circle."
| Attribute | Type | Description |
|---|---|---|
| algorithm | "circle" | |
| startAngle? | number | "where nodes start in radians"Default: 3 / 2 * Math.PI |
| sweep? | number | "how many radians should be between the first and last node (defaults to full circle)"Default: undefined |
| clockwise? | boolean, | "whether the layout should go clockwise (true) or counterclockwise/anticlockwise (false)"Default: true |
Concentric
"The concentric layout positions nodes in concentric circles, based on a metric that you specify to segregate the nodes into levels."
| Attribute | Type | Description |
|---|---|---|
| algorithm | "concentric" | |
| startAngle? | number | "where nodes start in radians"Default: 3 / 2 * Math.PI |
| sweep? | number | "how many radians should be between the first and last node (defaults to full circle)"Default: undefined |
| clockwise? | boolean | "whether the layout should go clockwise (true) or counterclockwise/anticlockwise (false)"Default: true |
| equidistant? | boolean | "whether levels have an equal radial distance between them"Default: false |
| minNodeSpacing? | number | "min spacing between outside of nodes (used for radius adjustment)"Default: 10 |
| concentric? | LiteralOrFieldOrExpression | "Returns numeric value for each node, placing higher nodes in levels towards the centre"Default is node degree |
| levelWidth? | LiteralOrFieldOrExpression | "the variation of concentric values in each level"Default: 4 |
Breadth First
"The breadth-first layout puts nodes in a hierarchy, based on a breadth-first traversal of the graph. It is best suited to trees and forests in its default top-down mode, and it is best suited to DAGs in its circle mode."
| Attribute | Type | Description |
|---|---|---|
| algorithm | "breadthfirst" | |
| circle? | boolean | "put depths in concentric circles if true, put depths top down if false"Default: false |
| grid? | boolean | "whether to create an even grid into which the DAG is placed (circle:false only)"Default: false |
| maximal? | boolean | "whether to shift nodes down their natural BFS depths in order to avoid upwards edges (DAGS only)" Default: false |
| algorithm | "cose" | "The cose (Compound Spring Embedder) layout uses a physics simulation to lay out graphs. It works well with noncompound graphs and it has additional logic to support compound graphs well.It was implemented by Gerardo Huck as part of Google Summer of Code 2013 (Mentors: Max Franz, Christian Lopes, Anders Riutta, Ugur Dogrusoz).Based on the article “A layout algorithm for undirected compound graphs” by Ugur Dogrusoz, Erhan Giral, Ahmet Cetintas, Ali Civril and Emek Demir.The cose layout is very fast and produces good results. The cose-bilkent extension is an evolution of the algorithm that is more computationally expensive but produces near-perfect results.."https://js.cytoscape.org/#layouts/cose |
| componentSpacing? | number | "Extra spacing between components in non-compound graphs"Default: 40 |
| nodeRepulsion? | LiteralOrFieldOrExpression | "Node repulsion (non overlapping) multiplier"Default: 2048 |
| nodeOverlap? | number | "Node repulsion (overlapping) multiplier"Default: 4 |
| idealEdgeLength? | LiteralOrFieldOrExpression | "Ideal edge (non nested) length"Default: 32 |
| edgeElasticity? | LiteralOrFieldOrExpression | "Divisor to compute edge forces"Default: 32 |
| nestingFactor? | number | "Nesting factor (multiplier) to compute ideal edge length for nested edges"Default: 1.2 |
| gravity? | number | "Gravity force (constant)"Default: 1 |
| numIter? | number | "Maximum number of iterations to perform"Default: 1000 |
| initialTemp? | number | "Initial temperature (maximum node displacement)"Default: 1000 |
| coolingFactor? | number | "Cooling factor (how the temperature is reduced between consecutive iterations)"Default: 0.99 |
| minTemp? | number | "Lower temperature threshold (below this point the layout will end)"Default 1.0 |
Avsdf (circular)
"An implementation of the Circular Drawing Algorithm by Hongmei He & Ondrej Sýkora."
| Attribute | Type | Description |
|---|---|---|
| algorithm? | "avsdf" | |
| nodeSeparation? | number | "How apart the nodes are"Default: 60 |
Dagre (for directed acyclic grpahs)
"The Dagre layout for DAGs and trees for Cytoscape.js. The dagre layout organises the graph using a DAG (directed acyclic graph) system, written by Chris Pettitt. It is especially suitable for DAGs and trees."
See the docs.
| Attribute | Type | Description |
|---|---|---|
| algorithm | "dagre" | |
| nodeSep? | number | "the separation between adjacent nodes in the same rank" |
| edgeSep? | number | "the separation between adjacent edges in the same rank" |
| rankSep? | number | "the separation between each rank in the layout" |
| rankDir? | "TB" or "LR" | "'TB' for top to bottom flow, 'LR' for left to right," |
| align? | "UL" or "UR" or "DL" or "DR", | "alignment for rank nodes. Can be 'UL', 'UR', 'DL', or 'DR', where U = up, D = down, L = left, and R = right" |
| acyclicer? | "greedy" or undefined | "If set to 'greedy', uses a greedy heuristic for finding a feedback arc set for a graph.A feedback arc set is a set of edges that can be removed to make a graph acyclic." |
| ranker? | "network-simplex" or "tight-tree" or "longest-path" | "Type of algorithm to assign a rank to each node in the input graph" |
| minLen? | LiteralOrFieldOrExpression | "number of ranks to keep between the source and target of the edge"Default: 1 |
| edgeWeight? | LiteralOrFieldOrExpression | "higher weight edges are generally made shorter and straighter than lower weight edges"Default: 1 |
Elk
"The elk layout algorithm adapter for Cytoscape.jsELK is a set of layout algorithms implemented by the Eclipse Foundation in Java. The source code is compiled to JS by the ELK.js project using GWT."
| Attribute | Type | Description |
|---|---|---|
| algorithm | "elk" | |
| elk.algorithm? | "box" or "disco" or "force" or "layered" or "mrtree" or "random" or "stress" |
This allows the choice of several algorithms:
"The main field to set is
algorithm, which controls which particular layout algorithm is used.
- box : Pack the nodes like boxes.
- disco : Pack the (disconnected) components. A secondary layout may be applied to each component via options.elk.componentLayoutAlgorithm.
- force : Apply a basic force-directed layout.
- layered : Apply a hierarchical layout, appropriate for DAGs and trees.
- mrtree : Apply a traditional, hierarchical tree layout.
- random : Apply random positions to the nodes.
- stress : Apply a force-directed layout"
Default: "layered"
Klay
"The Klay layout algorithm for Cytoscape.js (demo)This discrete layout creates good results for most graphs and it supports compound nodes."
| Attribute | Type | Description |
|---|---|---|
| algorithm | "klay" | |
| priority? | LiteralOrFieldOrExpression | "Edges with a non-nil value are skipped when greedy edge cycle breaking is enabled"Default: () => null |
| klay | KlayOptions |
KlayOptions:
| Attribute | Type | Description |
|---|---|---|
| addUnnecessaryBendpoints? | boolean | |
| aspectRatio? | number | "The aimed aspect ratio of the drawing, that is the quotient of width by height"Default: 1.6 |
| compactComponents? | boolean | "Tries to further compact components (disconnected sub-graphs)."Default: false |
| crossingMinimization? | "LAYER_SWEEP" or "INTERACTOVE" | "Strategy for crossing minimization.LAYER_SWEEP The layer sweep algorithm iterates multiple times over the layers, trying to find node orderings that minimize the number of crossings. The algorithm uses randomization to increase the odds of finding a good result. To improve its results, consider increasing the Thoroughness option, which influences the number of iterations done. The Randomization seed also influences results.INTERACTIVE Orders the nodes of each layer by comparing their positions before the layout algorithm was started. The idea is that the relative order of nodes as it was before layout was applied is not changed. This of course requires valid positions for all nodes to have been set on the input graph before calling the layout algorithm. The interactive layer sweep algorithm uses the Interactive Reference Point option to determine which reference point of nodes are used to compare positions."Default: "LAYER_SWEEP" |
| cycleBreaking? | "GREEDY" or "INTERACTIVE", | "Strategy for cycle breaking. Cycle breaking looks for cycles in the graph and determines which edges to reverse to break the cycles. Reversed edges will end up pointing to the opposite direction of regular edges (that is, reversed edges will point left if edges usually point right).GREEDY This algorithm reverses edges greedily. The algorithm tries to avoid edges that have the Priority property set.INTERACTIVE The interactive algorithm tries to reverse edges that already pointed leftwards in the input graph. This requires node and port coordinates to have been set to sensible values."Default: "GREEDY" |
| direction? | "UNDEFINED" or "RIGHT" or "LEFT" or "DOWN" or "UP", | "Overall direction of edges: horizontal (right / left) or vertical (down / up)"Default: "UNDEFINED |
| edgeRouting? | "ORTHOGONAL" or "POLYLINE" or "SPLINES", | "Defines how edges are routed (POLYLINE, ORTHOGONAL, SPLINES)"Defult: ORTHOGONAL |
| edgeSpacingFactor? | number | "Factor by which the object spacing is multiplied to arrive at the minimal spacing between edges."Default: 0.5 |
| feedbackEdges? | boolean | "Whether feedback edges should be highlighted by routing around the nodes"Default: false |
| fixedAlignment? | "NONE" or "LEFTUP" or "RIGHTUP" or "LEFTDOWN" or "RIGHTDOWN" or "BALANCED" | "Tells the BK node placer to use a certain alignment instead of taking the optimal result. This option should usually be left alone./* NONE Chooses the smallest layout from the four possible candidates.LEFTUP Chooses the left-up candidate from the four possible candidates.RIGHTUP Chooses the right-up candidate from the four possible candidates.LEFTDOWN Chooses the left-down candidate from the four possible candidates.RIGHTDOWN Chooses the right-down candidate from the four possible candidates.BALANCED Creates a balanced layout from the four possible candidates."Default: "NONE" |
| inLayerSpacingFactor? | number | "Factor by which the usual spacing is multiplied to determine the in-layer spacing between objects."Default: 1.0 |
| layoutHierarchy? | boolean | "Whether the selected layouter should consider the full hierarchy"Default: false |
| linearSegmentsDeflectionDampening? | number | "Dampens the movement of nodes to keep the diagram from getting too large"Default: 0.3 |
| mergeEdges? | boolean | "Edges that have no ports are merged so they touch the connected nodes at the same points."Default: false |
| mergeHierarchyCrossingEdges? | boolean | "If hierarchical layout is active, hierarchy-crossing edges use as few hierarchical ports as possible"Default: true |
| nodeLayering? | "NETWORK_SIMPLEX" or "LONGEST_PATH" or "INTERACTIVE" | "Strategy for node layeringNETWORK_SIMPLEX This algorithm tries to minimize the length of edges. This is the most computationally intensive algorithm. The number of iterations after which it aborts if it hasn't found a result yet can be set with the Maximal Iterations option.LONGEST_PATH A very simple algorithm that distributes nodes along their longest path to a sink node.INTERACTIVE Distributes the nodes into layers by comparing their positions before the layout algorithm was started.The idea is that the relative horizontal order of nodes as it was before layout was applied is not changed.This of course requires valid positions for all nodes to have been set on the input graph before calling the layout algorithm.The interactive node layering algorithm uses the Interactive Reference Point option to determine which reference point of nodes are used to compare positions."Default: "NETWORK_SIMPLEX" |
| nodePlacement? | "BRANDES_KOEPF" or "LINEAR_SEGMENTS" or "INTERACTIVE" or "SIMPLE" | "Strategy for Node PlacementBRANDES_KOEPF Minimizes the number of edge bends at the expense of diagram size: diagrams drawn with this algorithm are usually higher than diagrams drawn with other algorithms.LINEAR_SEGMENTS Computes a balanced placement.INTERACTIVE Tries to keep the preset y coordinates of nodes from the original layout. For dummy nodes, a guess is made to infer their coordinates. Requires the other interactive phase implementations to have run as well.SIMPLE Minimizes the area at the expense of... well, pretty much everything else."Default: "BRANDES_KOEPF" |
| randomizationSeed? | number | "Seed used for pseudo-random number generators to control the layout algorithm; 0 means a new seed is generated"Default: 1 |
| routeSelfLoopInside? | boolean | "Whether a self-loop is routed around or inside its node"Default: false |
| separateConnectedComponents? | boolean | "Whether each connected component should be processed separately"Default: true |
| spacing? | number | "Overall setting for the minimal amount of space to be left between objects"Default: 20 |
| thoroughness? | number | "How much effort should be spent to produce a nice layout"Default: 7 |
fCoSE
"fCoSE (pron. "f-cosay", fast Compound Spring Embedder), is a faster version of our earlier compound spring embedder algorithm named CoSE, implemented as a Cytoscape.js extension by i-Vis Lab in Bilkent University."
| Attribute | Type | Description |
|---|---|---|
| algorithm | "fcose" | |
| quality? | "draft" or "default" or "proof", | " - "draft" only applies spectral layout- "default" improves the quality with incremental layout (fast cooling rate)- "proof" improves the quality with incremental layout (slow cooling rate)"Default: "default" |
| randomize? | boolean | "Use random node positions at beginning of layout. If this is set to false, then quality option must be "proof""Default: true |
| samplingType? | boolean | "False for random, true for greedy sampling"Default: true |
| sampleSize? | number | "Sample size to construct distance matrix"Default: 25 |
| nodeSeparation? | number | "Separation amount between nodes"Default: 75 |
| piTol? | number | "Power iteration tolerance"Default: 0.0000001 |
| nodeRepulsion? | LiteralOrFieldOrExpression | "Node repulsion (non overlapping) multiplier"Default: 4500 |
| idealEdgeLength? | 50 | "Ideal edge (non nested) length"Default: 50 |
| edgeElasticity? | 0.45 | "Divisor to compute edge forces"Default: 0.45 |
| nestingFactor? | number | "Nesting factor (multiplier) to compute ideal edge length for nested edges"Default: 0.1 |
| numIter? | number | "Maximum number of iterations to perform - this is a suggested value and might be adjusted by the algorithm as required"Default: 2500 |
| tile? | boolean | "For enabling tiling"Default: true |
| tilingPaddingVertical? | LiteralOrFieldOrExpression | "Represents the amount of the vertical space to put between the zero degree members during the tiling operation"Default: 10 |
| tilingPaddingHorizontal? | LiteralOrFieldOrExpression | "Represents the amount of the horizontal space to put between the zero degree members during the tiling operation"Default: 10 |
| gravity? | number | "Gravity force (constant)"Default: 0.25 |
| gravityRangeCompound? | number | "Gravity range (constant) for compounds"Default: 1.5 |
| gravityCompound? | number | "Gravity force (constant) for compounds"Default: 1.0 |
| gravityRange? | number | "Gravity range (constant)"Default: 3.8 |
| initialEnergyOnIncremental? | number | "Initial cooling factor for incremental layout"Default: 0.3 |
| fixedNodeConstraint? | FixedConstraint[], | "Fix desired nodes to predefined positions [ {nodeId: 'n1', position: {x: 100, y: 200}}, ...]" Default: undefined |
| alignmentConstraint? | SetColaAlignmentConstraint[], | "Align desired nodes in vertical/horizontal direction{vertical: [['n1', 'n2'], [...]], horizontal: [['n2', 'n4'], [...]]} "Default: undefined |
| relativePlacementConstraint? | RelativeConstraint[] | "Place two nodes relatively in vertical/horizontal direction [{top: 'n1', bottom: 'n2', gap: 100}, {left: 'n3', right: 'n4', gap: 75}, {...}]" Default: undefined |
Constraint types are:
FixedConstraint:
| Attribute | Type | Description |
|---|---|---|
| nodeId | string | |
| position | { x: number, y: number } |
SetColaAlignmentConstraint:
| Attribute | Type | Description |
|---|---|---|
| vertical? | string[][] | |
| horizontal? | string[][] |
RelativeConstraintH
| Attribute | Type | Description |
|---|---|---|
| top | string | |
| bottom | string | |
| gap | number |
RelativeConstraintY:
| Attribute | Type | Description |
|---|---|---|
| left | string | |
| right | string | |
| gap | number |
CytoscapeLayoutCoseBilkent
"The CoSE (pron. "cosay", Compound Spring Embedder) layout for Cytoscape.js developed by i-Vis Lab in Bilkent University is a spring embedder layout with support for compound graphs (nested structures) and varying (non-uniform) node dimensions. A faster version of this layout style called fCoSE, also supporting user-defined placement constraints can be found here. Please cite the following when using this layout:U. Dogrusoz, E. Giral, A. Cetintas, A. Civril, and E. Demir, "A Layout Algorithm For Undirected Compound Graphs", Information Sciences, 179, pp. 980-994, 2009."
| Attribute | Type | Description |
|---|---|---|
| algorithm | "cose-bilkent" | |
| quality? | "draft" or "default" or "proof" | "- 'draft' fast cooling rate- 'default' moderate cooling rate- "proof" slow cooling rate"Default: "default" |
| nodeDimensionsIncludeLabels? | boolean | "Whether to include labels in node dimensions. Useful for avoiding label overlapDefault: false*/ |
| refresh? | number | "number of ticks per frame; higher is faster but more jerky"Default: 30 |
| fit? | boolean | "Whether to fit the network view after when done"Default: true |
| padding? | number | "Padding on fit"Default: 10 |
| randomize? | boolean | "Whether to enable incremental mode"Default: true |
| nodeRepulsion? | number | "Node repulsion (non overlapping) multiplier"Default: 4500 |
| idealEdgeLength? | number | "Ideal (intra-graph) edge length"Default: 50 |
| edgeElasticity? | number | "Divisor to compute edge forces"Default: 0.45 |
| nestingFactor? | number | "Nesting factor (multiplier) to compute ideal edge length for inter-graph edges"Default: 0.1 |
| gravity? | number | "Gravity force (constant)"Default: 0.25 |
| numIter? | number | "Maximum number of iterations to perform"Default: 2500 |
| tile? | boolean | "Whether to tile disconnected nodes"Default: true |
| tilingPaddingVertical? | LiteralOrFieldOrExpression | "Amount of vertical space to put between degree zero nodes during tiling"Default: 10 |
| tilingPaddingHorizontal? | LiteralOrFieldOrExpression | "Amount of horizontal space to put between degree zero nodes during tiling"Default: 10 |
| gravityRangeCompound? | number | "Gravity range (constant) for compounds"Default: 1.5 |
| gravityCompound? | number | "Gravity force (constant) for compounds"Default: 1.0 |
| gravityRange? | number | "Gravity range (constant)"Default: 3.8 |
| initialEnergyOnIncremental? | number | "Initial cooling factor for incremental layout"Default: 0.5 |
CiSE
"CiSE(Circular Spring Embedder) is an algorithm based on the traditional force-directed layout scheme with extensions to move and rotate nodes in the same cluster as a group. Further local improvements may be obtained by flipping clusters and by swapping neighboring node pairs in the same cluster, reducing the edge crossing number. The algorithm is implemented as a Cytoscape.js extension by i-Vis Lab in Bilkent University. Please cite the following when using this layout:M. Belviranli, A. Dilek and U. Dogrusoz, "CiSE: A Circular Spring Embedder Layout Algorithm" in IEEE Transactions on Visualization & Computer Graphics, vol. 19, no. 06, pp. 953-966, 2013."
| Attribute | Type | Description |
|---|---|---|
| algorithm | "cise" | |
| nodeSeparation? | number | "separation amount between nodes in a cluster. note: increasing this amount will also increase the simulation time"Default: 12.5 |
| idealInterClusterEdgeLengthCoefficient? | number | "Inter-cluster edge length factor (2.0 means inter-cluster edges should be twice as long as intra-cluster edges)"Default: 1.4 |
| allowNodesInsideCircle? | boolean | "Whether to pull on-circle nodes inside of the circle"Default: false |
| maxRatioOfNodesInsideCircle? | number | "Max percentage of the nodes in a circle that can move inside the circle"Default: 0.1 |
| springCoeff? | number | "Lower values give looser springs; Higher values give tighter springs"Default: 0.45 |
| nodeRepulsion? | number | "Node repulsion (non overlapping) multiplier"Default: 4500 |
| gravity? | number | "Gravity force (constant)"Default: 0.25 |
| gravityRange? | number | "Gravity range (constant)"Default: 3.8 |
CytoscapeLayoutEuler
"Euler is a fast, high-quality force-directed (physics simulation) layout for Cytoscape.js. It is based on cytoscape-ngraph.forcelayout, with several parts reworked and several general improvements." docs
| Attribute | Type | Description |
|---|---|---|
| algorithm | "euler" | |
| springLength? | LiteralOrFieldOrExpression | "The ideal length of a spring- This acts as a hint for the edge length- The edge length can be longer or shorter if the forces are set to extreme values"Default: 80 |
| springCoeff? | LiteralOrFieldOrExpression | " Hooke's law coefficient- The value ranges on [0, 1]- Lower values give looser springs- Higher values give tighter springs"Default: 0.0008 |
| mass? | LiteralOrFieldOrExpression | " Coulomb's law coefficient- Makes the nodes repel each other for negative values- Makes the nodes attract each other for positive values"Default: 4 |
| gravity? | number | "Coulomb's law coefficient- Makes the nodes repel each other for negative values- Makes the nodes attract each other for positive values"Default: -1.2 |
| pull? | number | "A force that pulls nodes towards the origin (0, 0). Higher values keep the components less spread out"Default: 0.001 |
| theta? | number | "Theta coefficient from Barnes-Hut simulation- Value ranges on [0, 1]- Performance is better with smaller values- Very small values may not create enough force to give a good result"Default: 0.666 |
| dragCoeff? | number | "Friction / drag coefficient to make the system stabilise over time"Default: 0.02 |
| movementThreshold? | 1 | "When the total of the squared position deltas is less than this value, the simulation ends"Default: 1 |
CytoscapeLayoutSpread
"The spread layout uses a force-directed physics simulation with several external libraries. The layout tries to keep elements spread out evenly, making good use of constrained space.The layout makes use of CoSE (MIT) and rhill-voronoi-core.js (MIT). CoSE is already bundled in Cytoscape.js, and rhill-voronoi-core.js is bundled in cytoscape-spread. There are two phases to this layout:
(1) A force-directed layout provides initial positions for the nodes. By default, the embedded version of CoSE is used, because it is fast and because it does not increase your app's bundle size any more than using Cytoscape.js itself. You can use an alternative layout by specifying options.prelayout with the layout options you want to use for the first phase (e.g. { name: 'grid' }) Alternatively, you can specify options.prelayout: false (falsey) to just use the node's existing positions for the first phase.
(2) Voronoi is used to spread out the nodes in the remaining space. Note that since you are composing layouts with phase (1), where options.prelayout is non-falsey, you will have more layout events. For example, you will have more than one layoutstop event -- one for the Spread layout overall and one for the prelayout within phase (1) of Spread. If you skip phase (1) with options.prelayout falsey, you will not get extra events within Spread. You can use promise chaining with two layouts to get the same effect as running a layout in phase (1):"
| Attribute | Type | Description |
|---|---|---|
| algorithm | "spread" | |
| prelayout? | any | "Layout options for the first phase"Default "{ name: 'cose' }" |
| maxExpandIterations? | number | "Maximum number of expanding iterations"Default: 4 |
| randomize? | boolean | "Uses random initial node positions on true"Default: false |
Graphviz
Graphviz is useful to render DAG and trees.
See the docs.
| Attribute | Type | Description |
|---|---|---|
| algorithm | "graphviz" | |
| nodeSep? | number | "the separation between adjacent nodes in the same rank" |
| edgeSep? | number | "the separation between adjacent edges in the same rank" |
| rankSep? | number | "the separation between each rank in the layout" |
| rankDir? | "TB" or "LR" | "'TB' for top to bottom flow, 'LR' for left to right," |
| minLen? | LiteralOrFieldOrExpression | "number of ranks to keep between the source and target of the edge"Default: 1 |
| edgeWeight? | LiteralOrFieldOrExpression | "higher weight edges are generally made shorter and straighter than lower weight edges"Default: 1 |
| rank? | LiteralOrFieldOrExpression | "The field indicating the ranks of nodes. Nodes with the same rank will appear on the same layer." |
| addedDot? | string | "dot string added to the dot specification. Can be used to add specific nodes, links, subgraphs, or specific dot parameters |
BioFabric
A layout in which nodes are represented by rows, and edges are vertical lines (see BioFabric.org and Combing the hairball with BioFabric: a new approach for visualization of large networks).
Note that the stand-alone Java application is much more scalable to larger networks that the implementation in NetPanorama.
As each link attached to a node has a different horizontal position, this can be considered to be a layout of a transformed network, in which each (node, link) combination in the original network has been replaced by a new node.
The transform also creates a new network, whose name can be set using the newNetworkName attribute.
Each node on the transformed network records the id of the original node that it was generated from; this id may be useful in interactions.
| Attribute | Type | Description |
|---|---|---|
| type | "bioFabric" | |
| name | string | A layout in which nodes are represented by rows, and edges are vertical lines.As each link attached to a node has a different horizontal position, this can be considered to be a layout of a transformed network,in which each (node, link) combination in the original network has been replaced by a new node.The name that will be given to the layout when it is created. |
| linkTypeColName? | string | Used to order links between the same pair of nodes. |
| saveIdAs? | string | The transformed network will contain new nodes, with different ids, but the ids of the original nodes that they were generated from will be saved as an attribute with this name (default: "_originalId"). |
| newNetworkName? | string | Name for the reshaped network (defaults to the name of the original network followed by "#BioFabric"). |
Bipartite Layout
The bipartite layout assigns each node to one of two layers. The nodes in one layer are assigned positions by applying a scale or ordering. The nodes in the other layer are positioned at the barycenter of the fixed nodes that they are connected to.
| Attribute | Type | Description |
|---|---|---|
| inFirstLayer | expression | If this expression evaluates to true for a node, then it is assigned to the first layer. |
| fixedLayer | 1 or 2 | Specifies whether the nodes in the first or second layer should be held fixed. |
| y | DimensionSpec | Determines positioning of nodes in fixed layer. |
| x | DimensionSpec | Determines positioning of nodes in fixed layer. |
Note that only one of x or y should be specified; which is used determines the orientation of the layout.