[SCIP] The rule of the slack variable in an indicator constraint

[Mathieu Besançon]

Dear Abbas,

Not exactly, SOS1 on variables SOS1(x1, x2, x3) means that at most one of
them can take a non-zero value.
You can see the corresponding doc page:
https://www.scipopt.org/doc/html/cons__sos1_8c.php

For the separation method, from a user perspective you do not need to worry
about it. If you are interested in the method used for separation, starting
from the paper linked in my previous response could be a good start.

Best,
Mathieu

On Mon, Aug 21, 2023 at 1:30 PM Abbas Omidi <abb.omidi at gmail.com> wrote:

> Dear Mathieu,
>
> Thank you so much for your reply and also the provided information. I
> actually saw the link corresponds to the indicator constraints, but I am
> not sure to fully understand how this separation works on the slack
> variable. Also, as the constraint that should be used in an indicator
> constraint is of the form (Ax <= b), the slack variable might be a
> violation on the constraint. Now, I have some questions and I was wondering
> if you can give some points to that:
>
>> This constraint is equivalent to a linear constraint ax−s≤b and an SOS1
>> constraint on y and s (at most one should be nonzero)
>
>
> 1) What is it meaning of SOS1 on "y" and "s"? I mean, AFAIK, the SOS1 is
> the form (\sum_{i} x_{i} = 1), how we can interpret the relation between
> "y" and "s" as a SOS1?
>
> In the implementation, we assume that bounds on the original variables x cannot
>> be influenced by the indicator constraint. If it should be possible to
>> relax these constraints as well, then these constraints have to be added as
>> indicator constraints.
>
>
> 2) Does it mean we cannot use the bounded variables as an input into the
> indicator constraint? If so, How can we deal with such a case?
> 3) Unfortunately, I cannot understand of how the SCIP can deal with the
> slack variable in the separation via the alternative polyhedron. It seems
> just to be as the SOS1. Would you please, explain a bit more only about the
> slack variable?
>
>
> All the best
> regards
> Abbas
>
> On Mon, Aug 21, 2023 at 10:25 AM Mathieu Besançon <
> mathieu.besancon at gmail.com> wrote:
>
>> Dear Abbas,
>>
>> The top-level description of the indicator constraint handler of SCIP
>> should be a good start:
>> https://www.scipopt.org/doc/html/cons__indicator_8c.php
>>
>> There are three ways indicator constraints are handled, separation,
>> preprocessing, and a heuristic. Separation is based on this paper in
>> particular: https://doi.org/10.1137/050645828
>>
>> Performance with a big M approach will typically differ. In my
>> experience, if you have a good bound M, a big M approach won't perform too
>> bad, but may be numerically more unstable.
>>
>> SCIP only supports
>> *LHS - slack <= RHS*
>> At least for now.
>>
>> Hope this helps,
>> Mathieu
>>
>> On Mon, Aug 21, 2023 at 8:34 AM Abbas Omidi <abb.omidi at gmail.com> wrote:
>>
>>> Dear support team,
>>>
>>> In the SCIP the indicator constraint can be written as indcons(expression,
>>> binary_var). Then it is interpreted as follows: (based on ".cip" format)
>>>
>>> *LHS - slack (<=/=/>=) RHS*
>>> *If: (binary_var = 1) -> (slack = 0)*
>>>
>>> As far as I know, CPLEX and maybe Gurobi have used binary variables and
>>> whose linking to linearize the logical constraints. I am actually not aware
>>> of their internal mechanism. Now, I would like to know how the SCIP can
>>> deal with indicator constraint internally, and also the rule of the slack
>>> variable in this form, and if is it necessary to use that instead of
>>> using e.g. a *BigM* approach.
>>>
>>>
>>> Best regards
>>> Abbas
>>> _______________________________________________
>>> Scip mailing list
>>> Scip at zib.de
>>> https://listserv.zib.de/mailman/listinfo/scip
>>>
>>
>>
>> --
>> Mathieu Besançon
>>
>

-- 
Mathieu Besançon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.zib.de/pipermail/scip/attachments/20230821/6dfbab1e/attachment.html>