Inner solves and projected problems

[jarlebring]

Several of the methods are inner-outer iteration methods. At some point in the algorithm you need to solve a smaller problem (typically the Galerkin projection of the problem). In commit 6554628cb1a5d91d5c1c622cd44d271f7908e3e4 and the following commits, I have made an attempt to make this systematic. The inner solves are controlled by the helper functions in inner_solver.jl. I have also already included it in iar, as an alternative way to extract eigenpairs complement to the computation of eigenvalues from the hessenberg matrix.

Consistent with IAR we now need to incorporate this system into

• [x] Jacobi-Davidson
• [x] NLArnoldi
• [x] TIAR

and we should and inner solver helper functions corresponding to a couple of other methods, at least

• [x] sgiter
• [x] iar (yes, thereby you can do inner and outer iterations with IAR)
• [x] augnewton
• [x] polyeig
• [x] beyncontour

(I don't think we need to include all methods we have as inner solves.)

[eringh]

Jacobi-Davidson already had a proj_eig_solver argument to solve the inner problem since 5343fa28e20dd8af2f7e69856221f99b587742db. However, that was in need of refactorization because of the EigSolver refactorization #32.

Regardless I think we should aim for consistency here.

[jarlebring]

Indeed, I know both you and @upadpup are solving projected problems in JD and nlar already. The proposed solution is inspired how we needed in there. This solution should hopefully make both JD and nlar cleaner and indeed consistent.

[eringh]

Commit 7f5f13341b4f569653a526d866fffea78d6811c7 together with @jarlebring.

Idea from this work and TODO: There is a "soft interface" where the outer methods provide certain reserved kwargs that are needed for the inner methods.

• j as number in min-max characerization for SgIter
• λv as initial guess for Newton methods
• Neigs as number of wanted eigenvalues for IAR
• σ as target in for example IAR
• potentially some other

If not provided, inner method requiring it cannot be used since not suitable for outer method.

[jarlebring]

Todo fixed.

[eringh]

Another thought on this. Should we pass the type of arithmetic as well? Our outer methods are typed in the arithmetic used, and since we are using these methods as inner solvers as well we have the opportunity to type them. Should we pass on that type from the outer to the inner in the kwargs. What do you think, @jarlebring ?

[jarlebring]

Yes. Good idea. The type of arithmetic is a good thing to propagate. I would suggest to have it as a mandatory first parameter in inner_solve. If we want it as a kwarg, we should check how julia JIT handles it, i.e., that a kwarg and a parameter in that situation compiles to the same code (@eringh: I think your friend suggested that a param is better than kwarg and that it would not compile to the same code but in the interest of learning it would be good to try e.g. with @code_llvm)

[eringh]

Yes I think so. Although I am not sure we need it to compile the inner_solve as that is more of a wrapper, and as long as we pass it on to the actual inner solver method most of it should be fine.

However, it might be good practice to pass it as an argument anyway, since we (probably) want it for all methods. And I don't think it will ever cause a problem.

Ergo: I agree to pass it as a required parameter, but for a different reason.