[SCIP] Constraint handlers and CONSEPALP callbacks

[Gregor Hendel]

Good morning Eleonora,


Am 31.01.2017 um 10:03 schrieb Pippia Eleonora:
> Good morning,
> I’m using SCIP to solve an ILP model MP in order to test a conjecture 
> related to graphs of low dimensions. Actually, the conjecture is 
> equivalent to state that an integer linear programming model MP is 
> unfeasible. I have few questions.
>
> 1) I’ve implemented two constraint handlers with separation callbacks. 
> I don’t understand in which order the callbacks CONSSEPALP for the 
> different constraints are called. Assume that at a node of the 
> branch-and-bound tree, four steps of the separation loop take place. 
>  It happened that in the first three steps SCIP recalled the SEPALP 
> callback from the first constraint handler to add a new violated cut 
> so that the SEPALP from the second constraint handler was delayed in 
> these steps. At the fourth step, sometimes SCIP called immediately the 
> SEPALP from the second constraint handler without calling the callback 
> from the first one. Why can this happen?
from your question, I guess you already made yourself familiar with the 
priorities to decide the order in which separators are called, and the 
delay mechanism.
There are some global parameters to further control the separation process:

   maxcuts               maximal number of cuts separated per separation round (0: disable local separation) [100]

   maxcutsroot           maximal number of separated cuts at the root node (0: disable root node separation) [2000]

   maxroundsroot         maximal number of separation rounds in the root node (-1: unlimited) [-1]

   maxstallrounds        maximal number of consecutive separation rounds without objective or integrality improvement (-1: no additional restriction) [5]


One reason for calling the delayed separator first might be that the 
stalling rounds limit "maxstallrounds" is reached.
If you would like to see a verbose explanation of what happens in SCIP 
right before separator is called, you can
recompile SCIP after putting

#define SCIP_DEBUG

at the top of the two files src/scip/{sepa,solve}.c. If this still 
doesn't explain the behavior of the separators, please report back to me.
>
> 2) Moreover, I ran the same instance with the same model MP but on two 
> different computers. It happened that at the same node of the 
> branch-and-bound, on the two computers SCIP found two different 
> fractional solutions of the LP. This had a strong impact on the number 
> of nodes generated to solve the instance. Is it a normal behavior?
Unfortunately, the answer is yes. This is why we always report our 
experimental setups as detailed as possible, including the operating 
system, the used compiler and its version, and the processor 
architecture plus memory size.
In my experience, matching operating system version and compiler version 
are sufficient in order to obtain reproducible results.

Can you give more details on the architectures you are testing on?
>
> 3) Finally, is there any way to use SCIP as an MIP-solver disabling 
> all the constraint programming features?
There is no such emphasis setting that comes with SCIP. I assume you 
would like to test a pure branch-and-cut approach, but disable restarts, 
conflict analysis, and domain propagation. However, I am warning you 
that such features are integrated and very essential for the solving 
process of all modern MIP solvers. Here is what a custom SCIP settings 
file for this purpose might look like:

conflict/enable = FALSE

presolving/maxrestarts = 0


In addition, set the propagation frequencies of all active propagators 
and constraint handlers (propagation frequency >=0) to -1 instead:

>> grep -P "(propagating/.*/freq|constraints/.*/propfreq) = [01]" default.set

constraints/nonlinear/propfreq = 1

constraints/quadratic/propfreq = 1

constraints/linear/propfreq = 1

constraints/abspower/propfreq = 1

constraints/and/propfreq = 1

constraints/bivariate/propfreq = 1

constraints/bounddisjunction/propfreq = 1

constraints/cardinality/propfreq = 1

constraints/cumulative/propfreq = 1

constraints/indicator/propfreq = 1

constraints/knapsack/propfreq = 1

constraints/linking/propfreq = 1

constraints/logicor/propfreq = 1

constraints/or/propfreq = 1

constraints/setppc/propfreq = 1

constraints/soc/propfreq = 1

constraints/SOS1/propfreq = 1

constraints/SOS2/propfreq = 1

constraints/superindicator/propfreq = 1

constraints/varbound/propfreq = 1

constraints/xor/propfreq = 1

constraints/components/propfreq = 1

propagating/dualfix/freq = 0

propagating/genvbounds/freq = 1

propagating/obbt/freq = 0

propagating/pseudoobj/freq = 1

propagating/redcost/freq = 1

propagating/rootredcost/freq = 1

propagating/vbounds/freq = 1



Kind regards,
Gregor



>
> Thanks for your time (and thanks for SCIP!!!)
> Best regards,
> Eleonora Pippia
>
>
>
> _______________________________________________
> Scip mailing list
> 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/20170202/059f8157/attachment.html>