[Couenne] Infeasibility on batchdes instance

[Pietro Belotti]

Giacomo,

Couenne uses a parameter, feas_tolerance, to check feasibility of the 
solutions. I believe its default value is 1e-5; try setting it to a very 
small value (1e-15, for instance) in the couenne.opt file.

Pietro

--
Pietro Belotti
Dept. of Mathematical Sciences
Clemson University
email: pbelott at clemson.edu
phone: 864-656-6765
web:   myweb.clemson.edu/~pbelott

On Thu, 9 Dec 2010, Stefan Vigerske wrote:

> 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
>
> _______________________________________________
> Couenne mailing list
> Couenne at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/couenne
>