[Coin-ipopt] l-BFGS

[Andreas Waechter]

Hi Ivan,

My apologies for this very belated reply.  I 'm cleaning up my inbox, and
realized that we never replied to your message...  You might no longer be
interested in my reply, but I send it anyway...

> We are having some difficulty accommodating the memory requirement for
> our Hessian storage (even when exploiting sparsity).  So we're
> contemplating implementing our own limited-memory BFGS, but it seems
> that, in the C++ version of IPOPT,
> IpoptCalculatedQuantities::curr_exact_hessian() is the only point of
> entry for a Hessian calculation, and there are no Hessian-vector
> equivalent callbacks.  It also seems (from
> TSymLinearSolver::MultiSolve()) that the ma27 routines used to solve for
> the search direction require a matrix and rhs, and there is no interface
> for an iterative method that takes operator-type inputs.  Is this
> correct?

This is correct.  For a number of reasons, we cannot easily use an
iterative linear solver, for example, because an iterative linear solver
could not compute the intertia of the linear system, which is required to
make sure that if necessary the Hessian matrix is perturbed so that the
necessary descent properites of the search direction can be ensured.
Also, the linear systems (in augmented form) become extremely
ill-condititioned.

> If so, do you have any suggestions of how to implement such a
> matrix-vector description of the Hessian's action?  Am I perhaps
> overlooking an interface that allows for this?  I recall you mentioned
> that there would be quasi-Newton capabilities in future releases, do the
> plans also include a limited-memory option?

Since at this point I don't see a soon integration of an iterative linear
solver, there are no plans to include anything that will ask the NLP for
Hessian-vector products.

As for the quasi-Newton option, yes, we are planning to add them
(hopefully in a few months) - they will be limited-memory.

Regards,

Andreas