Downloading and Unpacking

Files for download have names of the form program.platform.YYYYMMDD.tgz (for gzipped tar files) or program.platform.YYYYMMDD.zip where YYYYMMDD is the date of the most recently updated contained file, such as 20100917 for 17 September 2010.

Documentation appears in *.doc.* files. You can view *.pdf files with Acrobat Reader (or another PDF viewer). Text files in *.doc.*.tgz (viewable with a text editor) generally have names of the form README*. Corresponding files in *.doc.*.zip files have ".txt" appended to their names and have line endings in the style of MS-Windows (i.e., carriage-return, linefeed pairs rather than just linefeeds).

On Unix-like systems (including Linux, MacOSX, Solaris, Ubuntu, BSD, and on MS Windows systems with the Cygwin or MinGW shell), you can extract the contents of a gzipped tar file, say foo.tgz, by invoking 
 
    gzip -dc foo.tgz | tar xf - 
 
or can see its contents by invoking 
 
    gzip -dc foo.tgz | tar tv - 
 
With some versions of tar, you can alternatively invoke "tar -zxf foo.tgz" or "tar -ztvf foo.tgz".

Where to put things?

Where should you put executable programs, such as "ampl" and solvers? It is most convenient to add them to a directory (folder) on the usual search $PATH of your system, so you can invoke them by their names, rather than by full paths to them. $PATH specifies a sequence of directories in which the system should look to find programs. By invoking 
 
    echo $PATH 
 
or, in an AMPL session, by issuing the command 
 
    option PATH; 
 
you can see the current $PATH. On Unix-like systems, directory names in $PATH are separated by colons, whereas they are separated by semicolons on MS Windows systems. On recent version of MS Windows, the spelling is "Path" rather than "PATH", i.e., you in an AMPL session, you would invoke 
 
    option Path; 
 
Alternatively, in a Command Prompt window under MS Windows, simply type 
 
    path 
 
to see your current $Path. Some people include a personal "bin" in their $PATH, and this can be a good place to put "ampl" (if you are to be the only user); on some systems, a personal "bin" is automatically created for new accounts, but if you want one, it is easy to add it yourself. On Unix-like systems, the initial $PATH setting is generally specified in a file in your $HOME with a name that starts with ".", such as ".bashrc" or ".profile". On MS Windows systems, the details of adjusting $Path depend on the particular version of MS Windows. For example, with Windows 7, on the Start menu, click "Control Panel", "User Accounts and Family Safety", "User Accounts", "Manage Accounts", "Go to the main User Accounts page", and "Change my environment variables". Then select "Path" and click "Edit". Under Windows XP, click "Control Panel" on the Start menu, then "System", "Advanced", and "Environment Variables"; select "Path" in the "System variables" window and click "Edit". I usually have C:\bin as my personal "bin", created by invoking 
 
    mkdir c:\bin 
 
in a Command Prompt window.

32- versus 64-bit Binaries

For really large computations, you have no choice but to use 64-bit binaries. For smaller (albeit possibly rather large) problems, you may have a choice of using 32- or 64-bit versions of AMPL and solvers. A 32- or 64-bit version of AMPL can work with a 32- or 64-bit solver (unless both are sharing an imported function library, in which case both must be of the same sort, or you must arrange for both 32- and 64-bit versions of the shared library to be available in a way that the right program will find the right library). A 32-bit binary will use less memory and thus should make better use of cache. A 64-bit binary may have more instructions available (depending on the platform), and thus might either run faster or slower than a 32-bit binary, provided cache is not (too serious an) issue. In short, you mileage may vary, and you may need to experiment to see whether 32- or 64-bit binaries are better for particular applications. If you wish to have both 32- and 64-bit versions of AMPL and solvers available, you might want to append "32" or "64" to some of the names so you can readily control which you use.

Generally speaking, 64-bit systems can run 32-bit binaries if the standard 32-bit system libraries are installed. The 32-bit system libraries are not installed by default on some versions of Linux (though one can add them). So far, the 32-bit support libraries are installed by default on MacOSX and MS Windows systems, so for these systems we only provide 32-bit versions of some programs, such as the fingerprint program and floating-license manager.

Invoking AMPL

If you invoke AMPL without any arguments, by typing 
 
    ampl 
 
it will simply read the standard input (so you can type at it). But you can also specify file names on the command line, in which case it will read the files. A file named "-" (a single dash) is taken to be the standard input, so if you invoke, say, 
 
    ampl foo.mod foo.dat foo.run - 
 
then AMPL will read files foo.mod, foo.dat, and foo.run before reading the standard input. Suffixes on file names have no special meaning to AMPL, so if foo.dat is a data section (as the name suggests), it is convenient to have "data;" (without the quotes) appear at the beginning of the file. AMPL also recognizes various command-line options. For a summary, invoke 
 
    ampl -? 
 
or 
 
    ampl "-?" 
 
Whether quotes around -? are needed depends on the shell you are using.
Scrolling Windows

The ampl.mswin*.*.zip files include both our "standard" table handler, ampltabl.dll, and a scrolling-window program, sw.exe, that provides scrolling windows usable with any MS Windows console binary, such as ampl.exe. You can cut and paste text within these scrolling windows and (via the clipboard) copy text from the window to a text editor and vice versa. It's not necessary to use "sw" windows, but you may find them helpful. The readme file tells more (and appears within an "sw" window when you click "Help|Usage". On Unix-like platforms, X-Windows terminal programs provide the same functionality.

Shared Libraries

Some solvers, such as Gurobi and, on some systems, CPLEX, require one or more separate shared libraries to be installed. On MS Windows systems, they have names ending in ".dll" and can simply be put in the same place as the solver file (which will have a name ending in ".exe"). On a Unix-like system, the system has a sequence of directories in which it looks for shared libraries, such as "/lib", "/usr/lib", "/lib64", "/usr/lib64", "/usr/local/lib", "/usr/local/lib64", etc. It is also possible to specify the shared-library search path in an environment variable whose name is system-dependent. On many systems, $LD_LIBRARY_PATH serves this purpose (but it is $DYLD_LIBRARY_PATH, and on AIX systems it may be $LIBPATH). Then one can have a little shell script that actually invokes the solver, such as 
 
    #!/bin/sh
    LD_LIBRARY_PATH=$HOME/bin $HOME/bin/gurobix "$@" 
 
(to invoke Gurobi under Linux, assuming "gurobix" is the actual Gurobi binary, appearing in $HOME/bin, and that Gurobi's shared libraries are installed there rather than in one of the standard places for the system). In the above example, $"@" passes the command arguments on to gurobix. Where approrpiate, sample such shell scripts are included with solvers; they assume installation in standard places, but are easily edited for custom installations.

Notify List

By clicking "Notify list" on your download page you will see a page in which you can modify a list of E-mail addresses that should receive occasional brief messages about available updates to your licensed material.