msg=true and timeLimit are not working

[katherine-shiqi]

Hi team,

I am trying to solve a MIP program with PULP_CBC_CMD solver. Here is my code:
model.solve(pulp.PULP_CBC_CMD(gapRel=0.01, threads=threads, msg=True, timeLimit=60))

However, when i execute the optimizer, for a relative small input matrix (142 by 142 dimension), I am able to see the logs and results quickly. But for a large input matrix (655 by 655 dimension), the optimizer seems stuck without showing any logs and definitely didn't get finished within 60 seconds (I assume that timeLimit constraints apply to when the optimizer is actually running/outputting logs).

I wonder why pulp is taking so long to prepare data before running optimization, or is there any error?

Thanks,
Katherine

[katherine-shiqi]

Welcome to the CBC MILP Solver
Version: 2.10.3
Build Date: Dec 15 2019

command line - /home/uwv999/.conda/envs/zone_env/lib/python3.7/site-packages/pulp/apis/../solverdir/cbc/linux/64/cbc /tmp/756c37bb89
4e468b802496e874104a9d-pulp.mps max ratio 0.01 threads 64 branch printingOptions all solution /tmp/756c37bb894e468b802496e874104a9d-
pulp.sol (default strategy 1)
At line 2 NAME MODEL
At line 3 ROWS
At line 2049638 COLUMNS
At line 6379789 RHS
At line 8429423 BOUNDS
At line 9119828 ENDATA
Problem MODEL has 2049633 rows, 690404 columns and 3910383 elements
Coin0008I MODEL read with 0 errors
ratioGap was changed from 0 to 0.01
threads was changed from 0 to 64
Continuous objective value is 28350.3 - 915.98 seconds

it took 30 minutes to output the above rows and was stuck here for a long time...

[stumitchell]

Well it does say that your problem is actually 2,049,633 rows by 3,910,383 cols so it is quite big. I would suggest checking that you are modelling the problem correctly with a smaller instance, And if you are perhaps try solving it with another solver like gurobi. Stu Stuart Mitchell PhD Engineering Science Extraordinary Freelance Programmer and Optimisation Guru www.stuartmitchell.com

…

On Fri, Jun 18, 2021 at 9:39 AM Katherine Li ***@***.***> wrote: Welcome to the CBC MILP Solver Version: 2.10.3 Build Date: Dec 15 2019 command line - /home/uwv999/.conda/envs/zone_env/lib/python3.7/site-packages/pulp/apis/../solverdir/cbc/linux/64/cbc /tmp/756c37bb89 4e468b802496e874104a9d-pulp.mps max ratio 0.01 threads 64 branch printingOptions all solution /tmp/756c37bb894e468b802496e874104a9d- pulp.sol (default strategy 1) At line 2 NAME MODEL At line 3 ROWS At line 2049638 COLUMNS At line 6379789 RHS At line 8429423 BOUNDS At line 9119828 ENDATA Problem MODEL has 2049633 rows, 690404 columns and 3910383 elements Coin0008I MODEL read with 0 errors ratioGap was changed from 0 to 0.01 threads was changed from 0 to 64 Continuous objective value is 28350.3 - 915.98 seconds it took 30 minutes to output the above rows and was stuck here for a long time... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#456 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFUIWIRO7BZONG636QAWWDTTJTSVANCNFSM464NRG7Q> .

[wookenny]

definitely didn't get finished within 60 seconds (I assume that timeLimit constraints apply to when the optimizer is actually running/outputting logs).

The timeLimit is a bit problematic when running on CBC. It does not really obey this limit.
In particular, it only seems to be considered ,once the root relaxation has been solved. Therefore, the other option to limit the number of open nodes would also not help out (no nodes created so far).

For our cases, we added a hard timeout to the pulp handling of CBC.
E.g., We have the case of thousands of MIPs to solve in parallel, almost all of them in a few seconds.
Once in a while, some of them take extremely long. We added an interruption of the CBC subprocess with an additional hardTimeLimit.
...and use some heuristic solutions for them.

If you have an academic usecase, maybe SCIP is an option. It behaves nicer with resept to the time limit.
Sorry, bit of an explanation and not really a solution.

[tkralphs]

The timeLimit is a bit problematic when running on CBC. It does not really obey this limit.
In particular, it only seems to be considered ,once the root relaxation has been solved. Therefore, the other option to limit the number of open nodes would also not help out (no nodes created so far).

FYI, I've also noticed some pretty big inconsistencies with regard to Cbc obeying its time limit. I debugged a little and in addition to not being able to break out of the root relaxation, it also uses a different timer to check whether time limit has been reached than it does to report timing after exit, so this can also lead to what appear to be bigger violations of the time limit than one might expect. I'm trying to see if there are any easy fixes for this.