[Scip] "SCIProwGetScalarProduct: Assertion `row2->nonlpcolssorted' failed." after adding a cut.

Gerald Gamrath gamrath at zib.de
Thu Jan 5 14:27:20 MET 2012


Hi Daniel,

a happy new year to you, too.

Could it be that you called SCIPcacheRowExtensions() on the row without 
calling SCIPflushRowExtensions() afterwards, before adding the cut? That 
would explain why the delaysort flag is set to TRUE at this point. If 
you just flush the extensions then, before adding the cut, everything 
should work.

Besides, the two cuts seem to be exactly the same, which is not too bad, 
because SCIP will detect this and add only one of them, anyway. However, 
perhaps you can even avoid this in your cut generation process and save 
some time there?

Best,
Gerald

Am 05.01.2012 13:58, schrieb Daniel Karch:
> Hi and happy new year to everyone,
>
> I have the following problem.
> After adding a cut in a constraint handler with SCIPaddCut, I get the 
> following error (the added cuts are printed out with SCIPaddRow for 
> debugging purposes:
>
> ...
>  15.9s|     1 |     0 |  1445 |     - |  13M|   0 | 138 | 723 |1368 | 
> 723 |1435 |  71 |   1 |   0 | 8.287500e-01 | 1.050000e+00 |  26.70%
>  16.3s|     1 |     0 |  1448 |     - |  13M|   0 | 144 | 723 |1368 | 
> 723 |1436 |  72 |   1 |   0 | 8.287500e-01 | 1.050000e+00 |  26.70%
> E16.4s|     1 |     0 |  1448 |     - |  13M|   0 | 144 | 723 |1368 | 
> 723 |1436 |  72 |   1 |   0 | 8.287500e-01 | 9.783333e-01 |  18.05%
>  16.5s|     1 |     0 |  1448 |     - |  13M|   0 | 144 | 723 |1368 | 
> 723 |1436 |  72 |   1 |   0 | 8.287500e-01 | 9.783333e-01 |  18.05%
>  16.9s|     1 |     0 |  1465 |     - |  13M|   0 | 164 | 723 |1368 | 
> 723 |1439 |  75 |   1 |   0 | 8.287500e-01 | 9.783333e-01 |  18.05%
>  16.9s|     1 |     2 |  1465 |     - |  13M|   0 | 164 | 723 |1368 | 
> 723 |1439 |  75 |   1 |   0 | 8.287500e-01 | 9.783333e-01 |  18.05%
> Adding cut cons_vc2_6_10_3_11: 0 <= +1<t_y_(11,6)_6> 
> +1<t_x_(6,10)_[3->10]> +1<t_x_(11,3)_[7->10]> <= 2
> Adding cut cons_vc2_6_10_11_6: 0 <= +1<t_x_(6,10)_[3->10]> 
> +1<t_x_(11,3)_[7->10]> +1<t_y_(11,6)_6> <= 2
> scipmincon.linux.x86_64.gnu.dbg.cpx: src/scip/lp.c:6037: 
> SCIProwGetScalarProduct: Assertion `row2->nonlpcolssorted' failed.
> Aborted
>
>
> The stack trace is
>
> #0  0x00002aaaabfc9d95 in raise () from /lib64/libc.so.6
> #1  0x00002aaaabfcb2ab in abort () from /lib64/libc.so.6
> #2  0x00002aaaabfc28fe in __assert_fail_base () from /lib64/libc.so.6
> #3  0x00002aaaabfc29a2 in __assert_fail () from /lib64/libc.so.6
> #4  0x00000000005325b3 in SCIProwGetScalarProduct (row1=0x21060d0, 
> row2=0x2105da0) at src/scip/lp.c:6037
> #5  0x0000000000532b72 in SCIProwGetParallelism (row1=0x21060d0, 
> row2=0x2105da0, orthofunc=101 'e') at src/scip/lp.c:6125
> #6  0x0000000000532cbe in SCIProwGetOrthogonality (row1=0x21060d0, 
> row2=0x2105da0, orthofunc=101 'e') at src/scip/lp.c:6151
> #7  0x0000000000631268 in sepastoreUpdateOrthogonalities 
> (sepastore=0x175d7d0, blkmem=0x145e1b0, set=0x14601d0, 
> eventqueue=0x16387b0, eventfilter=0x1698e40, lp=0x1638360, 
> cut=0x21060d0, mincutorthogonality=0.5) at src/scip/sepastore.c:614
> #8  0x000000000063159f in sepastoreApplyCut (sepastore=0x175d7d0, 
> blkmem=0x145e1b0, set=0x14601d0, eventqueue=0x16387b0, 
> eventfilter=0x1698e40, lp=0x1638360, cut=0x21060d0, 
> mincutorthogonality=0.5, depth=6, ncutsapplied=0x7fffffffcf80) at 
> src/scip/sepastore.c:670
> #9  0x0000000000631bce in SCIPsepastoreApplyCuts (sepastore=0x175d7d0, 
> blkmem=0x145e1b0, set=0x14601d0, stat=0x156ccc0, tree=0x17ca160, 
> lp=0x1638360, branchcand=0x16382d0, eventqueue=0x16387b0, 
> eventfilter=0x1698e40, root=0, cutoff=0x7fffffffd6fc) at 
> src/scip/sepastore.c:817
> #10 0x000000000064ebd7 in priceAndCutLoop (blkmem=0x145e1b0, 
> set=0x14601d0, stat=0x156ccc0, prob=0x17b42c0, primal=0x17ca0b0, 
> tree=0x17ca160, lp=0x1638360, pricestore=0x175d710, 
> sepastore=0x175d7d0, cutpool=0x1908a00, branchcand=0x16382d0, 
> conflict=0x17ca330, eventfilter=0x1698e40, eventqueue=0x16387b0, 
> initiallpsolved=0, cutoff=0x7fffffffd6fc, unbounded=0x7fffffffd6f8, 
> lperror=0x7fffffffd548, pricingaborted=0x7fffffffd54c) at 
> src/scip/solve.c:2112
> #11 0x000000000064ffcb in solveNodeLP (blkmem=0x145e1b0, 
> set=0x14601d0, stat=0x156ccc0, origprob=0x156d6e0, 
> transprob=0x17b42c0, primal=0x17ca0b0, tree=0x17ca160, lp=0x1638360, 
> pricestore=0x175d710, sepastore=0x175d7d0, cutpool=0x1908a00, 
> branchcand=0x16382d0, conflict=0x17ca330, eventfilter=0x1698e40, 
> eventqueue=0x16387b0, initiallpsolved=0, cutoff=0x7fffffffd6fc, 
> unbounded=0x7fffffffd6f8, lperror=0x7fffffffd548, 
> pricingaborted=0x7fffffffd54c) at src/scip/solve.c:2434
> #12 0x000000000065216f in propAndSolve (blkmem=0x145e1b0, 
> set=0x14601d0, stat=0x156ccc0, origprob=0x156d6e0, 
> transprob=0x17b42c0, primal=0x17ca0b0, tree=0x17ca160, lp=0x1638360, 
> relaxation=0x162fa50, pricestore=0x175d710, sepastore=0x175d7d0, 
> branchcand=0x16382d0, cutpool=0x1908a00, conflict=0x17ca330, 
> eventfilter=0x1698e40, eventqueue=0x16387b0, focusnode=0x2aaaad505650, 
> actdepth=6, timingmask=1, propagate=1, solvelp=1, solverelax=1, 
> forcedlpsolve=0, nlperrors=0x7fffffffd56c, 
> fullpropagation=0x7fffffffd554, propagateagain=0x7fffffffd558, 
> initiallpsolved=0x7fffffffd564, solvelpagain=0x7fffffffd55c, 
> solverelaxagain=0x7fffffffd560, cutoff=0x7fffffffd6fc, 
> unbounded=0x7fffffffd6f8, lperror=0x7fffffffd548, 
> pricingaborted=0x7fffffffd54c, forcedenforcement=0x7fffffffd544) at 
> src/scip/solve.c:3036
> #13 0x0000000000652eda in solveNode (blkmem=0x145e1b0, set=0x14601d0, 
> stat=0x156ccc0, origprob=0x156d6e0, transprob=0x17b42c0, 
> primal=0x17ca0b0, tree=0x17ca160, lp=0x1638360, relaxation=0x162fa50, 
> pricestore=0x175d710, sepastore=0x175d7d0, branchcand=0x16382d0, 
> cutpool=0x1908a00, conflict=0x17ca330, eventfilter=0x1698e40, 
> eventqueue=0x16387b0, cutoff=0x7fffffffd6fc, unbounded=0x7fffffffd6f8, 
> infeasible=0x7fffffffd6f4, restart=0x7fffffffd888, 
> afternodeheur=0x7fffffffd6ec) at src/scip/solve.c:3269
> #14 0x00000000006558b9 in SCIPsolveCIP (blkmem=0x145e1b0, 
> set=0x14601d0, stat=0x156ccc0, mem=0x145c120, origprob=0x156d6e0, 
> transprob=0x17b42c0, primal=0x17ca0b0, tree=0x17ca160, lp=0x1638360, 
> relaxation=0x162fa50, pricestore=0x175d710, sepastore=0x175d7d0, 
> cutpool=0x1908a00, branchcand=0x16382d0, conflict=0x17ca330, 
> eventfilter=0x1698e40, eventqueue=0x16387b0, restart=0x7fffffffd888) 
> at src/scip/solve.c:3854
> #15 0x00000000005e7ed0 in SCIPsolve (scip=0x145c010) at 
> src/scip/scip.c:7562
> #16 0x000000000062ca33 in fromCommandLine (scip=0x145c010, 
> filename=0x7fffffffe41d "fsg/polska.fsg") at src/scip/scipshell.c:135
> #17 0x000000000062d2ef in SCIPprocessShellArguments (scip=0x145c010, 
> argc=3, argv=0x7fffffffdf78, defaultsetname=0xfd1b47 "scipmincon.set") 
> at src/scip/scipshell.c:341
> #18 0x0000000000408773 in runSCIP (argc=3, argv=0x7fffffffdf78) at 
> src/cppmain.cpp:85
> #19 0x000000000040893c in main (argc=3, argv=0x7fffffffdf78) at 
> src/cppmain.cpp:123
>
> At the beginning of SCIProwGetScalarProduct, the rows are sorted:
>
> /* make sure, the rows are sorted */
> SCIProwSort(row1);
> assert(row1->lpcolssorted);
> assert(row1->nonlpcolssorted);
> SCIProwSort(row2);
> assert(row2->lpcolssorted);
> assert(row2->nonlpcolssorted);
>
> In SCIProwSort, the method rowSortNonLP is called, and this is where 
> strange things happen:
>
> /* check, if row is already sorted in the non-LP part, or if the 
> sorting should be delayed */
> if( row->nonlpcolssorted || row->delaysort )
>   return;
>
> For my row, I get row->nonlpcolssorted = 0 and row->delaysort = 1, 
> which is why the method returns without actually doing something, and 
> the assertion fails.
>
> This is too deep inside of SCIP's guts for me to understand. If you 
> have an idea what usually triggers this error, and what I could do to 
> prevent it, I would greatly appreciate it.
> BTW, this happens in version 2.1.1 as well as 2.1.0.
>
> Best regards,
>
>   Daniel
>
>
>
>
>
>
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> http://listserv.zib.de/mailman/listinfo/scip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserv.zib.de/mailman/private/scip/attachments/20120105/219ba5fb/attachment.html


More information about the Scip mailing list