[Couenne] Infeasibility on batchdes instance

[Stefan Vigerske]

Hi,

from my experience, if the solution is found by the LP relaxation, then
is almost always a little bit infeasible. This is just because the LP is
always an outer approximation, thus its solution is always outside of
the actual feasible region, except if you are so lucky to find a point
where the boundaries of the LP and the NLP feasible set intersect.
The tighteness of the outer-approximation is usually controlled by some
parameter, which should not be smaller than the feasibility tolerance of
the LP solver. Thus, within these tolerances, 6000.000057 is equivalent
to 6000.

If the solution is found by the NLP heuristic in Couenne, then my naive
intuition is, that since Ipopt is an interior point solution, the point
that is found is also inside this region, so one may not observe this
behaviour for running NLPs so much.

For some other MINLP solvers, also an NLP solver is run once again after
the B&B, for the MINLP with integer variables fixed and using the
B&B-solution as starting point, so one can make this point "more feasible".

Stefan

Giacomo Nannicini schrieb:
> Hi,
> on some instances of MINLPLib, it seems to me that Couenne returns
> slightly infeasible solutions. One example is batchdes; I am attaching
> the AMPL mod file. But there are other examples as well. In my tests,
> the problem happens with different versions of Couenne and on
> different machines.
> I checked those solutions through AMPL, by comparing _con[i].lb,
> _con[i].ub, and _con[i].body, that is, lower/upper bounds of the
> constraints and their body, after solving the instance. And there are
> cases where some constraints are not satisfied (in particular,
> constraints involving exp functions).
> In the file that I am attaching, constraint e13 is reported to have a
> body with value 6000.000057, whereas the upper bound is 6000.000000. I
> had a very similar problem with Ipopt some time ago, and I solved it
> by setting the option bound_relax_factor 0. In fact, on the very same
> instance, if I just run Ipopt, it returns a solution that is
> infeasible (the same constraint evaluates to 6000.000263, when checked
> through AMPL), but when I set bound_relax_factor 0, it returns a
> feasible point.
> However, if I set the same option in couenne.opt, the problem is still
> there. Note that the objective function value coincides with the one
> reported by other solvers, so I believe that the solution is "almost"
> correct.
> 
> Does someone have some insight on how to get rid of that "almost"?
> 
> Giacomo
> 
> P.S: I am using default tolerances
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Couenne mailing list
> Couenne at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/couenne


-- 
Stefan Vigerske
Humboldt University Berlin, Numerical Mathematics
http://www.math.hu-berlin.de/~stefan