Having difficulty with LPSolve and GLPK solvers

[Nazmul Islam]

Hello,

I am trying to solve a mixed integer linear programming problem. At first, I tried to use LPSolve solver since 'bnb' was coming out to be very slow. Unfortunately, LPsolve is providing a feasible output for 'tight' constraints but infeasible output for 'relaxed' constraints. Besides, it is also showing comments like: "bfp_factorize: Resolving 1 singularity at refact 16" and "Lost feasibility 10 times", etc. I don't know if and where I made mistake. I have attached the corresponding file with the email. The .mat files need to be in the same folder before .m file is run.

Thereafter, I tried GLPK solver. At first, I installed GLPKMex. I saw that GLPKtest1 and test2 are working. Also, YALMIPtest found GLPK-Mex as the linear programming solver. However, when I run the above .m file with GLPK solver, all variables take zero value. This is completely wrong ! I wonder if the strange results of GLPK are due to installation issues (I know that I installed LPSolved correctly, though).

Any feedback on my errors will be highly appreciated.

Thanks,

Nazmul

[Johan Löfberg]

First, if you are in academia, take the opportunity and install gurobi, cplex, mosek or xpress. They all have free academic licenses, and perform much better in general

However, since you currently use lpsolve and glpk

1. lpsolve

I don't have lpsolve instyalled, so I cannot try it. My guess is that it simply isn't robust enough for this model (which involves very large numbers, and has optimal solutions which are very large. You should  perhaps try to rescale the model, i.e., work with MHz instead of Hz, kilometers instead of mm etc)

2. glpk

There is a left-over oddness in my interface to glpk. glpk requires explicit variable bounds which cannot be left empty. This means YALMIP has to add these before calling. In the code, they are currently bounded to 1e6, which clashes with the optimal solution of your model. If you really want to use glpk, edit callglpkcc and replace 1e6 with a large number of your choice. Note that a too large n umber, such as realmax, will cause numerical instabilities. With 1e12, the problem is trivially solved in no time (but it warns about some numerical issues)

3. bnb

Of course, bnb should never be used on MILPS, as there are many alternatives. However, I don't see any performance issues here actually. The MILP is trivially easy to solve also with bnb