[Couenne] SetCutoff()

[Pietro Belotti]

Francois,

>> I agree. I did that precisely for safety reasons, as bound reduction 
>> procedures were cutting out optimal solutions because of tight cutoffs. 
>> This shouldn't happen, but this is mostly a problem that shows up when 
>> the model contains very small or very large constants, or both. 1e-4 
>> seems a reasonable tradeoff between not eliminating feasible solutions 
>> and avoiding suboptimal regions.
>
> On some problem (ex1233, for example), it happens that the value of the 
> LP relaxation becomes larger than the value of the best known solution 
> for a large number of nodes. The nodes are not pruned, as the cutoff is 
> set to roughly 155026 while the best known solution has value 155011. 
> This does not look like much, but the lower bound inches up very slowly 
> and going from 155011 to 155026 is quite some work.

I have modified (in trunk and stable/0.3) the code so that the realcutoff 
is set at

cutoff + min (SafeDelta, SafeCutoff * (1 + abs (cutoff)))

where SafeCutoff is the same parameter as before and SafeDelta is, for 
now, set to 0.1. In my opinion, setting SafeDelta to a larger value would 
perpetuate the problem you point out, while a very small value might give 
the same numerical issues we are trying to avoid. We can make both user 
parameters, if necessary. I expect SafeDelta to be more sensible when the 
objective function value is larger in absolute value.

> I see problems finding a solution reasonably close to the optimal one 
> only sometimes on csched1. That problem has bad numerics and I don't 
> think that worrying about it makes much sense. Whatever the safety 
> settings you put in, one can find a badly formulated problem for which 
> the solution will not be found.

OK, though for usability I'd prefer to be robust enough to be able to 
solve the average-case problem (which sometimes has bad numerics).

> That might fix it for nvs19, but I also observed that the code enters an 
> infinite loop when the following happens: An integer variable x_i has 
> bounds [a, a] (i.e. it is fixed) but has value a - 1e-7 in the solution 
> of the LP relaxation. The Cbc object for x_i says that it has an 
> infeasibility of 0.

The cleanest way would be for Cbc to take care of this, but if the 
official policy of Cbc is to ignore small out-of-bound values, it should 
be done by Couenne as well.

> I could fix it by not adding the integer violation in the couenne object 
> if the bounds of x_i are identical. That fixes it. (Maybe a better 
> solution is not to add the integer violation in the couenne object if 
> the value of x_i is slightly out of bounds.)

The latter would also take care of the case in which lower and upper 
bounds are different and x_i is either lb - 1e-7 or ub + 1e-7, which 
should also be a case in which branching is not necessary. I have 
implemented and committed this version, but can't test it as I don't know 
what instance gave that behaviour. Please let me know if it still happens.

Pietro