SpringEmbedderPositioner

The SpringEmbedderPositioner does not provide absolute positions of the nodes. Instead of absolute positions a SpringEmbedderPositioner orders the nodes in such a way, that nodes being in a neighborhood relationship attract each other while the others repulse. For this reason the positions change dynamically.

All attraction and repulsion forces are being computed for all nodes in the network one after another once a second. Thus, the positions of all nodes might change permanently, since the distance between the nodes and thus the forces of attraction and repulsion change in every round.

Additionally to these positions, the SpringEmbedderPositioner stores the current absolute position. So, if an instance of the PositionPacketNodePositioner plugin becomes active after a SpringEmbedder instance, the new instance will be initiated with the absolute positions of all known nodes.

If a SpringEmbedderPositioner instance is being activated while another NodePositioner is running, the new instance will be provided with all nodes and its absolute positions by the old instance. Each of these nodes gets a random po- sition as a start position for the dynamic computing. The same is valid for new nodes during the running time of the instance.

There are several values to configure for a SpringEmbedderPositioner instance which is shown in the image below. Like a PositionPacketNodePositioner the SpringEmbedderPositioner has time-to-live for all nodes. If a node does not send a packet for a duration which is longer than this time-to-live-interval, it will be removed.

The most important value is/are the semantic type(s) of the packets, that provide the neighborhood information. If a node sends such a neighborhood packet (see Packet Format and Packet Types), it will be attracted by all its neighbors contained in the packets payload. This does not include the reverse, so a sender of the packet does not attract all its neighbors. A node A is only being attracted by another node B, if node A is contained in a neighborhood packet sent by node B.

The other configuration values are algorithm specific. The optimum spring length represents the distance, where the attraction force between to nodes comes into a resting state. The spring stiffness defines, how fast the positions of the nodes converge to this resting state. The value must be greater than 0 and not greater than 1.

The repulsion factor defines the dimension of repulsion between all nodes, while the efficiency of forces regulates the speed of the nodes movement. It must be greater than 0 and not greater than 1. Since these values are very network specific, they should be fitted to the current requirements on demand.

The example given in the image below bases on a network where nodes 1,2 and 3 have a neighborhood relationship to the node 100 and vice versa. This is also true for 1 and 10-19, 2 and 20-29 and 3 and 30-39. Thus e.g. node 100 has three neighbors, node 2 has 11 neighbors and node 20 has one neighbor. The figure shows the final resting position of the nodes. Actually there is no resting position since the algorithm for repositioning the nodes never comes to an end. But the changes decrease as longer the algorithm runs.

Since the PositionPacketNodePositioner provides absolute positions, it provides metrical information. The SpringEmbedderPositioners positions are not metric. Since some plugins can only display expedient information if the active NodePositioner instance provides its positions in such a metric way, all those instances are deactivated automatically when a SpringEmbedderPositioner instance is getting active. A warning window appears before the automatic deactivation, so the operation can be stopped. If a plugin needs metrical information or not is described in the appropriate chapter.