Error running cplexamp: termination code 9

[paterijk]

Hi

I try to solve a MIP via ampl with cplex, and I get the following
error message :

Error running cplexamp: termination code 9

This error occurs after hours of calculations. Other problems (smaller
size) are solved flawlessly using the same AMPL model.

I can't find any info concerning this termination code, therefore I am
wondering if someone in this forum could give me a hint on how to
solve this difficulty.

Thanx in advance for any information,

Patrick

[Paul]

One possibility is to have AMPL write the model out as a SAV file, load that file into the CPLEX interactive solver, let it rip and see if you get an error there (and, if so, whether the error message is a bit more informative).

Paul

[Robert Fourer]

Termination code 9 is an error code from the operating system level which
has generally been associated with out-of-memory errors. This is consistent
with the appearance of this error only when running your largest problem.
If you specify

option cplex_options 'mipdisplay 2 mipinterval 1000';

(or add these directives to a cplex_options string that you're already
using) then the resulting log should give some more useful information about
what's causing the problem. For further help you may want to post the
entire log.

Bob Fourer
4...@ampl.com

[Patrick Meyer]

Hi retried and again obtained the termination code 9.

Here's the output (I skipped a big part and wrote [...]) :

IBM ILOG License Manager: "IBM ILOG Optimization Suite for Academic
Initiative" is accessing CPLEX 12 with option(s): "e m b q ".
CPLEX 12.2.0.0: mipdisplay 2
mipinterval 1000
MIP Presolve eliminated 1560 rows and 30 columns.
MIP Presolve modified 3640 coefficients.
Reduced MIP has 10593 rows, 3183 columns, and 32534 nonzeros.
Reduced MIP has 2172 binaries, 0 generals, 0 SOSs, and 0 indicators.
Probing time = 0.01 sec.
Probing time = 0.01 sec.
Clique table members: 2721.
MIP emphasis: balance optimality and feasibility.
MIP search method: dynamic search.
Parallel mode: deterministic, using up to 32 threads.
Root relaxation solution time = 1.29 sec.

Nodes Cuts/
Node Left Objective IInf Best Integer Best Node ItCnt
Gap

0 0 0.0000 376 0.0000 9

0 0 0.0000 480 Cuts: 1359 760

0 0 0.0000 488 Cuts: 273 1454

0 2 0.0000 369 0.0000 1521

Elapsed real time = 11.35 sec. (tree size = 0.01 MB)
* 566+ 344 1.4200 0.0000 85844
100.00%
* 566+ 229 1.4160 0.0000 85844
100.00%
* 575+ 158 1.3800 0.0000 89166
100.00%
* 577+ 109 1.0800 0.0000 89649
100.00%
* 577+ 76 1.0741 0.0000 89649
100.00%
* 590+ 61 0.8360 0.0000 93967
100.00%
* 590+ 47 0.7906 0.0000 93967
100.00%
* 590+ 38 0.7876 0.0000 93967
100.00%
1000 405 0.0000 300 0.7876 0.0000 157035
100.00%
2000 1337 0.0400 278 0.7876 0.0000 311991
100.00%
* 2356+ 1602 0.7859 0.0000 345905
100.00%
* 2356+ 1602 0.7110 0.0000 345905
100.00%
3000 2215 0.0000 295 0.7110 0.0000 381054
100.00%
4000 3065 0.0200 192 0.7110 0.0000 463947
100.00%
5000 3865 0.0400 318 0.7110 0.0000 545310
100.00%
6000 4568 0.3050 226 0.7110 0.0000 593454
100.00%
* 6378+ 4788 0.3233 0.0000 601247
100.00%
* 6378+ 4788 0.3217 0.0000 601247
100.00%
* 6378+ 4788 0.2800 0.0000 601247
100.00%
* 6378+ 4788 0.2500 0.0000 601247
100.00%
7000 5246 0.0000 268 0.2500 0.0000 636107
100.00%
* 7540+ 5575 0.2344 0.0000 665479
100.00%
8000 5874 0.0000 186 0.2344 0.0000 691026
100.00%
9000 5729 0.0000 183 0.2344 0.0000 725217
100.00%
10000 6329 0.0000 188 0.2344 0.0000 774956
100.00%
Elapsed real time = 124.81 sec. (tree size = 1.64 MB)
11000 6932 0.0813 319 0.2344 0.0000 825896
100.00%

[...]

