I'm using CP optimizer to solve large scale scheduling problems, implemented with C++. I found that the built-in parameter, IloCP::TimeLimit, is not a strict wall time limit. For some of my instances, the solver took too long to terminate, far beyond 3600s, which is the value I set for IloCP::TimeLimit. According to the documentation, the actual time consumption could be up to IloCP::Workers * IloCP::TimeLimit. I am using 16 workers, so theoretically it could take 16 hours to terminate. However, one of the instances ran for a day without terminating. The output stucked in the following status:

 ! --------------------------------------------------- CP Optimizer 20.1.0.0 --
 ! Minimization problem - 13358 variables, 948642 constraints
 ! Presolve      : 1404 extractables eliminated
 ! TimeLimit            = 3600
 ! TimeMode             = CPUTime
 ! Workers              = 16
 ! Initial process time : 50.68s (50.65s extraction + 0.04s propagation)
 !  . Log search space  : 260558.0 (before), 260558.0 (after)
 !  . Memory usage      : 2.2 GB (before), 2.2 GB (after)
 ! Using parallel search with 16 workers.
 ! ----------------------------------------------------------------------------
 !          Best Branches  Non-fixed    W       Branch decision
                        0      13358                 -
 + New bound is 14850
 ! Using iterative diving.

Similar situations occurred in other instances, but they did terminate after a long time.

Also I have tried using callback to terminate IloCP::solve(), yet with no good. Calling IloCP::abortSearch() does not work for my instances. The program seems to be stuck at some step before the search. IloCP::abortSearch() cannot terminate the process at those phases.

Do I have no choice but to shorten the time limit or reduce the number of workers?

Hello,

there was a bug in the iterative diving search possibly causing such problems. It has been fixed in the last release of CP Optimizer, so updating your version should solve your problem. 

An alternative is to deactivate iterative diving, but the performances may be impacted for very large scheduling problems.

For one worker only, I would expect the limit works as expected, is it the behavior you can observe? 

 ! --------------------------------------------------- CP Optimizer 20.1.0.0 -- ! Minimization problem - 13358 variables, 948642 constraints ! Presolve      : 1404 extractables eliminated ! TimeLimit            = 3600 ! TimeMode             = CPUTime ! Workers              = 16 ! Initial process time : 50.68s (50.65s extraction + 0.04s propagation) !  . Log search space  : 260558.0 (before), 260558.0 (after) !  . Memory usage      : 2.2 GB (before), 2.2 GB (after) ! Using parallel search with 16 workers. ! ---------------------------------------------------------------------------- !          Best Branches  Non-fixed    W       Branch decision                        0      13358                 - + New bound is 14850 ! Using iterative diving.