Hello,
I'm trying to reduce a multigraph to a single graph in order to run a community detection algorithm on it. See my discussion here for more context. I solved the crashing/out of memory issues by using apoc.periodic.iterate to create the reduce...
I am trying to reduce a multigraph to a single graph using the following query for the cypher projection:
CALL gds.graph.create.cypher(
'myGraph',
'MATCH (n:WebContent {componentId: 0} ) RETURN id(n) AS id, labels(n) as labels,',
'MATCH (...
The docs for the Louvain algorithm mention that when doing the seeded approach, "the algorithm will try to keep the seeded community IDs", which is very vague. And after doing some testing, I did confirm that seeded community IDs can be overwritten -...
Actually I think it ultimately still comes down to a memory issue, caused by the count(m) operation between n1-n2 pairs.. The execution plan when I run this on a smaller component (of about 1500 WebContent nodes) shows that it takes 22MB of memory j...
Thanks for the reply; yeah, after looking at the results of PROFILE on a smaller component, I definitely think it's a cardinality issue and is running unnecessary duplicate operations. I'm trying to figure out how this query can be written differentl...
Here is what it's showing in the logs - it's due to an OutOfMemoryError:
Feb 17 01:24:38 ip-10-0-0-96 neo4j[179982]: Terminating due to java.lang.OutOfMemoryError: Java heap space
Feb 17 01:24:38 ip-10-0-0-96 systemd[1]: neo4j.service: Main process e...
Thanks for your response Michael! So is the advantage of providing seed IDs simply for performance improvement - i.e. it reaches the optimal modularity faster (assuming many have not changed communities)? I just want to make sure I understand the ben...
