TRY NOW!
AMPL > >Faqs

Errors and Messages

Why does AMPL reject my “let” statement with a “… has a := value in the model” message?

Your let command is attempting to assign a value to some set or parameter. In the set’s or parameter’s declaration, however, you have used a := phrase to permanently define the value. A let command is not permitted to redefine the value of such a parameter; hence the error message that you received.

As an example, if the model declares

param dstot {p in prod} := sum {w in whse} ds[p,w];

then dstot[p] is permanently defined to take the value sum {w in whse} ds[p,w]. You can make any changes you like to the ds[p,w] values, and AMPL will automatically change the dstot[p] values accordingly. Any command beginning let {p in prod} dstot[p] := ... will be in error, however.

If you want to be able to use let to override the defined value of a parameter, use default in place of := in your param declaration.

What does AMPL mean by “syntax error”? I double-checked the offending statement in the AMPL book, and my syntax is fine.

AMPL is signaling an invalid statement of some sort, but the error may not be a matter of “syntax” in the usual sense. For example, you could be trying to define a set index at a place where it is already in use:

ampl: display {i in ORIG}:
ampl?    supply[i] * sum {i in DEST} cost[i,j];
syntax error
context:  supply[i] * sum {i  >>> in  <<< DEST} cost[i,j];

The index i cannot be defined following sum, because it is within the scope of the index i that was defined following display.

If you receive a syntax error that is particularly hard to interpret, please let us know.

How can I tell whether messages on my screen are coming from AMPL or from the solver?

When a solver starts up, it displays a brief identification string such as MINOS 5.5 or CPLEX 12.4. Output that occurs before this string can be assumed to come from AMPL, while output after is the solver’s.

When a solver concludes its run, it returns a brief summary of the results, such as

optimal solution; objective 903202.0326
399 iterations (244 in phase I)

Output prior to this summary can be assumed to be caused by the solver, while output after is from AMPL again.

Why does AMPL appear to “hang” for a long time without accepting any input or producing any output?

If AMPL appears to hang after a solve command but before any output from a solver, then it may be taking much more time to generate your problem than you expected. Try setting option times 1, gentimes 1 to get more output recording AMPL’s progress, as explained in the FAQ question regarding insufficient memory.

The same advice applies if AMPL hangs after some other command, such as write or expand, that forces a lot of variables or constraints to be generated.

If AMPL appears to hang after a command that produces a listing, such as display, then the listing may be much longer than you expected. Usually it is possible to make a quick estimate of the size of the listing, in order to determine whether this could be the difficulty.

If AMPL appears to hang after a line or more from the solver, then your optimization problem may be taking much more time to solve than you expected. Try setting solver directives that provide more output recording progress toward an optimum. Some solvers may also respond to a “break” sequence (such as Ctrl-C) by returning the best solution found so far. These features differ from one solver to the next and even from one algorithm to the next within the same solver; see the solver-specific documentation for details.

Why does AMPL unexpectedly abort in the middle of doing something? I get a short error message, but I can’t find it explained in the AMPL book or in the solver documentation.

You have encountered a low-level error message generated by the operating system. AMPL and the solvers try to trap these messages so as to provide you with more useful information instead; but occasionally a mysterious message does get through.

Some messages, such as

no children
unrecoverable error, STAT = 1001
not enough swap space

usually indicate that AMPL can’t get enough computer resources to complete the current session. As an example, there might be insufficient disk space for AMPL to write the temporary file that the solver reads; to remedy the problem, you can reset option TMPDIR to change the directory to which temporary files are written. More often, however, the difficulty in this situation is insufficient memory, a more complicated matter that we discuss in the next question below.

Other messages, including

segmentation fault
bus error

indicate a bug in AMPL or a solver. Often there is some way to work around this trouble temporarily, but you should also look for a more permanent fix. You can consult our bug fix log to see whether this bug has been found and fixed already; if not, you can tell us about the problem through our comment form. Either way, you will want to request a newer version of the AMPL software that incorporates the fix.

What should I do if I suspect that there is insufficient memory for my AMPL session?

If AMPL fails before passing control to the solver, your computer may not have enough memory to hold all of the variables, constraints and objectives generated by the AMPL translator. If a failure occurs after the solver takes over, memory might be short because AMPL has taken some of it for generating the problem, leaving not enough memory for the solver to be active at the same time. (Operating systems do tend to “page out” a lot of the AMPL process to disk while running the solver, though.)

As a start in diagnosing these situations, display listings of AMPL’s memory use by repeating your run with one or more of

option times 1;
option gentimes 1;
option show_stats 1;

The times listing includes the amount of memory used by each phase of the AMPL translator:

parseinitial processing of model
data readinitial processing of data
compiletranslation of model and data
genmodgeneration of an explicit optimization problem
mergepostprocessing of optimization problem
collectpostprocessing of optimization problem
presolvereduction of problem size
outputwriting of problem file to be read by solver

The gentimes listing includes memory allocated for processing each declaration in the model. If AMPL fails before invoking a solver, this information will tell you how far it got. For failures in the presolve phase, you can save some memory by setting option presolve 0, though a larger problem will be sent to the solver as a result. (Each line in a times or gentimes listing appears when processing of the phase or component is finished. Thus the cause of a memory failure must be in the phase or component after the last one that appeared in the listing. It may help to first run a smaller version of your problem, so that you can see what ought to appear in a complete, correct listing.)

If failure doesn’t occur until after the solver is invoked, then the show_stats listing also appears, giving the numbers of variables and constraints generated and the numbers removed by presolve. If there are more variables or constraints than you expected, then check the gentimes listing for a declaration that has required a very large amount of memory (relative to what the whole model requires). The offending declaration may be incorrect; or, even if it is technically correct, the declaration may specify a very large number of variables or constraints that are unnecessary to the formulation. (Even if a variable is never referenced in the model, it takes up some minimum amount of space in the data structure that AMPL maintains in memory.)

If the difficulty is indeed insufficient memory to run the solver under AMPL, then there is a good chance that you can work around the problem by running AMPL and your solver separately. Here’s an example of how this is done:

ampl: model models\multmip3.mod;
ampl: data models\multmip3.dat;
ampl: write bmultmip3;   # "b" indicates a binary problem file
ampl: quit
C:\AMPL> cplex multmip3
No MIP presolve or aggregator reductions.
C:\AMPL> ampl
ampl: model models\multmip3.mod;
ampl: data models\multmip3.dat;
ampl: solution multmip3.sol;
CPLEX 3.0: optimal integer solution; objective 235625
684 simplex iterations
126 branch-and-bound nodes
ampl: display Trans;
Trans [CLEV,*,*]
:   bands coils plate    :=
DET     0   525   100
FRA   275    50    50  ...

This is inconvenient, but it can substantially reduce the overall memory requirement.

To diagnose insufficient memory, you may need some idea of the amount of memory available for allocation by AMPL and the solver. Your computer may have a utility to help with this, or you may be able to run a short program like this (in C) that tries to allocate as much as possible:

#include <stdio.h>
#include <stdlib.h>
int main()
{
    long int avail, incr;
    avail = 0;
    for (incr = 1024 * 1024; incr >= 1; incr >>= 1)
        while (malloc(incr)) avail += incr;
    printf ("Total allocated: %i\n", avail);
}

Keep in mind that the available memory is often influenced not only by the amount of memory physically installed in the computer, but by the amount of disk space allocated to memory swapping and by the requirements of all other processes currently running on the computer.

If AMPL seems to be using much less memory that you have available, then you should also check that you are using 64-bit versions of your operating system, AMPL, and solvers. A 32-bit version cannot possibly access more the 4 gigabytes of memory, and is limited to as few as 2 gigabytes on some computers.