[Osi] CPLEX Error 1217: No solution exists

[Matthew Saltzman]

On Mon, 2008-06-02 at 18:46 -0400, Laszlo Ladanyi wrote:
> On Mon, 2 Jun 2008, Matthew Saltzman wrote:
> 
> >
> > On Mon, 2008-06-02 at 18:00 -0400, Laszlo Ladanyi wrote:
> >> No bug.
> >>
> >> Pure and implemented means that if a derived class does not implement it then
> >> you get a compile time error. So it forces the user to think and implement
> >> something for the method. However, there is a default implementation, so the
> >> user can simply invoke the default implementation.
> >
> > OK But the "user" in this case is OsiCpx, right?
> 
> Yes.
> 
> > So what's the right
> > behavior for OsiCpx?  Implement a method that just invokes the
> > base-class method?
> >
> 
> If that's the right (and fastest/simplest :-) thing to do, then yes.
> 
> The default getObjValue() implementation actually recomputes the objective 
> value (multiplies the solution vector with the coeff vector and subtracts the 
> offset). If that's what OsiCpx wants to do, because, e.g., cplex can't 
> return the solution value because of problem change, but colsol is still 
> cached, then do it. On the other hand the maintainer of OsiCpx may decide to 
> do what cplex does and not return a sol value if things changed (which seems 
> to be the current behavior). That approach can be justified, too.
> 
> That's why I was saying that making the method pure virtual forces the 
> implemeter of the derived class to think a bit.

The behavior should probably be as consistent as possible across OsiXxx
classes.  So:

(1) Is the behavior in other SIs consistent?  If so, what is it?  (If
someone knows, it will save me some time that I don't really have right
now, as I'm teaching summer school.  TIA.)

(2) Does anyone in userland have an argument for how it oughta work,
different from the answer to (1)?

> 
> >>
> >> --Laci
> >>
> >> On Mon, 2 Jun 2008, Matthew Galati wrote:
> >>
> >>> Umm... ok, header has pure (=0) but src has it implemented. Bug.
> >>>
> >>>> It looks to me like base implementation is pure virtual
> >>>>     /// Get objective function value
> >>>>     virtual double getObjValue() const = 0;
> >>>>
> >>>>
> >>>>
> >>>>> CPLEX wipes out all solution information as soon as you make any
> >>>>> change to the problem whatsoever. I don't believe that the objective
> >>>>> value is one of the things cached in the base class. If you look at
> >>>>> the current implementation of getObjVal() in OsiCpx, it tries to get
> >>>>> the objective value using CPXgetobjval(). If Cplex reports
> >>>>> CPXERR_NO_SOLN, then the function returns 0.0 by default. In the base
> >>>>> class, the default implementation of the getObjVal() function computes
> >>>>> the objective value on the fly from cached data, which I guess would
> >>>>> fix the problem. Try just commenting out the getObjVal() function in
> >>>>> OsiCpx or else call the base class implementation from there and see
> >>>>> if that does what you need.  If that works, we should probably make
> >>>>> that change.
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> Ted
> >>>>>
> >>>>>
> >>>>>
> >>>>> Matthew Galati wrote:
> >>>>>
> >>>>>> This might be related to an old discussion...
> >>>>>>
> >>>>>> Using OsiCpx, I do
> >>>>>>   initialSolve()
> >>>>>>   getObjValue()
> >>>>>>   addCols()
> >>>>>>   getObjValue()  --> returns CPLEX Error  1217: No solution exists
> >>>>>>
> >>>>>> This is just an LP. Earlier issues with caching seem to have to do
> >>>>>> with switching from MIP to LP, etc.
> >>>>>>
> >>>>>> It looks like some attempt to keep cache was already made. Any ideas?
> >>>>>> If needed, I can create a driver program to show this issue.
> >>>>>>
> >>>>>> int err = CPXaddcols(env_,
> >>>>>> getLpPtr(OsiCpxSolverInterface::KEEPCACHED_ROW),
> >>>>>>                       numcols, nz, const_cast<double*>(obj),
> >>>>>>                       start, index, elem,
> >>>>>>                       const_cast<double*>(collb),
> >>>>>>                       const_cast<double*>(colub), NULL );
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Osi mailing list
> >>>>>> Osi at list.coin-or.org
> >>>>>> http://list.coin-or.org/mailman/listinfo/osi
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Osi mailing list
> >>>> Osi at list.coin-or.org
> >>>> http://list.coin-or.org/mailman/listinfo/osi
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Osi mailing list
> >>> Osi at list.coin-or.org
> >>> http://list.coin-or.org/mailman/listinfo/osi
> >>>
> >> _______________________________________________
> >> Osi mailing list
> >> Osi at list.coin-or.org
> >> http://list.coin-or.org/mailman/listinfo/osi
> > --
> >                Matthew Saltzman
> >
> > Clemson University Math Sciences
> > mjs AT clemson DOT edu
> > http://www.math.clemson.edu/~mjs
> >
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs