matlab_and_gams:interfacing_optimization_and_visualization_software_via_the_gdxmrw_utilities

**This is an old revision of the document!**

**Note:** The gdxmrw utilities have been developed by Steven P. Dirkse (GAMS Development) and Michael C. Ferris (University of Wisconsin Madiscon

All the GAMS/Matlab utilities (rgdx, wgdx, and gams) previously documented and made available here are fully integrated into the GAMS distribution, so no separate downloads are necessary. We recommend that you use the supported version of these utilities integrated into and documented in the GAMS distributions available for download.

The previous versions, along with their documentation, can be found here, but be aware that these older versions are unsupported and differ in syntax and functionality from the supported versions.

We have collected some of the examples and tests for GDXMRW and made them available here. If you cannot run these *with the most recent GAMS distribution and its integrated GDXMRW utilities* please contact GAMS support.

gdxmrw is available for Windows 32-bit, Windows 64-bit, Linux 64-bit, and Mac OS X 64-bit. Both Linux 32-bit and Mac OS X 32-bit are currently (GAMS distribution 23.7) not supported. Since the MathWorks have announced plans to drop support for 32-bit Linux and Mac it is not likely we will be adding support for these platforms.

Please also note that a 32-bit version of Matlab requires a 32-bit version of GAMS, and the 64-bit version of Matlab will only work with the 64-bit version of GAMS.

A common question goes along the lines of *“How can I construct an interface between GAMS and Matlab?”* The answer to that depends on the situation, but one general guideline I offer is to break the process into smaller steps by using rgdx and wgdx to move the data around and only use the gams call to run the model, not to pass data to or from GAMS. This offers a number of advantages:

- Creating, debugging, and maintaining the interface will be easier if things are broken into smaller steps. For example, you can check that the data you export from Matlab to GDX was transferred correctly by using the utilities for viewing GDX data, such as the GAMS IDE. Once the input data is computed, you can run the GAMS model outside of Matlab, since the GDX files it reads are independent of Matlab and the model contains no Matlab-specific syntax.
- Data transfer is more flexible when using rgdx/wgdx than when using gams. Consider the case where the model needs to read sets at compile time but data at execution time. This will be difficult or impossible to do using gams, but simple to do using wgdx.
- Efficiency can be a consideration. If a sequence of similar runs needs to be executed with a large amount of common data but with some varying parameters, the common data can be written once before the sequence of runs starts, while a second GDX file can be used to transfer the run-specific data.
- If you need help, you'll get better help for an application that uses rgdx and wgdx to transfer data. Problems will be easier to reproduce and to locate, and the model will contain no Matlab-specific syntax.

An example application in two variations is available here. The .gms files contain comments as well as GAMS source. The .m files should be run from Matlab.

Under construction: updated debugging and support instructions

The installation and testing procedure is described in the GDXMRW documentation. If you are new to GAMS, you may find the amplified instructions below helpful when running the GAMS/Matlab utilities for the first time. We assume you are using the GAMS IDE, not the command line.

- Make sure you have the latest version of GAMS installed. Be sure to check if there are incremental updates available, since they may address issues that come up between releases.
- Create a scratch directory to run the tests in.
*Do not*run tests in the testlib_ml directory. I suggest you create directory C:\tmp. - Open the GAMS IDE.
- Create a project
*in this scratch directory.* - Extract the model gdxmrw05 from testlib. To do this from the IDE, you use the Model Libraries tab. Choose GAMS Test Library, type gdxmrw05 in the search box, and double-click the model to copy it, along with its support files, into the current project dir. To do this on the command line, open the command prompt from the GAMS IDE and run testlib gdxmrw05.
- Observe that the files have been copied to the scratch directory - gdxmrw05.gms plus some other files, including testinst.m.
- Close the GAMS IDE.
- Open Matlab,and cd to the scratch directory created above.
- Set the Matlab path as described in the documentation.
- Verify that the path is set correctly and that it points to the desired GDXMRW files. To do so, use the Matlab which command, e.g. which gams, which rgdx, etc. The output should indicate that the Mex-files to run are in the intended GAMS system directory.
- Run testinst from Matlab. This will send some log output to the screen and also create a file testinstlog.txt. The log output should give a clear indication of success or failure.
- If the test fails, send the output in the Matlab window (including the output from which) and the file testinstlog.txt to GAMS Support.

This problem and its solution are discussed in a recent Matlab help forum article. I have this problem on my Windows 7 desktop machine, and I could solve it by saving the pathdef.m file to the Matlab start directory C:\Users\sdirkse\Documents\MATLAB. There are a couple of problems with this fix though: it is specific to how Matlab is started (desktop shortcuts can specify different start directories) and it doesn't maintain a separate pathdef.m file for different Matlab versions. In spite of these problems, you should ensure that your Matlab system starts with the GAMS system directory in the Matlab Path. The GDXMRW utilities will not function if the GAMS system directory is not in the Matlab Path, and setting this manually at the start of each session is annoying and easy to forget.

I run Matlab on a machine where I have no root privileges so updating the system-wide `pathdef.m`

is not possible. However, Matlab checks the MATLABPATH environment variable on startup and prepends that to its search path, so setting this in your `.bashrc`

or similar startup file should have the desired affect. For example, I have something like this:

oxon$grep MAT .bashrc export MATLABPATH=/usr/local/gams/23.7.2:/home/steve/comp-pak/src/interfaces/Matlab oxon$echo $MATLABPATH /usr/local/gams/23.7.2:/home/steve/comp-pak/src/interfaces/Matlab

The full text of the error message is:

last error message: Undefined function or method 'gams' for input arguments of type 'char'. last error identifier: MATLAB:UndefinedFunction See testinst log file testinstlog.txt for details ??? Error using ==> testinst at 127 Error in testinst: terminating prematurely

and the file testinstlog.txt reads something like:

Date = 15-Jul-2011 Matlab version = 7.12.0.635 (R2011a) Error in testinst: terminating prematurely last error message: Undefined function or method 'gams' for input arguments of type 'char'. last error identifier: MATLAB:UndefinedFunction

The error message indicates that you did not set the path to GAMS in Matlab or that you run an old GAMS version which does not include gams.m and the mex library files.

The full text of the error message is:

last error message: Attempt to execute SCRIPT gams as a function: C:\Program Files (x86)\GAMS23.7\gams.m last error identifier: MATLAB:scriptNotAFunction See testinst log file testinstlog.txt for details ??? Error using ==> testinst at 127 Error in testinst: terminating prematurely

and the file testinstlog.txt reads something like:

Date = 15-Jul-2011 Matlab version = 7.12.0.635 (R2011a) Error in testinst: terminating prematurely last error message: Attempt to execute SCRIPT gams as a function: C:\Program Files (x86)\GAMS23.7\gams.m last error identifier: MATLAB:scriptNotAFunction

The problem here is that the version of GAMS and the version of Matlab are built for different architectures, so the wrapper-script `gams.m`

was not able to find a `gams`

Mex-file built for the same architecture as the running Matlab. Most likely you are trying to run a 32-bit version of GAMS with a 64-bit version of Matlab (or vice versa). Your GAMS license will work equally well with the 32-bit and 64-bit versions of GAMS so you should install a GAMS system built for the same platform/architecture as the Matlab system you have installed. To check the Matlab architecture, use Matlab's `computer`

function. The `mexext`

function gives a clue about what Mex-files need to be in the GAMS sysdir as well.

>> computer ans = PCWIN64 >> computer('arch') ans = win64 >> mexext mexw64

Some users have reported errors when calling gams() from within a Matlab loop. The symptoms vary - some users report incorrect values being returned to Matlab, while others report that gams.exe has crashed.

There are three workarounds or solutions to the problem.

**This problem has been fixed.**If you have a GAMS Distribution 23.9.3 (Sep 2012) or later it should have the updated mex-files. If you don't have a version as recent as this, the solution is to update your GAMS system to use distribution 23.9.3 or later. To check the version info of your mex-files:

>> wgdx('?') GDXMRW::wgdx : rev32781 2012-04-26 18:00:27Z sdirkse

This is the earliest revision with the fix. If you have a lower revision number than 32781 or a last-source-change date earlier than 26 April 2012, you should update to a newer GAMS distribution. Don't try to just slide some newer mex-files into an older GAMS distribution: components are designed and tested to work with the distribution they belong to.

- Another approach is to use rgdx() and wgdx() to transfer data between Matlab and GAMS and to use Matlab's system() call to execute the GAMS job. This solution has some other benefits as well, as described above. For example:

for i=1:365 wgdx(input,...); % sometimes the mex-function gams fails when run in a loop % gams(model); % but running gams in a subshell via the system() function is OK system (['gams model lo=2 --TRIP=', int2str(i)]); rgdx(results); end

- The most painful and least recommended approach, but one that allows you to keep using the gams() mex-function, is to copy the mex-function and use the copy in your Matlab code. When making the copy, do not copy or modify the gams.m script - this only contains documentation for the mex-function. The mex-function extension varies by platform - use the Matlab routine
`mexext`

to get the extension.

>> mexext mexw64 >> which gams C:\gams_64\23.7.2\gams.mexw64 >> cd \gams_64\23.7.2\ >> system ('copy gams.mexw64 rgams.mexw64') 1 file(s) copied. ans = 0 >> which rgams C:\gams_64\23.7.2\rgams.mexw64 >>

Once you have made the copy, you can use the new name as necessary to avoid problems with running gams() in a loop. If you are surprised that such a trivial change is enough to work around the problem, you are not alone.

There are two ways to do that. One way is to use the GAMS/Convert tool to write out the LP data in GDX form: The option file `convert.opt`

looks like

jacobian jac.gdx

and then you can use the GDXMRW utilities to read the GDX data in Matlab. This will be quite efficient for large data and you should get the data with full double precision.

Another option is to use the MPECDUMP solver and the `matlab`

option. This dumps the data to text files that can be written in Matlab, and also writes a .m file to do it for you. Try this by creating the option file `mpecdump.opt`

with

matlab xxx

and run

gamslib trnsport gams trnsport lp mpecdump optfile 1

and you'll get `xxx.m`

that reads lots of data into Matlab.

IMPRESSUM / LEGAL NOTICE
PRIVACY POLICY
matlab_and_gams/interfacing_optimization_and_visualization_software_via_the_gdxmrw_utilities.1367514200.txt.gz · Last modified: 2013/05/02 19:03 by support