Open christoph-cullmann opened 3 months ago
Could you use git bisect
to find the exact commit where the change occurred? That would probably help, although it could be that this is due to a pre-existing bug and some unrelated change caused the solution process to change in a way that tickled the bug.
That is not that easy as I use a mirror that just not contains all that stuff and can't use the repos as is as I need it CMake based. If I have more hints where the issue might be, I can add that here.
I have a bunch of ILPs with results 'verified' with a second solver like cplex that I use as regression tests, is there some way to add such stuff to the auto tests?
https://github.com/christoph-cullmann/ilp
At least all x months they find regressions in cbc and Co.
I have many versions of master. The one I am working on most now lacks many recent updates and gets correct answer. A vanilla up to date master does get the answer wrong - so I can slowly find problem. At a first glance it looks like a bad cut generator. If I add -cgraph clq to go back to old type cliques it solves correctly.
As to auto tests. I have a directory ~/cullmann with files and a file testset in that directory and then cbc -dirmiplib ~/cullmann ..... works (you do need to set a maximum nodes or seconds as cbc does not do too well on a few problems).
Problem is CoinStaticConflictGraph - may take some time to work out what it does/did.
Thanks as lot for investigating this!
If it is of any help, the other test that has different results for me with the current version is
https://github.com/christoph-cullmann/ilp/blob/main/value_28841479959.lp
That is now just infeasible:
❯ ../usr/bin/cbc ../lpsolve.clpsolve/test/value_28841479959.lp
Welcome to the CBC MILP Solver
Version: trunk
Build Date: Aug 29 2024
command line - ../lpsolve.clpsolve/test/value_28841479959.lp (default strategy 1)
CoinLpIO::readLp(): Maximization problem reformulated as minimization
Problem value_28841479959.lp has 8062 rows, 22012 columns and 52444 elements
Coin0009I Switching back to maximization to get correct duals etc
Continuous objective value is 2.88415e+10 - 0.690207 seconds
Cgl0003I 0 fixed, 7536 tightened bounds, 0 strengthened rows, 0 substitutions
Cgl0003I 0 fixed, 3 tightened bounds, 0 strengthened rows, 0 substitutions
Cgl0004I processed model has 4610 rows, 16352 columns (16352 integer (917 of which binary)) and 41524 elements
Coin3009W Conflict graph built in 0.003 seconds, density: 0.006%
Cgl0015I Clique Strengthening extended 0 cliques, 0 were dominated
Cbc0031I 20 added rows had average density of 43.7
Cbc0013I At root node, 145 cuts changed objective from 2.884148e+10 to 2.8841372e+10 in 11 passes
Cbc0014I Cut generator 0 (Probing) - 8 row cuts average 2.5 elements, 22 column cuts (22 active) in 0.353 seconds - new frequency is 1
Cbc0014I Cut generator 1 (Gomory) - 10 row cuts average 387.4 elements, 0 column cuts (0 active) in 0.019 seconds - new frequency is -100
Cbc0014I Cut generator 2 (Knapsack) - 0 row cuts average 0.0 elements, 0 column cuts (0 active) in 0.010 seconds - new frequency is -100
Cbc0014I Cut generator 3 (Clique) - 421 row cuts average 2.0 elements, 0 column cuts (0 active) in 0.002 seconds - new frequency is 1
Cbc0014I Cut generator 4 (OddWheel) - 0 row cuts average 0.0 elements, 0 column cuts (0 active) in 0.002 seconds - new frequency is -100
Cbc0014I Cut generator 5 (MixedIntegerRounding2) - 0 row cuts average 0.0 elements, 0 column cuts (0 active) in 0.017 seconds - new frequency is -100
Cbc0014I Cut generator 6 (FlowCover) - 0 row cuts average 0.0 elements, 0 column cuts (0 active) in 0.008 seconds - new frequency is -100
Cbc0001I Search completed - best objective -1e+50, took 121 iterations and 0 nodes (1.60 seconds)
Cbc0035I Maximum depth 0, 0 variables fixed on reduced cost
Cuts at root node changed objective from 2.88415e+10 to 2.88414e+10
Probing was tried 11 times and created 30 cuts (0.353472 seconds)
Gomory was tried 11 times and created 10 cuts (0.018909 seconds)
Knapsack was tried 11 times and created 0 cuts (0.010064 seconds)
Clique was tried 11 times and created 421 cuts (0.002397 seconds)
OddWheel was tried 11 times and created 0 cuts (0.00194 seconds)
MixedIntegerRounding2 was tried 11 times and created 0 cuts (0.016779 seconds)
FlowCover was tried 11 times and created 0 cuts (0.008125 seconds)
TwoMirCuts was tried 1 times and created 0 cuts (0.003247 seconds)
ZeroHalf was tried 1 times and created 0 cuts (0.009432 seconds)
Result - Problem proven infeasible
No feasible solution found
Enumerated nodes: 0
Total iterations: 121
Time (CPU seconds): 1.59816
Time (Wallclock seconds): 1.61948
Total time (CPU seconds): 1.62267 (Wallclock seconds): 1.64403
Many models on standard tests get wrong answer too!
The problem was introduced by using std::vector more. You can get use of uninitialized values in CoinAdjacencyVector (that is easily fixed). However the problem here is using size() as a test for whether a vector is empty in CoinStaticConflictGraph. Maybe someone who know code better than I do could fix - otherwise it will take a bit of time.
Hope I have fixed it in master.
I think the std::vector changes were part of PR240 on CoinUtils. There may be more surprises there.
Thanks, at least my initial regression tests work for all things that did work in the old release I had.
I would recommend rolling back the changes to vector.
When Samuel was developing the conflict graph infrastructure, we did some benchmarking on code that used it versus code with pointers and arrays and performance degradation with vectors was noticeable.
On Fri, Aug 30, 2024, 03:20 John Forrest @.***> wrote:
Many models on standard tests get wrong answer too!
The problem was introduced by using std::vector more. You can get use of uninitialized values in CoinAdjacencyVector (that is easily fixed). However the problem here is using size() as a test for whether a vector is empty in CoinStaticConflictGraph. Maybe someone who know code better than I do could fix - otherwise it will take a bit of time.
— Reply to this email directly, view it on GitHub https://github.com/coin-or/Cbc/issues/668#issuecomment-2320764915, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB4VZOXWWMJI42NSBGHVJ4TZUBBOLAVCNFSM6AAAAABNGFJHJWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRQG43DIOJRGU . You are receiving this because you are subscribed to this thread.Message ID: @.***>
That is not that easy as I use a mirror that just not contains all that stuff and can't use the repos as is as I need it CMake based. If I have more hints where the issue might be, I can add that here.
I have a bunch of ILPs with results 'verified' with a second solver like cplex that I use as regression tests, is there some way to add such stuff to the auto tests?
https://github.com/christoph-cullmann/ilp
At least all x months they find regressions in cbc and Co.
Can you tell me where the Cmakelist.txt file is hiding, I have looked everywhere for it?
See the attached ILP value_3810812.lp.gz
I updated my local CBC to current master (including osi,coinutils,...), now cbc computes a different result (mismatching the cplex one)