bug-glpk
[Top][All Lists]
Advanced

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

Re: [Bug-glpk] GMPL performs correct translation to MPS, but does not so


From: Andrew Makhorin
Subject: Re: [Bug-glpk] GMPL performs correct translation to MPS, but does not solve correctly directly.
Date: Thu, 10 Sep 2015 13:42:11 +0300

> Thank you for the help. I am not so concerned about solving my
> optimization problem; I know that the problem can be badly scaled and
> that this can be solved by removing constraint coefficients that are
> too low compared to the rest. I was just very puzzled by the behavior
> of not being able to solve correctly from GMPL, but solving from an
> MPS file generated from the GMPL file does work.

Most probably the solver you used removes tiny coeffs (treating them 
as exact zeros) while glpsol never does that to keep the user data
untouched.

Nevertheless, if you look at glpsol output produced by "-o OUTFILE", you
may note that the solution found is correct *within a tolerance* :

Problem:    CBM_LP
Rows:       43
Columns:    81
Non-zeros:  2663
Status:     OPTIMAL
Objective:  Costrate = 66.14773806 (MINimum)

[...]

Karush-Kuhn-Tucker optimality conditions:

KKT.PE: max.abs.err = 1.46e-15 on row 1
        max.rel.err = 1.09e-17 on row 1
        High quality

KKT.PB: max.abs.err = 2.40e-16 on row 43
        max.rel.err = 2.40e-16 on row 43
        High quality

KKT.DE: max.abs.err = 9.47e-13 on column 74
        max.rel.err = 1.24e-16 on column 74
        High quality

KKT.DB: max.abs.err = 0.00e+00 on row 0
        max.rel.err = 0.00e+00 on row 0
        High quality

> 
> I have just studied the output files generated by solving both the MPS
> and the MOD file with glpsol using '--wlp OUTFILE_***'. It appears
> that the problem generated from the MPS file has already removed (i.e.
> set to 0) constraint coefficients that are smaller than 10^{-11} and
> this is why this solves fine. 

No. This is because no such coefficients were generated. The MathProg
translator never removes non-zero coefficients.

> The MPS file itself however does contain all the constraint
> coefficients that are smaller than 10^{-11}. It appears that in
> parsing a model from MPS, there is some preprocessing step that does
> this automatically. When building a model from a MOD file where
> constraint coefficients are actually computed, this does not happen.
> For your convenience, I have attached the output files and MPS file.
> Now that I have some understanding of what is happening, I am not sure
> I would qualify this as a bug. It is at least unexpected behaviour
> though. At the same time, most users will not use GMPL to compute most
> constraint coefficients, but will read their constraint coefficients
> from a file. They are therefore unlikely to encounter this behaviour.

I think it is quite easy to modify the MathProg model to get red of
generating tiny coeffs.





reply via email to

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