This directory contains source for a library of routines that help
solvers work with AMPL. In this README file, the library is called
amplsolver.a (the name it usually has on Unix systems), but on some
systems it may have another name, such as amplsolv.lib on Microsoft
systems. Services provided by amplsolver.a include reading AMPL's
generic output (.nl) files, and writing solution (.sol) files. On
netlib, subdirectories (e.g., cplex, examples, minos) contain
interface routines for particular solvers; you may wish to modify
these routines to make your own solver work with AMPL.
To make an executable version of a particular solver, you need
at least this directory and the solver's subdirectory. You need
to invoke "make" once in this directory to create amplsolver.a,
and then invoke "make" in each solver subdirectory of interest.
The exact form of the "make" command depends on the system you
are using. There is more discussion about "make" and makefiles
below.
Some installations have several kinds of computers, with various
hardware and operating systems, and with cross-mounted file systems
visible from the various computers. On such systems, the "configure"
script may be helpful. It arranges to compile amplsolver.a in
system-specific subdirectories with names that, unless otherwise
specified, begin with "sys." and by default are determined by the
Bourne-shell syntax
sys.`uname -m`.`uname -s`
Invoking
./configure
creates a sys.* directory for the current system and adds a
generic makefile, such that invoking "make" will give the
same result as
cd sys.`uname -m`.`uname -s`
make
(creating amplsolver.a in the system-specific subdirectory).
Alternatively, if you deal with only one kind of hardware and
Unix- or Linux-like operating system (including Cygwin or MinGW/MSYS
under MS Windows), you could invoke
./configurehere
to arrange for compiling amplsolver.a in this directory. Either
way (after "./configure" or "./configurehere") you invoke "make"
to compile amplsolver.a
Updates to the source for amplsolver.a appear first in
http://ampl.com/netlib/solvers
and the current source is generally available in the gzipped tar file
http://ampl.com/netlib/solvers.tgz
In the course of a week or so, updates should reach netlib servers,
such as http://www.netlib.org.
For more about AMPL itself, see the AMPL book (second edition):
"AMPL: A Modeling Language for Mathematical Programming"
by Robert M. Fourer, David M. Gay, and Brian W. Kernighan;
Duxbury Press / Brooks/Cole Publishing Company, 2002;
ISBN 0-534-38809-4
PDF files for individual chapters are freely available from the
AMPL web site; see http://ampl.com/resources/the-ampl-book/ .
For solvers written in Fortran 77, we assume the f2c calling
conventions. Source for f2c (Fortran-to-C converter) is
available from netlib.
See README.f77 for a summary of adjustments that permit use of the
native Fortran 77 compilers on some systems.
For machines with IBM mainframe arithmetic (i.e., the arithmetic
of the IBM 360 and 370 series and their successors and imitators,
such as Amdahl), use arith.ibm as arith.h and add rnd_prod.s to
the end of the "a =" assignment in the makefile. For other systems,
let the makefile compile and execute arithchk.c to create a
suitable arith.h. Do not copy arith.h from one kind of computer
to another.
See the comments in "makefile" about compiling on particular systems.
Various solver-specific subdirectories are available from netlib or
http://ampl.com/netlib, including the following. They provide sample
AMPL interfaces, but do not include source or objects for the solvers
themselves (which you must get from the relevant solver vendor, noted
in the README.1st file in each subdirectory).
Subdirectory Comments
bpmpd Research interior LP code by Cs. Meszaros.
cplex Uses CPLEX Corp.'s solver: linear (simplex and
interior algorithms), network, quadratic, and MIP
problems.
donlp2 General nonlinear optimizer by Peter Spellucci.
Uses an SQP algorithm and dense linear algebra.
examples Source for examples in "Hooking Your Solver to AMPL".
fsqp Based on CFSQP, a nonlinear solver by Craig Lawrence,
Jian L. Zhou, and Andre L. Tits.
funclink Examples and system-specific makefiles for making
shared libraries (.dll files) of imported (i.e.,
user-defined) functions.
gurobi Uses Gurobi Optimization's solver: linear (simplex
and interior algorithms), network, quadratic, and
MIP problems.
lancelot Based on LANCELOT (by A. R. Conn, Nick Gould, and
Ph. L. Toint): general nonlinear programming code
using sparse linear algebra.
loqo Interior code by Robert Vanderbei: for linear and
convex quadratic (or convex nonlinear) problems.
lpsolve Simplex and MIP solver based on lp_solve by
Michel Berkelaar (michel@es.ele.tue.nl).
minos Uses Murtagh & Saunders's code for nonlinear problems;
reduces to simplex on linear problems.
nlc Source for "nlc" program, which emits Fortran or C
for computing objectives, constraint bodies, and
their gradients.
npopt New version of npsol (see below), available from
Philip Gill to people who have npsol.
npsol Based on NPSOL (by Gill, Murray, Saunders, Wright),
a sequential quadratic programming code for solving
nonlinear programming problems.
path Based on the PATH solver of Prof. Michael C. Ferris
and his former students Steven P. Dirkse and Todd S.
Munson, for solving "square" nonlinear
complementarity problems.
snopt Sparse nonlinear solver by Philip Gill et al.,
available from him to people who have npsol.
xpress Based on XPRESS-MP, a solver for linear and
quadratic programming problems involving continuous
or integer variables by Fair Isaac Corporation.
For information about arranging to use other solvers with AMPL,
see "Hooking Your Solver to AMPL", Postscript for which is
http://ampl.com/REFS/hooking.ps.gz
and a corresponding html version is
http://ampl.com/REFS/HOOKING/
Updates to AMPL are reported in
http://ampl.com/dl/ampl.updates.html
This directory contains two makefile variants with names of the
form makefile.*; makefile.u is for Unix systems and makefile.vc is
for Microsoft systems. Comments in makefile.u describe adaptions
for particular Unix systems.
The makefile.vc variant creates "amplsolv.lib" and has comments about
linking solvers. This variant require you to make details.c by hand
(since deriving it automatically seems hard to do reliably). The
details.c file should reflect the compiler you are using. For
example, for Microsoft Visual C++ 6.0, having details.c consist of the
single line
char sysdetails_ASL[] = "MS VC++ 6.0";
would be appropriate. This string is used by some solvers as part of
the output produced for the "version" keyword and the -v command-line
option.
If you know that your math library never sets errno, adding -DNO_ERRNO
to the relevant CFLAGS assignment will save a little time and perhaps
avoid compiler complaints.
When linking nonlinear solvers on some systems, it's necessary to
add system-dependent keywords to the linking command, e.g., to make
dlopen() visible. Some of the makefiles for specific solvers have
comments about this, and on netlib, subdirectory funclink contains
sample makefiles that illustrate how to do things on for several'
popular systems.
In general, it is necessary once in this directory to give the
appropriate "make" invocation, such as
make
on Unix platforms,
nmake -f makefile.vc
under MS Windows, and then to give a suitable "make" invocation in
each solver subdirectory of interest. On non-Unix (non-Linux)
systems, in many of the solver subdirectories it may be necessary to
modify the Unix makefile into the form required by the system.
With Microsoft Studio 2017, due to a compiler bug you will need to
compile avltree.c without optimization. After the "nmake" invocation
aborts with an error message about an internal error in the compiler,
invoke
cl -c -MT avltree.c
and then again invoke
nmake -f makefile.vc
to continue building the solver-interface library.
A variant of the "solvers" directory is "solvers2", whose source is
in the gzipped tar file
http://ampl.com/netlib/solvers2.tgz
which is preferable for use with many nonlinear solvers, because its
nonlinear evaluations are often faster, and for large problems, its
internal representation of nonlinear expressions takes less space.
With suitable call variants involving a thread-specific workspace,
it also allows parallel nonlinear evaluations. For most nonlinear
solvers that just use one thread, "solvers2" is a drop-in replacement
for the "solvers" directory. Solvers that use multiple threads should
first call fg_read() or pfgh_read() and then invoke
EvalWorkspace *ew = ewalloc();
(or "ew = asl->p.Ewalloc(asl);") once per thread. Such solvers should
use the resulting thread-specific ew value in call variants whose
names end in "_ew" and whose first argument is ew, e.g.,
"objval(ew,np,x,ne)" rather than "objval(np,x,ne)". The "_ew"
variants are declared in solvers2/asl.h.
Some solvers, such as ilogcp for constraint programming, need to see
expression graphs. Such solvers must continue to use "solvers"
rather than "solvers2".
Solver source can check "#ifdef _ASL_EW_" to determine whether header
files come from "solvers2" (when the "ifdef" test is true) or
"solvers". This should only be relevant to solvers that use multiple
threads. When using the "solvers" directory (rather than "solvers2"),
for each new thread, such solvers must allocate a new ASL structure,
use it in a call on the desired .nl reader, and use the thread-specific
asl value when doing nonlinear evaluations.