Elapsed real time = 24200.60 sec. (tree size = 8554.09 MB)
Nodefile size = 8425.47 MB (2148.18 MB after compression)
4631000 2877304 0.0676 253 0.1000 0.0000
3.25e+08 100.00%
4632000 2877972 0.0330 223 0.1000 0.0000
3.26e+08 100.00%
4633000 2878625 0.0840 166 0.1000 0.0000
3.26e+08 100.00%
4634000 2879293 0.0170 171 0.1000 0.0000
3.26e+08 100.00%
4635000 2879913 infeasible 0.1000 0.0000
3.26e+08 100.00%
4636000 2880567 0.0252 195 0.1000 0.0000
3.26e+08 100.00%
4637000 2881197 0.0773 199 0.1000 0.0000
3.26e+08 100.00%
4638000 2881827 0.0900 132 0.1000 0.0000
3.26e+08 100.00%
4639000 2882463 0.0640 162 0.1000 0.0000
3.26e+08 100.00%
4640000 2883095 0.0882 81 0.1000 0.0000
3.26e+08 100.00%
Elapsed real time = 24358.31 sec. (tree size = 8576.43 MB)
Nodefile size = 8447.44 MB (2153.76 MB after compression)
4641000 2883729 0.0918 300 0.1000 0.0000
3.26e+08 100.00%
4642000 2884365 infeasible 0.1000 0.0000
3.26e+08 100.00%
4643000 2884928 0.0700 165 0.1000 0.0000
3.26e+08 100.00%
4644000 2885526 0.0950 107 0.1000 0.0000
3.26e+08 100.00%
4644000 2885526 0.0950 107 0.1000 0.0000
3.26e+08 100.00%
error running cplexamp:
termination code 9
<BREAK>

That's all I get. The computer on which this is run has 256 Gigabytes of
RAM.

Any idea ?

Patrick

[Robert Fourer]

The problem here may be that CPLEX is using 32 parallel threads, each of
which maintains its own substantial search tree in memory. Could you test
this hypothesis by seeing what happens when you add, say, 'threads 8' to the
cplex_options string?

In general this does not look like a promising run, as the lower bound never
rises above zero, and for every 1000 nodes explored only about 400 are
fathomed while 600 are added to the tree for further processing. There's no
end in sight. It might be worth investigating how it is that solutions to
the linear relaxation can have an objective of zero, and whether cuts can be
added to raise that value. Also CPLEX has many algorithmic options for
integer programming (see chapter 7 of
www.ampl.com/BOOKLETS/amplcplex122userguide.pdf) and for a very hard problem
it can be worth experimenting with changes to some of the default settings.

Bob Fourer
4...@ampl.com

[paterijk]

I have tried with 8 threads, and the result is similar to before
(except for the running time which is much much lower) :

Tried aggregator 2 times.

MIP Presolve eliminated 1560 rows and 30 columns.
MIP Presolve modified 3640 coefficients.

Aggregator did 3 substitutions.

Reduced MIP has 10593 rows, 3183 columns, and 32534 nonzeros.
Reduced MIP has 2172 binaries, 0 generals, 0 SOSs, and 0 indicators.
Probing time = 0.01 sec.

Tried aggregator 1 time.
Presolve time = 0.06 sec.

Probing time = 0.01 sec.
Clique table members: 2721.
MIP emphasis: balance optimality and feasibility.
MIP search method: dynamic search.

Parallel mode: opportunistic, using up to 8 threads.
Root relaxation solution time = 0.50 sec.

Nodes Cuts/
Node Left Objective IInf Best Integer Best Node
ItCnt Gap

