[Scip] Upper bound on variables during pricing

Wed Mar 20 00:36:19 MET 2013

Hi Hélène,

>>>> 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?

looking at your attached statistics I cannot detect any propagator
reducing a domain or even fixing a variable. Was an upperbound of some
variable in the corresponding run also changed to zero? If so, you could
try to use gdb or any other debugger and set a watchpoint on the
corresponding upperbound, which will not be changed by your own plugins.
If you might send us some statistics of a run where you didn't encounter
such a bound change, can you please send us a new one of a run when
encountering it.

Best, Michael

> 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
>>>
>>
>
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> http://listserv.zib.de/mailman/listinfo/scip
>