Algebraic connectivity, Fiedler vector and spectral ordering #1134
Conversation
Looks good. I think the tracemin implementation could be vectorized more, but that doesn't need to be in this PR. By the way, the application of Laplacian system solvers to graph algorithms is trendy, for example |
|
@chebee7i The remaining question is whether I should restore the Cholesky solver from |
|
The question is whether to paste scikits.sparse code into networkx so that if users have CHOLMOD separately installed then they can use it through this wrapper? |
|
@argriffing Importing from |
|
TLDR: I vote for including it. My personal opinion is that open source software packages are too fussy in deciding whether to use other open source packages. If a mistake is made (wrt licensing), it's not as if it was done in bad faith. So if someone upstream makes an issue of it and has weight to throw around, then we change it. No big deal. We are not lawyers and the legal status of linking and derivative works, especially as it relates to Python's run-time compiled modules, is still undecided. Due to project relevance, we are also probably some of the least likely projects to face litigation . IMO, simply typing: Interesting discussion in this thread...here are two views similar to what i just described: Grant Edwards: https://groups.google.com/forum/#!msg/comp.lang.python/zYZGRRqs_Mk/cMJkm9gfi-0J |
Conflicts: networkx/linalg/algebraic_connectivity.py
This reverts commit 1be3dd8. Conflicts: .travis.yml networkx/linalg/algebraic_connectivity.py
|
@argriffing I wonder what you mean by "vectorization" here. I suppose that it is not the same thing as what you get from BTW, for the orthonormalization step in TraceMIN I had wanted to use |
@ysitu I just meant avoiding the python loops |
I haven't checked this in detail but given that its first line https://github.com/scipy/scipy/blob/master/scipy/linalg/decomp_svd.py#L201 calls svd without specifying extra options, and given that svd without extra options computes full MxM and NxN matrices https://github.com/scipy/scipy/blob/master/scipy/linalg/decomp_svd.py#L15 I would agree that appears to unnecessarily bomb the memory. |
|
I've added a PR to fix the |
|
I think that I have no further planned changes. Here are the latest benchmarking results (let me omit ARPACK and SuperLU to save testing time): |
|
Great work @ysitu! This is very, very nice. I've tagged this as 1.9 because it seems that it's ready for merging, but I didn't look at it closely. Any more comments? |
It looks well tested so I assume it works, and I can vouch that it provides functions that are useful for spectral graph theory. I hope it is merged soon! |
|
Merging... |
Algebraic connectivity, Fiedler vector and spectral ordering
This addresses #1123.
This basically involves finding the second smallest eigenvalue and its eigenvector of the Laplacian matrix of a graph. Supposedly, this should be handled by SciPy, but I included an one extra algorithm so that for each of my eight test problems, at least one algorithm solves it within 10 seconds.
Algorithms
To be clear up front, NumPy alone or anything based on dense matrices will not do the job as it will become a memory bomb when used on large graphs. SciPy provides two sparse solvers
eigshandlobpcg.eigshis the implicitly restarted Lanczos iteration from ARPACK.lobpcgstands for "locally optimal block preconditioned conjugate gradient". I know about the "PCG" part but not the "LOB" part.The algorithm not from SciPy is TraceMin. I am using a version specifically designed for finding Fiedler vectors. TraceMin relies on a linear system solver. PCG is an obvious options. But personally I prefer sparse direct solvers as they are robust, and their comfort zone well covers the graph sizes within NetworkX's reach. SciPy bundles SuperLU as
splu. There are better options, but they are shut out by licensing issues—UMFPACK, CHOLMOD and PARDISO all fall into this category.Benchmarking
The second column in the computed eigenvalue, and the third column is the time in seconds. The numbers in brackets are the Cholesky/LU factorization times. Cholesky factorization relies on the GPL
scikits.sparsewrapper for CHOLMOD. For this reason, the related code is not in this PR. I suppose thatscikits.sparsecan be stripped down to use only the LGPL portion of CHOLMOD and become LGPL itself, but I am not familiar with Cython to do the work.From the data, it is evident that
eigshis not nearly as robust as the rest, although it can be fast at times.lobpcgandTraceMin_chol/luboth have good and bad cases, whileTraceMin_pcgsits somewhere between the two. It should be noted that forlobpcgandTraceMin_pcg, I am using only Jacobi preconditioning. (In separate tests, passing the Cholesky factorization as the preconditioner tolobpcgimproves its bad cases by at least an order magnitude but produces incorrect results in one case.)lobpcgis very sensitive to the initial guess and can fail to converge if it is not good enough. I produce an estimate of the Fiedler vector using the reverse Cuthill–McKee ordering. The same estimate does not seem to help TraceMin.The effectiveness of Cholesky/LU factorization highly depends on the structure of the matrix and the matrix reordering algorithm. For example, both
gl6andgw6are three-dimensional grid graphs.gw6has a larger bisection width and thus requires long time to factorize. The METIS library used by CHOLMOD is much more effective in discovering small bisections than the multiple minimum degree algorithm used by SuperLU. As a result, CHOLMOD is more than 40 times faster in factorizinggw6. (As a separate issue, it may be of interest to some users if NetworkX includes graph ordering and partitioning functionalities.)