[Scip] Upper bound on variables during pricing

Hélène Toussaint helene.toussaint at isima.fr
Wed Mar 20 14:22:42 MET 2013


Hi Michael,

It was on this run but I think I understand what happens:
the modifications I do on the problem data at each node depend, among 
other things, on the upper bound (of the solution).Since the upper bound 
is updated during the tree search I update the problem data each time I 
enter a node and fix the variables. So it may be that I don't fix 
exactly the same variables for a same node and SCIP has kept in memory 
the fixed variables the last time it had visited the node.

Thank you for your help.

Best,
Hélène




Le 20/03/2013 00:36, michael.winkler at zib.de a écrit :
> 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
>>

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


More information about the Scip mailing list