bug-glpk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-glpk] internal error: x <= ub; file glpios03.c, line 264


From: Andrew Makhorin
Subject: Re: [Bug-glpk] internal error: x <= ub; file glpios03.c, line 264
Date: Fri, 21 Dec 2007 21:36:35 +0300

> I may have found a bug causing an assertion failure in GLPK 4.24.
> I see the following message at the end of output; abort() is called.

>> Model has been successfully generated
>> glp_simplex: original LP has 493 rows, 383 columns, 1210 non-zeros
>> glp_simplex: presolved LP has 374 rows, 281 columns, 865 non-zeros
>> lpx_adv_basis: size of triangular part = 254
>>       0:   objval =   6.065620000e+05   infeas =   1.000000000e+00 (106)
>>       4:   objval =   7.346340000e+05   infeas =   0.000000000e+00 (118)
>> *     4:   objval =   7.346340000e+05   infeas =   0.000000000e+00 (118)
>> *    24:   objval =   1.835197111e+06   infeas =   4.547473509e-13 (117)
>> OPTIMAL SOLUTION FOUND
>> Integer optimization begins...
>> +    24: mip =     not found yet <=              +inf        (1; 0)
>> GLPK internal error: x <= ub; file glpios03.c, line 264

> This might be a problem with my model, which is complex and generated
> by another program. I noticed that the problem occurs with model "A.mod" 
> but not with model "B.mod", which seems to me to be more complex. Other
> models generated by the same program also work. I loaded the 
> models using commands like:

>     ./glpsol --math A.mod

> My version is compiled on i386 Debian from glpk-4.24.tar.gz, md5 
> 765dcecc20dc6b80362e65c755f41976. Please let me know if I can
> provide more information.

Thank you for the bug report.

The bug appears due to a lack in the mip solver routine which checks
integrality condition. I hope to improve that routine it by including
a more appropriate check in a next release of the package.

On the other hand, the bug is caused by a bad formulation of your
instance. Namely, in your instance there are many variables marked as
integer, whose values in the optimal solution are expected to be
very large (about 1e7). This leads to numerical difficulties, because
the underlying lp solver is not able to provide sufficient accuracy
for such integer variables.

Andrew Makhorin





reply via email to

[Prev in Thread] Current Thread [Next in Thread]