[Ipopt] Segmentation fault due to MUMPS memory allocation
Damien
damien at khubla.com
Thu Jan 23 09:31:11 EST 2020
FYI MUMPS 5.x works with IPOPT. The parallelism is decent as well, it's
now threaded as well as multi-process.
Damien
On 1/23/2020 7:24 AM, Elias Trommer wrote:
>
> Very good advice, thank you!
> Indeed I was using MUMPS4.0 and switching over to MA97 seems to have
> fixed it! I'll look into PARDISO as well.
>
> Best regards, Elias
>
> ------------------------------------------------------------------------
> *Von:* Sean Hardesty <sean.hardesty at gmail.com>
> *Gesendet:* Donnerstag, 16. Januar 2020 05:58
> *An:* Elias Trommer
> *Cc:* ipopt at list.coin-or.org
> *Betreff:* Re: [Ipopt] Segmentation fault due to MUMPS memory allocation
> 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...
>
> Sean
>
> On Mon, Jan 13, 2020 at 1:34 AM Elias Trommer
> <elias.trommer at rl-institut.de <mailto:elias.trommer at rl-institut.de>>
> wrote:
>
> Hi everyone,
>
> 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.
>
>
> 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.
>
> 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.
>
>
> I was hoping someone could help me pin down the cause of this
> issue (and ideally how to fix it)!
>
>
> Thank you in advance,
>
> Elias Trommer
>
>
> ```
>
> This is Ipopt version 3.12.10, running with linear solver mumps.
> NOTE: Other linear solvers might be more efficient (see Ipopt
> documentation).
>
> Number of nonzeros in equality constraint Jacobian...: 863116
> Number of nonzeros in inequality constraint Jacobian.: 108177
> Number of nonzeros in Lagrangian Hessian.............: 358996
>
>
> Total number of variables............................: 145445
> variables with only lower bounds: 0
> variables with lower and upper bounds: 144771
> variables with only upper bounds: 0
> Total number of equality constraints.................: 145338
> Total number of inequality constraints...............: 36059
> inequality constraints with only lower bounds: 0
> inequality constraints with lower and upper bounds: 0
> inequality constraints with only upper bounds: 36059
>
> iter objective inf_pr inf_du lg(mu) ||d|| lg(rg) alpha_du
> alpha_pr ls
> 0 2.3869702e+03 4.60e+01 1.00e+00 -1.0 0.00e+00 -
> 0.00e+00 0.00e+00 0
> 1 2.3914541e+03 4.48e+01 2.58e+05 -1.0 6.23e+01 -
> 2.96e-05 2.61e-02F 1
> 2 2.3936754e+03 3.08e+02 7.11e+07 -1.0 6.07e+01 -
> 4.74e-01 9.61e-01f 1
> 3 2.3924281e+03 3.08e+02 7.10e+07 -1.0 4.05e+03 -2.0 1.11e-03
> 6.56e-04f 1
> 4 2.3924033e+03 3.08e+02 7.10e+07 -1.0 1.40e+03 -1.6 5.44e-03
> 3.68e-05f 1
> 5 2.3920925e+03 3.08e+02 7.10e+07 -1.0 3.06e+03 -2.1 2.68e-03
> 3.03e-04f 1
> 6 2.3918892e+03 3.08e+02 7.10e+07 -1.0 1.07e+04 -
> 6.52e-04 1.30e-04f 1
> 7 2.3915687e+03 3.07e+02 7.09e+07 -1.0 1.11e+03 -
> 5.12e-03 7.38e-04f 1
> 8 2.3908132e+03 3.07e+02 7.08e+07 -1.0 1.13e+03 -
> 1.08e-02 2.08e-03f 1
> 9 2.3907401e+03 3.07e+02 9.31e+09 -1.0 7.76e+02 -
> 2.79e-02 1.84e-04f 1
> iter objective inf_pr inf_du lg(mu) ||d|| lg(rg) alpha_du
> alpha_pr ls
> 10 2.3892870e+03 3.05e+02 1.62e+10 -1.0 5.84e+02 -
> 2.56e-02 6.94e-03f 1
> 11 2.3894049e+03 3.04e+02 3.09e+10 -1.0 4.25e+02 -
> 4.15e-02 1.21e-03f 1
> 12 2.3960908e+03 2.88e+02 3.92e+10 -1.0 3.76e+02 -
> 8.17e-02 5.33e-02f 1
> 13 2.4009546e+03 2.78e+02 2.85e+10 -1.0 3.05e+02 -
> 3.87e-03 3.45e-02f 1
> 14 2.4012483e+03 2.77e+02 3.19e+10 -1.0 2.93e+02 -
> 1.40e-02 2.36e-03f 1
> 15 2.4038152e+03 2.72e+02 3.44e+10 -1.0 2.93e+02 -
> 3.19e-02 2.10e-02f 1
> 16 2.4038403e+03 2.72e+02 4.23e+10 -1.0 2.86e+02 -
> 2.55e-02 2.15e-04h 1
> 17 2.4036648e+03 2.71e+02 4.17e+10 -1.0 4.57e+03 -
> 3.36e-06 3.15e-04f 1
> 18 2.4069581e+03 2.67e+02 3.57e+10 -1.0 2.89e+02 -
> 2.86e-04 1.71e-02f 1
> 19 2.4069888e+03 2.67e+02 6.39e+10 -1.0 2.83e+02 -
> 2.26e-02 1.75e-04h 1
> iter objective inf_pr inf_du lg(mu) ||d|| lg(rg) alpha_du
> alpha_pr ls
> 20 2.4068113e+03 2.67e+02 6.38e+10 -1.0 3.88e+04 -
> 1.85e-06 2.86e-05h 1
> 21 2.4067828e+03 2.67e+02 4.51e+10 -1.0 4.20e+03 -
> 3.96e-06 7.14e-05h 1
> MUMPS returned INFO(1) = -9 and requires more memory,
> reallocating. Attempt 1
> Increasing icntl[13] from 80 to 160.
> MUMPS returned INFO(1) = -9 and requires more memory,
> reallocating. Attempt 1
> Increasing icntl[13] from 160 to 320.
> MUMPS returned INFO(1) = -9 and requires more memory,
> reallocating. Attempt 2
> Increasing icntl[13] from 320 to 640.
> MUMPS returned INFO(1) = -9 and requires more memory,
> reallocating. Attempt 3
> Increasing icntl[13] from 640 to 1280.
> MUMPS returned INFO(1) = -9 and requires more memory,
> reallocating. Attempt 4
> Increasing icntl[13] from 1280 to 2560.
> 22 2.4067829e+03 2.67e+02 4.51e+10 -1.0 5.70e+00 5.8 2.39e-05
> 1.79e-05h 1
> MUMPS returned INFO(1) = -9 and requires more memory,
> reallocating. Attempt 1
> Increasing icntl[13] from 2560 to 5120.
> MUMPS returned INFO(1) = -9 and requires more memory,
> reallocating. Attempt 2
> Increasing icntl[13] from 5120 to 10240.
> MUMPS returned INFO(1) = -9 and requires more memory,
> reallocating. Attempt 3
> Increasing icntl[13] from 10240 to 20480.
> Problem with integer stack size 1 1 6
>
> signal (11): Segmentation Fault
>
> ```
>
>
> _______________________________________________
> Ipopt mailing list
> Ipopt at list.coin-or.org <mailto:Ipopt at list.coin-or.org>
> https://list.coin-or.org/mailman/listinfo/ipopt
>
>
> _______________________________________________
> Ipopt mailing list
> Ipopt at list.coin-or.org
> https://list.coin-or.org/mailman/listinfo/ipopt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/ipopt/attachments/20200123/5b58b80e/attachment-0001.html>
More information about the Ipopt
mailing list