AMPL is a computer language for describing production, distribution, blending, scheduling and many other kinds of problems known generally as large-scale optimization or mathematical programming.
AMPL’s familiar algebraic notation and interactive command environment are designed to help formulate models, communicate with a wide variety of solvers, and examine solutions.
AMPL’s flexibility and convenience make it ideal for rapid prototyping and development of models, while its speed and generality provide the resources required by repeated production runs.
The Excel spreadsheet package comes with solvers for linear, nonlinear, and integer programming; it accepts enhanced add-in solvers as well. Their principal advantage lies in allowing all aspects of optimization — including formulation, solution, and analysis of results — to be performed within the spreadsheet environment. In particular, variables and constraints can be defined directly in terms of ranges of spreadsheet cells.
AMPL incorporates a far richer language than spreadsheet optimizers for describing optimization problems. As a result, AMPL is much more natural and reliable for developing and maintaining complex models. The difference is particularly pronounced when many model components have more than two dimensions (or more than two subscripts or indices, in AMPL terms).
By avoiding much of the spreadsheet overhead, AMPL also generates model instances faster than spreadsheet optimizers. AMPL’s speed advantage is significant for a few thousand model components, and becomes relatively greater as problem size increases.
AMPL’s interface design encourages developers to hook additional solvers to AMPL. Thus AMPL is available with a greater variety of solvers than spreadsheet optimizers.
AMPL models can read and write spreadsheet data that is structured in the form of relational tables, through use of the
read table and
write table commands.
AMPL is one of several optimization modeling systems that are designed around specialized algebraic modeling languages. These languages employ adaptations of familiar mathematical notation to describe optimization problems as
the minimization or maximization of algebraic expressions in numerical decision variables,
subject to constraints expressed as equalities or inequalities between algebraic expressions in the decision variables.
Advanced interpreters and interfaces for these languages provide support for simplifying and analyzing models. Some also provide language extensions for describing algorithmic schemes that attack difficult problems by alternately solving interrelated subproblems.
Some of the other commercially distributed algebraic modeling languages are:
AIMMS, providing a graphical application development environment and a GAMS compatibility mode supplementing its own language.
GAMS, one of the first such languages, now widely used in a number of industries.
LINGO, a more powerful sibling of the LINDO language widely used in elementary instruction.
MPL, notable for its associated graphical interface and database links.
AMPL is designed to combine and extend the expressive abilities of these languages, while remaining easy to use for elementary applications. AMPL is particularly notable for the naturalness of its syntax and for the generality of its set and indexing expressions.
AMPL provides strong support for validation, verification and reporting of optimal solutions, through numerous alternatives for presenting data and results. AMPL’s extensive preprocessing routines can automatically carry out transformations that serve to reduce problem size, convert piecewise-linearities to linear terms, and substitute out selected variables.
AMPL is further distinguished by its continuing development to serve users’ needs. Recent additions include looping and testing constructs for writing executable scripts in the AMPL command language, and facilities for defining and working with several interrelated subproblems. Numerous commands have also been added for producing diagnostic reports and custom-formatted tables.
There are also many optimization modeling systems based on representations other than algebraic modeling languages. Popular alternative forms include:
block-schematic diagrams, which depict a linear constraint matrix as a collection of structured submatrices (or blocks).
activity specifications, which describe a model in terms of activities (variables) and their effects (constraints) on inputs and outputs.
netforms, which use graph or network diagrams to depict models involving flows and allocations.
Each of these has special advantages for certain classes of problems. In contrast, an algebraic modeling language such as AMPL is more general. It is the most natural form for many classes of problems, and is one of the most natural forms for an even broader variety of problem classes.
The AMPL book is the most comprehensive source of information on AMPL. It is written in the form of a textbook with an appendix for reference, in contrast to the more common format of a reference manual with some tutorial material at the front. Virtually all language features are illustrated by continuing, meaningful examples, and additional exercises are provided. Chapters can be freely downloaded, and hardbound printed copies can be purchased.
For working through the examples and exercises in the book, a free size-limited student edition of AMPL may be downloaded. Courses using AMPL can get time-limited but size-unlimited versions of AMPL and solvers through the AMPL for Courses program.
The free “student” version of AMPL is limited to 300 variables (500 for linear problems) and a total of 300 objectives and constraints. However all other AMPL versions have no intrinsic limit on problem size; they are limited only by the resources available to the computer that is running AMPL.
In practice, memory is most often the limiting resource. The amount of memory used by AMPL necessarily depends on the numbers of variables and constraints, and on the number and complexity of the terms in the constraints — or in the case of linear programs, on the number of nonzero coefficients in the constraints. Memory use also depends on the size and complexity of the model’s sets and parameters. AMPL’s presolve phase may require additional memory to execute (though it may accomplish problem reductions that allow savings of memory later).
AMPL’s memory use for a linear program can be estimated crudely as 1000000 + 260 (m + n) + 50 nz bytes, where m is the number of constraints, n the number of variables, and nz the number of nonzeroes. A computer having 4GB or more of memory and running a 64-bit operating system can thus typically accommodate over a million variables and/or constraints. Memory required for a solver may have to be added, however, if the solver is to be run while AMPL remains active. See also our advice elsewhere in this FAQ for further comments on what to do (including running the solver separately) if you suspect a problem with insufficient memory.
Especially difficult problems may cause your solver to encounter its own resource limitations. Solvers that accept binary and integer variables, in particular, can consume impractical amounts of time and disk space as well as memory, even for problems of apparently modest size. Nonlinear problems can also be very time-consuming compared to linear programs in the same numbers of variables and constraints.
As a practical matter, there is no substitute for experimentation to determine the resource requirements of your particular problem. The best approach is usually to try out your model on progressively larger collections of data, so that you can record the trend in resource requirements as problem size increases.
Currently AMPL is not configured as a subroutine library whose individual pieces can be called as needed from a user’s program. A “batch” session of AMPL can be executed from a program in any popular programming language, however. This feature can be used as a high-level “call” to AMPL that is sufficient for some applications.
In a C program, you would execute AMPL by use of the system procedure, as in these examples:
system("ampl <cut.run"); system("ampl <cut.run >cut.out");
The argument to
system can be anything one would type on a command line. Most commonly, an input file (
cut.run above) contains a series of AMPL commands that read model and data input, invoke solvers, and write results to files. This arrangement does not provide for results to be passed back directly to your program; following the call to
system, your program must get the results by reading a file that AMPL has written. Other languages (such as C++, C#, Java, Python) have their own calling conventions, but the principles are the same.