[Couenne] Infeasibility on batchdes instance

[Giacomo Nannicini]

Hi Pietro,
I tried that option already, but it does not seem to work in this
case. I do not know why the solutions are slightly infeasible (more
than the tolerances), but maybe what Stefan says (running Ipopt after
fixing the integer variables to "polish" a solution) would be the way
to go.

Giacomo

On Tue, Dec 14, 2010 at 1:00 AM, Pietro Belotti <pbelott at clemson.edu> wrote:
> 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
>>
>