[SCIP] Transformed Problem + Infeasible solution at Constraint Handler

[Gregor Hendel]

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 
> <mailto: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 list
>>     Scip at zib.de  <mailto:Scip at zib.de>
>>     https://listserv.zib.de/mailman/listinfo/scip
>
>     _______________________________________________
>     Scip mailing list
>     Scip at zib.de <mailto: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/20191210/a8c9dd57/attachment.html>