[SCIP] Differences between "active" and "enabled" of constraints

Gregor Hendel hendel at zib.de
Wed Dec 16 12:38:01 CET 2015


Dear Feng and list,

it seems like some additional clarification is needed here. The 
callbacks CONS(DE)ACTIVE, CONSDIS/ENABLE **can** be used to update 
constraint data when the mentioned constraint state is about to change. 
A local constraint gets deactivated or activated no matter if the 
callbacks are present.

Activation/Deactivation and Enabling/Disabling are two different 
concepts, one denoting the presence of the constraint in the local 
subtree, and one denoting the local or global redundancy of the constraint.

The corresponding set covering constraints are global constraints that 
the pricer captures in the pricerInitBinpacking callback. Capturing 
constraints is the way to tell SCIP that the pricer has its data hands 
on these constraints such that they are not accidentally deleted while 
the caller of the capture still wants to work with it.

During presolving, a set covering might be disabled through a call to, 
e.g., SCIPdelCons() (Where SCIP sees that this deletion cannot be 
performed because of the capturing mentioned above).

For exploring things like this on your own, you may simply put an assert 
in the binpacking or your own code at this location, asserting that 
SCIPconsIsEnabled(cons) is equal to SCIPconsIsActive(cons) and trying to 
trace a constraint where the assertion fails (remember to compile in 
debug mode by specifying 'make OPT=dbg' to enable/activate assertions ;).

A last word on this: I wouldn't worry too much about this specific 
detail.I just put the mentioned assert while writing this mail and ran a 
debug test on the six provided instances. In the example, this assertion 
is always fulfilled for both types of constraints, samediff and set 
covering.

Kind regards,
Gregor