0 0 0.0000 505 0.0000
1427
0 0 0.0000 292 Cuts: 348
1791
0 0 0.0000 442 Cuts: 639
2619
0 0 0.0000 351 Cuts: 169
3032
0 0 0.0000 369 Cuts: 356
3538
* 0+ 0 1.4400 0.0000
3538 100.00%
0 2 0.0000 281 1.4400 0.0000
3538 100.00%
Elapsed real time = 9.50 sec. (tree size = 0.00 MB)
* 538+ 305 1.1257 0.0000
50895 100.00%
* 538+ 305 1.0943 0.0000
50895 100.00%
* 539+ 304 1.0600 0.0000
51046 100.00%
* 544+ 214 1.0150 0.0000
62342 100.00%
* 544+ 142 0.3983 0.0000
62342 100.00%
1000 403 0.0000 249 0.3983 0.0000
118948 100.00%
2000 1206 0.1224 136 0.3983 0.0000
181077 100.00%
* 2900+ 1784 0.3118 0.0000
206192 100.00%
3000 1839 infeasible 0.3118 0.0000
207976 100.00%
4000 2432 0.2400 132 0.3118 0.0000
233780 100.00%
5000 3106 0.2025 94 0.3118 0.0000
262760 100.00%
6000 3737 0.2640 55 0.3118 0.0000
282417 100.00%
7000 4425 0.0882 114 0.3118 0.0000
303072 100.00%
8000 5122 0.0000 156 0.3118 0.0000
322336 100.00%
9000 5791 0.1295 94 0.3118 0.0000
339891 100.00%
10000 6513 0.1280 96 0.3118 0.0000
354550 100.00%
Elapsed real time = 108.02 sec. (tree size = 844.60 MB)
Nodefile size = 717.34 MB (537.64 MB after compression)

[...]

Elapsed real time = 346.00 sec. (tree size = 9793.51 MB)
Nodefile size = 9666.08 MB (7278.54 MB after compression)
* 96317+73730 0.1401 0.0000
2393073 100.00%
97000 74304 0.0816 132 0.1401 0.0000
2413738 100.00%
98000 75113 0.1029 130 0.1401 0.0000
2440799 100.00%
99000 75918 0.1058 161 0.1401 0.0000
2466351 100.00%
100000 76713 0.0680 179 0.1401 0.0000
2493644 100.00%
*100013+76659 0.1394 0.0000
2494128 100.00%
*100019+76553 0.1348 0.0000
2494269 100.00%
*100020+76456 0.1333 0.0000
2494511 100.00%
101000 77215 0.1131 120 0.1333 0.0000
2521182 100.00%
102000 77973 0.0721 128 0.1333 0.0000
2552471 100.00%
103000 78772 0.0625 178 0.1333 0.0000
2581490 100.00%
104000 79588 0.1331 131 0.1333 0.0000
2614659 100.00%
105000 80379 infeasible 0.1333 0.0000
2645477 100.00%
106000 81199 0.1034 135 0.1333 0.0000
2673921 100.00%
Elapsed real time = 376.60 sec. (tree size = 10836.22 MB)
Nodefile size = 10708.47 MB (8068.49 MB after compression)
107000 82016 0.1289 126 0.1333 0.0000
2697021 100.00%
108000 82806 0.0133 166 0.1333 0.0000
2718805 100.00%
109000 83571 0.0849 144 0.1333 0.0000
2747532 100.00%
110000 84375 0.0949 107 0.1333 0.0000
2768922 100.00%
111000 85139 0.0755 133 0.1333 0.0000
2790211 100.00%
112000 85924 0.0993 150 0.1333 0.0000
2816098 100.00%
113000 86680 0.0856 134 0.1333 0.0000
2839661 100.00%
114000 87440 0.0433 171 0.1333 0.0000
2869203 100.00%
115000 88254 0.0644 150 0.1333 0.0000
2898262 100.00%
116000 89058 0.0765 161 0.1333 0.0000
2927666 100.00%
Elapsed real time = 404.91 sec. (tree size = 11901.76 MB)
Nodefile size = 11773.98 MB (8878.61 MB after compression)
117000 89857 0.0708 149 0.1333 0.0000
2960270 100.00%
118000 90641 0.1117 126 0.1333 0.0000
2984750 100.00%
119000 91473 0.0807 145 0.1333 0.0000
3015359 100.00%
120000 92297 0.1330 115 0.1333 0.0000
3046295 100.00%
121000 93116 0.0699 105 0.1333 0.0000
3074451 100.00%
122000 93928 0.0894 138 0.1333 0.0000
3108215 100.00%
123000 94727 0.0712 165 0.1333 0.0000
3141546 100.00%

And then it's over again (termination code 9 for ampl, and a break).

Does this confirm your hypothesis ?

Patrick

On 25 juin, 21:02, "Robert Fourer" <4...@ampl.com> wrote:
> The problem here may be that CPLEX is using 32 parallel threads, each of
> which maintains its own substantial search tree in memory.  Could you test
> this hypothesis by seeing what happens when you add, say, 'threads 8' to the
> cplex_options string?
>
> In general this does not look like a promising run, as the lower bound never
> rises above zero, and for every 1000 nodes explored only about 400 are
> fathomed while 600 are added to the tree for further processing.  There's no
> end in sight.  It might be worth investigating how it is that solutions to
> the linear relaxation can have an objective of zero, and whether cuts can be
> added to raise that value.  Also CPLEX has many algorithmic options for

