[Coin-symphony] tracking cuts

[Ted Ralphs]

Michael Hennebry wrote:

> 'Tain't tolerance.
> I have 0-1 variables and all-integer constraint data.
> user_is_feasible can be broadminded about what constitutes an integer.
> It can calculate a bound on how close to integer the variables have
> to be to ensure that rounding to exact integers will preserve
> constraint satisfaction.
> If they're not close enough, the solution is declared infeasible.
> If they are close enough, the rounded solution might be a new improved
> solution (IP_HEUR_FEASIBLE) or not (IP_INFEASIBLE).
> In either case, user_is_feasible can find a cut that will remove
> the rounded and fractional solutions from further consideration.

What do you mean by "removing the rounded solution from further 
consideration"? The rounded solution is feasible, right? How can it be 
cut off? If you are somehow cutting off the rounded solution and not the 
fractional solution, this could cause problems. All cuts must violate 
the current fractional solution or they will be discarded.

> One problem turned out to be that user_is_feasible was finding a cut
> and user_find_cuts wasn't always adding them.
> Fixing that cured the repetitive solution problem,
> though the previous behaviour still seems mysterious.
> 
> Cuts are still being rediscovered though.
> I think that they are in different nodes.
> There are output lines like:
> Cuts in the local pool: 22

It's certainly possible to rediscover cuts in a different node. In fact, 
the purpose of the cut pool is to enable this to happen. Am I 
understanding you correctly?

> I want is to set parameters so that a
> rediscovered cut is proof of an error somewhere.

I'm not sure I see why it would be if it is in a different node, unless 
it is a descendant.

> I've been calling cg_add_explicit_cut with send_to_cp=true.
> 
> parameters:
> time_limit 2400
> touches_until_deletion 100000000
> verbosity 11
> ineffective_constraints 0
> 
> 
>>I would suggest turning up the verbosity to 11 so that all status
>>information is printed out every iteration and looking at exactly what
>>is happening. You should be able to see what cuts are being marked
>>ineffective and what cuts are being deleted, whether the lower bound is
>>monotone, whether it is going into an infinite loop, etc. If you post
>>the output for an example node where this happens, I should be able to
>>help spot the problem. Also, please post exactly what parameters you are
>>using. It is possible that changes in the parameters from defaults are
>>contributing to the problem.
>>
>>Another option is to change the criteria by which constraints are
>>determined to be ineffective, i.e., deletable.
>>
>>
>>>Is there a way I can tell Symphony
>>>to not delete any cuts ever?
>>
>>Yes, there are two options. If you want to turn off deletion of cuts
>>universally, then set the parameter "ineffective_constraints" to
>>NO_CONSTRAINT_IS_INEFFECTIVE (0). By default, it is set to
>>BASIC_SLACKS_ARE_INEFFECTIVE. See
>>
>>http://www.branchandcut.org/SYMPHONY/man/node257.html
>>
>>You can also disallow deletion of any particular cut. In the cut_data
>>data structure, there is a field "deletable." If this is set to FALSE
>>when the cut is passed to SYMPHONY, then the cut will never be deleted.
>>In fact, if you calloc the cut_data structure, then by default, the cut
>>will never be deleted. See
> 
> 
> Is there a way to do that with cg_add_explicit_cut?

Not currently, but I could add this if it's useful.

Cheers,

Ted
-- 
Dr. Ted Ralphs
Assistant Professor
Industrial and Systems Engineering
Lehigh University
(610)758-4784
tkralphs at lehigh.edu
www.lehigh.edu/~tkr2