Please help me with out of memory
ユーザーの入力を待っています。I am currently trying to model a big MV distribution network (180 buses). I am using Pyomo to build the model. The model runs when I project 20 scenarios, but when I up them to 40 scenarios for example it just says "ApplicationError: Solver (gurobi) did not exit normally"
gurobipy.GurobiError: Out of memory
ERROR: Solver (gurobi) returned non-zero return code (1)
ERROR: See the solver log above for diagnostic information.
This happens very early on.
I've tried various values for Threads (1,2,4...). Is there ANY way to make sure that the model is solved, regardless of losing some precision in results or it taking more time? At this point I'm desperate and just want it to work... I know the problem is very large... This is the information for the 40 scenarios ( Reading time = 47.63 seconds
x2813798: 5823001 rows, 2813795 columns, 103742919 nonzeros )
I'm not too sure what to do...
-
-
Gurobi Staff
Hi Fabio,
You may find our knowledge base article on how to avoid an out-of-memory condition useful:
How do I avoid an out-of-memory condition?It may also be helpful to set the SoftMemLimit parameter in your case. The SoftMemLimit parameter leads to a graceful exit of the optimization, and it is possible to retrieve solution information even if the solver has terminated with an out-of-memory condition.
Best regards,
Simran0 -
-
Hi Simranjit, thank you for the idea.
I'd wanna ask if maybe it is an issue with the license im using? I have an academic license. Is it an issue with a limitation there? Because it seems that the solver can not read the lp file if it ends up being above 2GB in size.
When it is for example 1.8GB it works. This might also be an issue with the pyomo building the model, so I apologize if I am asking for something you can't help me with.
Thanks a lot for the support.0 -
-
-
Hi Fabio,
With Gurobi academic licenses you get all features and performance of the Gurobi Optimizer. There are no limits on model size. Reading a 2GB LP file should not be an issue unless you have limited memory available on your machine. Do you get an error message when you read the larger lp file?
Best regards,
Simran0 -
-
Hello. I get an error ERROR: Solver (gurobi) returned non-zero return code (1)
ERROR: Solver (gurobi) did not exit normally.
Something seems to be inconsistent though... Because it eventaully did solve the problem this size ( ( Reading time = 47.63 seconds x2813798: 5823001 rows, 2813795 columns, 103742919 nonzeros )), but after changing some values, went for another run, and it did not solve... Am I somehow limiting my machine in any way? It has 16GB of RAM.0 -
-
-
Hi Fabio,
Thanks for sharing more information.
Since you get the out-of-memory error while trying to read a lp file larger than 2GB, I wonder if you are using a 32-bit Windows OS or you are using 32-bit Python on a 64-bit Windows OS. According to Memory Limits for Windows Releases at MSDN, there is a default limit of 2GB for every process on a 32-bit Windows system and every 32-bit process on a 64-bit Windows system. If this applies to you, can you please try using 64-bit Python on a 64-bit Windows OS and see if it resolves the memory issue?
Best regards,
Simran0 -
-
Hello!
This is what is shown on the kernel when I open the IDE i'm using (Spyder through Anaconda)
Python 3.9.13 (main, Aug 25 2022, 23:51:50) [MSC v.1916 64 bit (AMD64)]
Type "copyright", "credits" or "license" for more information.
I'm not too sure if that's even possible, but could it be an issue with the lp file that Pyomo builds being formatted for 32-bit?
Regards,
Fábio0 -
-
-
Hi Fabio,
Ok, so you have a 64-bit Python installed.
To isolate if the memory issue is coming from Pyomo, could you please check if you can read your LP file and solve the model using the Gurobi Command Line interface (gurobi_cl)?
On a Windows, please open a command prompt and run:
> gurobi_cl <path_to_your_lp_file>/model.lp
Please share the Gurobi log of the solve. It will also help to monitor the memory usage via the Windows Resource Monitor to identify exactly when in the solve processs the out-of-memory condition happens.
Best regards,
Simran0 -
-
In the mean time I eventually reduced my attempted scenarios from 40 to 32, resulting in an lp file sized 1.8GB. It is solvable, but not always... The exact same model sometimes solves, and sometime gives the error I stated above... It's not too clear why for me.
It did read the file the way you recommended, and it also solved tremendously faster (Achieving the exact same objective function)... Through the direct communication in Spyder the model took 2529.11sec to solve (8439sec if you count the building part by Pyomo), and through the method you just recommended it took only 147.32sec, which is fantastic, and maybe leads me to believe there is some issue with the solver communicating through my IDE (Tried Spyder and VSCode, same thing).
Only thing is, im not too sure how I can access the specific values of the variables in the model through this way you recommended. Is there any way to store the solutions after solving through the lp file in the command window? Or maybe there are some solver settings that I can define in the code to help emulate this fast solving?I'm not too sure if you meant the entire log, but here it goes:
C:\Users\fabio>gurobi_cl C:\Users\fabio\AppData\Local\Temp/tmpqo238rcm.pyomo.lp
Set parameter Username
Set parameter LogFile to value "gurobi.log"
Academic license - for non-commercial use only - expires 2024-02-22
Using license file C:\Users\fabio\gurobi.lic
Gurobi Optimizer version 10.0.1 build v10.0.1rc0 (win64)
Copyright (c) 2023, Gurobi Optimization, LLC
Read LP format model from file C:\Users\fabio\AppData\Local\Temp/tmpqo238rcm.pyomo.lp
Reading time = 55.97 seconds
x4385222: 8987466 rows, 4385219 columns, 110079271 nonzeros
CPU model: AMD Ryzen 7 5800H with Radeon Graphics, instruction set [SSE2|AVX|AVX2]
Thread count: 8 physical cores, 16 logical processors, using up to 16 threads
Optimize a model with 8987466 rows, 4385219 columns and 110079271 nonzeros
Model fingerprint: 0x2c8af03f
Variable types: 4190465 continuous, 194754 integer (65158 binary)
Coefficient statistics:
Matrix range [1e-05, 7e+03]
Objective range [8e-03, 1e+06]
Bounds range [1e+00, 1e+00]
RHS range [4e-05, 2e+02]
Presolve removed 0 rows and 0 columns (presolve time = 7s) ...
Presolve removed 0 rows and 0 columns (presolve time = 10s) ...
Presolve removed 4343061 rows and 1 columns (presolve time = 20s) ...
Presolve removed 8769343 rows and 1 columns (presolve time = 26s) ...
Presolve removed 8769345 rows and 3 columns (presolve time = 31s) ...
Presolve removed 8769345 rows and 4316989 columns (presolve time = 37s) ...
Presolve removed 8791367 rows and 4316989 columns (presolve time = 42s) ...
Presolve removed 8920844 rows and 4317691 columns (presolve time = 52s) ...
Presolve removed 8929430 rows and 4328894 columns (presolve time = 55s) ...
Presolve removed 8930840 rows and 4330178 columns
Presolve time: 57.45s
Presolved: 56626 rows, 55041 columns, 190598 nonzeros
Variable types: 53288 continuous, 1753 integer (613 binary)
Deterministic concurrent LP optimizer: primal and dual simplex
Showing first log only...
Root simplex log...
Iteration Objective Primal Inf. Dual Inf. Time
0 4.3938595e+06 9.058289e+02 1.209629e+10 73s
Concurrent spin time: 0.01s
Solved with dual simplex
Root simplex log...
Iteration Objective Primal Inf. Dual Inf. Time
34758 8.8950444e+06 0.000000e+00 0.000000e+00 75s
Root relaxation: objective 8.895044e+06, 34758 iterations, 2.33 seconds (1.86 work units)
Total elapsed time = 75.01s
Nodes | Current Node | Objective Bounds | Work
Expl Unexpl | Obj Depth IntInf | Incumbent BestBd Gap | It/Node Time
0 0 8895044.41 0 184 - 8895044.41 - - 75s
0 0 8990000.47 0 334 - 8990000.47 - - 77s
0 0 8991725.46 0 341 - 8991725.46 - - 78s
0 0 8997929.11 0 343 - 8997929.11 - - 78s
0 0 8997929.47 0 336 - 8997929.47 - - 78s
0 0 9123088.35 0 324 - 9123088.35 - - 79s
0 0 9125789.01 0 345 - 9125789.01 - - 80s
0 0 9126464.55 0 351 - 9126464.55 - - 81s
0 0 9126566.64 0 380 - 9126566.64 - - 81s
0 0 9126826.61 0 376 - 9126826.61 - - 81s
0 0 9126915.88 0 376 - 9126915.88 - - 81s
0 0 9126923.61 0 376 - 9126923.61 - - 82s
0 0 9188898.09 0 320 - 9188898.09 - - 84s
0 0 9206875.40 0 431 - 9206875.40 - - 86s
0 0 9207924.23 0 381 - 9207924.23 - - 86s
0 0 9207941.35 0 390 - 9207941.35 - - 86s
H 0 0 1.043263e+07 9207941.35 11.7% - 89s
0 0 9224879.41 0 420 1.0433e+07 9224879.41 11.6% - 89s
H 0 0 1.040148e+07 9238172.78 11.2% - 90s
0 0 9238172.78 0 421 1.0401e+07 9238172.78 11.2% - 90s
0 0 9238696.08 0 374 1.0401e+07 9238696.08 11.2% - 91s
0 0 9238967.79 0 422 1.0401e+07 9238967.79 11.2% - 91s
0 0 9238970.24 0 426 1.0401e+07 9238970.24 11.2% - 92s
0 0 9246195.62 0 268 1.0401e+07 9246195.62 11.1% - 92s
0 0 9247586.62 0 394 1.0401e+07 9247586.62 11.1% - 94s
0 0 9248190.68 0 455 1.0401e+07 9248190.68 11.1% - 94s
0 0 9249446.10 0 389 1.0401e+07 9249446.10 11.1% - 95s
0 0 9249694.13 0 406 1.0401e+07 9249694.13 11.1% - 95s
0 0 9249696.53 0 405 1.0401e+07 9249696.53 11.1% - 96s
0 0 9255079.00 0 224 1.0401e+07 9255079.00 11.0% - 96s
0 0 9255505.26 0 210 1.0401e+07 9255505.26 11.0% - 98s
0 0 9255505.78 0 198 1.0401e+07 9255505.78 11.0% - 98s
0 0 9255787.22 0 288 1.0401e+07 9255787.22 11.0% - 99s
0 0 9255787.22 0 273 1.0401e+07 9255787.22 11.0% - 100s
0 2 9255787.22 0 263 1.0401e+07 9255787.22 11.0% - 104s
1 4 9258337.83 1 264 1.0401e+07 9258337.83 11.0% 3768 105s
15 24 9296015.96 4 272 1.0401e+07 9272561.40 10.9% 2464 110s
39 46 9372353.14 5 272 1.0401e+07 9329587.20 10.3% 2300 115s
78 70 1.0217e+07 8 321 1.0401e+07 9329587.20 10.3% 1823 121s
113 93 1.0244e+07 10 247 1.0401e+07 9329587.20 10.3% 1533 126s
163 121 1.0260e+07 13 222 1.0401e+07 9329587.20 10.3% 1233 130s
H 212 143 1.019374e+07 9329587.20 8.48% 1058 133s
H 220 143 1.017228e+07 9329587.20 8.28% 1039 133s
261 121 cutoff 6 1.0172e+07 9452395.71 7.08% 944 138s
H 266 121 1.016057e+07 9502437.75 6.48% 951 138s
313 48 cutoff 7 1.0161e+07 9548471.96 6.02% 831 141s
417 4 cutoff 11 1.0161e+07 1.0139e+07 0.21% 637 145s
Cutting planes:
Gomory: 4
Cover: 27
Implied bound: 10
MIR: 685
StrongCG: 4
Flow cover: 10746
Flow path: 2162
GUB cover: 35
Zero half: 4
Network: 135
RLT: 2
Relax-and-lift: 1638
Explored 427 nodes (336402 simplex iterations) in 147.32 seconds (129.76 work units)
Thread count was 16 (of 16 available processors)
Solution count 5: 1.01606e+07 1.01723e+07 1.01937e+07 ... 1.04326e+07
Optimal solution found (tolerance 1.00e-04)
Best objective 1.016056699441e+07, best bound 1.016056699441e+07, gap 0.0000%I appreciate your help very much, thanks for the attention.
Best regards,
Fábio0 -
-
-
Hi Fabio,
In the mean time I eventually reduced my attempted scenarios from 40 to 32, resulting in an lp file sized 1.8GB. It is solvable, but not always... The exact same model sometimes solves, and sometime gives the error I stated above... It's not too clear why for me.
Do you see this behaviour when solving your models with gurobi_cl also?
It did read the file the way you recommended, and it also solved tremendously faster (Achieving the exact same objective function)... Through the direct communication in Spyder the model took 2529.11sec to solve (8439sec if you count the building part by Pyomo), and through the method you just recommended it took only 147.32sec, which is fantastic, and maybe leads me to believe there is some issue with the solver communicating through my IDE (Tried Spyder and VSCode, same thing).
I am glad that you were able to solve your model with the Gurobi Command Line interface (gurobi_cl). This also indicates that the memory issue is not related to Gurobi solving the model.
Solving the model with gurobi_cl is indeed significantly faster. It is worth checking if you were using any non-default parameters when solving the model with Pyomo that were impacting the solver's runtime.
Only thing is, im not too sure how I can access the specific values of the variables in the model through this way you recommended. Is there any way to store the solutions after solving through the lp file in the command window?
You can write the final solution using the resultfile parameter
> gurobi_cl resultfile="solution.sol" <path_to_your_lp_file>/model.lp
Alternatively, you can use Gurobi's Python API to solve the model and access the solution as follows:
import gurobipy as gp
# read model and optimize()
m = gp.read("mymodel.lp")
m.opimize()
# write solution in a file
m.write("solution.sol")
# access value of variables in the solution
for v in m.getVars():
print('%s %g' % (v.VarName, v.X))Or maybe there are some solver settings that I can define in the code to help emulate this fast solving?With gurobi_cl <path_to_your_lp_file>/model.lp command, your model is solved with Gurobi's default parameter setting. You can remove any user-defined parameters when solving with Pyomo and check if that improves performance.Best regards,Simran0 -
サインインしてコメントを残してください。
コメント
9件のコメント