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.