[Scip] Upper bound on variables during pricing

Alessia Violin aviolin at ulb.ac.be
Wed Mar 20 14:41:17 MET 2013


Hello Hélène,

at some point I also got an error of some numerical troubles in LP only 
for a couple of instances, now I don't remember the exact error, but I 
think it was due from the fact that I was checking the positivity of the 
reduced cost to add columns (I am maximizing) with an epsilon of 10^-8, 
and actually the numerical precision of Cplex is smaller (I think around 
10^-5). So I changed the epsilon to 10^-5 and didn't have any more this 
problem.

I don't know if this will solve your problem, but trying it is very easy.

Alessia


On 03/19/2013 02:32 PM, Hélène Toussaint wrote:
> Hi Gerald,
>
> Thank you for your answer. I enclose the statistics.
>
> Indeed I use propagation to propagate my modifications on the problem 
> data and variables. But I have some doubts concerning the scip_prop() 
> and scip_active() methods of the constraint handler for branching 
> decisions:
>
> 1. Is scip_prop() always called after scip_active() when SCIP enter a 
> node?
> 2. Why I can't fix variables in scip_active()? If I try then 
> SCIPnodeAddBoundinfer() displays an assertion about the nodetype 
> (which is equal to 8 in this case)
> 3. In scip_prop(), what method should I use to set a variable to 0: 
> SCIPchgVarUb() or SCIPfixVar()?
>
> Furthermore I have tried to link with cplex instead of soplex. All my 
> instances give good results except one which stops with the following 
> error message:
>
> "ERROR: (node 2502) unresolved numerical troubles in LP 3348 cannot be 
> dealt with"
>
> Is it an error from cplex? How can I see what happens? Debug mode 
> doesn't give more information.
>
> Best,
> Hélène
>
>
> Le 19/03/2013 12:48, Gerald Gamrath a écrit :
>> Hi Hélène,
>>
>> you are right, that should not happen. Can you send me the solving 
>> statistics, which you get by typing "display statistics" in the 
>> interactive shell or calling SCIPprintStatistics()? This should help 
>> to identify the plugin which changes the bound.
>>
>> Besides, you best disable the other propagators, too, if you don't 
>> want SCIP to change bounds itself. You can either disable all 
>> propagation by setting propagating/maxrounds and 
>> propagating/maxroundsroot to 0, but I guess your modifications to the 
>> problem data after branching are also done during propagation? In 
>> this case, you need to disable all default propagators individually 
>> by setting their freqency to -1.
>>
>> Best,
>> Gerald
>>
>> Am 18.03.2013 11:37, schrieb Hélène Toussaint:
>>>
>>> Dear all,
>>>
>>> I use SCIP to code a branch & price algorithm on positive continuous 
>>> variables. I branch on instance data (using a constraint handler to 
>>> store the branching decisions). When I modify the instance data some 
>>> variables become forbidden (I fix their upper bound to 0).
>>>
>>> I'd like SCIP to not set upper bound on the other variables. As 
>>> explained in the FAQ I have marked all constraints containing priced 
>>> variables as modifiable and added SCIPsetIntParam(scip, 
>>> "propagating/rootredcost/freq", -1). But occasionally there is a 
>>> variable with an upper bound equals to 0 although it isn't forbidden 
>>> in the current node. How is this possible? Could you please help me 
>>> with this issue?
>>>
>>> Best regards,
>>>
>>> Hélène
>>>
>>>
>>>
>>> _______________________________________________
>>> Scip mailing list
>>> Scip at zib.de
>>> http://listserv.zib.de/mailman/listinfo/scip
>>
>
>
>
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> http://listserv.zib.de/mailman/listinfo/scip

-- 
Alessia Violin
Service Graphes et Optimisation Mathématique (G.O.M.)
Université Libre de Bruxelles
C.P. 210/01
Boulevard du Triomphe
B-1050 BRUXELLES
Tel: 02 650 58 80 - Fax: 02 650 59 70
Email: aviolin at ulb.ac.be
Webpage: http://homepages.ulb.ac.be/~aviolin/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserv.zib.de/mailman/private/scip/attachments/20130320/03c5d135/attachment.html


More information about the Scip mailing list