Installing Arpack in the containers #3323
Conversation
|
Have you considered using Arpack++ as well? |
The initial code was using Arpack++ but that library is not very readily available, in particular, it can not be installed using spack. Because, we were just using a single function from Arpack I went ahead and called the fortran routines directly. |
|
I can build and push the container if there's agreement to add this, though would you mind laying out your plans for Arpack here so I get an idea what you want to use it for? |
|
@nilsleiffischer the PR description has been updated to answer your question. |
|
Thanks for explaining @GitHimanshuc! I'm building the container now and will merge this PR once I have pushed the container to Dockerhub. Have you tried a matrix-free approach with Arpack to avoid building the matrix explicitly? I think Arpack supports this. The idea is to provide only a function that computes the matrix-vector product, instead of the explicit matrix. The matrix-vector product is all that typical iterative algorithms need. In many cases, when the matrix becomes too large to build explicitly, the matrix-free approach is the way to go. I don't know enough about the Strahlkoerper eigenvalue problem to understand if this approach can also work for you. We can discuss this further in #3211. |
Proposed changes
Installs Arpack in the containers
Why we need Arpack
Short version
Using Arpack makes the finding the spin of black hole with highly deformed horizons much faster.
Slightly longer version
StrahlkorperGr needs to solve a generalized eigenvalue problem (M x = \lambda B x) to find the spin of a Black Hole. Right now we are using Lapack's dggev to solve this but dggev has a very bad scaling O(L^6), where L is the highest degree spherical harmonic used to describe the horizon. The reason dggev is not ideal for us is because it finds all the eigenvectors of the system while we only need those corresponding to the three smallest eigenvalues.
In Arpack we can specify the eigenvectors that we want and it will solve only for those. Because the matrices that we are working with can get quite large (number of rows = L^2) there is a significant time difference in finding all the eigenvectors and finding just the three that we need.
Two most costly steps in finding the spin are generation of the matrices (M and B) and then solving the eigenvalue problem.
When L is around 80, dggev takes close to 30minutes to run and the matrix generation takes around 2mins. If we use Arpack then the time to find the three eigenvectors goes below 10seconds (majority of this is doing the LU decomposition required by Arpack) and the matrix generation still takes 2mins. Thus, we reduce the total time from 30mins to 2mins.
Note that this becomes relevant only when L goes beyond 60-70. Before that the generation of the matrices is the slowest step. Another advantage is that the matrix generation, which is the bottleneck when using Arpack, scales as O(L^4) unlike dggev which scales as O(L^6).
#3211 is the PR which replaces dggev with Arpack