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.

SGI machines executing binaries compiled with -n32 or -64 (but not -o32)
do not do correct IEEE arithmetic: they flush underflows to zero rather
than underflowing gradually.  For many (non-benchmark) computations,
there are no underflows, so this detail does not matter, but it can
lead to different computational results when true IEEE arithmetic would
involve gradual underflow.

There are several ways to work around this bug.  The least attractive
is machine-dependent source code modification: in the source file for
main(), insert

	#include <sys/fpu.h>

and at the start of main(), insert

	union fpc_csr f;
	f.fc_word = get_fpc_csr();
	f.fc_struct.flush = 0;
	set_fpc_csr(f.fc_word);

A more portable approach, not requiring changes to source code or
makefiles, is to put a suitable "cc" shell script into a directory in
$PATH (ahead of the directory containing SGI's "cc") to cause binaries
to be linked as described in the following messages.  For example,
for -64 C compilation, I might have a "cc" in my bin consisting of

	#!/bin/sh
	exec /bin/cc -64 -L/usr/dmg/lib/64 -Wl,-init,__zap_fz_bit /usr/dmg/lib/64/zapfzbit.o "$@"

with zapfzbit.o compiled from

	/* Clear FPCSR_FLUSH_ZERO bit on SGI machines -- see mbox./98/bean */
	/* Load with cc -Wl,-init,__zap_fz_bit */

	#include <sys/fpu.h>
	#include <sys/syssgi.h>

	 void
	__zap_fz_bit(void)
	{
		union fpc_csr f;

		f.fc_word = get_fpc_csr();
		f.fc_struct.flush = 0;
		set_fpc_csr ( f.fc_word );
		}

For C++, something more complicated is required, as seen in the
following messages...

From bean@sgi.com Thu Oct 22 16:41:06 1998
From: bean anderson <bean@sgi.com>
To: dmg@bell-labs.com, cbm@research.bell-labs.com
Subject: FPCSR_FLUSH_ZERO

Hi David,

It was a pleasure talking with you today.  I've written
up what we talked about and I hope it will meet your needs.
Again, don't hesitate to call me directly if you have
any problems with it.

I've attached three files:

	ieee.c    -- The source code for setting processor state.
	bug.c     -- Simple test case.
	Makefile  -- Build and test

A discussion of how to use this mechanism and what the
performance costs might be are included in comments
in the file "ieee.c".  And, if it should be necessary,
the engineering bug report number is PV 628694.

-bean

[ Bean Anderson, bean@sgi.com, 650-933-4107 ]

begin 644 t.tar.gz
M'XL(`%&=+S8``^U72V_;1A!6TDO(2WK,<9(T@!Q(-&7+<I!'D4?E5$#<&+;[
M.`0@:&HH;4/N"KM+RW+JMG^@0']"D;;W'E*@Q]S:0POT7[3H(9?^@<Z2U(.*
M$Q\:I6C+#[:7WIW'-S,[RZ5>KBP<KNNNKZV!&1O-;'17FMF8`]Q6J[&ZWF@U
MU^FY07`KL+9X:I5*HK0OB4HW[IT@A_)EZWD<D_%?`KV\Z3_$D$6X.!^4CU:S
M^>+Z-]8:D_HWFNM4_Y6U9JL"[N(H3?$_K__%\Z!BV@&VK5%IZRKL)3W;<I;-
M8-.?;,81P!#1$;85!%`7\-9-J'\8U>J,,UWSO(WW[]WS.NUVV[NUW=E]=[.]
MV[E3T`-[ZO+-LU__TJR<KHC/*I53,U1.G7WRM)H*G/ZT2;_G)@JGCWXPX]GO
M/_@YDYRLC,<SN=QW^<0;J?SC/W0Z/OGUIW3\]O:7+TC#C[/_3.0?__ZTZ*=R
M)J=Z,_/WQ=."7NYOROM1QON;[3&OS_,1YOQ#IO_;>,OG\7SR53;_Y\V,U[-J
MD>>S/%^C<\?YGZX?G#M.WT";2CO!_/0KQ4G]WVPUY_O?72W[_[7@(N-!E'01
MKBO=9<+IOVW;79'L10@'<`,:6%]UW1J,S+,S>5UGT]=L._89K^X+UEVR']F0
M(]<_I/7QU"'I'T`=1M<F4P/)N`ZK%XR;2TYCI?>`CZ:/%VIP0&Z7IO(LA"K)
MWJ!)F/J:M[:32'I4>!X@$SY/MF:L'`%&"E]B(&59X'$XJV[;1_9_J__3`WJA
M!\`)_;_:6F_-]_^*ZY;]_SJP?!ELN%Q_E2![L-&YU[Z:O?N#!=BG'^MNXDN?
M:T0P%P_8P[Z_SX2$(=-]D*@&&&C0`KK(A8S]B!UB%W@2[Z%4CC&P`%Z6.0K!
M\Q1J+U3>'M.>%IX+U:6<M'4G0E\JV-@!6@3&(8R$KQGOP4#0`02!X%J*"&A7
MZD11'#VF-$IGK/_>_5U*+.SVF8)0R``5^'1NSED1`Y3TO^`*4BW=]RD7=,W+
MLT%*BIP/$A*5$+->7T,/N5'"5&$L)CB(1!LYRJ26_H"TS%,?X2%*CA$,^R@Q
M=X*TJK1,`N,:B"'&240FNQ/Z[Z1VC1'DBNTCQ4OOGB&+(L`#(LV0!P@^*-;C
M+&0!%3C5BX0B,B&02&BJ25)CF[,I'W@#B0$=_S,9WTZXR7.^4,>#``<IO]BX
MKFY?,>TJ>#1:<@`*:;8HS0B90-\D+!Y;GTOWQ&:VL:S;&/AT7AC")O,U,*56
MP(4F!:68>3N.\TE$9G=HJI^6CW<5$>I0`607I9$W)@N[>2P'0X28#K*L#(DD
MG;"0JRQ6$@59R`84LY&Q3__<YU2%-/0:Q4#DTQIUI1]3X($?12-0D1C2NWY(
MDK0T24FJ/M[,7:RE87],[&!N@ZBL50L1/1>^SAQ3;R,9`@Q#T]9F6Y(U"9N=
MK1T*1E`?*)'WM65>U#,[X[B/DU3.A$&=L"?(MAX*D+35&4>5[ZQ7?CBT/[JU
MN67.1:KJOJ!F#!.>M8J?:#%-+/4JA=2C7(/YO@+-8G1@LCDO`7V#62D>I''0
M]U@\,AHP,W?2UUDNEW^>S5C+3.5SN;$H6-"!N6R/+Z#6=352R^$@,5?0XB3]
MJAY+KZ:FI-9QYRO0_=-*N$EF.`B\0$D(Z?YIA4X8>$-J(;K2]=(C(EVLTITN
M6\NVHQ-&B>J3#%UJ+365@RI,+9#.49%"X;PA`AG3ZL[=CK?3WO4VMKRM[?:=
MSDZ[UB@H'UN1S,2\Y93I<Q%7,W-_O_[_]/VC1(D2)4J4*%&B1(D2)4J4*%&B
.1(D2B\-?J5T;9``H````
`
end

From dmg Thu Oct 22 17:38:16 1998
From: "David M. Gay" <dmg@research.bell-labs.com>
To: bean@sgi.com (bean anderson)
Subject: FPCSR_FLUSH_ZERO

Thanks for your helpful message.  That's a nice way get
initializations done.

If you could some little functions like __set_fs_bit_to_0 and
__set_fp_precise into, e.g., libc, then it would be easy to
add a set of flags to cc to specify various behaviors
independently.  But for now I'm glad to have a simple work-around
(a suitable "cc" script in PATH) that permits gradual underflow with
64-bit addressing.

-- dmg

From bean@sgi.com Thu Oct 22 18:03:03 1998
Sender: bean@sgi.com
From: bean anderson <bean@sgi.com>
To: "David M. Gay" <dmg@research.bell-labs.com>
Subject: FPCSR_FLUSH_ZERO

David,

I was just reminded that for released compilers, C++ already
uses the -init functionality for static initializers/constructors,
so these mechanisms may  interfere with each other.  [ This is
because the linker can handle at most one -init function. ]

As of 7.3, the linker will accept multiple -init entries
and it plays well with c++ static initializers.  [The 7.3
compiler release is in test right now and is scheduled for
release in March '99]

In the mean time, as long as you are not using static
constructors in C++, there should be no problem.

-bean

------------

p.s.  Here is an alternate way to deal with this if
	c++ static constructors become a problem.

Another way to deal with this is to recognize that the .init
section exists in each a.out and each DSO (dynamic library) so
as each executable file gets loaded by the dynamic loader,
it's associated .init section get's run.

In the worst case scenario, you could put the ieee.o
file into it's own dynamic library.  Here is an
example (assuming it is a -64 compile):

	% ld -64 -shared -o libieee.so -soname libieee.so \
		ieee.o -init __FULL_IEEE_ARITHMETIC

	%	CC -64 -o myprog ... -L. -lieee ...


There are two ways to "find" this library at run time.

	(1)  Copy it to one of the standard locations in
	     which the runtime loader (RLD) always looks
	     for requested dynamic libraries:

		% cp libieee.so /usr/lib64/internal
	     or
		% cp libieee.so /opt/lib64

		% myprog


	(2)  Set an environment variable to tell the runtime
	     loader (RLD) where else search:

		% setenv LD_LIBRARY_PATH my-library-directory
		% myprog

From dmg Fri Oct 23 23:31:58 1998
To: bean@sgi.com (bean anderson)
Subject: FPCSR_FLUSH_ZERO

Thanks for the second message you sent yesterday (about C++
and using dynamic libraries).  I had assumed that one could
have multiple -init functions and am glad to hear that will
eventually be possible.

-- dmg

The following changes (to solvers/makefile and solvers/*/makefile)
may permit use of the native Fortran 77 compiler on some systems.
On other systems, you may be able to discover suitable changes by
studying system documents (including man pages), and by using the nm
command to look at the names in relevant libraries.  Often the
compiler flags "-v -v" (two -v's) will cause the compiler to tell
you what libraries it references; if, say, /usr/lib/libF77.a is
among them, you could try thing like

	nm /usr/lib/libF77.a | grep -i arg

to get a hint at the system's variant (if any) of xargv.

If you make the changes shown below, also remove -lf2c from
solvers/*/makefile.  In other words, if you use the native Fortran
compiler, do not link against libf2c.a.


Sun SunOS:
	CFLAGS = -O -DKR_headers -DMAIN__=MAIN_ -Dxargv=_xargv


Sun Solaris:
	CFLAGS = -O -DMAIN__=main_ -Dxargv=__xargv
	For solvers defining MAIN__, add fmain.o built
	from fmain.f consisting of the two lines
		call main
		end


HP:
	CFLAGS = -Aa -O
	FFLAGS = +ppu
	For solvers defining MAIN__, add fmain.o built
	from fmain.c consisting of the following:

		char **xargv;
		extern void MAIN__(void);
		main(int argc, char **argv)
		{
			xargv = argv;
			MAIN__();
			return 0;
			}


IBM RS6000:
	CFLAGS = -O -Dxargv=p_xargv -DMAIN__=main_
	FFLAGS = -qextname
	For solvers defining MAIN__, add fmain.o built
	from fmain.f consisting of the two lines
		call main
		end


SGI IRIX:
	CFLAGS = -O -Dxargv=f77argv


DEC OSF1 (Unix for Alpha chip):
	CFLAGS = -O -Dxargv=for__a_argv

Linux (with g77):
	CFLAGS = -O -Dxargv=f__xargv

Linux (with gfortran):
	CFLAGS = -O
	For solvers defining MAIN__, supply fmain.o as for HP above.
	For solvers (e.g., snopt) that reference etime_(), append

		extern double xectim_();
		float etime_(float *tarray) { return (float) xectim_(); }

	to fmain.c (source for fmain.o; see HP above).

Unfortunately, we have not yet had time to update "Hooking Your Solver
to AMPL" to explain facilities we added a few years ago for exchanging
suffixes with AMPL.  Use of these facilities from a user's perspective
are described in chapter 14 of the second edition of the AMPL book,
with older descriptions appearing in

	http://www.ampl.com/NEW/statuses.html
and
	http://www.ampl.com/NEW/suffixes.html

If your solver deals with a basis, it would be good if your driver
could accept an incoming basis and return an optimal basis.  The
process is fairly straightforward.  You declare

	 static SufDecl
	suftab[] = {
		{ "sstatus", 0, ASL_Sufkind_var, 1 },
		{ "sstatus", 0, ASL_Sufkind_con, 1 }
		};

Before calling the .nl reader, you invoke

	suf_declare(suftab, sizeof(suftab)/sizeof(SufDecl));

to tell the reader to save the incoming .sstatus values.  If you were
interested in other incoming or outgoing suffix values, you would also
include lines for them in suftab.  See, for example,
/netlib/ampl/solvers/cplex/cplex.c or /netlib/ampl/solvers/osl/osl.c .

To access an incoming suffix array (after calling the .nl reader,
which reads them), say an array of priorities on variables, declare

	SufDesc *dp;

and invoke

	dp = suf_get("priority", ASL_Sufkind_var);

suf_get returns a pointer to a SufDesc (which is declared in asl.h);
the second argument indicates the kind of entity to which the suffix
pertains:  variable, constraints, objective, or problem.

If you wanted to see integer values for the suffix, then dp->u.i is
the array of suffix values; otherwise dp->u.r is the array of (real)
suffix values.

To return .sstatus values (i.e., a basis), you call suf_iput
twice, once for constraint.sstatus and once for variable.sstatus.
It's probably simplest to proceed as in /netlib/ampl/solvers/minos/m55.c:
having declared

	int *varstat;
	SufDesc *csd, *vsd;

and having computed NB = M + N, where M >= n_con and N >= n_var are the
numbers of constraints and variables (possibly adjusted, depending on the
needs of your solver -- for example, some solvers require adding an
extra variable and possibly an extra constraint to add a constant term
to the objective values that they report if they're asked to print
progress lines during their solution process), you allocate storage
for the .sstatus values by (something equivalent to)

	varstat = (int*)M1alloc(NB*sizeof(int));
	vsd = suf_iput("sstatus", ASL_Sufkind_var, varstat);
	csd = suf_iput("sstatus", ASL_Sufkind_con, varstat + N);

before invoking the .nl reader.  After calling the reader, deal
appropriately with the incoming .sstatus values, if present:

	if (vsd->kind & ASL_Sufkind_input)

then you have incoming variable.sstatus values in array varstat
(the third argument to suf_iput); similarly,

	if (csd->kind & ASL_Sufkind_input)

then you have incoming constraint.sstatus values (which, in the
above example, are in varstat+N, though you might wish to give
a separate name to this array).  The values are encoded as in
the first column of AMPL's default $sstatus_table:

	0	none	no status assigned
	1	bas	basic
	2	sup	superbasic
	3	low	nonbasic <= (normally =) lower bound
	4	upp	nonbasic >= (normally =) upper bound
	5	equ	nonbasic at equal lower and upper bounds
	6	btw	nonbasic between bounds

After solving the problem and before calling write_sol (which will
transmit the suffix arrays mentioned in previous suf_iput and, for
real, i.e., double, values, suf_rput calls), translate your basis
information to values in the outgoing status arrays that accord with
the above table.

For returning real (floating-point) suffix values, call suf_rput
rather than suf_iput.  Examples (for sensitivity information, i.e.,
suffixes .up, .current, and .down) appear in the cplex.c and osl.c
files mentioned above.

Another detail not yet documented in "Hooking Your Solver..." is that
you should assign a solve_result_num value to indicate success,
failure, iteration limit, etc. before calling write_sol.  This is
an integer value in one of the ranges indicated by AMPL's default
$solve_result_table:

	0	solved
	100	solved?
	200	infeasible
	300	unbounded
	400	limit
	500	failure

For successful solves, solve_result_num should thus be an integer
in [0,99].  If the problem might be solved, but tolerances may have
been too tight to satisfy all stopping tests, assign an integer in
[100,199], etc. -- any value >= 500 indicates failure (such as
insufficient memory).  Then AMPL's symbolic solve_result will be
assigned one of the values in the second column of the above table,
and scripts that need more detail can base tests on solve_result_num.

Many of the sample solver interfaces appearing in subdirectories
of netlib's ampl/solvers directory make use of suffixes and supply
solve_result_num.