> integer programming (see chapter 7 ofwww.ampl.com/BOOKLETS/amplcplex122userguide.pdf) and for a very hard problem

[paterijk]

Hi,

I have tried with 8 threads, and I obtain the same error (after a much
shorter calculation time) :

IBM ILOG License Manager: "IBM ILOG Optimization Suite for Academic
Initiative" is accessing CPLEX 12 with option(s): "e m b q ".
CPLEX 12.2.0.0: mipdisplay 2
mipinterval 1000

threads 8
timing 1
logfile amplMIP3.log

MIP Presolve eliminated 1560 rows and 30 columns.
MIP Presolve modified 3640 coefficients.
Reduced MIP has 10593 rows, 3183 columns, and 32534 nonzeros.
Reduced MIP has 2172 binaries, 0 generals, 0 SOSs, and 0 indicators.
Probing time = 0.01 sec.
Probing time = 0.01 sec.
Clique table members: 2721.
MIP emphasis: balance optimality and feasibility.
MIP search method: dynamic search.

Parallel mode: opportunistic, using up to 8 threads.
Root relaxation solution time = 0.50 sec.

Nodes Cuts/
Node Left Objective IInf Best Integer Best Node
ItCnt Gap

[...]

3141546 100.00%

error running cplexamp:
termination code 9
<BREAK>

Does this confirm your hypothesis ?

Patrick

On 25 juin, 21:02, "Robert Fourer" <4...@ampl.com> wrote:

> The problem here may be that CPLEX is using 32 parallel threads, each of
> which maintains its own substantial search tree in memory.  Could you test
> this hypothesis by seeing what happens when you add, say, 'threads 8' to the
> cplex_options string?
>
> In general this does not look like a promising run, as the lower bound never
> rises above zero, and for every 1000 nodes explored only about 400 are
> fathomed while 600 are added to the tree for further processing.  There's no
> end in sight.  It might be worth investigating how it is that solutions to
> the linear relaxation can have an objective of zero, and whether cuts can be
> added to raise that value.  Also CPLEX has many algorithmic options for

> integer programming (see chapter 7 ofwww.ampl.com/BOOKLETS/amplcplex122userguide.pdf) and for a very hard problem

[Robert Fourer]

It appears that when using only 8 threads the tree is indeed larger, though
surprisingly far fewer nodes have been created than in the 32-thread
example. This may reflect some glitch in CPLEX reporting. You could try
reducing to 4, 2, 1 thread to see what the trend is. You could also try
updating to version 12.2.0.2, which is said to have some memory-management
bug fixes, though there's no guarantee that they will address your problem;
see

https://www-304.ibm.com/support/docview.wss?dc=D400&rs=539&uid=swg24028951&c
ontext=SSC5SPS&cs=utf-8&lang=en&loc=en_US

In fact there is a new version 12.3 of CPLEX for which we have AMPL support,
but I'm not sure it is available yet through the IBM Academic Initiative.
If you want to send me some files I will try running your model under 12.3
to see what happens (though I have access to only 12GB of RAM). (I can also
try applying Gurobi to it.)

For a stubborn CPLEX problem you also have the option of posting to one of
the IBM ILOG Optimization Forums; see

http://www.ibm.com/developerworks/forums/category.jspa?categoryID=260

This puts you in touch with the CPLEX developers. If in AMPL you specify,
say,

option cplex_options 'writeprob paterijk.sav';

(or add this directive to any cplex_options string you're currently
specifying) then CPLEX will write your problem in ".sav" format which may be
helpful to the CPLEX people (though it may also help them to see your AMPL
model).

Bob Fourer
4...@ampl.com

> -----Original Message-----
> From: am...@googlegroups.com [mailto:am...@googlegroups.com]

> On Behalf Of paterijk
> Sent: Tuesday, June 28, 2011 3:54 AM
> To: AMPL Modeling Language

> --
> You received this message because you are subscribed to the Google
> Groups "AMPL Modeling Language" group.
> To post to this group, send email to am...@googlegroups.com.
> To unsubscribe from this group, send email to
> ampl+uns...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/ampl?hl=en.

