[SCIP] Transformed Problem + Infeasible solution at Constraint Handler

[Matheus Ota]

Hi Gregor,

- The call where the described scenario happens is when calling the
CONSEPALP callback. I call my separation routine at CONSEPALP and
CONSEPASOL.
- I printed the model in my separation routine using SCIPwriteLP(scip,
"test.lp"). Indeed, the knapsack constraint does not appear at that file.
- SCIPgetLPSolstat(scip) == SCIP_LPSOLSTAT_OPTIMAL returns true
- I'm querying the variables using SCIPgetSolVal(scip, sol, x[v][i]), where
sol is NULL if the routine was called from CONSEPALP.

Thanks,
Matheus

Em ter., 10 de dez. de 2019 às 04:49, Gregor Hendel <hendel at zib.de>
escreveu:

> Hi Matheus,
>
> If the constraint flags are set to TRUE, I no longer suspect an issue with
> the constraint separation/enforcement order.
>
> Could you verify that the constraint is contained in the LP using
> SCIPwriteLP() in your consenfolp callback? Could you assert that
> SCIPgetLPSolstat(scip) == SCIP_LPSOLSTAT_OPTIMAL? Finally, how do you query
> the LP solution values of the variables?
>
> I hope this will help to narrow it down,
> Gregor
>
> Am 09.12.19 um 21:23 schrieb Matheus Ota:
>
> Hi Gregor,
>
> My original constraint is flagged with true for the initial, separate and
> check parameters.
> Indeed, my constraint handler has a higher priority (greater than zero,
> since I want to separate fractional solutions) than the knapsack constraint
> handler. So what you are saying is that I'm calling my callback routine
> before adding the knapsack constraints (even though SCIP printed the
> knapsack constraint for the transformed model)? Then I guess this would
> only happen only once? Because after SCIP adds the knapsack constraints,
> all the solutions that enters my callback will respect the knapsack
> constraints (**).
>
> Can I change the separation priority of the knapsack constraint in the
> transformed model? This way I guarantee that the solution that enters my
> callback already satisfies (**).
>
> Thanks,
> Matheus
>
> Em seg., 9 de dez. de 2019 às 13:22, Gregor Hendel <hendel at zib.de>
> escreveu:
>
>> Hi Matheus,
>>
>> your reasoning about negation is correct, so I would expect that the LP
>> solution satisfies ** at CONSENFOLP. A special case occurs if the knapsack
>> constraint is flagged by (not initial/not separate/not check), in which
>> case the constraint is not immediately part of the root LP and might not be
>> separated at violation.
>>
>> Note that the knapsack constraint handler has a very low enforcement
>> priority, -600000. Probably, the enforcement priority of your constraint
>> handler is higher, and the knapsack constraint handler would add its
>> constraint to the LP in the same enforcement round, but later?
>>
>> Kind regards,
>> Gregor
>>
>> Am 06.12.19 um 01:01 schrieb Matheus Ota:
>>
>> Hi all,
>>
>> First I would like to say that I'm very grateful for all the help I
>> received from this mailing list! I have a question regarding a MIP model
>> that I'm solving. I have some equalities of the following type
>>
>>> x_i,0 + x_i,1 == 1, for i = 0, ..., 8 (*)
>>>
>>
>> Thus, SCIP presolve routines replace some of my variables (x_i,0) by the
>> negation of other variables (1 - x_i,1). In the transformed model I have
>> only this constraint
>>
>> [knapsack] <R>: +1<~t_x_8,1>[B] +1<~t_x_7,1>[B] +1<~t_x_6,1>[B]
>>> +1<~t_x_5,1>[B] +1<~t_x_4,1>[B] +1<~t_x_3,1>[B] +1<~t_x_2,1>[B]
>>> +1<~t_x_1,1>[B] +1<~t_x_0,1>[B] <= 4;
>>>
>>
>>  And each variable x is binary. The tilde (~) means negation here? If so,
>> replacing <~t_x_i,1> by <t_x_i,0> this would give
>>
>>> <t_x_8,0> + ... + <t_x_0,0><= 4 (**)
>>>
>>
>> But at the CONSENFOLP method, SCIP is entering with a "solution" S with
>> x_i,0 = 1 and x_i,1 = 0, for i = 0, ..., 8. Which is infeasible because
>> violates (**). But the SCIP documentation says that CONSENFOLP is called
>> when an LP solution is available. But this solution S do not respect the
>> constraints in my LP. I'm a little confused with this behavior and would be
>> glad if someone could give me some light here.
>>
>> Thanks!
>> Matheus
>>
>> _______________________________________________
>> Scip mailing listScip at zib.dehttps://listserv.zib.de/mailman/listinfo/scip
>>
>>
>> _______________________________________________
>> Scip mailing list
>> Scip at zib.de
>> https://listserv.zib.de/mailman/listinfo/scip
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.zib.de/pipermail/scip/attachments/20191211/6acf30ee/attachment.html>