Problems solving large SOCP with CPLEX/GUROBI

[arnaud...@student.uclouvain.be]

Hello everyone,

I am currently trying to solve a large ( >500 variables) SOCP model with CPLEX.

When solving my problem with CPLEX i get a certain optimal solution.
But by simply adding a constraint to my problem I get a solution which is also optimal but with a significantly better objective (but the status of CPLEX is still "optimal solution found").

If my second "better" solution is feasible for the second problem it should also be feasible for my original problem. Therefore I suppose the solution of my first problem was not really optimal or the solution of my second problem is not really feasible.

I also tried to solve the same problem with GUROBI and I get an objective which is significantly lower than with CPLEX ( in both cases ) with a model that is "solved to optimality subject to tolerance" and with the warning "Failed to compute QCP dual solution due to inaccurate barrier solution. Try decreasing BarQCPConvTol for more accuracy". If I effectively decrease BarQCPConvTol, Gurobi only obtain suboptimal termination.

Someone has any ideas or help on what is happening ?

Arnaud Fabri

[Robert Fourer]

Some SOCP problems are ill-conditioned and cannot be solved reliably with any solver. But to learn what might be happening with your problem, the first step is to get some detailed log output. The following will cover all the possibilities:

option cplex_options 'bardisplay=1 mipdisplay=2';
option gurobi_options 'outlev=1';

(or add these settings to any existing cplex_options or gurobi_options string). In comparing the two CPLEX runs, look especially for error and warning messages, and anything that suggests the returned solution may not be feasible or optimal. Also after solving you can display the maximum infeasibilities in the constraints and the variable bounds with these commands:

display (min {i in 1.._ncons: _con[i].slack < 0} _con[i].slack);
display (min {j in 1.._nvars: _var[j].slack < 0} _var[j].slack);

Tiny negative values like -3.31738e-09 or -2.17382e-12 can be disregarded, but significant negative values relative to your bound or right-hand-side magnitudes indicate that the solution returned by the solver is not feasible.

Bob Fourer
am...@googlegroups.com

=======

[Robert Fourer]

You could send to sup...@ampl.com the files needed to reproduce this result on our computers. Then we will be able to double-check the result and report it to the CPLEX developers at IBM.

Bob Fourer
am...@googlegroups.com

=======

From: am...@googlegroups.com [mailto:am...@googlegroups.com] On Behalf Of Tony
Sent: Sunday, July 2, 2017 11:11 AM
To: AMPL Modeling Language

Cc: 4...@ampl.com
Subject: Re: [AMPL 14362] Problems solving large SOCP with CPLEX/GUROBI

Bob thanks for the helpful clarification. Indeed, for the problem reported above by Arnaud one obtains
ampl: display (min {i in 1.._ncons: _con[i].slack < 0} _con[i].slack);
min{i in 1 .. _ncons: _con[i].slack < 0} _con[i].slack = -0.00422293

ampl: display (min {j in 1.._nvars: _var[j].slack < 0} _var[j].slack);
min{j in 1 .. _nvars: _var[j].slack < 0} _var[j].slack = -8.6237e-06

which seems non-negligible.

The bad numerical behavior of the algorithm due to ill conditioning may be inevitable, but CPLEX reports solve_result=solved, and solve_result_num=0, which is clearly misleading. Would it be useful to you if we provide the data set that is causing this bug, so that it can be followed up with CPLEX? There is obviously a bug here which needs to be fixed.