[Cbc] CBC rejecting its own solution as MIP start

[Rudi Araújo]

John,

 

Regarding the other thread (assertion failure), your fix seems to work,
thanks.

 

I have unearthed this week-old thread because we came across a different
situation where CBC reports infeasibility, even though the problem is indeed
feasible. See files here:

 

https://drive.google.com/open?id=0B-5kPpSmX5imVllVaUdxVWY3TGc

 

Breaking it down:

 

*         cbc -import test.lp -mipstart ms.before.txt

Reports infeasibility.

 

*         cbc -import test.lp -mipstart ms.txt

Solves problem to optimality, but rejects MIP start.

 

The files ms.txt and ms.before.txt have exactly the same solution.

 

We traced the issue to this constraint:

 

__one = 1

 

If we remove it, the .before MIP start is accepted and the model is solved
to optimality.

 

In this particular case, we can do without the __one var, but in the general
case we add it because it is sometimes convenient for us to pass a constant
term in the objective function.

 

Can you take a look at it?

 

Thanks,

Rúdi Araújo.

 

From: John Forrest [mailto:john.forrest at fastercoin.com] 
Sent: quinta-feira, 5 de janeiro de 2017 15:29
To: Rudi Araújo <rudi.araujo at siscog.pt>
Cc: 'Tiago Maduro Dias' <tiago at siscog.pt>; 'Luís Borges de Oliveira'
<lbo at siscog.pt>
Subject: Re: CBC rejecting its own solution as MIP start

 

Rudi,

On 04/01/17 17:39, Rudi Araújo wrote:
> 

> John,

> 

> 

> 

> Thank you the fast reply.

> 

> 

> 

> The .before hint did the trick for the LP I sent you. However, we

> came across a different situation where the mipstart is accepted but

> CBC reports infeasibility and exits without finding an integer

> solution, even though it exists:

> 

>
That was more interesting - a bug which was unlikely to occur in normal use,
but could.  As the code had a cutoff value, it added that as a constraint in
preprocessing and there was a bug there.


 

> By the way, what is the reason for building the initial solution only

> after pre-processing by default? Would it make sense to do it the

> other way around - by default before, with an option to do it only

> after?

> 

> 

I did not write that bit of code and don't really want to do too much to it.
Some information which could get used in heuristics can not easily be passed
across when creating solution before - so on the whole it is more efficient
to try and do work on preprocessed problem.
> 

> One last thing: trunk appears to be broken. We tried compiling it and

> tripped over this error:

> 

>
My error (you picked it up before I was told off this morning after standard
Coin builds were done).  I am doing some development in trunk and thought I
might as well commit some extra changes instead of taking them out
temporarily.  However I forgot that I would also need to commit changes from
CoinUtils.


John Forrest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/cbc/attachments/20170112/f61df4cb/attachment.html>