[Scip] Could a global cut be discarded ?

[nikolaj@crt.umontreal.ca]

> Hi Nikolaj,

Hi Tobias,

Thank you very much for your answer and help.

I still have some issues with global cuts not taken into account. See below.

> Now back to your questions:
>
>
> As far as I can see, you are essentially facing two issues:
>
>
> 1. The global cut pool is not separated at local nodes, because the
> "separating/poolfreq" parameter is still on its default value 0. You
> should just set it to 1 (or any appropriate positive value) in order to
> make sure that your cuts from one local node are also used in other local
>  nodes.

I've set this parameter to 1 but nothing changed. I still see my global
cut discovered/violated three times during the search.

>
> 2. Even if the global cut pool added one of your "old" cuts to the
> intermediate cut storage (from which the cuts are added to the LP after cut
> filtering), you will find the same cut again in your separator and
> basically waste the time to find an already known cut.

Ok, I understand this.

> In order to avoid
> this, my suggestion is to separate your cuts in a "delayed" fashion. This
>  means, when your cut separator is called (which is always after the
> global cut pool has already been scanned), and there are already cuts in
> the separation storage, then you just do nothing and wait for the next
> round. If you want to do this manually, you can call SCIPgetNCuts() to get
> the current number of cuts stored in the separation storage. If this is
> positive, just set *result = SCIP_DELAYED and do nothing. The
> SCIP_DELAYED
> status tells SCIP that even though your separator did not find any cuts it
>  should be called again (even on the same solution) if nobody else found
> a cut or all cuts have been discarded in the filtering step. The same thing
> can be done automatically by setting the SEPA_DELAY flag to TRUE in the
> creation of the separator plugin. For constraint handlers, this flag is
> called CONSHDLR_DELAYSEPA, see the sepa_xxx.c and cons_xxx.c templates. If
> the plugin has this flag, than SCIP only calls it if none of the higher
> priority plugins have found a cut for the current solution. If you want to
> have a finer control on when to separate cuts and when to delay your
> separator, you need to use the manual way described above. But I think you
> should be fine with the automatic way, at least if your separation
> procedure is so expensive that you really want to only call it if nobody
> else has found a cut.
>
>

This sounds like a perfect answer to my problem but I can't make it work.
Maybe I'm doing something wrong somewhere? I've tried both solution (by
hand by
calling SCIPgetNCuts() and the automatic version by setting the SEPA_DELAY
flag to TRUE)
but none of them seems to work: the global cut is still generated three
times.

I've tested each solution separately and together.

I've taken away all the other separators and added the "faulty" separator
with SEPA_DELAY flag to FALSE and tested
how many cuts where in the global cut pool. SCIPgetNCuts() always returns
0 at the beginning of the separator.

SCIPgetNCutsApplied() and SCIPgetNCutsFound() always return exactly the
same number of cuts and this number is exactly the number of discovered
cuts
by the separator. What I understand is that the same cut that was
generated three times is considered as three different cuts. Is this
correct ? But it is exactly the same cut discovered by the same separator..

>
> I hope this solves most of your issues. If not, feel free to ask again.

Thank you very much for your help.

>
>
>
> Best,
>
>
> Tobias

Best regards,

Nikolaj
>
>
>