[SCIP] Fwd: A specific question about the Graph Coloring Application

Rolf van der Hulst rolfvdhulst at gmail.com
Wed Jul 7 15:46:19 CEST 2021 

Dear Marc,

The error is triply subtle:

First, I think there's a mistake in pricer_coloring.c, line 320. The given
if statement is often always false: I think this should be used

if ( pricerdata->actindex+1 == pricerdata->maxvarsround )

Because now, the relevant code below is never hit (by what seems according
to the documentation, by accident), and the pricing problem always solved
to optimality, even if bestonly = FALSE.

In the solution callback of tclique, the computation can be stopped early.
Although the 'onlybest' variable is TRUE in the default settings,
preventing this issue from happening, it can stop the clique algorithm
early when not using these default settings. (See lines 320-331,
pricer_coloring.c), In this case, the generated bound would be invalid (or
atleast, you can not certify that the bound is valid).

With these changes, one can for example run the test instance queen9_9.col
and find a invalid lower bound of 9.26 in the root node (it should be 9),
by setting max_vars_round = 1 (this needs to be done in heur_init.c, as
otherwise it is overwritten by it), and onlybest = FALSE. The third
subtlety is that since the bound is only used when doing early branching,
it is very easy for it to go 'undetected' as it is discarded after solving
the branch and bound node. Only when I printed this value, I detected the
above issues.

The numerical issues you mention can also be significant; for some
difficult instances the pricer as implemented in SCIP cannot find the last
few columns and stops pricing too early (for example, the dimacs instance
DSJC125.1 has fractional coloring in the root node of 4.45222 when using
'safe lower bounds' / better pricing algorithms, but the coloring
application puts it at 4.46.... ).

As a general note, I would not recommend to always solve the pricing
problem to optimality for graph coloring from my computational experience.
It is often quite expensive to solve the pricing problem to optimality
compared to the cost of finding a negative reduced cost column,
particularly for larger, more difficult, graphs. Solving until finding a
reduced cost column is typically much faster for difficult instances, and
smart pricing schemes which alternate between finding columns quickly and
between solving to optimality can in some instances be orders of magnitude
faster. (for reference, see 'graph coloring problems via constraint
programming and column generation' by Gaulandi and Malucelli).

Best,

Rolf

On Wed, Jul 7, 2021 at 12:00 PM Marc Pfetsch <
pfetsch at mathematik.tu-darmstadt.de> wrote:

>
>
> Dear Rolf,
>
> you mentioned below that the tcliqueMaxClique algorithm may terminate
> early. I have looked in the code and there are no limits (e.g., node
> limits etc.) that would imply that this may happen. What may happen is
> that the precision of the computations is not enough, so rounding errors
> might cause problems.
>
> Can you send me directly (off the list) an example where things go wrong
> and maybe a way to reproduce that pricing does not produce correct bounds?
>
> Best
>
> Marc
>
> On 07/07/2021 08.22, Rolf van der Hulst wrote:
> >
> >
> > ---------- Forwarded message ---------
> > From: *Rolf van der Hulst* <rolfvdhulst at gmail.com
> > <mailto:rolfvdhulst at gmail.com>>
> > Date: Wed, Jul 7, 2021 at 8:17 AM
> > Subject: Re: [SCIP] A specific question about the Graph Coloring
> Application
> > To: Yunzhuang Shen <s3640365 at student.rmit.edu.au
> > <mailto:s3640365 at student.rmit.edu.au>>
> >
> >
> > Dear Yunzhuang,
> >
> > For my thesis I am also working on Graph Coloring and used SCIP as my
> > starting point. I think I can help you a bit:
> > In the attachment is a pdf which explains the bound (see section 2.1).
> > What may be a source of confusion is that for graph coloring, the
> > pricing problem is typically negated to make it more readable. e.g.:
> > Minimal_reduced_cost = 1 - Maximum Weight Stable Set. This is, where the
> > (1- obj) part comes in.
> >
> > Note the bound given in SCIP is not in fact the strongest lower bound:
> > the bound
> > LP_obj / (1- c*)  = LP_obj / (maximum_stable_set_weight)
> >
> > is stronger and valid here (given that the pricing problem is solved to
> > optimality). This is also used in the paper 'An Exact approach for the
> > vertex coloring problem' by Malaguti, Monaci and Toth (equation 15) and
> > many more important papers in this area.
> >
> > However, in my applications, I've had to adjust the code around this
> > bound as well; the given SCIP coloring is not necessarily optimal as the
> > tcliqueMaxClique algorithm may terminate early. In this case, the bounds
> > above are not valid, as they rely on knowledge of the optimal/minimal
> > reduced cost. This is *not* currently implemented correctly in SCIP as
> > far as I know, and for some instances, you may get invalid lower bounds
> > which are too high as a result. I've encountered this for several
> > instances (particularly, very large ones).
> >
> > Note I'm working in SCIP 7.0.2: The above /may/ be fixed in 7.0.3 but I
> > haven't seen anything about it in the release notes.
> >
> > Feel free to ask any more questions if you have any.
> >
> > Best,
> >
> > Rolf
> >
> >
> > On Wed, Jul 7, 2021 at 6:05 AM Yunzhuang Shen
> > <s3640365 at student.rmit.edu.au <mailto:s3640365 at student.rmit.edu.au>>
> wrote:
> >
> >     Hi SCIP Team,
> >
> >     I am doing research about Branch-and-Price, using the code of the
> >     Graph Coloring Problem provided in the SCIP applications folder.
> >
> >     In `pricer_coloring.c', lines 717-725 are for updating the lower
> >     bound using the Lagrangian bound of the current LP to my
> understanding.
> >
> >     However, The equation for computing the Lagrangian bound seems to be
> >     incorrect. Specifically, why the primal bound is used to multiple by
> >     the reduced cost?
> >     SCIPgetLPObjval(scip) + ((1.0 - max_obj) * SCIPgetPrimalbound(scip))
> >
> >     However, the Lagrangian bound to the current RMP seems to be simply
> >     the optimal LP objective value of the current restricted master
> >     problem plus the optimum of the current pricing problem.
> >
> >     I would like to confirm this with you either this is a typo or I
> >     misunderstood something.
> >
> >     Regards,
> >     Yunzhuang
> >
> >     _______________________________________________
> >     Scip mailing list
> >     Scip at zib.de <mailto:Scip at zib.de>
> >     https://listserv.zib.de/mailman/listinfo/scip
> >     <https://listserv.zib.de/mailman/listinfo/scip>
> >
> >
> > _______________________________________________
> > Scip mailing list
> > Scip at zib.de
> > https://listserv.zib.de/mailman/listinfo/scip
> >
> _______________________________________________
> Scip mailing list
> Scip at zib.de
> https://listserv.zib.de/mailman/listinfo/scip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.zib.de/pipermail/scip/attachments/20210707/0a70c866/attachment.html>

More information about the Scip mailing list