MISOCP solves returning status "Unknown" (different from #100)

[chriscoey]

We also get Unknown from a large number of MISOCPs we attempt to solve. What we observe is that MOSEK gets to the time limit AND has a feasible solution, but apparently the optimality gap is not yet satisfied. Then Mosek.jl fails to handle the status properly and returns Unknown (perhaps it should be Suboptimal).

In another case where no feasible solution was found by the time limit, MOSEK finished and Mosek.jl returned (correctly) the UserLimit status. The only difference here was that no feasible solution was found, whereas in the Unknown cases, we had both upper and lower bounds.

Here is the end of a printout (the lines with ## are our printings, not MOSEK's):

1179079  1176550  335532   30       5.0076984618e+05     5.0052105644e+05     0.05        3599.5
1179105  1176576  335540   24       5.0076984618e+05     5.0052105735e+05     0.05        3599.5
1179131  1176602  335546   45       5.0076984618e+05     5.0052105779e+05     0.05        3599.6
1179157  1176628  335550   24       5.0076984618e+05     5.0052105879e+05     0.05        3599.7
1179183  1176654  335560   36       5.0076984618e+05     5.0052106168e+05     0.05        3599.8
1179209  1176680  335566   39       5.0076984618e+05     5.0052106190e+05     0.05        3599.8
1179235  1176706  335570   35       5.0076984618e+05     5.0052106307e+05     0.05        3599.9
1179261  1176732  335576   29       5.0076984618e+05     5.0052106463e+05     0.05        3600.0
Maximum amount of time 3600.00 (=dpar_optimizer_max_time) is reached.

Objective of best integer solution : 5.007698461827e+05      
Best objective bound               : 5.005210646327e+05      
Construct solution objective       : Not employed
Construct solution # roundings     : 0
User objective cut value           : 0
Number of cuts generated           : 0
Number of branches                 : 1179261
Number of relaxations solved       : 1176732
Number of interior point iterations: 21020134
Number of simplex iterations       : 0
Time spend presolving the root     : 0.00
Time spend in the heuristic        : 0.00
Time spend in the sub optimizers   : 0.00
  Time spend optimizing the root   : 0.00
Mixed integer optimizer terminated. Time: 3601.02

Optimizer terminated. Time: 3601.03 
#STATUS# Unknown
#OBJVAL# 500769.8461827041
#OBJBOUND# 500521.06463272555
#TIMESOLVER# 3601.032301902771

@mlubin @ulfworsoe

[erling-d-andersen]

There is almost surely a bug in Julia interface.

Btw getting the Julia interface to print the MOSEK solution summary after each optimization as default would help debugging so much.

[mlubin]

@ulfworsoe, looks like the fix to #89 was incomplete

[ulfworsoe]

The issue is at least partially fixed now. A feasible solution should now produce Suboptimal status.

[mlubin]

@ulfworsoe, that doesn't follow the MPB convention. If the solver stops because of a time limit, it should return :UserLimit regardless of whether it has found a primal solution so far.

[ulfworsoe]

Fair enough. The status function is a mess since it mixes Mosek's response code, problem status and solution status into one value. Do you have a description of MPB conventions somewhere?

[ulfworsoe]

Basically the relevant questions:

• Does UserLimit take precedence over an optimal solution or only a feasible one?
• Does Stall take precedence over an optimal solution or a feasible one?

[mlubin]

The statuses are currently documented at http://mathprogbasejl.readthedocs.io/en/latest/solverinterface.html#status. I agree that they could use a revamp, that's something I'm open to considering.

Does UserLimit take precedence over an optimal solution or only a feasible one?

I don't understand how the solver could terminate because of the time limit if it already has an optimal solution.

Does Stall take precedence over an optimal solution or a feasible one?

Stall is not a standard status. Error maybe?

You should consider the statuses, as they're currently defined, as an explanation of why the solver stopped. :Optimal is not really about the solution itself but more explaining that the solver stopped because it found a solution that it was happy with. @ccoffrin has pointed out that :Optimal should really be called :Success or something similar.

[mlubin]

Btw getting the Julia interface to print the MOSEK solution summary after each optimization as default would help debugging so much.

Agreed. @ulfworsoe, could we do that?

[ulfworsoe]

Done.

[mlubin]

@ulfworsoe, Mosek seems to be returning :Stall on some problems where it used to return :Optimal and is therefore failing JuMP's tests.

[ulfworsoe]

Yes. If the solver stalls and stops, but finds that the solution after post-solve happens to be optimal, it will produce an optimal solution but still return the actual reason for stopping.

[mlubin]

Fair enough

[erling-d-andersen]

Unless you are doing something special in the interface then this not correct explenation. Postsolve cannot fix a broken solution. What can happen on linear problems is that the interior-point optimizer stalls but the subsequent basis identification succeeds. 2016-12-28 9:28 GMT+01:00 Ulf Worsøe <notifications@github.com>:

…

Yes. If the solver stalls and stops, but finds that the solution after post-solve happens to be optimal, it will produce an optimal solution but still return the actual reason for stopping. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#101 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJwCcSYDB14HHvUYIw4d7j2ALETn6G0Iks5rMh2rgaJpZM4LLcy8> .