[Bonmin] Assertion in OsiSimpleInteger::createBranch()

[Stefan Vigerske]

Hi,

ok, I added that cast to size_t in Ipopt/trunk.

Stefan

On 06/21/2017 12:04 AM, David Wilkinson wrote:
> Hi Stefan:
> 
> In Bonmin 1.8.6, when I activate ma57 solver, I also see a Visual C++ 
> warning (signed/unsigned mismatch) from the code
> 
> if( wd_lfact_ > std::numeric_limits<size_t>::max() / sizeof(double) ) {
> 
> at Ipopt\src\Algorithm\LinearSolvers\IpMa57TSolverInterface.cpp line 657
> 
> This signed/unsigned mismatch warning always makes me very nervous 
> (especially in 64-bit builds). Personally I would do something like
> 
> assert(wd_lfact_ >= 0);
> if ( (size_t)wd_lfact_ > std::numeric_limits<size_t>::max() / 
> sizeof(double) ) {
> // ...
> }
> 
> Or better, re-write the code so that a cast (implicit or explicit) is 
> not necessary.
> 
> Thanks,
> 
> David Wilkinson
> 
> =========================
> 
> 
> On 20.06.2017 12:17, Stefan Vigerske wrote:
>> 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