[Scip] Added Variables missing in problem / solution

[Gerald Gamrath]

Dear Jan,

sorry for the late reply, we were quite busy in the last weeks. Find my 
comments inline.


> following your comments, we changed our code, so that only some 
> initial variables are created & added at the beginning. In the pricing 
> process, variables with reduced cost are created and added to the 
> problem. In this way, all created and added variables appear in the 
> solution SCIPprintSol(). The pricing process is now running fine.
Good to hear that.

> Before the change of the pricing implementation, the objective 
> SCIPgetSolOrigObj(scip, scipSol) did worsen in some iterations. Now 
> the total objective improves in every iteration. However, in some 
> iterations the sum of the objective values of the solution variables 
> is smaller than the total objective. This iterations have a relaxed 
> solution, with the solution status "LP was solved to optimality".
>
>         SCIP_VAR** pricerSolVars = SCIPgetVars(scip);
>         SCIP_Real pricerSolSum   = 0;
>         for(int vi=0; vi<SCIPgetNVars(scip); vi++){
>             pricerSolSum += SCIPvarGetLPSol(pricerSolVars[vi]) * 
> SCIPvarGetObj(pricerSolVars[vi]);
>         }
>
> My guess is, that SCIPgetSolOrigObj() always refers to the best 
> overall objective of the solution, wheras
> SCIPvarGetLPSol() gets the solution value of the current relaxation. 
> Is there any way to get the relaxed objective directly? As far as I 
> could see, SCIPgetSolTransObj() always returns the same value as the 
> original objective.
You are right, SCIPvarGetLPSol() does always return the value of the 
variable in the current LP relaxation solution (as the name suggests :-)).
On the other hand, SCIPgetSolOrigObj() and SCIPgetSolTransObj() return 
the solution value of a given solution either in the original problem 
space or in the transformed one. The difference is that presolving might 
scale the objective or introduce an objective offset, in which case they 
might differ (which should normally not be the case for branch-and-price 
applications, as you verified).
However, as I said, it returns the value of a given solution. So what 
objective you get depends on which solution you supply and you did not 
tell which one this is. If it is the solution obtained by 
SCIPgetBestSol(), this always refers to the best-known primal feasible 
solution (i.e., which also satisfies integrality restrictions). But you 
can also give NULL as sol, in which case you get the objective of the LP 
solution.


> At the end, the solution is optimal. We're just using binary variables 
> in settppc and knapsack constraints with a linear cost function. The 
> log shows, that a scip-supplied branching rule is used. I have 
> disabled the heuristic "shiftandpropagate", because it increases the 
> solution time 10x. How much could be gained from implementing a 
> problem specific branching rule?
This depends heavily on your specific problem and how your branching 
rule would work. In general, branching on the master variables is a bad 
idea, because 1) it is unbalanced and 2) you have to make sure that your 
pricing does not generate a copy of a variable you just fixed to 0. This 
can increase you pricing effort significantly. In some special cases, if 
might work, as in the example for which you sent the log file, where the 
dual bound is quite good from the beginning. But if this is not the case 
anymore for larger instances, you should consider a problem-specific 
branching rule.

Best,
Gerald