[mina]

Hi,

I have tried to run my model via AMPL with Cplex and since it's a large problem, I set different time limits for it to get the lowest possible gap. I run it for 6 and 10 hours and for each, I got this: time limit with integer solution :....

But when I run it for 24 hours, I got this: termination code 9. I have attached two screenshots showing all the calculations that is done before getting the error.

I appreciate it if someone can take a look at the files and let me know if something could be wrong with my model or it's just due to lack of memory.

Thanks in advance.

Mina

[Robert Fourer]

The "error running cplex: termination code 9" message indicates a low-level error in the CPLEX program, which might be due to insufficient memory (though your problem does not appear to be especially large) or might result from a bug of some kind. If you are in a hurry to get a successful run, then you may want to just switch to another solver, such as either the latest version of CPLEX (12.6.1), or Gurobi or Xpress. If you want to investigate this problem further, then in your cplex_options string remove 'mipinterval=18000', add 'logfile=cplex.out', and reply to am...@googlegroups.com with the resulting file cplex.out as an attachment; that will provide more information as to what is happening in CPLEX, including memory use.

The solution process for your model produces a presolve_inteps warning and reports many modified coefficients:

Setting $presolve_inteps >= 1.2e-05 could change presolve results
MIP Presolve modified 80437 coefficients

This most often happens when the model uses a "big M" constant that is set to something like 10000000. Sometimes you can help the solver by analyzing the constraints and picking a much smaller valid constant yourself (and not necessarily the same constant for every constraint).

Bob Fourer
am...@googlegroups.com

=======

[Mina Hadianniasar]

Dear Rob,

I have tried different things but could not figure out the problem and I really need to somehow get a smaller gap by running my model via cplex. As you suggested, I added 'logfile=cplex.out'  in my cplex_options string and attached to this email the resulting files. I really appreciate it if you could take a look at them and let me know your opinion. Also, please let me know if you need my model and data as well.

Thanks in advance for your help.

Best regards,

Mina

--
You received this message because you are subscribed to a topic in the Google Groups "AMPL Modeling Language" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ampl/6W4qI0ssLio/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ampl+uns...@googlegroups.com.

To post to this group, send email to am...@googlegroups.com.

Visit this group at http://groups.google.com/group/ampl.
For more options, visit https://groups.google.com/d/optout.

--

Mina Hadian

Ph.D. student

Department of Industrial Engineering

4120 Bell Engineering Center

University of Arkansas

Fayetteville, AR 72701
Phone: (479) 575-7372

[Robert Fourer]

The objective value of the continuous relaxation of your binary integer program is zero -- as indicated under Cuts/Best Bound on the first line of the log. The solver works hard to raise the lower bound by generating large numbers of cuts, but still at the end of the listing (in cplex.outtimelimit=86400threads=4) it can only get the bound up to within 23% of the best solution found so far. Also at that point the size of the search tree (under Nodes Left) is continuing to grow and is taking over 20GB of memory.

To avoid running out of memory, you could try adding nodefile=3 to the cplex_options string to so that the compressed node file is saved on disk rather than in memory. Even so, with the formulation that you are using, the bound is so weak that you will probably need to stop the solver at some point and use the best solution that it has found. Perhaps there is a different formulation that will give a better lower bound; you might give some thought to why the objective value has a minimum of zero when the integrality of the variables is relaxed, and how you could add or change constraints to force the relaxation objective to be higher. Also you could look at some of the suggestions in http://inside.mines.edu/~anewman/MIP_practice120212.pdf.

Bob Fourer
am...@googlegroups.com

=======

From: am...@googlegroups.com [mailto:am...@googlegroups.com] On Behalf Of Mina Hadianniasar
Sent: Friday, April 3, 2015 9:03 PM
To: am...@googlegroups.com

[Mina Hadianniasar]

Dear Robert;

I hope all is well with you.

As you suggested, I added "nodefile=3" to the cplex_options string and I got a best integer solution with a gap of 1.96% from the CPLEX in only 40 seconds! Before adding this option, after 10 hours of running CPLEX, the obtained gap was 27% (Model and data for both situations are the same. The only difference is the nodefile=3 option that is added to the cplex_options string). Do you think this significant reduction in gap and computational time is reasonable?

Thanks in advance for your kind help.

Best regards,

Mina