Am 14.12.2015 um 14:51 schrieb John Von:
> Dear Gregor,
>
>   Thanks for your help!  I still have some problems:
>   (1) "Enabling is best understood by understanding disabling, I am 
> citing from SCIPdisableCons() in scip.h:
>   disables constraint's separation, propagation, and enforcing 
> capabilities, s.t. the constraint is not propagated,
>   *  separated, and enforced anymore until it is enabled again with a 
> call to SCIPenableCons();
>   *  in contrast to SCIPdelConsLocal() and SCIPdelConsNode(), the 
> disabling is not associated to a node in the tree and
>   *  does not consume memory; therefore, the constraint is neither 
> automatically enabled on leaving the node nor
>   *  automatically disabled again on entering the node again;
>   *  note that the constraints enforcing capabilities are necessary 
> for the solution's feasibility, if the constraint
>   *  is a model constraint; that means, you must be sure that the 
> constraint cannot be violated in the current subtree,
>   *  and you have to enable it again manually by calling 
> SCIPenableCons(), if this subtree is left (e.g. by using
>   *  an appropriate event handler that watches the corresponding 
> variables' domain changes)"
>
>   - The above description means disabled constraints will skip the 
> enforing, which is necessary for the solution's feasibility. However, 
> I found the following description in the "How to add constraint 
> handler" document:
>
>   "The CONSENABLE callback method is called each time a constraint of 
> the constraint handler is enabled. Constraints might be active without 
> being enabled. In this case, only the feasibility checks are executed, 
> but domain propagation and separation is skipped."
>
>   which said the feasibility checks are executed even for disabled 
> constraints, How can I understand this?
>
>    (2) "In the binpacking example, the first loop in the 
> addBranchingDecisionConss() method loops over samediff-constraints. 
> Since the constraint handler does not enable/disable constraints by 
> itself, the loop can simply skip non-active constraints."
>
>    -In the pricer of binpacking example, in the inner for loop of  the 
> local method addFixedVarsConss(...),  SCIPIsEnabled(cons) is called to 
> check the cons which is a set-covering constraint, I checked the 
> cons_setppc.c file, and found the CONSENABLE/DISABLE callbacks are not 
> implemented (just define as NULL,  so the constraint handler does not 
> enable/disable constraints ?), So why SCIPIsEnabled is used here while 
> SCIPconsIsActive is used in addBranchingDecisionConss(...) instead ?
>
>   (3) Some constraint handlers use disabling of their constraints for 
> a more memory-efficient deactivation of separation, propagation, etc. 
> than by deleting the constraint locally. An example that is easy to 
> understand is a logicor-constraint, where one out of a set of binary 
> variables must be set to one. As soon as one variable from this set is 
> fixed to one in the current subtree, the constraint becomes redundant 
> and therefore disabled (locally). It remains present in order to be 
> checked for (global) feasibility, if it is a global constraint.
>
>  -Like with (2), the CONSENABLE/DISABLE callbacks are not implemented 
> (just define as NULL) in the logicor-constraint handler 
> (cons_logicor.c) either, So how "the constraint becomes redundant and 
> therefore disabled" without CONSENABLE/DISABLE callbacks?
>
>   Thanks again,
>
> Best regards,
> Feng
>
>
>
>
> 2015-12-14 11:09 GMT+01:00 Gregor Hendel <hendel at zib.de 
> <mailto:hendel at zib.de>>:
>
>     Dear Feng,
>
>     the best source to start with about such issues is maybe the How
>     To on Adding Constraint handlers in the documentation, where the
>     description of the corresponding callbacks CONSACTIVATE/DEACTIVATE
>     and CONSENABLE/DISABLE tells you what the flags mean.
>
>     Constraints are active as long as the search explores the subtree
>     to which they have been added. This is important for local
>     constraints that are only valid in a part of the search tree.
>
>     Enabled constraints are active constraints that have not been
>     marked "disabled" by their own constraint handler. Enabling is
>     best understood by understanding disabling, I am citing from
>     SCIPdisableCons() in scip.h:
>
>     disables constraint's separation, propagation, and enforcing
>     capabilities, s.t. the constraint is not propagated,
>      *  separated, and enforced anymore until it is enabled again with
>     a call to SCIPenableCons();
>      *  in contrast to SCIPdelConsLocal() and SCIPdelConsNode(), the
>     disabling is not associated to a node in the tree and
>      *  does not consume memory; therefore, the constraint is neither
>     automatically enabled on leaving the node nor
>      *  automatically disabled again on entering the node again;
>      *  note that the constraints enforcing capabilities are necessary
>     for the solution's feasibility, if the constraint
>      *  is a model constraint; that means, you must be sure that the
>     constraint cannot be violated in the current subtree,
>      *  and you have to enable it again manually by calling
>     SCIPenableCons(), if this subtree is left (e.g. by using
>      *  an appropriate event handler that watches the corresponding
>     variables' domain changes)
>
>     Some constraint handlers use disabling of their constraints for a
>     more memory-efficient deactivation of separation, propagation,
>     etc. than by deleting the constraint locally. An example that is
>     easy to understand is a logicor-constraint, where one out of a set
>     of binary variables must be set to one. As soon as one variable
>     from this set is fixed to one in the current subtree, the
>     constraint becomes redundant and therefore disabled (locally). It
>     remains present in order to be checked for (global) feasibility,
>     if it is a global constraint.
>
>     In the binpacking example, the first loop in the
>     addBranchingDecisionConss() method loops over
>     samediff-constraints. Since the constraint handler does not
>     enable/disable constraints by itself, the loop can simply skip
>     non-active constraints.
>
>     I hope this helps.
>
>     Best regards,
>     Gregor
>
>
>
>
>     On 13.12.2015 01:22, johnvon2012 wrote:
>
>         Hi,
>                 I encoutered functions SCIPconsIsActive( cons) and
>         SCIPconsIsEnabled(cons), but I do not under  the differences
>         between "active" and "enabled" of constraints? I have checked
>         these two functions but am  still a little confused with this.
>            I also noticed that both functions are called in the pricer
>         of the binpacking example, SCIPconsIsEnabled is in the
>         SCIP_DEL_PRICERREDCOST callback  and SCIPconsIsActive is in
>         the addBranchingDecisionConss  local method, respectively.
>            Could you please help me with this, especially in the
>         binpacking example?
>
>             Thanks a lot!
>
>
>         best,
>
>         Feng
>
>         _______________________________________________
>         Scip mailing list
>         Scip at zib.de <mailto:Scip at zib.de>
>         http://listserv.zib.de/mailman/listinfo/scip
>
>
>     _______________________________________________
>     Scip mailing list
>     Scip at zib.de <mailto:Scip at zib.de>
>     http://listserv.zib.de/mailman/listinfo/scip
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.zib.de/pipermail/scip/attachments/20151216/dfd9b840/attachment.html>


More information about the Scip mailing list