General Algebraic Modeling System
From Wikipedia, the free encyclopedia
The General Algebraic Modeling System (GAMS) is a high-level modeling system for mathematical programming and optimization. GAMS is designed for modeling linear, nonlinear and mixed integer optimization problems. The system is tailored for complex, large scale modeling applications, and allows the user to build large maintainable models that can be adapted to new situations. GAMS is available for use on various computer platforms and models are portable from one platform to another. The system contains an integrated development environment (IDE) and a group of integrated solvers (for more information see here). GAMS was the first algebraic modeling language (AML) and is formally similar to commonly used programming languages. Models are described in concise algebraic statements which are easy for both humans and machines to read.
Contents |
[edit] History
Initial Research and Development of GAMS was funded by the International Bank for Reconstruction and Development, usually referred to as The World Bank, through the Bank’s Research Committee (RPO 671-58, RPO 673-06) and carried out at the Development Research Center in Washington DC. Since 1987, R&D has been funded by GAMS Development Corporation.
The system was developed in close cooperation of mathematical economists who are an important group of GAMS users. The synergy between economics, computer science and operations research was the most important success factor in the development of the system. Mathematical programming and economics theory are closely intertwined. The Nobel Prize in Economics awarded to Leonid Kantorovich and Tjalling Koopmans in 1975 for their “contribution to the theory of optimal allocation of resources” was really a prize in mathematical programming. Other Nobel laureates like Kenneth Arrow in 1972, Wassily Leontief in 1973, and Harry Markowitz in 1990 are well known names in math programming. Another early example of this synergy is the use of LP in refining operations, which was started by Alan Manne, an economist, with his book on Scheduling of Petroleum Refinery Operations in 1956.
The origins of linear programming algorithms stem from George Dantzig’s early work in the 1940s and 1950s. Computing technology and algorithmic theory had developed at a rapid pace. Thirty years later, it was possible to solve problems of practical size and complexity that allowed the user to test the economic theory on real life problems. The research agenda at the World Bank in the 1970s and 1980s created the perfect environment to bring different disciplines together to apply mathematical programming to research and operational questions in Economic Development.
The focus and technical constraints of the development of modeling systems have changed in the last 30 years. The dominant constraints in the first phase were the computational limits of algorithms. Problem representation had to abide by algorithmic convenience, centralized expert groups managed large, expensive and long lasting projects and end users were effectively left out. The second phase has the model in focus. This volume is about languages and systems supporting this stage. Applications are limited by modeling skill, project groups are much smaller and decentralized, the computational cost are low and the users are involved in the design of the application. Applications are designed to be independent of computing platforms and frequently operate in a client-server environment. The third phase has the application as its focus and the optimization model is just one of many analytic tools that help making better decisions. User interfaces are build with off-the shelf components and frequently change to adjust to evolving environments and new computing technologies.
[edit] Time Line
- 1975 GAMS idea presented at the ISMP Budapest
- 1978 Phase I: GAMS supports linear programming. Supported platforms: Mainframes and Unix Workstations
- 1979 Phase II: GAMS supports nonlinear programming.
- 1987 GAMS becomes a commercial product
- 1988 First PC System (16 bit)
- 1988 Alex Meeraus, the initiator of GAMS and founder of GAMS Development Corporation, awarded INFORMS Computing Society Prize
- 1990 32 bit Dos Extender
- 1990 GAMS moves to Georgetown, Washington, D.C.
- 1991 Mixed Integer Non-Linear Programs capability (DICOPT)
- 1994 GAMS supports mixed complementarity problems
- 1995 MPSGE language added for CGE modeling
- 1996 European branch opened in Germany
- 1998 32 Bit native Windows
- 1998 Stochastic programming capability (OSL/SE, DECIS)
- 1999 Introduction of the GAMS Integrated development environment (IDE)
- 2000 GAMS World initiative started
- 2001 GAMS Data Exchange (GDX) introduced
- 2002 GAMS listed in OR/MS 50th Anniversary list of milestones
- 2003 Conic programming added
- 2003 Global optimization in GAMS
- 2004 Quality insurance initiative started
- 2004 Support for Quadratic Constrained programs
- 2005 Support for 64 bit PC Operating systems
- 2006 GAMS supports parallel grid computing
[edit] Background
The driving force behind the development of GAMS has been the users of mathematical programming who believed in optimization as a powerful and elegant framework for solving real life problems in the sciences and engineering. At the same time, these users were frustrated with the high cost, skill requirements, and overall low reliability of applying optimization tools. Most of the system's initiatives and support for new development arose in response to problems in the fields of economics, finance, and chemical engineering. These disciplines find it natural to view and understand the world and its behavior as a mathematical program.
GAMS’s impetus for development arose out of the frustrating experiences of a large economic modeling group at the World Bank. In hindsight, one may call it a historical accident that in the 1970s mathematical economists and statisticians were assembled to address problems of development. They used the best techniques available at the time to solve multi sectoral economy-wide models and large simulation and optimization models in agriculture, steel, fertilizer, power, water use, and other sectors. Although the group produced impressive research, initial successes were difficult to reproduce outside their well functioning research environment. The existing techniques to construct, manipulate, and solve such models required several manual, time-consuming, and error-prone translations into the different, problem-specific representations required by each solution method. During seminar presentations, modelers had to defend the existing versions of their models, sometimes quite irrationally, because the time and money needed to make proposed changes were prohibitive. Their models just could not be moved to other environments, because special programming knowledge was needed, and data formats and solution methods were not portable.
The idea of an algebraic approach to represent, manipulate, and solve large scale mathematical models fused old and new paradigms into a consistent and computationally tractable system. Using matrix generators for linear programs revealed the importance of naming rows and columns in a consistent manner. The connection to the emerging relational data model became evident. Experience using traditional programming languages to manage those name spaces naturally lead one to think in terms of sets and tuples, and this led to the relational data model.
Combining multidimensional algebraic notation with the relational data model was the obvious answer. Compiler writing techniques were by now widespread, and languages like GAMS could be implemented relatively quickly. However, translating this rigorous mathematical representation into the algorithm specific format required the computation of partial derivatives on very large systems. In the 1970s, TRW developed a system called PROSE that took the ideas of chemical engineers to compute point derivatives that were exact derivatives at a given point, and to embed them in a consistent, Fortran-style calculus modeling language. The resulting system allowed the user to use automatically generated exact first and second order derivatives. This was a pioneering system and an important demonstration of a concept. However, PROSE had a number of shortcomings: it could not handle large systems, problem representation was tied to an array-type data structure that required address calculations, and the system did not provide access to state-of-the art solution methods. From linear programming, GAMS learned that exploitation of sparsity was the key to solve large problems. Thus, the final piece of the puzzle was the use of sparse data structures.
[edit] A Sample Model
A transportation problem from George Dantzig is used to provide a sample GAMS model. This model is part of the model library which contains many more complete GAMS models. This problem finds a least cost shipping schedule that meets requirements at markets and supplies at factories.
Dantzig, G B, Chapter 3.3. In Linear Programming and Extensions. Princeton University Press, Princeton, New Jersey, 1963.
This formulation is described in detail here or in:
Rosenthal, R E, Chapter 2: A GAMS Tutorial. In GAMS: GAMS: A User's Guide. The Scientific Press, Redwood City, California, 1988.
Sets i canning plants / seattle, san-diego / j markets / new-york, chicago, topeka / ;
Parameters
a(i) capacity of plant i in cases / seattle 350 san-diego 600 /
b(j) demand at market j in cases / new-york 325 chicago 300 topeka 275 / ;
Table d(i,j) distance in thousands of miles new-york chicago topeka seattle 2.5 1.7 1.8 san-diego 2.5 1.8 1.4 ;
Scalar f freight in dollars per case per thousand miles /90/ ;
Parameter c(i,j) transport cost in thousands of dollars per case ;
c(i,j) = f * d(i,j) / 1000 ;
Variables
x(i,j) shipment quantities in cases z total transportation costs in thousands of dollars ;
Positive Variable x ;
Equations
cost define objective function supply(i) observe supply limit at plant i demand(j) satisfy demand at market j ;
cost .. z =e= sum((i,j), c(i,j)*x(i,j)) ;
supply(i) .. sum(j, x(i,j)) =l= a(i) ;
demand(j) .. sum(i, x(i,j)) =g= b(j) ;
Model transport /all/ ;
Solve transport using lp minimizing z ;
Display x.l, x.m ;