[Scip] Upper bound on variables during pricing

[Hélène Toussaint]

Hi Gerald,

Thanks for this clarification.

I have tested again with Cplex as lp solver and the error doesn't occur 
anymore, I do not know why. I use a remote server so perhaps it was an 
error with it...

Best,
Hélène

Le 19/03/2013 22:57, Gerald Gamrath a écrit :
> Hi Hélène,
>
> 3. You can use both methods, SCIPfixVar() will internally use 
> SCIPchgVarUb() in this case, anyway.
> 1. scip_prop() is called when a node is processed for the first time 
> (and sometimes also later again, if a node was marked to be 
> repropagated). You don't need to do it again if you enter the same 
> node again during the tree search (when switching to a node in the 
> corresponding subtree), because the bound changes are locally stored, 
> such that they will be undone when you leave the node (or its 
> subtree), and will be re-applied when you re-enter the node (or its 
> subtree).
> In contrast to that, scip_active() is called every time a node is 
> entered, i.e., also when you switch to a new node in the corresponding 
> subtree. It should be used to update your internal data, which SCIP 
> cannot do automatically.
> 2. You are only allowed to change bounds either globally or at the 
> current focus node, i.e., the node that is currently processed. 
> However, when you switch from one node to another in the tree, all 
> nodes from the common ancestor to the newly focused node are 
> activated, so scip_active() is called. But these nodes are not the 
> focusnode, so you are not allowed to change bounds.
>
> Regarding your issue with CPLEX as LP solver, you can enable the LP 
> solver output by setting the parameter "display/lpinfo" to TRUE, that 
> should help you to check whether its a CPLEX error. Best you also set 
> "display/verblevel" to 5 to see the full output. It might also be that 
> SCIP does not accept the CPLEX LP solution when checking for its 
> (primal and dual) feasibility; in this case, SCIP reoptimizes the LP 
> after changing some LP settings several times until the LP solution 
> passes the SCIP checks.
>
> Best,
> Gerald
>
>
>
>
> Am 19.03.2013 14:32, schrieb Hélène Toussaint:
>> 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
>>>
>>
>

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