help-glpk
[Top][All Lists]
Advanced

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

Re: [Help-glpk] MILP solutions using different solvers


From: Andrew Makhorin
Subject: Re: [Help-glpk] MILP solutions using different solvers
Date: Sat, 02 Mar 2013 19:04:46 +0400

On Sat, 2013-03-02 at 03:31 -0800, Sundaravalli Narayanaswami wrote:
> Thanks for the quick responses. Please find attached my mod and sol
> files for the first three instances. 
> 
> I am running the mod file on Gusec (with appropriate parameters
> setting) and translate the files to lp and mps formats. I solved lp
> files on CPLEX and mps on Gurobi. For the first three instances,
> objective values of the order of 70000 does not make sense at all for
> the problem I modeled. 
> The GLPK solutions that I included on spread sheet are correct values;
> but I am unable to understand why a mps or a lp file generates such
> large values as objectives. 


Now all is clear to me.

The objective function in your model has a constant term, so called
"shift". When the model is passed directly to the glpk mip solver, the
constant term is taken into account, however, it is not written to mps
file. Probably you missed the message displayed by glpsol like this:

lpx_read_model: row delay; constant term -107465 ignored

That is, when you pass mps to cplex or gurobi, they report correct
results, however, the objective value is reported *without* the shift.
For example, for Bi-data-set-1.mps both cplex and gurobi report the
optimum 72124, and the objective shift for that model is (-72115), so
the correct objective value is 72124 - 72115 = 9 that you just see in
the glpsol output.

You can determine the shift by writing the model in cplex lp format with
--wlp option, in which case you will see something like this at the top
of the file:

Minimize
delay: + actArr(7,1) + actArr(7,2) + actArr(7,3) + actArr(7,4)
+ actArr(7,5) + actArr(7,6) + actArr(7,7) + actArr(7,8) + actArr(7,9)
. . .
+ 7 actArr(6,10) + 7 actArr(6,11) + 7 actArr(6,12) + 7 actArr(6,13)
+ 7 actArr(6,14) + 7 actArr(6,15)
\* constant term = -72115 *\        <--- look here

To resolve the problem you may replace the objective statement in your
model

minimize delay: sum{i in 1..m, k in station} ( Weight[i] *
(actArr[i,k] ...

by the following two statements:

s.t. foo: delay = sum{i in 1..m, k in station} ( Weight[i] *
(actArr[i,k] ...

minimize obj: delay;

in which case the new objective will have a zero shift, and the problem
will disappear.

FYI: Your glpk version is very old. The most recent version is 4.48.



Andrew Makhorin

> 
> Thanks
> SV
> 
> --- On Sat, 3/2/13, Andrew Makhorin <address@hidden> wrote:
> 
> > From: Andrew Makhorin <address@hidden>
> > Subject: Re: MILP solutions using different solvers
> > To: "Sundaravalli Narayanaswami" <address@hidden>
> > Date: Saturday, March 2, 2013, 4:39 PM
> > On Fri, 2013-03-01 at 23:29 -0800,
> > Sundaravalli Narayanaswami wrote:
> > > Thanks Andrew. Please find attached all my instances in
> > mps format in
> > > a zipped file. Also I am sending the objective values
> > obtained using
> > > all the solvers in a spread sheet. 
> > 
> > Thanks.
> > 
> > > My hunch is that there is something wrong that I do
> > about output
> > > display formats in other solvers or the GLPK solver. 
> > > 
> > > Appreciate your help.
> > > 
> > > Regards,
> > > SV
> > > 
> > 
> > I run glpsol to solve your first three instances and found
> > nothing
> > wrong--all optimal objective values are the same as you
> > reported for
> > other solvers. Please see the attachment.
> > 
> > In which way did you solve the instances with glpk and how
> > obtain the
> > solution that happened to be wrong?
> > 
> > Best,
> > 
> > Andrew Makhorin
> >







reply via email to

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