Repository navigation
EigenSolve.jl or not [BifurcationKit] #561
Description
Hi,
In BifurcationKit.jl, there is an infrastructure that looks a bit like LinearSolve.jl but for eigensolvers (see here). I am wondering if this would be a good idea to make a new package EigenSolve.jl where a single interface would give access to many possible packages (KrylovKit.jl, ArnoldiMethods.jl, ...). An advantage would be to have Krylov-space re-use but also to have, say Shift-Invert pre-conditioning available for all methods (it is not available for KrylovKit.jl at the moment).
Or should it live in LinearSolve.jl?
Best regards
Activity
ChrisRackauckas commentedon Dec 1, 2024
I am on the fence whether it should be LinearSolve.jl or EigenSolve.jl. The reason is because there's a good amount of infrastructure I think that can be reused here regarding
initandsolve!handling, but you wouldn't want to make ARPACK be a hard dependency for the default algorithm.Note this is already being discussed in #143. But basically, yes SciML needs to support something here, it has many requests, and we just haven't gotten to it yet.
j-fu commentedon Dec 1, 2024
... I would at least have an eye on such an effort (need to be careful with commitments due to finite bandwith...).
ChrisRackauckas commentedon Aug 23, 2026
Completed