[Scip] Added Variables missing in problem / solution

Gerald Gamrath gamrath at zib.de
Fri Feb 6 11:59:05 CET 2015


Dear Jan,

sorry for the delayed reply. See my comments below.

>
> My scheduling problem has one set partitioning constraint for every 
> vehicle and binary variables for every possible start-timeslot. All 
> variables are created at the beginning, but only two variables for 
> every vehicle/setppc-constraint are added to the problem and their 
> constraints right away. At the end, the solution must have one binary 
> variable set to one for every vehicle/setppc-constraint.
>
> In the pricing process, the reduced cost of the other variables (start 
> slots) are calculated and added to the problem with SCIPaddPricedVar() 
> and added to the transformed constraints afterwards. In the iteration 
> process, more and more variables are added to the problem. But 
> sometimes the objective value is rising slightly, which is odd because 
> added variables enlarge the solution space which should lead to a 
> decreasing objective value.
What do you mean with objective value? The optimum of the LP? By which 
amount (absolute and relative) does the objective change? Really small 
changes could just be caused by numerics.


> Unfortunately, some variables don't appear in the solution 
> SCIPprintSol() but in the solution SCIPprintTransSol(). 
> Unsurprisingly, these are all priced variables. The objective value of 
> both solution-files are the same, though. But if the objective value 
> is calculated by all solution variables (SCIPvarGetLPSol(vars(f,d)) == 
> 1)  and their objective function values (SCIPvarGetObj(vars(f,d)), the 
> result is a little bit lower than the printed 
> solution-objective-function-values.
Yes, since the priced variables have no equivalent in the original 
space, they are left out when printing an original solution. The 
objective, however, is the one of the transformed solution, so solution 
and objective do not necessarily fit together (on the other hand, 
printing a wrong objective value would be bad as well). So you need to 
get the transformed solution when you do branch-and-price. In most of 
the cases when doing branch-and-price, you even write your own solution 
printing method, since you rather want to write down the "meaning" of 
the variables instead of the names.
Your case is very special, because you create all variables in the 
beginning, but since they are not added to the original problem, they 
cannot be printed in the original solution.

>
> To summarize the matter, there is a serious problem in connection with 
> the pricing problem and the transformed problem.
>
> - Could the error stem from the fact that the variables are added from 
> pricerdata to the problem?
No, this should be ok.

> - Is it necessary to add the priced variables to the original problem, 
> too?
No, this is not possible, since the original problem cannot be changed 
during the solving process.

> - Is there some presolving/branch&bound/relaxation going on, which 
> interferes with the pricing?
If you marked your constraints to be modifiable, no presolving should 
interfere. Branch-and-bound is of course happening when the root LP was 
finally solved, and you should implement your problem-specific branching 
rule when doing branch-and-price.

> - Could numerical inconsistencies lead to such behaviour?
Yes, at least to small changes in the objective.


If you send me your log file including statistics, I can have a look to 
check for problems.

Best,
Gerald





More information about the Scip mailing list