--
You received this message because you are subscribed to a topic in the Google Groups "AMPL Modeling Language" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ampl/6W4qI0ssLio/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ampl+uns...@googlegroups.com.
To post to this group, send email to am...@googlegroups.com.
Visit this group at http://groups.google.com/group/ampl.
For more options, visit https://groups.google.com/d/optout.

[Robert Fourer]

I would not expect such a big improvement from adding "nodefile=3". There may be an explanation, but the only way to know more is to put 'mipdisplay=2' in the cplex_options string and then compare the logs from the two runs. If you can post the logs then I might be able to say more about the reason for the difference.

[Nic Woyak]

Bob when you say, "for every 1000 nodes explored only about 400 are fathomed while 600 are

added to the tree for further processing.  There's no end in sight. "

That is because of the 1000 given here: "option cplex_options 'mipdisplay 2 mipinterval 1000';"

and the numbers all approximately 400 in the 4th column from the left (IInf) below. Is that correct? 

         Nodes                                         Cuts/
    Node  Left     Objective  IInf  Best Integer     Best Node    ItCnt
     Gap

       0     0        0.0000   376                      0.0000        9

       0     0        0.0000   480                  Cuts: 1359      760

       0     0        0.0000   488                   Cuts: 273     1454

       0     2        0.0000   369                      0.0000     1521

[Robert Fourer]

I was referring to the counts in the "Nodes" and "Nodes Left" column later in the log. CPLEX produces a log line at every 1000th nodes that it generates. The "Nodes Left" count is the number of nodes remaining to be processed, and this count is observed to be increasing by about 600 from one log line to the next.

In your question you only show the first 4 lines of the log, which shows the results of some initial processing; the "Nodes" and "Nodes Left" counts only start increasing in later log lines.

Bob Fourer
am...@googlegroups.com

=======

From: am...@googlegroups.com [mailto:am...@googlegroups.com] On Behalf Of Nic Woyak
Sent: Thursday, July 7, 2016 2:49 PM
To: AMPL Modeling Language

[Gaby Hannoun]

Hello, 

My model is solving for smaller instances but as I slightly increase the problem size I am face the same termination code 9 error even before the generation of the root node (kindly see below). I am providing a MIP initial solution and the model is solving a vehicle routing and scheduling problem with movement synchronization. 

Could it be also associated with an out-of memory error? 

Thanks,

Gaby

SOLVING ...

CPLEX 12.9.0.0: mipdisplay 2

mipinterval 1

symmetry 5

presolve 1

nodefile 3

1 of 1 MIP starts provided solutions.

MIP start 'm1' defined initial solution with objective 6589.6287.

MIP Presolve eliminated 411378 rows and 291444 columns.

MIP Presolve modified 4051048 coefficients.

Reduced MIP has 1171990 rows, 376474 columns, and 65665842 nonzeros.

Reduced MIP has 376350 binaries, 0 generals, 0 SOSs, and 0 indicators.

Probing time = 13.51 sec. (2689.34 ticks)

Cover probing fixed 2 vars, tightened 0 bounds.

MIP Presolve eliminated 0 rows and 2 columns.

Reduced MIP has 1171990 rows, 376472 columns, and 65665828 nonzeros.

Reduced MIP has 376348 binaries, 0 generals, 0 SOSs, and 0 indicators.

Probing fixed 1 vars, tightened 0 bounds.

Probing time = 8.96 sec. (2182.68 ticks)

Clique table members: 11538889.

MIP emphasis: balance optimality and feasibility.

MIP search method: dynamic search.

Parallel mode: deterministic, using up to 16 threads.

error running cplex:

termination code 9

<BREAK>

[AMPL Google Group]

After the initial processing, CPLEX needs to create a copy of the problem for each parallel thread that you will be using. So when CPLEX uses a large number of threads -- 16 in your example -- it has a large memory requirement. In practice, there is often no benefit to having so many threads, because the communication time (to balance work between threads) becomes excessive. In many cases, 8 threads work just as well, so I suggest trying again with threads=8 added to your cplex_options string. If you still get the "termination code 9" error, then try threads=4 and even threads=2 to see whether that makes a difference.

--
Robert Fourer
am...@googlegroups.com

{#HS:1207063792-81541#}

--
You received this message because you are subscribed to the Google Groups "AMPL Modeling Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ampl+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ampl/c39cd2a4-da92-49e0-87e0-7c18d6faf565o%40googlegroups.com.