[Bonmin] Assertion in OsiSimpleInteger::createBranch()

[Stefan Vigerske]

Hi,

On 06/20/2017 05:36 PM, David Wilkinson wrote:
> Hi Stefan:
> 
> I will certainly upgrade to Bonmin 1.8.6, as I see it has all the 
> changes regarding FORTRAN_INTEGER_TYPE and NO_CATCH_ALL that you and I 
> have been discussing. Thanks for that! But are there other changes 
> relative to Bonmin 1,8.4?

Bonmin 1.8.4 is based on a Cbc that is similar old as the Bonmin 1.8.4 
release. Bonmin 1.8.5/1.8.6 uses a current Cbc release, which should 
have less bugs.

> What do you mean by "fixed integer variable"? Do you mean one where the 
> user has set the upper and lower bounds to be the same? That I certainly 
> have not done.

It's more likely that Bonmin fixed some variable during branching.
It's not wrong that variables get fixed (locally) during B&B, or that 
one has fixed variables in the problem, but attempting to branch on 
fixed variables is wrong.

> Until recently we were using (the very ancient) Bonmin 1.3.2, and 
> interestingly this problem did not arise there.

Yes, that were the times when Pierre, the Bonmin developer, was still 
active :).

Stefan

> 
> David Wilkinson
> 
> ============================
> 
> On 20.06.2017 09:29, Stefan Vigerske wrote:
>> Hi,
>>
>> it sounds as if Bonmin tries to branch on a fixed integer variable.
>> You might want to trace who created this OsiBranchingInformation and
>> why this has happened.
>>
>> Also consider upgrading to Bonmin 1.8.5 or 1.8.6 first. Bonmin 1.8.4
>> is 21 months old.
>>
>> Stefan
>>
>> On 06/20/2017 03:16 PM, David Wilkinson wrote:
>>> This is a Bonmin question, but I haven't seen any activity in the 
>>> Bonmin group for a while, so I am sending to the Ipopt group also.
>>>
>>> I am using Bonmin 1.8.4 with "B-BB" algorithm to solve a problem with 
>>> two integer variables, both with lower bound 0 and upper bound 3, 
>>> with an initial guess of (1,1). I am seeing an assertion error in 
>>> OsiSimpleInteger::createBranch() around line 626 of 
>>> OsiBranchingObject.cpp. The purpose of the assertion is to check that 
>>> the upper bound for the variable under consideration is greater than 
>>> the lower bound. When I hit the assertion, the value of columnNumber_ 
>>> is 0, and both info->lower_[0] and info->upper_[0] are 0.0, so the 
>>> assertion is correctly triggered.
>>>
>>> Since assertions are not supposed to happen, I initially suspected 
>>> user (me) error in setting up the problem, but I do not think so, 
>>> because our driver program repeatedly requests optimizations of a 
>>> similar type (with different objective and constraint functions, but 
>>> the same bounds), and several such optimizations have been done 
>>> correctly before this one. It may be that these optimizations do not 
>>> fully satisfy the Bonmin convexity requirements, but surely this 
>>> should not cause an assertion in the code? Our program will tolerate 
>>> cases where Bonmin fails and emits an exception, and indeed if I 
>>> throw an exception in OsiSimpleInteger::createBranch() instead of the 
>>> assertion, our program continues with other successful Bonmin 
>>> optimizations.
>>>
>>> Any ideas?
>>>
>>> Thanks,
>>>
>>> David Wilkinson
>>> _______________________________________________
>>> Bonmin mailing list
>>> Bonmin at list.coin-or.org
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__list.coin-2Dor.org_mailman_listinfo_bonmin&d=DwICAg&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=BRcuJnQr5NAzU29t80hk2rsLc4vrlRySBDabuq0O1ZI&m=fSexfIOcTv9KTMRQVZe65MHJusguSwsHMzfmO1Q4DoE&s=vOOwrD4g3FsVpmxBP1Zdx0SWV-pW18OHMbJUxShxkVg&e= 
>>>
> 


-- 
http://www.gams.com/~stefan