Originally posted by: lyxthe

I give an extract from a log file : 

  * 23204 19165      integral     0      153.0000       48.9999   365149   67.97%

  23205 19164    infeasible            153.0000       48.9999   365149   67.97%

  23206 19165       68.0000   332      153.0000       48.9999   365150   67.97%

  23566 19285       78.0000   273      153.0000       48.9999   370634   67.97%

Elapsed real time = 958.46 sec. (tree size = 411.68 MB, solutions = 13)

Nodefile size = 279.90 MB (77.14 MB after compression)

  24253 19904       95.0000   173      153.0000       48.9999   380973   67.97%

  24820 20428      112.0000   122      153.0000       48.9999   390040   67.97%

  25434 20975      145.0000   125      153.0000       48.9999   399576   67.97%

* 25487+21005                          152.0000       48.9999   400744   67.76%

  26199 21642       70.0000   224      152.0000       48.9999   408471   67.76%

* 26238+21674                          142.0000       48.9999   408913   65.49%

  26505 21634      102.0000   160      142.0000       48.9999   411787   65.49%

  27038 22080      141.0000    30      142.0000       48.9999   420772   65.49%

  27991 22947       85.0000   232      142.0000       48.9999   432418   65.49%

 

Implied bound cuts applied:  10

Mixed integer rounding cuts applied:  76

Zero-half cuts applied:  67

Gomory fractional cuts applied:  116

 

Root node processing (before b&c):

  Real time             =   10.75

Parallel b&c, 4 threads:

  Real time             = 1168.62

  Sync time (average)   =   36.30

  Wait time (average)   =    0.00

                          -------

Total (root+branch&cut) = 1179.37 sec.

in this execution the EpGap parameter is set to 0.69 

Why the feasible solution found with a gap to 67.97% is not the one that stop the execution ?

Thanks for your attention.

In multi-threaded solves there may be some delay between reaching a stopping criterion and actually stopping. This is due to thread-synchronization (one thread may hit the stopping criterion but still needs to tell the other threads about that). Especially in deterministic multi-threading this is likely to happen.

Does the problem also happen in opportunistic multi-threading (setting CPX_PARAM_PARALLELMODE to -1)?

Can you reproduce the problem in the interactive? To check this export your problem to a SAV file model.sav and then do

CPLEX> read model.sav
CPLEX> set mip tol mipgap 0.69
CPLEX> opt

If it reproduces in the interactive, could you show us the full log file?

Originally posted by: lyxthe

Thanks for the answer. I'm going to try all that and let you know the results asap :)