[Scip] Question about SCIPdebugCheckConflictFrontier(...) and debugCheckBdchginfos(...)

[michael.winkler at zib.de]

Hi Jana,

sorry for the late response.

I will try to explain what can be the problem.
During branch and bound at each node SCIP performs propagation.
Propagation uses local information, e.g. local bounds of variables, but
also global information, e.g. cliques, to deduce better bounds on
variables. If infeasibility is detected in this node or some descendant,
SCIP asks all perpetrators (plugins) that did bound changes, which led to
the current infeasibility, for an explanation of their local bound
changes. For that, SCIP calls the ...RESPROP callbacks, and there the
plugins report all variables (corresponding to their local bounds) that
led to their performed bound changes (which they should explain).

SCIP uses this information to build up a conflict graph, where each node
contains a variable and a local bound. An arc between two nodes indicates
which information implies the other.

Each cut in the conflict graph defines a valid set of bound changes on
variables that lead to an infeasible sub-problem. SCIP uses some of these
sets to generate conflicts. Each of these sets is called a conflict
frontier.

So a possible reason for a wrong conflict frontier can be, that a bound
changes was not explained correctly. (Not explaining the bound change is
also valid but might lead to longer solving times.)

Did you implement ...RESPROP (CONSRESPROP) callbacks in your plugins that
do propagation? If so please check the correctness.

Best, Micha

P.S. A literal comes from SAT, and means a binary variable or its
negation. (The comment is not correct since a conflict in MIP can contain
also non-binary variables (with bounds).)

> Hi SCIP users!
> I'm using a debug solution and SCIP terminates with the following error:
[src/scip/debug.c:1311] ERROR: invalid conflict frontier:
> <t_t#3#C1_a#1>[1] >= 1(1)
> hsnp: src/scip/debug.c:1329: SCIPdebugCheckConflictFrontier: Assertion
`0' failed.
> The corresponding original variable is set to 1 in my debug solution so
I don't understand why the above inequality is not valid.
> The variable is fixed to 1 at some point and therefore triggers some
propagations which result to a call to SCIPanalyzeConflictCons(...). I
had a look at debug.c and I don't understand which is meant by "check,
whether at least one literals is TRUE in the debugging solution" in
debugCheckBdchginfos(...).
> What is meant by literals?
> Can you help me?
> Thanks,
> Jana Kutscheid
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> http://listserv.zib.de/mailman/listinfo/scip