[Couenne] SetCutoff()

[Pietro Belotti]

Francois,

> In Couenne/stable/0.3, the code for CouenneProblem::setCutoff(double 
> value) always sets the value to
>
> cutoff + SafeCutoff * (1. + fabs(cutoff))
>
> where SafeCutoff is 1e-4. While that might be safe, it might also be 
> disastrous for problems with many optimal solutions or many feasible 
> solutions within SafeCutoff * (1. + fabs(optimal_value)) of the optimal 
> value. While it might be a reasonable thing to do in some situations, it 
> seems that when the code claims to have found a feasible solution with 
> value v, the cutoff should be set to v, not slightly higher.

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.

Do you have specific examples? For example, if all those solutions have 
(just like the cutoff) a very large value such as 1e+6, the cutoff is set 
100 above where it should be. This can be avoided simply by adding an 
_absolute_ term instead, i.e., by setting the cutoff as

cutoff + min (1., SafeCutoff * (1. + fabs (cutoff)))

but if, again, apart from large solution values, there were very large or 
very small quantities in the problem, we may cut optima.

> I also noted that Couenne/stable/0.3 (downloaded today) does not 
> terminate on nvs19. On a Fedora 13 (linux 64 bits) install, I get:
>
> Cbc0015I Node 175 Obj -1103.72 Unsat 100 depth 88
> ## WEAK up-br: [9.00000000 ,(9.00000000)] -> 9.00000000
>
> and then the last line repeats with no end. This is using
>
> bb_log_level 3
> variable_selection osi-strong
>
> and all other defaults as in the provided couenne.opt file.

I committed a revision in Couenne/stable that should take care of that. 
Again, numerical issues: an integer variable whose value looks integer to 
Cbc (which, I believe, has an infeasibility of 1e-7 or above) but not 
Couenne, whose COUENNE_EPS, used in computing branching infeasibility, was 
set to 1e-8. I simply restored COUENNE_EPS=1e-7, as it was not long ago. 
nvs19 is now solved with the settings you provided (note: the very same 
problem is giving troubles to Couenne/trunk...).

Cheers,
Pietro