-
-
Notifications
You must be signed in to change notification settings - Fork 218
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
Exponential RK + Krylov + large, complex ODE system = segfault #1447
Comments
That looks like JuliaLang/LinearAlgebra.jl#754 . Which Julia version are you using? |
|
Can confirm x = zeros(ComplexF64, 10001)
x' * x reproduces |
I think that should be fixed on 1.6.1. Are you using the Julia office binary from https://julialang.org/downloads/ ? |
Yes, official binary |
I see. Do you mind to try Julia v1.7 beta out to see if the problem persists? I couldn't reproduce this segfault myself on 1.6.1. |
BTW, I cannot run the MWE you posted. It errors with julia> # krylov=true required
# Also errors with ETDRK4
sol = solve(prob,LawsonEuler(krylov=true);dt = 0.01)
ERROR: MethodError: no method matching eigen!(::SymTridiagonal{ComplexF64, Vector{ComplexF64}})
Closest candidates are:
eigen!(::SymTridiagonal{var"#s832", V} where {var"#s832"<:Union{Float32, Float64}, V<:AbstractVector{var"#s832"}}) at /Users/scheme/.bin/julia-release/usr/share/julia/stdlib/v1.6/LinearAlgebra/src/tridiag.jl:280
eigen!(::SymTridiagonal{var"#s832", V} where {var"#s832"<:Union{Float32, Float64}, V<:AbstractVector{var"#s832"}}, ::UnitRange) at /Users/scheme/.bin/julia-release/usr/share/julia/stdlib/v1.6/LinearAlgebra/src/tridiag.jl:283
eigen!(::SymTridiagonal{var"#s832", V} where {var"#s832"<:Union{Float32, Float64}, V<:AbstractVector{var"#s832"}}, ::Real, ::Real) at /Users/scheme/.bin/julia-release/usr/share/julia/stdlib/v1.6/LinearAlgebra/src/tridiag.jl:288
...
Stacktrace:
[1] expv!(w::Vector{ComplexF64}, t::Float64, Ks::ExponentialUtilities; cache::ExponentialUtilities)
@ ExponentialUtilities ~/.julia/packages/ExponentialUtilities/vU95t/src/krylov_phiv.jl:85
[2] perform_step!(integrator::OrdinaryDiffEq.ODEIn, cache::OrdinaryDiffEq.Lawso, repeat_step::Bool)
@ OrdinaryDiffEq ~/src/julia/OrdinaryDiffEq/src/perform_step/exponential_rk_perform_step.jl:86
[3] perform_step!
@ ~/src/julia/OrdinaryDiffEq/src/perform_step/exponential_rk_perform_step.jl:71 [inlined]
[4] solve!(integrator::OrdinaryDiffEq.ODEIn)
@ OrdinaryDiffEq ~/src/julia/OrdinaryDiffEq/src/solve.jl:478
[5] __solve(::ODEProblem{Vector{Co, ::LawsonEuler{DataType; kwargs::Base.Iterators.Pairs)
@ OrdinaryDiffEq ~/src/julia/OrdinaryDiffEq/src/solve.jl:5
[6] #solve_call#58
@ ~/src/julia/DiffEqBase/src/solve.jl:61 [inlined]
[7] #solve_up#60
@ ~/src/julia/DiffEqBase/src/solve.jl:82 [inlined]
[8] #solve#59
@ ~/src/julia/DiffEqBase/src/solve.jl:70 [inlined]
[9] top-level scope
@ REPL[15]:3 |
Very interesting! I get (the same?) error:
Trying 1.7 next |
I get the same |
When I try to solve my large (# of eqns = 128^2)
ComplexF64
-valued ODE with any krylov-enabled exponential RK method, using an in-place derivative function, I get a segfault. (and all of those are strict requirements, no segfault without them)The segfault occurs for both hermitian (
lanczos
) and non-hermitian (arnoldi
) linear parts in the semilinear problem.It is somehow related to this line, which calls
arnoldi!
with aKrylovSubspace
cache which was allocated here (A). ThisKrylovSubspace
is slightly different from the one created by out-of-placearnoldi
, see here (B).In particular, (B) has
KrylovSubspace.V
as a sparse array, while (A) has it as a dense one instead.Calling
arnoldi!
on its own with such an (A) constructed subspace object triggers the segfault.The segfault would not trigger if the
ConstantCache
variants were used, but I don't know how to set this as an option tosolve
?I don't know enough to say if this is really a DiffEq issue, or an ExponentialUtilities one, but it seems like it can be fixed by changing how the cache is set up somehow.
Gist with minimum reproducible code
I'm on the latest version:
Thanks!
The text was updated successfully, but these errors were encountered: