[Scip] Problem with Conflict Analysis

Alexander Schnell alexander.schnell at univie.ac.at
Thu Oct 10 17:44:30 CEST 2013


Hi Ambros,

yes, the lower bound is tighter. 

Alex



On Thu, 2013-10-10 at 17:20 +0200, Ambros Gleixner wrote:
> Hi Alexander,
> 
> is the value of the variable responsible for the lower bound change 
> tighter than the value that was stored in inferinfo?
> 
> I think this could be correct, if global bound changes have occured in 
> the meantime.  Can somebody confirm this?
> 
> Ambros
> 
> 
> 
> 
> Am 10.10.2013 17:15, schrieb Alexander Schnell:
> > Dear Marc,
> >
> > my problem is not about the variable
> > for which the lower bound change is applied (infervar) but about the
> > variable responsible for the lower bound change
> > (i.e. the lower bound of this variable).
> >
> > For this variable SCIPvarGetLbAtIndex(...,...,TRUE) and
> > SCIPvarGetLbAtIndex(...,...,FALSE) are the same values.
> >
> > I integrate the lower bound of this variable as an integer inferinfo
> > in the function SCIPinferVarLbCons(). Moreover, if I query
> > the lower bound of this variable in the CONS_RESPROP function
> > by SCIPvarGetLbAtIndex(), this does not correspond to the
> > inferinfo value.
> >
> > Note, that I can be sure that the value returned
> > from SCIPvarGetLbAtIndex() is integer (I tested it by
> > SCIPisFeasIntegral()).
> >
> > Best regards,
> > Alexander
> >
> >
> >
> >
> >
> >
> > On Thu, 2013-10-10 at 16:09 +0200, Marc Pfetsch wrote:
> >>
> >> Dear Alexander,
> >>
> >> the function SCIPvarGetLbAtIndex() contains a parameter in which you can
> >> specify whether the bound change in questions has already been applied.
> >> To which value have you set this value? In principle, you should be able
> >> to reconstruct the bound change at that time (using infervar and the
> >> above function).
> >>
> >> Please also check whether the bound change via SCIPinferVarLbCons()
> >> actually changed the bound (check return values infeasible and tightened).
> >>
> >> You can look at other examples of conflict resolution, e.g.,
> >> cons_linearordering.c in examples/LOP. Please note that implementing
> >> conflict resolution always is a tricky thing.
> >>
> >> If this does not explain the problem, we would need more details from
> >> you in order to be able to reconstruct the problem. Possibly off this
> >> list ...
> >>
> >> Best
> >>
> >> Marc
> >>
> >>
> >> On 10.10.2013 15:32, Alexander Schnell wrote:
> >>> Dear SCIP team,
> >>>
> >>> I implemented a Constraint Handler for a special
> >>> project scheduling problem.
> >>>
> >>> In the CONS_RESPROP function, I try to explain the bound
> >>> changes processed through the propagation algorithm implemented in
> >>> the CONS_PROP function.
> >>>
> >>> In the function for the explanation generation, I observed a problem
> >>> with the function SCIPvarGetLbAtIndex(...):
> >>>
> >>> In the propagation algorithm, the lower bound is propagated with
> >>> the function SCIPinferVarLbCons(). I integrate the integer lower bound
> >>> of the variable responsible for the processed bound change as an
> >>> inferinfo in this function.
> >>>
> >>> In the CONS_RESPROP function, I compare the latter value with the actual
> >>> lower bound of the responsible variable given by
> >>> SCIPvarGetLbAtIndex(...) at the given bound change index.
> >>>
> >>> My problem is that these values are not the same, which should not be
> >>> the case in my understanding.
> >>>
> >>> Thank you in advance for your help.
> >>>
> >>> Best regards,
> >>> Alexander Schnell
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Scip mailing list
> >>> Scip at zib.de
> >>> http://listserv.zib.de/mailman/listinfo/scip
> >>>
> >> _______________________________________________
> >> Scip mailing list
> >> Scip at zib.de
> >> http://listserv.zib.de/mailman/listinfo/scip
> >
> >
> >
> > _______________________________________________
> > Scip mailing list
> > Scip at zib.de
> > http://listserv.zib.de/mailman/listinfo/scip
> >
> 





More information about the Scip mailing list