I’m trying to use eigs and I’m running into arparck errors. More specifically, when eigs doesn’t converge the function itself doesn’t throw or return some kind of flag (even though that is what the documentation seemed to suggest, it returns an nconved value after all), but the arparck wrapper throws an unspecified error (1).
This is cryptic and I was wondering if this could be improved a bit? A few months earlier I ran into a similar unspecified error (-1), and that was because my particular matrix had “Inf” values.
More importantly, in my particular use-case I’m solving the eigenvalue problem a number of times, everytime increasing the desired precision.
So really, it not converging at first is not that big of a problem, but I’d still like to retrieve the partially converged eigenvectors. Is there any way to do this? Ideally I’d get the partially converged result along with a bound on the error.
Throwing an error for partial convergence seems to be an oversight in an inadequately reviewed commit. Result flags from the ARPACK library are themselves not very consistent, so the wrapper developers deserve some sympathy. Probably this merits an issue at the usual place.
More immediately, you should see whether increasing maxiter and/or ncv arguments to eigs helps for your problem (perhaps that’s what you meant by “increasing the desired precision”?). From what I’ve seen (as an experienced user, not an actual mathematician), one can fruitfully analyze the accuracy of an eigenvalue which ARPACK calls converged, but any others are rather wild. Qualification of eigenvectors is harder.
Someone opened an issue about this and it got closed so I wasn’t entirely sure if it was desired behavior or not.
Increasing maxiter does help but right now I have a for-try-catch-loop where I increase maxiter everytime I get an exception. It’s a bit … ugly. Not only that, this code is part of an iterative scheme where the matrix is calculated using it’s biggest eigenvector (and vice versa) so I don’t really need to have fully converged eigenvectors in the first few iterations (which is when eigs fails).
I’m going to open an issue and see what happens, thanks for the help.
Expert users might want to avoid an error but less experienced users might accidentally use the eigenvalues without noticing that the values haven’t converged if no error is thrown. Maybe we should have a keyword argument to specify the behavior when ARPACK fails.
3 Likes
Even more than just expert vs less experienced, I think there’s also a difference between interactive REPL usage and library function usage. In the REPL, you don’t want to check flags and all of that: an error is nice to tell you not to trust the output. But in a library, you want full control.
I think this points to having an argument to switch the behavior as the most reasonable way forward.