Re: [ojAlgo-user] Problematic small MIP model

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

Unfortunately I don't have executable code that isolates this issue, it was
built as a part of a larger system and is not easily extracted.

As said, the issue and the model was just something that I managed to
observe sometimes, and tried to dump sufficiently to make it reproducible.
It is not something I will be actively using (the problems are way to hard
for MIP, even Gurobi had troubles with small instances), so it is not an
issue for me.

Kind regards,
Anders



On Tue, Aug 19, 2014 at 10:19 PM, Anders Peterson <an...@op...>
wrote:

> Thanks for reporting the problem. Can you send me executable code that
> (sometimes) reproduce the problem - something that I can easily turn into a
> junit test.
>
> I believe this is a concurrency related problem with the integer solver.
>
> /Anders
>
>
> On 19 aug 2014, at 13:48, Anders Johansson <and...@gm...>
> wrote:
>
> > 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
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > ojAlgo-user mailing list
> > ojA...@li...
> > https://lists.sourceforge.net/lists/listinfo/ojalgo-user
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> ojAlgo-user mailing list
> ojA...@li...
> https://lists.sourceforge.net/lists/listinfo/ojalgo-user
>