Reuse Arpack in order to compute norm of Bk

[MohamedLaghdafHABIBOULLAH]

Based on this commit 48e6f01#diff-72ed386c2a0cd1d23c0968297e70023ed98c22490d146dd89fc91f48369bad4dL7

[MohamedLaghdafHABIBOULLAH]

Please hold off on merging for now, as some tests are affected by #42 .

@nathanemac you can try to merge this PR locally with R2N in order to use ADNLPModels

[nathanemac]

@MohamedLaghdafHABIBOULLAH, using Arpack instead of TSVD indeed solves the Lapack issue for R2N on the dummy example:

nlp = ADNLPModel(x -> (1-x[1])^2 + 100(x[1]-x[2]^2)^2, [1., 1.], backend=:generic) h = NormL1(1.0) options = ROSolverOptions() res_r2n = R2N(nlp, h, options)

[MohamedLaghdafHABIBOULLAH]

@nathanemac thanks for the confirmation, we believe that Arrack may be more accurate than TSVD, but still have some bugs...
If you encounter one, do not hesitate to share it.

[MohamedLaghdafHABIBOULLAH]

This PR should address the problem encountered in this issue #42
by catching the XYAUPD_Exception error in Arpack calls and dynamically increase NCV as needed to handle convergence issues. This modification addresses instability in LSR1 computations due to insufficient NCV.

[MaxenceGollier]

Just wondering, @MohamedLaghdafHABIBOULLAH, is it possible to use the frobenius norm instead of the operator norm for your algorithm ? QRMumps has a function (see qrm_spmat_nrm) that allows to compute this quite efficiently I think and it could allow to reduce the number of dependencies because I am already adding QRMumps in my own PR #145.

[MohamedLaghdafHABIBOULLAH]

@MaxenceGollier yes one could and it has been discussed in the paper and in this issue #133 , however I'm afraid that the solver will become slower as the step size is related to 1/|B_k|, in this case the Frobenius norm might represent a loose bound on the operator norm or the largest eig norm.

[dpo]

You can’t compute the Frobenius norm of a quasi-Newton operator without a lot of work.

[MaxenceGollier]

@MohamedLaghdafHABIBOULLAH can we add a wrapped allocs unit test to be sure that opnorm does not allocate as well ?

[MaxenceGollier]

Arpack actually uses restarted Lanczos or Arnoldi iterations and allocates, wouldn't it be easier to try to make something work with Krylov.jl that has the same type of method and has in place methods @dpo ? I can open a PR with Krylov instead if this sounds ok.

[MohamedLaghdafHABIBOULLAH]

@MohamedLaghdafHABIBOULLAH can we add a wrapped allocs unit test to be sure that opnorm does not allocate as well ?

It sure does allocate, but I can add it, although it's not the objective of this package.

[MohamedLaghdafHABIBOULLAH]

Arpack actually uses restarted Lanczos or Arnoldi iterations and allocates, wouldn't it be easier to try to make something work with Krylov.jl that has the same type of method and has in place methods @dpo ? I can open a PR with Krylov instead if this sounds ok.

Does Krylov contain any solver that enable to approximate the opnorm ?

[MohamedLaghdafHABIBOULLAH]

@MohamedLaghdafHABIBOULLAH can we add a wrapped allocs unit test to be sure that opnorm does not allocate as well ?

What do you think, @dpo? The issue is that we're almost certain the tests will fail…

[dpo]

All tests fail. Did you test these changes locally? It doesn’t look like you did.

[MohamedLaghdafHABIBOULLAH]

I apologize, indeed because we added R2N recently, I should have taken into account the way it computes the norm of Bk as well.

[dpo]

Thank you.