Open gewesp opened 2 years ago
This looks to be the bug that was fixed here. Can you check what SHA you are on in CoinUtils?
Hi @tkralphs, thanks for looking into it! Unfortunately, it looks like it wasn't fixed.
I just recompiled and the error still occurs in the same form AFAICS.
The latest commit I have is 78fdcdbc6841668af6c254d0b296380685a0f879, Mar 2 by Lou Hafer, and I do see the Jan 3 commit you quoted in my log.
My build commands are:
wget https://raw.githubusercontent.com/coin-or/coinbrew/master/coinbrew
chmod u+x coinbrew
mkdir cbc
cd cbc
../coinbrew --ssh -j8 build Cbc@master
This is strange. I can replicate the error, but I don't have the bandwidth at the moment to debug it. Strangely, for me, even m.optimize()
with no parameters seems to give the same error. It should be easy to debug. Looking quickly at the code, I can see where it fails and where the error is being printed (it's in the C extension), but just not why. It should be obvious from looking at the source, but it's not. To debug requires building a debug version of Cbc and running Python in a debugger to step through to the line where the error occurs. It still looks to me like this is the bug I already fixed, but obviously not.
OK thanks! I'll see, maybe I find a few cycles to investigate. After all, I have the current source already on my machine.
Some differential diagnosis:
m.threads
before calling m.optimize()
triggers the same error.m.foobar
before calling m.optimize()
works without any effect, as expected.m.max_seconds
before calling m.optimize()
somewhat surprisingly does not trigger the error, but also doesn't have the desired effect of terminating after the specified number of seconds.Looks like I might have a fix, if you want to assign the ticket to me and add me to the project, happy to submit a PR.
I'm not actually a maintainer here. I did assign the ticket to you, which I can do, but I would leave it to the maintainers to add you to the project. That's not required to submit a PR, however.
@gewesp You can easily fork this project in your private space and from there you can create a pull request (PR) into the python-mip repository. You don't need any rights to the project to create it, only as a maintainer you can merge the PR.
@sebheger I did, see above. I didn't realise initially that I need to fork ... too many different workflows around these days.
The issue is probably in CoinUtils, I submitted a PR to that repo.
OK, this should now be fixed by https://github.com/coin-or/CoinUtils/pull/192.
Unfortunately, this still doesn't seem to work on MacOS, the last time I tried was with Cbc @ 98633b3e8d34e6ee4ce076d84275da08df9e2ba3
I'm not sure exactly where the problem lies though. Other parameters likemax_mip_gap
, threads
etc. seem to be affected as well.
@gewesp Have you checked latest commit on cbc. There was a known issue on the C-Interface of CBC. See https://github.com/coin-or/Cbc/commit/f25c45d188ce9cc2128be02966d4c5e8eb582b1a
I still have this problem for mip==1.14.1
If I call the solver with status = self.m.optimize(max_seconds=10)
it terminates after 140 second with very little debug output from cbc.
Welcome to the CBC MILP Solver
Version: Trunk
Build Date: Oct 24 2021
Starting solution of the Linear programming relaxation problem using Dual Simplex
Clp0024I Matrix will be packed to eliminate 9205 small elements
Coin0506I Presolve 5156 (-337) rows, 3464 (-316) columns and 275873 (-49138) elements
Clp0014I Perturbing problem by 0,001% of 5 - largest nonzero change 0,00019996328 ( 5,2500605%) - largest zero change 0
Clp0000I Optimal - objective value 375,36884
Coin0511I After Postsolve, objective 375,36884, infeasibilities - dual 0 (0), primal 0 (0)
Clp0032I Optimal objective 375,3688434 - 3130 iterations time 0,382, Presolve 0,03
Starting MIP optimization
Cgl0002I 211 variables fixed
Cgl0004I processed model has 5156 rows, 3464 columns (944 integer (944 of which binary)) and 276432 elements
Coin3009W Conflict graph built in 0,002 seconds, density: 0,019%
Cgl0015I Clique Strengthening extended 0 cliques, 0 were dominated
Cbc0045I Nauty sparseSpace 1186862 affine 152457 coefficient count 161078
Cbc0045I Nauty: 71183 orbits (1263 useful covering 2697 variables), 1154 generators, group size: inf - sparse size 1186862 - took 143,491 seconds
Cbc0020I Exiting on maximum time
Cbc0005I Partial search - best objective 1e+50 (best possible -375,36884), took 0 iterations and 0 nodes (144,22 seconds)
Cbc0035I Maximum depth 0, 0 variables fixed on reduced cost
Total time (CPU seconds): 143,87 (Wallclock seconds): 144,22
no feasible solution found, lower bound is: 375.36884336844
Describe the bug
max_seconds
doesn't work for me currently, it leads to:This is with:
compiled from master as indicated above on a Mac M1.
I can provide a minimal example, however I'm pretty sure this is a simple oversight. The only difference between my code working and not working is addition of the
max_seconds
parameter in theoptimize()
call. Let me know if you need any other info.To Reproduce
In the same code base, calling
optimize()
without any parameters works perfectly.Expected behavior
Solver terminates after at most 1234 seconds.
Desktop (please complete the following information):
Additional context Add any other context about the problem here.