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 contact us.
When a solver starts up, it displays a brief identification string such as
MINOS 5.4 or CPLEX 3.0. 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 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 by contacting support. 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 most of it for generating the
problem, leaving not enough memory for the solver to be active at the same time.
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 C program like this
that tries to allocate as much as possible:
#include <stdio.h>
#include <stdlib.h>
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.
|
