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

Abbas Omidi abb.omidi at gmail.com
Wed Aug 23 13:15:14 CEST 2023


Dear Mathieu,

Many thanks for your mentioned link. It is very helpful and gives me some
new insight about SOS1 constraints.
For the second, I actually need more time to understand the idea behind
that.

Thanks once again
All the best
Abbas

On Tue, Aug 22, 2023 at 12:04 AM Mathieu Besançon <
mathieu.besancon at gmail.com> wrote:

> 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/20230823/c1a4d36c/attachment.html>


More information about the Scip mailing list