Interface to neos solvers

[Wannes Van Loock]

For some of the nonconvex problems I attempt to solve, I notice a large performance difference between solving the problems locally on my machine using YALMIP or online using the solvers on the NEOS server. For a small problem of 20 variables it takes 400 seconds on my machine and 0.4 seconds on the NEOS server, both using Ipopt. I'm using the saveampl as interface to the NEOS solvers. Is this difference due to exact derivative information in AMPL which is not available with YALMIP?

Anyhow, due to this big difference, I whipped together a basic interface to the NEOS solvers in MATLAB to avoid the detour of uploading and postprocessing the files generated on NEOS. This way I can also test solvers I do not have available locally. In my opinion, this could be a useful addition to YALMIP. Would you be interested in supporting this in a future release? I would be happy to contribute in any way.

[Johan Löfberg]

YALMIP supplies exact derivatives, so this sounds strange. Having said that, YALMIP was not developed for nonlinear programming so there are some inefficiencies, but such difference is not reasonable.

I would really like to get my hands on that model. Please send it to me per email.

The neos interface is definitely something that could be supported. I guess I could interface it like any other solver.

[Johan Löfberg]

Based on the received model, the conclusion is that ipopt behaves slightly different on feasibility and optimality problems. The following approach is as fast as (or even better than) the AMPL version in terms of iterations/function evaluations/time

solvesdp(Constraints,[],sdpsettings('solver','ipopt'));
solvesdp(Constraints,Objective,sdpsettings('solver','ipopt','usex0',1));


In other words, we first solve the feasibility problem to try to get a feasible point, and then we start the optimization from there. This performs very well, despite the fact that YALMIP only supplies first derivatives and no hessian. I guess it is just a property of the solution algorithm in ipopt. The objective has perhaps some weird shape around the origin were the solution is started, and this sets the solver on the completely wrong track during the first iterations when the hessian approximation is starting to be built if the objective is included

[Johan Löfberg]

And note that fmincon solves the problem rather easily using the 'active-set' algorithm

solvesdp(Constriants,Objective,sdpsettings('fmincon.Algorithm','active-set'))