[SCIP] conflict analysis

[James Cussens]

Dear Marc,

Thanks that is helpful. I'll start by simply re-running the inference. Perhaps I can work out a way of using the inferinfo value to at least speed this up - perhaps in special cases.

James


James Cussens
Room MVB 3.26
School of Computer Science, University of Bristol
Phone: +44 (0)117 455 8723
https://jcussens.github.io/
________________________________
From: Scip <scip-bounces at zib.de> on behalf of Marc Pfetsch <pfetsch at mathematik.tu-darmstadt.de>
Sent: 01 August 2024 20:14
To: scip at zib.de <scip at zib.de>
Subject: Re: [SCIP] conflict analysis


Dear James,

yes, encoding the reason into just an int is quite limiting. In most
cases, this was enough in the past and this information has to be stored
for every bound change - so it is better to keep storage small.

Your consdata might have significantly changed between the time you
performed the propagation and the time the resolving happens, because
the latter is called at the time infeasibility occurs - possibly much
deeper in the tree than the propagation.

One solution that often helps is to just indicate the type of reduction
and then rerunning the reduction steps. You can access the bound changes
as they have been at the time of reduction - so it is "just" a question
of running time. Of course, if your reduction is slow, then this might
not be an option.

Hope this helps.

Best

Marc

On 01/08/2024 13:18, James Cussens wrote:
> Hi all,
>
> I am considering adding conflict analysis to a constraint handler
> (CONSRESPROP) for which I already have a propagator (CONSPROP). The
> constraint handler involves only n X n binary variables which represent
> the adjacency matrix for a directed graph. The "reason" for a
> propagation is that a set of binary variables are locally fixed to 1
> which means that another set of binary variables should all be fixed to 0.
>
> I'm predicting that encoding the "reason" - the relevant set of binary
> variables locally fixed to 1 as a single inferinfo int will be tricky,
> particularly for large values of n. That's a bit frustrating since it's
> easy enough to store this set in the consdata at propagation (CONSPROP)
> time. Is there any reason to think that this information will not still
> be in my consdata when CONSRESPROP is called?
>
> James
>
> James Cussens
> Room MVB 3.26
> School of Computer Science, University of Bristol
> Phone: +44 (0)117 455 8723
> https://jcussens.github.io/ <https://jcussens.github.io/>
>
> _______________________________________________
> 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/20240802/5649a6a9/attachment.html>