Matlab is a numerical computing environment from The MathWorks. Matlab is proprietary and cross-platform.


GLPKMEX

edit

GLPKMEX is a Matlab MEX interface to the GLPK library. GLPKMEX was originally developed by Nicolò Giorgetti with more recent input from Niels Klitgord. GLPKMEX is released under the GNU General Public License 2. Official support may be available at sourceforge.net/projects/glpkmex/support.

GPLKMEX binaries are available for Windows and MacOS X, and source code for Linux. Files can be downloaded at SourceForge. Be careful though — version 2.8 was only available precompiled for 32-bit (and not 64-bit) Windows systems — whilst noting that version 2.11 is now current.

More precompiled binaries and an updated version of glpkmex are available in a fork make by Benoît Legat.

For usage documentation see the comment header of file glpk.m.

Windows 7 (32-bit)

edit

Make sure all your components match your operating system:

  • 32-bit Matlab environment
  • 32-bit compiled mex interface
  • 32-bit GLPK library file (.lib)

Follow the instructions in file INSTALL.

The .lib file needed is the one created by Build_GLPK_with_VC10.bat. The .lib file from GLPK for Windows cannot be used.

Windows 7 (64-bit)

edit

Make sure all your components match your operating system:

  • 64-bit Matlab environment
  • 64-bit compiled mex interface
  • 64-bit GLPK library file (.lib)

Follow the instructions in file INSTALL.

The .lib file needed is the one created by Build_GLPK_with_VC10.bat. The .lib file from GLPK for Windows cannot be used.

Alternatives to Matlab

edit

There are close alternatives if you do not wish to use Matlab:

Use of PARFOR

edit

The PARFOR command is used to loop over a block of code that then executes in parallel on a cluster of workers. In 2011, Tim Kam used PARFOR in combination with GLPKMEX. He experienced memory leaks and determined that this combination was the cause. Tim writes "maybe the garbage collection using MATLAB's mxFree() for this particular MATLAB binding (see GLPKCC.cpp in GLPKMEX) does not seem to work when these functions are evaluated at the level of the parallel workers? So my not-so-elegant hack is to close and restart the parallel jobs each time I exit and re-enter the PARFOR loop instance (takes a couple seconds to send the close and restart signal to the parallel workers). That way I have roughly a constant demand on the memory by these parallel executions of large-ish GLPKMEX jobs."