<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none"><!--P{margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>Very good advice, thank you!<br>
Indeed I was using MUMPS4.0 and switching over to MA97 seems to have fixed it! I'll look into PARDISO as well.<br>
<br>
Best regards, Elias<br>
<br>
</p>
<div style="color: rgb(33, 33, 33);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>Von:</b> Sean Hardesty <sean.hardesty@gmail.com><br>
<b>Gesendet:</b> Donnerstag, 16. Januar 2020 05:58<br>
<b>An:</b> Elias Trommer<br>
<b>Cc:</b> ipopt@list.coin-or.org<br>
<b>Betreff:</b> Re: [Ipopt] Segmentation fault due to MUMPS memory allocation</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div>Do you know what version of MUMPS you are using? According to my notes from experiments a couple years ago, MUMPS 4 does not use internal 64-bit integer indexing, so if you have more than 2^31 non-zeros (or maybe 2^32), it will crash. I think this is supported
as of MUMPS 5.1.0, but I don't know whether Ipopt works with MUMPS 5. In order to solve problems requiring 64-bit indexing, I had to use MA86 or MA97. MA27 and MA57 don't use 64-bit integers either. I tried to use Pardiso, but had difficulty getting it to
link against MKL, so I don't know how it behaves...</div>
<div><br>
</div>
<div> Sean<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Jan 13, 2020 at 1:34 AM Elias Trommer <<a href="mailto:elias.trommer@rl-institut.de">elias.trommer@rl-institut.de</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div dir="ltr" style="font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255); font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Hi everyone,</p>
<p>I'm trying to use ipopt as a solver for a non-linear optimization problem in Julia. This works fine for smaller instances of the problem, however for larger instances MUMPS seems to fail because of a failing memory allocation. The full error output is at
the end of this eMail.<br>
</p>
<p><br>
</p>
<p>Because I previously had problems with this, I've decreased the option `mumps_mem_percent` to a value of 100 so that the restoration would not fail during the first iteration as described in the error message.</p>
<p>However, for this particular problem, I'm having a hard time pinning down the source. It's running on an Ubuntu 18.04 machine with 64Gb of RAM and 16Gb of Swap, so I presume it's not a lack of actual memory, but rather an allocation issue. I've also checked
the ulimit on the machine I'm working on and it's set to unlimited.<br>
</p>
<p><br>
</p>
<p>I was hoping someone could help me pin down the cause of this issue (and ideally how to fix it)!</p>
<p><br>
</p>
<p>Thank you in advance,</p>
<p>Elias Trommer<br>
</p>
<p><br>
</p>
```
<p>This is Ipopt version 3.12.10, running with linear solver mumps.<br>
NOTE: Other linear solvers might be more efficient (see Ipopt documentation).<br>
<br>
Number of nonzeros in equality constraint Jacobian...: 863116<br>
Number of nonzeros in inequality constraint Jacobian.: 108177<br>
Number of nonzeros in Lagrangian Hessian.............: 358996</p>
<p><br>
Total number of variables............................: 145445<br>
variables with only lower bounds: 0<br>
variables with lower and upper bounds: 144771<br>
variables with only upper bounds: 0<br>
Total number of equality constraints.................: 145338<br>
Total number of inequality constraints...............: 36059<br>
inequality constraints with only lower bounds: 0<br>
inequality constraints with lower and upper bounds: 0<br>
inequality constraints with only upper bounds: 36059<br>
<br>
iter objective inf_pr inf_du lg(mu) ||d|| lg(rg) alpha_du alpha_pr ls<br>
0 2.3869702e+03 4.60e+01 1.00e+00 -1.0 0.00e+00 - 0.00e+00 0.00e+00 0<br>
1 2.3914541e+03 4.48e+01 2.58e+05 -1.0 6.23e+01 - 2.96e-05 2.61e-02F 1<br>
2 2.3936754e+03 3.08e+02 7.11e+07 -1.0 6.07e+01 - 4.74e-01 9.61e-01f 1<br>
3 2.3924281e+03 3.08e+02 7.10e+07 -1.0 4.05e+03 -2.0 1.11e-03 6.56e-04f 1<br>
4 2.3924033e+03 3.08e+02 7.10e+07 -1.0 1.40e+03 -1.6 5.44e-03 3.68e-05f 1<br>
5 2.3920925e+03 3.08e+02 7.10e+07 -1.0 3.06e+03 -2.1 2.68e-03 3.03e-04f 1<br>
6 2.3918892e+03 3.08e+02 7.10e+07 -1.0 1.07e+04 - 6.52e-04 1.30e-04f 1<br>
7 2.3915687e+03 3.07e+02 7.09e+07 -1.0 1.11e+03 - 5.12e-03 7.38e-04f 1<br>
8 2.3908132e+03 3.07e+02 7.08e+07 -1.0 1.13e+03 - 1.08e-02 2.08e-03f 1<br>
9 2.3907401e+03 3.07e+02 9.31e+09 -1.0 7.76e+02 - 2.79e-02 1.84e-04f 1<br>
iter objective inf_pr inf_du lg(mu) ||d|| lg(rg) alpha_du alpha_pr ls<br>
10 2.3892870e+03 3.05e+02 1.62e+10 -1.0 5.84e+02 - 2.56e-02 6.94e-03f 1<br>
11 2.3894049e+03 3.04e+02 3.09e+10 -1.0 4.25e+02 - 4.15e-02 1.21e-03f 1<br>
12 2.3960908e+03 2.88e+02 3.92e+10 -1.0 3.76e+02 - 8.17e-02 5.33e-02f 1<br>
13 2.4009546e+03 2.78e+02 2.85e+10 -1.0 3.05e+02 - 3.87e-03 3.45e-02f 1<br>
14 2.4012483e+03 2.77e+02 3.19e+10 -1.0 2.93e+02 - 1.40e-02 2.36e-03f 1<br>
15 2.4038152e+03 2.72e+02 3.44e+10 -1.0 2.93e+02 - 3.19e-02 2.10e-02f 1<br>
16 2.4038403e+03 2.72e+02 4.23e+10 -1.0 2.86e+02 - 2.55e-02 2.15e-04h 1<br>
17 2.4036648e+03 2.71e+02 4.17e+10 -1.0 4.57e+03 - 3.36e-06 3.15e-04f 1<br>
18 2.4069581e+03 2.67e+02 3.57e+10 -1.0 2.89e+02 - 2.86e-04 1.71e-02f 1<br>
19 2.4069888e+03 2.67e+02 6.39e+10 -1.0 2.83e+02 - 2.26e-02 1.75e-04h 1<br>
iter objective inf_pr inf_du lg(mu) ||d|| lg(rg) alpha_du alpha_pr ls<br>
20 2.4068113e+03 2.67e+02 6.38e+10 -1.0 3.88e+04 - 1.85e-06 2.86e-05h 1<br>
21 2.4067828e+03 2.67e+02 4.51e+10 -1.0 4.20e+03 - 3.96e-06 7.14e-05h 1<br>
MUMPS returned INFO(1) = -9 and requires more memory, reallocating. Attempt 1<br>
Increasing icntl[13] from 80 to 160.<br>
MUMPS returned INFO(1) = -9 and requires more memory, reallocating. Attempt 1<br>
Increasing icntl[13] from 160 to 320.<br>
MUMPS returned INFO(1) = -9 and requires more memory, reallocating. Attempt 2<br>
Increasing icntl[13] from 320 to 640.<br>
MUMPS returned INFO(1) = -9 and requires more memory, reallocating. Attempt 3<br>
Increasing icntl[13] from 640 to 1280.<br>
MUMPS returned INFO(1) = -9 and requires more memory, reallocating. Attempt 4<br>
Increasing icntl[13] from 1280 to 2560.<br>
22 2.4067829e+03 2.67e+02 4.51e+10 -1.0 5.70e+00 5.8 2.39e-05 1.79e-05h 1<br>
MUMPS returned INFO(1) = -9 and requires more memory, reallocating. Attempt 1<br>
Increasing icntl[13] from 2560 to 5120.<br>
MUMPS returned INFO(1) = -9 and requires more memory, reallocating. Attempt 2<br>
Increasing icntl[13] from 5120 to 10240.<br>
MUMPS returned INFO(1) = -9 and requires more memory, reallocating. Attempt 3<br>
Increasing icntl[13] from 10240 to 20480.<br>
Problem with integer stack size 1 1 6<br>
<br>
signal (11): Segmentation Fault</p>
```
<p><br>
</p>
</div>
_______________________________________________<br>
Ipopt mailing list<br>
<a href="mailto:Ipopt@list.coin-or.org" target="_blank">Ipopt@list.coin-or.org</a><br>
<a href="https://list.coin-or.org/mailman/listinfo/ipopt" rel="noreferrer" target="_blank">https://list.coin-or.org/mailman/listinfo/ipopt</a><br>
</blockquote>
</div>
</div>
</div>
</body>
</html>