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

mode=:error_estimate gives wrong results for long times #160

Closed
axsk opened this issue Jan 12, 2024 · 3 comments · Fixed by #165
Closed

mode=:error_estimate gives wrong results for long times #160

axsk opened this issue Jan 12, 2024 · 3 comments · Fixed by #165
Labels
bug Something isn't working

Comments

@axsk
Copy link

axsk commented Jan 12, 2024

Describe the bug 🐞

expv(t, A, b, mode=:error_estimate) gives vastly different results for longer time-steps.

Expected behavior

I would expect error_estimate and happy_breakdown results to at least have the same magnitudes

Minimal Reproducible Example 👇

A = I - sprand(100,100,.1) * .1
b = rand(100)
@assert expv(10, A,b)  expv(10, A,b ,mode=:error_estimate)

Error & Stacktrace ⚠️

julia>  expv(10, A,b)
100-element Vector{Float64}:
  19372.458459100264
 -57030.13477800453
   3852.973450336655
  -7684.450057227177

julia>  expv(10, A,b ,mode=:error_estimate)
100-element Vector{Float64}:
 -3.1939130045290945e15
  4.314219301303509e15
 -1.6738861310296682e15
 -4.276422508317541e15

Environment (please complete the following information):

  • Output of using Pkg; Pkg.status()
[d4d017d3] ExponentialUtilities v1.25.0
  • Output of versioninfo()
julia> versioninfo()
Julia Version 1.10.0
Commit 3120989f39b (2023-12-25 18:01 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 64 × AMD EPYC 7502P 32-Core Processor
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-15.0.7 (ORCJIT, znver2)
  Threads: 11 on 64 virtual cores
Environment:
  JULIA_HISTORY = ./.history.jl_
@axsk axsk added the bug Something isn't working label Jan 12, 2024
@daviehh
Copy link
Contributor

daviehh commented Feb 13, 2024

It's been a while since I last read through the code, but iirc the error estimation routine only implements the Lanczos algorithm, i.e. mostly for Hermitian (or, in your real-valued case, symmetric) matrices.

# Currently only expv for Lanczos is implemented.

for j in 1:m
lanczos_step!(j, A, V, α, β)
expT!(@view(α[1:j]), @view(β[1:j]), t, cache)
# This is practical error estimate Er₂ from
#
# Saad, Y. (1992). Analysis of some Krylov subspace
# approximations. SIAM Journal on Numerical Analysis.
σ = β[j] * Ks.beta * abs(cache.v[j])
verbose && @printf("iter %d, α[%d] %e, β[%d] %e, σ %e\n", j, j, α[j], j, β[j], σ)
if σ < ε
Ks.m = j
break
end
end
verbose && println("Krylov subspace size: ", Ks.m)

Note with your example, with a symmetric A A += A' the results do agree w/

expv(10, A, b) - expv(10, A, b, mode=:error_estimate)

--
more details:
the non error-estimation expv call uses the arnoldi method which only switches to the Lanczos step based on the isherimtian argument

ishermitian &&
return lanczos!(Ks, A, b; tol = tol, m = m, init = init, t = t, mu = mu, l = l)

however, the implementation of the error-estimation just checks the KrylovSubspace type

function get_subspace_cache(Ks::KrylovSubspace{T, U}) where {T, U <: Complex}
error("Subspace exponential caches not yet available for non-Hermitian matrices.")
end

@ChrisRackauckas
Copy link
Member

So if you do :error_estimate and are non Hermition, we should throw an error saying that it's an inappropriate choice of error estimator?

@daviehh
Copy link
Contributor

daviehh commented Feb 14, 2024

@ChrisRackauckas Yes, would make sense since it assumes Lanczos/tridagonal KrylovSubspace.H to use with the stegr call

LAPACK.stegr!(α, β, cache.sw)

correction in PR. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants