Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Every GMRES Algorithm Fails Silently From Stagnation #297

Closed
packquickly opened this issue May 3, 2023 · 4 comments
Closed

Every GMRES Algorithm Fails Silently From Stagnation #297

packquickly opened this issue May 3, 2023 · 4 comments

Comments

@packquickly
Copy link

Every implemented GMRES algorithm often fails to converge when restart is less than the problem dimension, but will return without indicating failure.

This failure (likely due to stagnation) seems to depend on the absolute difference between the problem dimension and the Krylov subspace dimension (gmres_restart.) The rate of failure is slightly different for each algorithm, but the lowest failure rate resulting from a 1-dimensional difference in the example case I provided is 30%, ie. problem_dim = 100 and gmres_restart = 99 will silently fail and return an incorrect solution ~30% of the time. As will problem_dim=25 and gmres_restart=24. If the difference is 5 dimensions, that failure rate is 90% for KrylovKit, and >99% for the other two algorithms.

See the issues raised here for reproducing code:
JuliaLinearAlgebra/IterativeSolvers.jl#338
Jutho/KrylovKit.jl#70
JuliaSmoothOptimizers/Krylov.jl#729

@ChrisRackauckas
Copy link
Member

It sounds like these are upstream issues?

@packquickly
Copy link
Author

Not entirely.

  1. We probably don't want users to need to understand that GMRES can fail silently sometimes regardless of upstream implementation.
  2. Krylov.jl returns a stats object which we can use to detect this failure mode. However, when used to solve a linear system in LinearSolve.jl this information is not returned and the failure becomes silent.

@packquickly
Copy link
Author

Actually, on further inspection Krylovkit.jl catches this as well (albeit does not raise an error, grr) and this information seems lost in the call to LinearSolve.jl

ChrisRackauckas added a commit that referenced this issue Jun 18, 2023
This solves #297. KrylovKit.jl already throws `ReturnCode.Failure` if it doesn't converge, IterativeSolvers.jl doesn't have it possible, and now Krylov.jl is using retcodes. So now nothing is silent on non-convergence when it's possible to be known from the solver. This also fixes #298
@ChrisRackauckas
Copy link
Member

This was fixed back in #334

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants