AMPL > >Faqs

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.

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.

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.

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.

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.

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:

parse | initial processing of model |

data read | initial processing of data |

compile | translation of model and data |

genmod | generation of an explicit optimization problem |

merge | postprocessing of optimization problem |

collect | postprocessing of optimization problem |

presolve | reduction of problem size |

output | writing 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.