[Scip] LP not solved but heuristic called

[Gerald Gamrath]

Dear Jens,

heuristics with timing SCIP_HEURTIMING_AFTERLPLOOP are called after the 
LP solving loop at a node was finished, but (perhaps a bit 
counter-intuitively) independently of whether the LP was solved to 
optimality. In your case, there probably are numerical troubles at node 
175 (please set the verblevel to 5 to verify this), so the LP at this 
node could not be solved.

I would suggest to add a check in your heuristic which stops the 
procedure if the LP was not solved to optimality. This is already done 
in many of SCIP's heuristics, see, e.g., heur_rounding.c.

By the way: For what you are doing, a heuristic is not really the 
correct plugin, but you should better use a relaxation handler. If you 
set the priority of your relaxator to a negative value, it will always 
be called after the LP solving.

Best,
Gerald


> Hello Mailinglist,
>
> I implemented a heuristic to update the dual bound of the current 
> node. Its timingmask is SCIP_HEURTIMING_AFTERLPLOOP, and it needs to 
> results of all the pricingproblems of the last iteration in the 
> pricing loop, as well as the LP solution and duals.
>
> For some reason the LP does not get solved for node 175 (see the 
> extract from the log file below), but the heuristic is called.
> At least I guess the LP was not solved, because there is no output 
> from the LP solver, as is the case for other nodes.
>
> This results in the heuristic taking the pricing results of the 
> previous iteration, and the old LP solution which is not feasible for 
> the current node.
>
> Does anyone know where the trouble might come from?
>
> Thanks
>
> Jens Leoff
>
>
>
>
>   2.5s|   174 |   150 | 10713 |  45.3 |5608k|  73 |  23 |1809 | 784 
> |1808 | 819 |   0 |   0 |   0 | 8.183333e+01 |      -- |    Inf
> In 'scip_active'..of cons: sequence: [19 >= 2], bound: 1.00000000e+00
> In 'scip_prop' of GBBranchingDecisions..
>
> ICHBAS02 basis redimensioning invalidates factorization
> IBASIS02 loading of Basis invalidates factorization
> starting value = 8.20000000e+01
> starting shift = 0.00000000e+00
> type |   time |   iters | facts |  shift   |    value
>   L  |    0.0 |       0 |   414 | 0.00e+00 | 8.20000000e+01
> WDEVEX02 trying refinement step..
>  --- checking feasibility and optimality
>  --- solve(leave) triggers refactorization
>  --- refactorizing basis matrix
>  --- leave finished. iteration: 6, value: 8.20066667e+01, shift: 
> 0.00000000e+00, epsilon: 1.00000000e-16, feastol: 1.00000000e-06, 
> opttol: 1.00000000e-07
> ISOLVE57 stop: 0, basis status: DUAL (1), solver status: RUNNING (-1)
> DSHIFT07 = unshifting ...
>  --- maxInfeas: 3.88578059e-16, shift: 0.00000000e+00, leavetol: 
> 1.00000000e-07
> Finished solving (status=OPTIMAL, iters=6, leave=6, enter=0, flips=0, 
> objValue=8.20066667e+01)
>
> In 'priceSubproblems' (redCost)..
>
> In 'scip_exec' of HeurLagrangeanDualBound..
> globalDualBound: 8.18333333e+01, localDualBound: 8.20066667e+01, 
> lagrangeanDualBound: 8.20066667e+01
>
>   2.5s|   175 |   151 | 10719 |  45.0 |5610k|  74 |  38 |1809 | 784 
> |1808 | 820 |   0 |   0 |   0 | 8.183333e+01 |      -- |    Inf
> In 'scip_deactive'..of cons: sequence: [19 >= 2], bound: 1.00000000e+00
> In 'scip_active'..of cons: sequence: [19 < 2], bound: 1.20000000e+01
> In 'scip_prop' of GBBranchingDecisions..
> In 'scip_exec' of HeurLagrangeanDualBound..
>
> pricing results:
> [(sequence: [], -2.22044605e-16), (sequence: [19 >= 2], -1.11022302e-16)]
> stack:
> [(sequence: [19 < 2], 0xfb7ed0, L: 1.20000000e+01)]
>
> trackLength: 1.19066667e+01
>
> *** Program received signal SIGABRT (Aborted) ***
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> http://listserv.zib.de/mailman/listinfo/scip