[Scip] Column generation + branch and bound (from binpacking example)

Luigi Malagò luigi.malago at gmail.com
Mon Sep 26 18:10:48 MEST 2011


i solved. the problem was in the formulation of the pricer.

thanks alot,
luigi

On Mon, Aug 22, 2011 at 3:49 PM, Luigi Malagò <luigi.malago at gmail.com>wrote:

> hi gerald,
> your suggestions helped. the same variable has been generated twice by the
> pricer problem.
> this is unexpected. i'm investigating more. i will let you know.
>
> thanks a again ;-)
> luigi
>
>
> On Mon, Aug 22, 2011 at 2:14 PM, Gerald Gamrath <gamrath at zib.de> wrote:
>
>>  Hi Luigi,
>>
>> SCIP copies all original variables when creating the transformed problem,
>> but they get the prefix "t_" then. Also when negating a variable, a new
>> variable with a similar name is created, but it gets the suffix "_neg".
>> However, SCIP never copies variables giving them the exact same name.
>>
>> Thus, it seems that you create two variables with the same name. How are
>> your names built? Do you have a counter that you increase or is it the
>> meaning of the variable (i.e., the set of items), that defines the name? It
>> might happen, that you create two variables for the same set, e.g. due to
>> numerical problems or if you have explicit upper bounds on the variables.
>>
>> The branching candidates are a list of all integer (or binary) variables
>> in the LP, that have a fractional value in the current LP solution. Thus,
>> there might be an arbitrary number of branching candidates, upon which you
>> have to choose a variable to branch on (or in this case two items to branch
>> on).
>>
>> However, it is strange that not all of the variables are contained in the
>> list returned by SCIPgetVars(). Did you update the list right before
>> checking? You could also print the LP solution by SCIPprintTransSol(scip,
>> NULL, NULL, TRUE) and SCIPprintSol(scip, NULL, NULL, TRUE) and check whether
>> the variables appear twice there, too.
>>
>> I hope that helps a bit to locate the problem.
>>
>> Best,
>> Gerald
>>
>> Am 22.08.2011 11:37, schrieb Luigi Malagò:
>>
>> hi list,
>> i'm stuck again with my code, even if now the problem is with
>> branch and bound and the binpacking example. i have some unexpected
>> behavior and i dont understand where is the problem. maybe some of you can
>> help...
>>
>> i'm working on the existing code of binpacking, to add my variables and
>> adapt to my problem,
>> since my example is similar in practice to the binpacking. i have
>> extra variables both in the master and in the pricing problem, all
>> continuous.
>>
>> my question is about the SCIP_DECL_BRANCHEXECLP(branchExeclpRyanFoster)
>> callback.
>> i understand tha Ryan Foster branching, and i want to implement it also in
>> my problem.
>> since the binary variables of the master of the binpacking example are the
>> only
>> binary variables in my master, i think the code should be exacly the same.
>> nevertheless i have some problems:
>>
>> when branching the first time, the SCIPgetLPBranchCands function returns 4
>> variables,
>> my problem is that the 1st and 3rd, and 2nd and 4th, respectively, have
>> the same name, but different
>> fractional value that (in both cases) sum to 1 (the value is then saved in
>> pairweights).
>> as a consequence bestvalue equals 0, and the assert then fails.
>>
>>
>> i dont know if i'm right, but i expect only 2 variables to appear in the
>> array
>> obtained with SCIPgetLPBranchCands. first i tought i had duplicate
>> variables in my problem.
>> i checked the value of the pointers to these 4 vars contained in lpcands,
>> the 1st and 2nd pointers to vars correspond to some variables that appear
>> among the
>> vars of probdata, while the other two do not appear among that list.
>> i obtained this list with SCIPgetVars(scip), where i correcly see the
>> original master variables, plus all that i have added at each iteration of
>> the master/pricer loop.
>>
>> i guess something is wrong with my code, but if the variables are not
>> duplicated in the problem, i have no idea why i obtain duplicate variables
>> then... any idea that could help?
>>
>> once again, thanks a lot for your help,
>> luigi malagò
>>
>>
>> _______________________________________________
>> Scip mailing listScip at zib.dehttp://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/20110926/902d20a8/attachment.html


More information about the Scip mailing list