Closed colin-daniels closed 5 years ago
Input that fails faster (8 seconds).
Maybe this one https://gist.github.com/db7a5ffbf1d9cb9d2f19cd3a8af3068f
Edit: All of them relaxed.tar.gz
Note to self: Do not close without replacing this error message with something clearer.
(it happens when the python script returns no eigenvectors)
on the second input, k=12
is super slow, and k=300
completed almost instantly. Looks like perhaps all we need is more lanczos vectors for speedier convergence of non-shift-invert
Edit: Nope, that's not it. Something else must have been running in the background and I didn't realize it. (besides, now that I think about it, BOTH the shift-invert and non-shift-invert calls sped up, but I only changed the non-shift-invert one)
This is bizarre.
The number of lanczos vectors is irrelevant. Simply requesting more solutions apparently has an impact on convergence speed.
from scipy.sparse.linalg import eigsh, ArpackNoConvergence
def num_sols(*args, **kw):
try: return len(eigsh(*args, **kw)[0])
except ArpackNoConvergence as e:
return len(e.eigenvalues)
m = # load gamma-dynmat from a failed run of 3agnr_l21
# Consistently finishes quickly and prints 300
print(num_sols(m, which='SA', k=300, ncv=601))
# Consistently takes several minutes and prints 12
print(num_sols(m, which='SA', k=12, ncv=601))
I looked through scipy's code and k
doesn't affect anything else besides the NEV
and NCV
arguments to ARPACK. Whatever is going on here must be happening somewhere in ARPACK.
Timings of running sparse diagonalization on that input for various values of k, averaged over 20-ish something runs for each k.
A few distinct portions of the are seen in the graph of runtime vs k:
I want to obtain timings for various sizes of matrices, as well as for matrices with strongly imaginary modes vs matrices without imaginary modes, but currently do not have saved matrices of reasonable size.
A couple of weeks ago, I tried to improve the error by throwing an error on the python end, but I just realized two things today:
EOF while parsing a value at line 1 column 0
So I should do something about that as well
The EOF while parsing
error was trivial to fix (b9c4f9d0b4a4b908585f83a81df578e82b8dcc15). I can't believe I left the issue open this long.
I'll make a new issue about the performance stuff.
Inputs.