Solution of large NLP model with Mosek

This report shows some good results with Mosek on a very large convex NLP model. 

Convex Linearly Constrained Model

I was given a very large convex linearly constrained model (exceeding half a million variables). The "standard" NLP solvers (Conopt,Minos,Snopt) were very slow on this model, not even being close to optimality after hours of working. Mosek solved the model very fast, but not to optimality: Solution status : NEAR_OPTIMAL.

Unfortunately this near optimal point could not be improved quickly by other solvers. In the end we solved a few QP approximations of the form:

min g(x)=f(x⁰) + ∇ f(x⁰) (x-x⁰) + 0.5 (x-x⁰)^T ∇ ² f(x⁰) (x-x⁰)
s.t. Ax=b

Here x⁰ is the current value of x.

Basically a Taylor series approximation of the objective. This actually converged rapidly to an optimal solution we could verify with Conopt. (Conopt complained about some reduced gradients being too large, but could not improve the solution further). What this algorithm lacks in refinement it gains in simplicity: just a loop around a solve statement.

Implementing such a problem specific algorithm is easy to do in GAMS using its procedural features (the complete code in this case is less than 20 lines), and for the most difficult problems this often can help. We further benefitted from having access to multiple NLP solvers (in this case Mosek and Conopt).

GAMS/Mosek link bug

GAMS/Mosek stops but GAMS keeps it a secret why this happened. A few extra lines with some text explaining why the solve was aborted would not be unwelcome:

               S O L V E      S U M M A R Y
 
     MODEL   LANDentSN2          OBJECTIVE  ENTROPY
     TYPE    NLP                 DIRECTION  MINIMIZE
     SOLVER  MOSEK               FROM LINE  249734
 
**** SOLVER STATUS     4 TERMINATED BY SOLVER    
**** MODEL STATUS      7 INTERMEDIATE NONOPTIMAL 
**** OBJECTIVE VALUE              217.6762
 
 RESOURCE USAGE, LIMIT        539.256    900000.000
 ITERATION COUNT, LIMIT         0        900000
 EVALUATION ERRORS              0             0
 
 MOSEK Link       Aug  1, 2008 22.8.1 WEX 5438.6015 WEI x86_64/MS Windows
 
 M O S E K       version 5.0.0.90 (Build date: Jun  6 2008 14:57:22)
 Copyright (C)   MOSEK ApS, Fruebjergvej 3, Box 16
                 DK-2100 Copenhagen, Denmark
                 http://www.mosek.com

The log file may contain additional information. Unfortunately if you run GAMS from the command line (e.g. by Linux users) the log is not saved. (The IDE under Windows will save a copy).

GAMS/Mosek Bug

Mosek does not return the best integer solution found sofar when interrupted. Below we interrupted a MIP run, while integer solutions were found by the solver (the model was no longer intermediate integer infeasible).

**** SOLVER STATUS     8 USER INTERRUPT         
**** MODEL STATUS      14 NO SOLUTION RETURNED  
**** OBJECTIVE VALUE             3885.0000
 
 RESOURCE USAGE, LIMIT          6.618      3600.000
 ITERATION COUNT, LIMIT         0      10000000
 
 MOSEK Link       May  1, 2008 22.7.1 WIN 3927.4700 VIS x86/MS Windows
 
 M O S E K       version 5.0.0.79 (Build date: Jan 29 2008 13:41:45)
 Copyright (C)   MOSEK ApS, Fruebjergvej 3, Box 16
                 DK-2100 Copenhagen, Denmark
                 http://www.mosek.com
 
 
No solution returned

I don't know if this is caused by a misbehavior of the link or by Mosek itself. Work around: when stopped on a RESLIM limit, GAMS/Mosek will report the best integer solution. Don't press the Interrupt button if you don't want to loose your solution.

Note also that the iteration count is reported as zero, which is another bug.

Mosek bug

Cplex needed a long time to solve the root node of an MIQCP model. I tried Mosek, but that gave



This is with version:

MOSEK Link       May  1, 2008 22.7.2 WEX 3927.4799 WEI x86_64/MS Windows
M O S E K       version 5.0.0.79 (Build date: Jan 29 2008 13:47:58)

I sent it to GAMS for further investigation. This problem seems only to happen with the 64 bit version. The work around would be to use the 32 bit version.