[Scip] Problem with Conflict Analysis

[Alexander Schnell]

Hi Ambros,

thank you again for your answer. This is now clear for me.
Now I have the same problem with an upper bound.

The upper bound of a variable at the time of the bound change 
is 1. When I try to explain the bound change the upper bound
of the same variable is 0 (with SCIPvarGetUbAtIndex()).

But the global upper bound of this variable is 1 and not 0.
I also queried the value var->glbdom.lb and var->glbdom.ub
of the same variable.

Is it normal that var->glbdom.lb = 1 and var->glbdom.ub = 0?
Note that the domain of this variable is {0,1}.

Thanks,
Alex
   


On Thu, 2013-10-10 at 18:46 +0200, Ambros Gleixner wrote:
> Hi Alex,
> 
> this is a good remark.  The point is that it is a tighter *global* 
> bound.  Hence in your example,  if s has a lower bound of 5, the reasons 
> "s >= 3" and "s >= 5" are equivalent: an empty list of bound changes. 
> (I.e., t >= 6 should be globally valid.)
> 
> Thanks,
> 
> Ambros
> 
> 
> PS: Maybe you want to confirm for your safety that the tighter value 
> from SCIPvarGetLbAtIndex() is the same as SCIPvarGetLbGlobal().
> 
> 
> 
> Am 10.10.2013 18:31, schrieb Alexander Schnell:
> > Thank you for this information. This helped very much but
> > I have another remark.
> >
> > I agree on the part that the tighter bound may be used
> > as a reason for the propagation, but i think the old lower
> > bound would lead to a better explanation:
> >
> > assume that s >= 3 lead to the bound change of t >= 6
> > and the tighter global lower bound 5 is introduced for s.
> >
> > Then the old explanation s>= 3 -> t >= 6 is stronger than
> > s>= 5 -> t >= 6.
> >
> > Alex
> >
> >
> > On Thu, 2013-10-10 at 17:50 +0200, Ambros Gleixner wrote:
> >> That means you may use the tighter bound when computing a reason for the
> >> propagation.  This is preferable since it can give you a smaller reason
> >> than the bound that was known when the propagation was actually
> >> performed; smaller meaning a reason with less changes compared to the
> >> global bounds now.
> >>
> >> Hope that helps,
> >>
> >> ambros
> >>
> >>
> >>
> >> Am 10.10.2013 17:44, schrieb Alexander Schnell:
> >>> 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
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >
> >
> > _______________________________________________
> > Scip mailing list
> > Scip at zib.de
> > http://listserv.zib.de/mailman/listinfo/scip
> >
>