[Scip] pricing with upper bounds on variables

Martin Tieves Martin.Tieves at rwth-aachen.de
Thu Jan 19 11:59:29 MET 2012


Hallo

I have a problem with my column generation algorithm. Especially, my question centers around pricing variables with upper bounds.

For training issues, I used the cpp interface of scip (soplex solver) to implement my own version of the coloring (pricing: stable set) example.
I can generate a new variable (stable set) and add it. Then, in the next step, the same variable is generated, again (though it is already used in the new basis solution). From my point of view, the problem lies in the dual variables. Since this variable imposes an upper bound (of value 1 - the stable sets are binary decisions), the infomation about the dual value of this variable is missing in my pricing problem.
So my question is, how can I obtain that dual value?

I am aware of the SCIPchgVarUbLazy command (e.g. in the above example) - which helps in the above case (and is used in the given coloring example code). But what is to do, if the upper bounds are not implicitely given, such that one realy needs the additional bounds (dual variables). From my understanding, this commands forces to ignore the bound-constraints in the lp calculations, only, is that true?

In this context, I have some question to the SCIPgetVarRedcost command. In the above situation, the already added variable has a negative reduced costs value (which should be impossible in my point of view) in the next pricing step, but only if the variable bound was not decleared as lazy. Why is this? I am not sure if the newly added (variable) bound is treated correctly in the corresponding redcost calculation (though I am probably mistaken here ;)  ). (this behaviour can be observed at the example's code as well, if disabling the "lazy" command.)

I am not sure if I understand correctly what happens, if one defines (not implicitely given) upper bounds in the priced variables, from a computational point of view. Do you have any advice how to avoid the above mentioned problems?

Best Regards

Martin




More information about the Scip mailing list