Process finished with exit code 137 (interrupted by signal 9: SIGKILL)
Answered
Hi!
Does anyone know why the solver is stopped followed by this message? Can this happen if the computer does not have enough memory?
-
Official comment
This post is more than three years old. Some information may not be up to date. For current information, please check the Gurobi Documentation or Knowledge Base. If you need more help, please create a new post in the community forum. Or why not try our AI Gurobot?. -
Yes, being out of memory could cause this:
https://stackoverflow.com/questions/43268156/process-finished-with-exit-code-137-in-pycharm
0 -
Do you know if I can see how far the solver came and how much that was left? Can I calculate the total amount of nodes or figure out the time the solver would use in any other way?
Below is a log of the current run, but the previous run stopped at about 6 000 000 nodes explored and 5 000 000 nodes unexplored:
/Users/sebastianeriklokenrindvoll/PycharmProjects/OptimizeFSM/venv/bin/python /Users/sebastianeriklokenrindvoll/PycharmProjects/OptimizeFSM/venv/GurobiModel.py
Using license file /Users/sebastianeriklokenrindvoll/gurobi.lic
Academic license - for non-commercial use only
Changed value of parameter MIPGap to 0.01
Prev: 0.0001 Min: 0.0 Max: inf Default: 0.0001
Gurobi Optimizer version 9.0.2 build v9.0.2rc0 (mac64)
Optimize a model with 32396 rows, 27416 columns and 303045 nonzeros
Model fingerprint: 0x0e0a9d8b
Variable types: 776 continuous, 26640 integer (0 binary)
Coefficient statistics:
Matrix range [1e+00, 1e+04]
Objective range [7e-02, 1e+03]
Bounds range [1e+00, 1e+03]
RHS range [1e+00, 5e+02]
Presolve removed 5074 rows and 1245 columns
Presolve time: 0.36s
Presolved: 27322 rows, 26171 columns, 147710 nonzeros
Variable types: 771 continuous, 25400 integer (25400 binary)
Deterministic concurrent LP optimizer: primal and dual simplex
Showing first log only...
Concurrent spin time: 0.00s
Solved with primal simplex
Root relaxation: objective 5.399574e+04, 4766 iterations, 0.25 seconds
Nodes | Current Node | Objective Bounds | Work
Expl Unexpl | Obj Depth IntInf | Incumbent BestBd Gap | It/Node Time
0 0 53995.7371 0 228 - 53995.7371 - - 12s
0 0 53995.7371 0 140 - 53995.7371 - - 17s
0 0 53995.7371 0 146 - 53995.7371 - - 28s
0 0 53995.7371 0 216 - 53995.7371 - - 30s
0 0 53995.7371 0 199 - 53995.7371 - - 30s
0 0 53995.7371 0 122 - 53995.7371 - - 35s
0 0 53995.7371 0 117 - 53995.7371 - - 35s
0 0 53995.7371 0 129 - 53995.7371 - - 42s
0 0 53995.7371 0 140 - 53995.7371 - - 43s
0 0 53995.7371 0 149 - 53995.7371 - - 48s
0 0 53995.7371 0 145 - 53995.7371 - - 50s
0 0 53995.7371 0 145 - 53995.7371 - - 54s
0 0 53995.7371 0 128 - 53995.7371 - - 54s
0 0 54017.3760 0 124 - 54017.3760 - - 61s
0 0 54020.0426 0 112 - 54020.0426 - - 63s
0 0 54020.0426 0 119 - 54020.0426 - - 63s
0 0 54153.3760 0 122 - 54153.3760 - - 64s
0 0 54153.3760 0 107 - 54153.3760 - - 65s
0 0 54153.3760 0 130 - 54153.3760 - - 66s
0 0 54153.3760 0 126 - 54153.3760 - - 66s
0 0 54153.3760 0 134 - 54153.3760 - - 68s
0 0 54153.3760 0 148 - 54153.3760 - - 69s
0 0 54153.3760 0 95 - 54153.3760 - - 73s
0 0 54153.3760 0 141 - 54153.3760 - - 78s
0 0 54153.3760 0 103 - 54153.3760 - - 81s
0 0 54153.3760 0 103 - 54153.3760 - - 82s
0 2 54153.3760 0 103 - 54153.3760 - - 90s
3 6 54153.3760 2 116 - 54153.3760 - 1863 95s
27 25 54453.9315 7 177 - 54153.3760 - 613 102s
54 46 54611.5704 12 141 - 54153.3760 - 502 105s
141 91 55590.9969 32 131 - 54153.3760 - 307 110s
209 136 55819.0541 47 148 - 54153.3760 - 265 115s
322 213 57092.1997 70 150 - 54153.3760 - 222 120s
407 255 57172.1997 81 154 - 54153.3760 - 197 126s
490 291 61675.7947 97 169 - 54153.3760 - 188 130s
630 396 62527.9285 122 171 - 54153.3760 - 172 135s
742 437 63127.9572 149 168 - 54153.3760 - 158 141s
817 487 65864.9833 186 163 - 54153.3760 - 154 145s
964 586 88252.2088 216 124 - 54153.3760 - 155 154s
997 652 88252.2088 224 124 - 54153.3760 - 160 156s
1083 653 88380.2802 222 140 - 54153.3760 - 156 169s
1084 654 54611.4811 15 140 - 54153.3760 - 156 170s
1086 655 55439.2945 26 215 - 54153.3760 - 156 175s
1089 657 55408.4357 16 128 - 54153.3760 - 155 191s
1093 660 58093.5428 84 131 - 54153.3760 - 155 199s
1095 661 58632.1622 67 114 - 54153.3760 - 154 205s
1097 662 55120.3538 12 112 - 54153.3760 - 154 214s
1099 664 55408.4357 16 111 - 54153.3760 - 154 218s
1101 665 56707.9868 72 111 - 54153.3760 - 153 226s
1105 668 54653.5191 15 104 - 54153.3760 - 153 240s
1107 669 56870.5527 78 104 - 54153.3760 - 153 264s
1108 673 54153.3760 13 103 - 54153.3760 - 424 268s
1110 674 54153.3760 14 99 - 54153.3760 - 424 270s
1126 677 54345.3760 16 109 - 54153.3760 - 421 275s
1166 698 54443.8859 21 157 - 54337.7315 - 416 280s
1223 718 54779.0031 26 142 - 54337.7315 - 406 287s
1246 732 55130.1718 29 140 - 54337.7315 - 403 290s
1287 743 55192.2273 34 130 - 54337.7315 - 394 295s
1325 756 55292.7098 39 139 - 54337.7315 - 388 300s
1508 799 56041.5846 54 132 - 54337.7315 - 356 305s
1790 843 57995.1261 81 103 - 54337.7315 - 309 310s
2001 959 54691.5704 34 90 - 54361.3760 - 290 315s
2295 1048 55836.7492 37 119 - 54453.9315 - 265 320s
2684 1278 54847.2605 56 102 - 54460.2894 - 240 326s
2984 1387 56471.5154 140 105 - 54460.2894 - 224 330s
...
278944 237642 55198.7428 79 130 - 54650.4593 - 122 3722s
279228 237962 56087.4988 190 117 - 54650.4593 - 122 3729s
279567 238534 55591.2926 95 116 - 54650.4593 - 122 3734s
280203 238890 54672.6815 45 145 - 54650.4593 - 122 3740s
280593 239426 55181.4649 98 128 - 54650.4593 - 122 3748s
281179 240161 55240.3538 64 119 - 54650.4593 - 122 3755s
282050 240734 58959.3693 202 121 - 54650.4593 - 122 3761s0 -
Hi Sebastian,
I just shortened the log output in your previous post for better readability.
On topic: Tree size estimation is still an open question and people are actively researching in this area. You might find this article interesting: http://www.optimization-online.org/DB_HTML/2020/04/7722.html
Cheers,
Matthias0 -
Thank you Matthias! :)
0 -
Hi again Matthias Miltenberger!
Do you know if a more aggressive Presolve and Cuts will certainly make the process faster for such a tough MIP problem?
0 -
Hi Sebastian,
I would recommend you just try a few different parameters to see how they perform. It's almost impossible to give a parameter suggestion that makes the optimization "certainly faster". You should also check out this part in our documentation about how to read MIP log files.
Cheers,
Matthias0 -
Thank you! :)
But it is difficult to test for my model since when I increase one of the parameters in my model from 3 to 4 it goes from 30 seconds to over 20 000 seconds. And if I have understood your documentation right it seems like something that works for my model when I set the parameter in my model equal to 3 does not have to be the right parameter tuning when I set the parameter in my model to 4.
0
Post is closed for comments.
Comments
8 comments