[SCIP] creating and checking solution in the original space

[Rolf van der Hulst]

Dear Marko,

I noticed a potential point of confusion; you mention that you 'get' the 
solution using SCIPlinkLPSol().
However, this function does not set the the values of the variables in 
the solution, and only semantically 'links' the solution to the current 
LP solution, so that the solution can be associated with a certain lp 
solution. Instead, one should use SCIPgetSolVal(), SCIPgetSolVals() or 
SCIPgetSolVarsData() with a NULL ptr for the SCIP_SOL * argument in 
order to get the solution values of the current LP solution.

You also mention using SCIPgetSolVal(), but if one uses this on the 
SCIP_SOL * on which SCIPlinkLPSol() was called and which is not NULL, 
then the output should be bad because you are not actually working with 
the LP solution.


Best,

Rolf

On 20-10-2022 00:35, Ambros Gleixner wrote:
> Dear Marko,
>
> Sorry for the delayed reply.  From your description I have no good 
> idea what could go wrong.  Your workflow should be fine.  Could it be 
> that you use SCIP_VAR* pointers for transformed problem variables when 
> calling SCIPsetSolVal() on the original solution? I suppose you have 
> run the code in debug mode and no asserts came up?
>
> Best,
> Ambros
>
>
>
> Am 13.10.22 um 09:31 schrieb HORVÁTH Markó:
>> Hi all,
>>
>> I'm working on a project, where we need to solve a task 
>> assignment-like problem. Briefly,
>> - we have x-variables to assign quantities to operators in a planning 
>> horizon,
>> - we have y-variables to aggregate certain x-variables (i.e., y = x + 
>> x + ... + x),
>> - we have surplus/backlog variables to handle stock level (i.e., y(t) 
>> + s(t-1) + b(t) = s(t) + b(t-1) + demand(t)),
>> - and we have a lot of knapsack constraints on x-variables which make 
>> the problem hard.
>>
>> Because on bigger instances SCIP hardly finds an integer feasible 
>> solution, I'm about to create a primal heuristic method. That is, I 
>> want to round down the LP values of the x-variables, and adjust the 
>> other variables to satisfy the aggregation and balance equations.
>>
>> I want to work on original variables, because preprocessing may 
>> change variable bounds, and the created solution would be infeasible 
>> (and I also should deal with multi-agregated variables, etc.). It is 
>> not problem for me, if I cannot store the solution in SCIP, but I 
>> want to check its feasiblity.
>> 1) I created a primal heuristic class from *scip::ObjHeur*.
>> 2) I got the current LP solution via *SCIPlinkLPSol*.
>> 3) I created a new primal solution in the original space via 
>> *SCIPcreateOrigSol*.
>> 4) Then, for (original) x-variables I do the rounding: *SCIPgetSolVal 
>> -> SCIPfloor -> SCIPsetSolVal*. (And for all the other variables I 
>> also set the adjusted value via SCIPsetSolVal).
>> 5) Unfortunately (for the second time), *SCIPcheckSolOrig**raises an 
>> error*: solution violates original bounds of variable <t_x_47_128_2> 
>> [-0,0] solution value <15>
>>
>> But, when I check the solution value of the original/transformed 
>> variables x_47_128_2/t_x_47_128_2 in the new solution, these are not 
>> 15, but 0.
>>
>> So, could you please help me if my approach is good or not, and if 
>> yes, what can cause this checking error?
>>
>> Best regards,
>> Marko
>>
>>
>>
>> _______________________________________________
>> Scip mailing list
>> Scip at zib.de
>> https://listserv.zib.de/mailman/listinfo/scip
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> https://listserv.zib.de/mailman/listinfo/scip