[ojAlgo-user] Problematic small MIP model

[Anders J. <and...@gm...>]

Hello,

I would like to report a small MIP-model that OjAlgo had trouble solving
correctly that I found.

The model is over 16 integer variables x0..x15 with domain [0..414]. There
are four constraints as follows:

117 <=  30 30 30 30  0  4  0  0  0  4  0  0  0  4  0  0  <=  14868
 36 <=   0  4  0  0 40 40 40 40  0  0  4  0  0  0  4  0  <= 170569
341 <=   0  0  8  0  0  0  8  0 68 68 68 68  0  0  0  5  <= 140833
413 <=   0  0  0  8  0  0  0  9  0  0  0  6 59 59 59 59  <=  48321

The weights for the variables are
[2691.5357279536333,2600.760150603986,2605.8958795795374,2606.7208332501104,2715.0757845953835,2602.194912040238,2606.0069468717575,2609.0385816244316,2750.0520522057927,2602.048261785581,2600.507229973181,2602.046307869504,2721.343937605796,2601.7367414553805,2600.595318433882,2599.405979211142]
and the solution mode is to minimize the value.

Sometimes, but not always, OjAlgo will report a solution as both feasible
and optimal, even though some of the constraints are actually violated. The
invalid solution produced is
    x =  1  2  0  0  0  0  0  1  0  4  0  0  2  3  0  2

Here is a printout of the model when that happens:
############################################
0 <= x0: 1.000000 (2691.535728) <= 414.000000
0 <= x1: 2.000000 (2600.760151) <= 414.000000
0 <= x2: 0 (2605.895880) <= 414.000000
0 <= x3: 0 (2606.720833) <= 414.000000
0 <= x4: 0 (2715.075785) <= 414.000000
0 <= x5: 0 (2602.194912) <= 414.000000
0 <= x6: 0 (2606.006947) <= 414.000000
0 <= x7: 1.000000 (2609.038582) <= 414.000000
0 <= x8: 0 (2750.052052) <= 414.000000
0 <= x9: 4.000000 (2602.048262) <= 414.000000
0 <= x10: 0 (2600.507230) <= 414.000000
0 <= x11: 0 (2602.046308) <= 414.000000
0 <= x12: 2.000000 (2721.343938) <= 414.000000
0 <= x13: 3.000000 (2601.736741) <= 414.000000
0 <= x14: 0 (2600.595318) <= 414.000000
0 <= x15: 2.000000 (2599.405979) <= 414.000000
36.000000 <= constraint 1: 48.0 <= 14868.000000
413.000000 <= constraint 3: 422.0 <= 170569.000000
341.000000 <= constraint 2: 282.0 <= 140833.000000
117.000000 <= constraint 0: 118.0 <= 48321.000000
############################################


As can be seen, constraint 2 is clearly violated by this solution.

This was just found during some testing using some generated models, but I
thought that you might be interested.

Kind regards,
Anders