What is the graph layout algorithm that is used in Neo4j?
I would like to have the paper that explain the graph layout algorithm that is shown in NEO4J.
I wan to know why the nodes are organized in the way Neo4j presents them.
The layout algorithm used for visualizing graphs in the Neo4j browser is a force directed algorithm. From Wikipedia:
Their purpose is to position the nodes of a graph in two-dimensional or three-dimensional space so that all the edges are of more or less equal length and there are as few crossing edges as possible, by assigning forces among the set of edges and the set of nodes, based on their relative positions, and then using these forces either to simulate the motion of the edges and nodes or to minimize their energy.
For academic references, there is a chapter from the Handbook of Graph Drawing and Visualization that covers much of the literature here.
In addition to the Neo4j Browser code linked in stdod--'s answer there is a D3 example of force directed layout here.
To visualize a graph in the neo4j-browser is used d3 library.
View implementation of d3.layout.force here: layout.ts.
Related
Is there any domain (/ dedicated keyword) of graph theory that covers graphs where the edges represent forces?
Force is a vector. Thus, it has two attributes: weight, and direction.
weight represents the magnitude of the force.
direction represents the direction in which the force is acting. This direction is different from directed graphs where only the head or tail nodes matter.
The sense of direction can be better understood by the following examples:
Example 1:
Consider a network of inelastic strings under tension. Let's say the network is under equilibrium. If we pull a node, all other nodes will be pulled. Please note, the length of the strings (~ weight) won't change. But, the locations of the nodes and thereby the direction of the strings may change to bring all the nodes back to equilibrium after the pull.
Example 2: Consider all the planets (~nodes) in the universe in the form of a graph. All of them impart gravitational force (~edges) on each other and are under equilibrium. If we dislodge (or increase the size) of a planet/sun, others are likely to disturb.
The edge weight/length can represent the magnitude of force (But, direction??).
In both the example, the direction component differ them from traditional sense of edge weights where the edges are just scalars. They, do not have direction.
The scalars can be analogous to a sense of distance (shortest distance, eccentricity, closeness centralities) or flow (betweenness centrality etc.); but not force.
The question is How to incorporate direction of edges (in addition to length/weight) in network analysis? Is there any domain that focuses on graphs where edges have weights as well as direction?
Note: The direction of the edge can be an additional parameter like angle; or be specified by the location of the connecting nodes.
What you're describing sounds like force-directed graph drawing algorithms as discussed here. Since you tagged this with networkx, the spring_layout method uses the Fruchterman-Reingold force-directed algorithm.
The networkx documentation doesn't list an actual reference to the algorithm, but the R igraph package lists this as the reference for their layout_with_fr function:
Fruchterman, T.M.J. and Reingold, E.M. (1991). Graph Drawing by Force-directed Placement. Software - Practice and Experience, 21(11):1129-1164.
this seems to be a repeated questioned. But I did not get the expected results following previos Q/A. I am exploring things that I did not have time in the past. It is for my own enrichment only. My background in Java is almost non-existing and struggling with Jung too.
These are what I have done (or trying to do):
(1) Define network topology with MIT network GNU Octave toolbox, i.e., vertices and edges.
(2) Define Jung graph vertices and edges in a Java class I put together. Octave invokes the class method.
(3) Vertex layout in Jung with the graph and dimension. KKLayout selected.
(4) Visualization of the layout in Jung.
(5) Output the post-layout vertices (and their xy) and edges back to Octave.
xy of the vertices are located similar to How to use JUNG layout transformations correctly? except that the posting as it is would not compile. Instead, I sent the graph to Abstractlayout and used the transform operated on the graph vertices to generate the xy, as other posts suggested or my understanding of other posts. Abstractlayout is the only layout interface provides the getX and getY methods I found. So I cannot use KKlayout to export xy by design.
However, I am not getting the xy in (5) as shown in (4). The edges appear to be correctly returned. But the xy of the vertices are completely different. See the attached picture.
I further compared the xy within my Java class vs. what is in Octave. They are the same. So, I am getting vertices xy but not the xy used for visualization.
My question is how to extract the vertices xy after Jung layout in 2.0.1? Is there an example that I can follow?
two results
I was recently going through Topological Sort and DFS from CRLS. They have this entry/exit time concept by which we can classify graph edges into
tree edge
forward edge
back edge
cross edge
So the question is - does Topological sort using DFS try to remove forward edges from the tree keeping only tree edges to arrive at the sorted result?
Note that if a graph has a back-edge, it is not a DAG (Directed Acyclic Graph) since it contains a cycle and hence cannot be topologically sorted.
When we're topologically sorting, we are not removing any edge, we're simply providing a linear order so that edges only travel in one direction: from nodes that appear earlier in the order to nodes that appear later. Forward edges are certainly allowed to exist is such an order. What kind of topological order do you believe the following graph exhibits?
I have been searching online and trying to understand the literature I have, but something is eluding me.
Given a SOM, when visualized with a U-Matrix, does the U-Matrix represent the distance between a given node and every other node, or the distance between a node and its direct neighbours?
Regards,
Jack Hunt
EDIT:- Suggestions for alternative visualization techniques are welcome.
Generally the color of a node in the U-matrix is based on the distance between neighboring nodes in the lattice (link). There are other ways to color a U-matrix, but that is the most common.
Other visualization techniques depend entirely upon your data and what you are looking for.
I'm drawing graphs with force-directed layout, and the problem is that the created graphs are oriented randomly and unpredictably, which makes looking at them somewhat confusing. For example, suppose node A is a member of the two separate graphs G1 and G2. With force-directed layout, node A may end up on the left side of G1, but on the right side of G2.
Now I'm trying to reduce the confusion by automatically rotating the graph in a deterministic way after the graph layout algorithm has been applied to it. One could compute the minimum bounding rectangle for this, but it would be nicer if the rotation algorithm could include some of the additional information on the vertices and edges.
In this case, each vertex is a document with a timestamp and a word count, and the edges represent undirected and directed relationships between the documents. Perhaps there's a way to rotate the graph so that older documents concentrate on the left, and newer ones on the right? Same with links: The arrows should point more to the right than to the left. This sounds like a reasonable approach, but I have no idea how to calculate something like this (and Google didn't really help either).
Notes:
I think there are graph layout algorithms that take care of the rotation, but I'd prefer a solution that involves force-directed layout.
One could let the user rotate the graph by hand, but this requires saving the graph orientation, which is something I'd prefer to avoid, cause there's no room for this in the document database.
You can either use
a dynamic force-directed algorithm that preserves a user's mental map between frames (e.g. Graph Drawing in Motion, in Journal of Graph Algorithms and Applications (JGAA), 6(3), 353–-370, 2002), or
Procrustes Analysis to translate, rotate and scale frames so that the relative positions of "landmarks points" are preserved.
You may use a layout which uses a seed to generate random numbers. Try the Yifan Hu multilevel algorithm in Gephi.