EigenSolve.jl or not [BifurcationKit]

[rveltz]

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

[ChrisRackauckas]

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 init and solve! 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]

... I would at least have an eye on such an effort (need to be careful with commitments due to finite bandwith...).