node time keeps increasing
AnsweredIn my optimization, the node time keeps increasing and the optimization is not coming to an end.
But from the log i can see the barrier method already solved something ? Can I speed it up somehow ? I already use a 64 threads machine.
Here is the log:
Barrier statistics:
AA' NZ : 5.367e+06
Factor NZ : 2.275e+07 (roughly 1.7 GB of memory)
Factor Ops : 6.821e+08 (less than 1 second per iteration)
Threads : 62
Objective Residual
Iter Primal Dual Primal Dual Compl Time
0 4.21024724e+13 -4.96398323e+14 5.88e+05 1.87e+05 4.57e+08 79s
1 1.54226798e+13 -2.54923639e+14 7.09e+04 1.83e+05 8.68e+07 81s
2 9.74368602e+12 -5.97457357e+13 3.16e+04 1.27e+04 2.20e+07 83s
3 1.84787900e+12 -1.00479217e+13 9.62e+02 1.40e-09 2.45e+06 85s
4 6.57421666e+11 -3.43381239e+12 2.03e+02 9.31e-10 8.13e+05 86s
5 9.26674180e+10 -1.82295018e+12 9.34e+01 9.31e-10 3.78e+05 87s
6 5.06379548e+10 -1.25991090e+12 5.09e+01 9.31e-10 2.57e+05 88s
7 2.62566769e+10 -7.86822263e+11 2.70e+01 1.05e-09 1.59e+05 89s
8 1.34076262e+10 -3.74265398e+11 1.36e+01 1.28e-09 7.59e+04 90s
9 1.73676744e+09 -4.69404330e+10 1.05e+00 1.63e-09 9.49e+03 91s
10 2.27455779e+07 -1.39269991e+09 2.66e-03 1.98e-09 2.75e+02 93s
11 8.63071359e+06 -7.52507912e+08 1.74e-05 1.40e-09 1.48e+02 94s
12 6.73026750e+06 -7.36297864e+08 2.49e-06 1.40e-09 1.44e+02 95s
13 2.77953716e+06 -4.68343067e+08 9.09e-10 1.40e-09 9.16e+01 96s
14 6.25962378e+05 -4.18577024e+08 3.08e-10 1.40e-09 8.15e+01 97s
15 -1.41607381e+05 -6.55550949e+07 9.69e-11 8.15e-10 1.27e+01 98s
16 -4.90327326e+05 -9.14557035e+06 4.48e-11 6.98e-10 1.68e+00 100s
17 -8.86679411e+05 -5.57138818e+06 2.10e-11 4.66e-10 9.11e-01 101s
18 -9.17952543e+05 -3.22082121e+06 1.93e-11 4.66e-10 4.48e-01 102s
19 -1.18936436e+06 -2.43749265e+06 9.23e-12 4.66e-10 2.43e-01 103s
20 -1.28187533e+06 -1.89102781e+06 1.24e-11 4.66e-10 1.18e-01 105s
21 -1.32150442e+06 -1.72890452e+06 1.18e-11 4.66e-10 7.92e-02 106s
22 -1.35110384e+06 -1.61973098e+06 2.83e-11 4.66e-10 5.22e-02 107s
23 -1.37436725e+06 -1.56444482e+06 2.98e-11 4.66e-10 3.69e-02 108s
24 -1.38572180e+06 -1.52571120e+06 1.04e-11 4.66e-10 2.72e-02 109s
25 -1.40133866e+06 -1.49346389e+06 1.52e-11 4.66e-10 1.79e-02 110s
26 -1.40812676e+06 -1.47757851e+06 1.45e-11 4.66e-10 1.35e-02 111s
27 -1.41432450e+06 -1.46512732e+06 3.03e-11 4.66e-10 9.87e-03 112s
28 -1.41879235e+06 -1.45628263e+06 4.24e-11 4.66e-10 7.29e-03 114s
29 -1.42261605e+06 -1.44710872e+06 4.13e-11 4.66e-10 4.76e-03 116s
30 -1.42450623e+06 -1.44035980e+06 3.39e-11 4.66e-10 3.08e-03 118s
31 -1.42535535e+06 -1.43502345e+06 4.05e-11 4.66e-10 1.88e-03 120s
32 -1.42604436e+06 -1.43389905e+06 6.51e-11 4.66e-10 1.53e-03 121s
33 -1.42625157e+06 -1.43300402e+06 7.31e-11 4.66e-10 1.31e-03 122s
34 -1.42653105e+06 -1.43192995e+06 4.92e-11 4.66e-10 1.05e-03 123s
35 -1.42673427e+06 -1.43053467e+06 2.63e-11 4.66e-10 7.39e-04 125s
36 -1.42700248e+06 -1.42991342e+06 4.98e-11 4.66e-10 5.66e-04 126s
Barrier solved model in 36 iterations and 126.13 seconds (82.38 work units)
Optimal objective -1.42700248e+06
Root crossover log...
208952 DPushes remaining with DInf 0.0000000e+00 128s
18358 DPushes remaining with DInf 0.0000000e+00 130s
0 DPushes remaining with DInf 0.0000000e+00 134s
1200431 PPushes remaining with PInf 0.0000000e+00 134s
714778 PPushes remaining with PInf 3.0886203e-01 136s
413615 PPushes remaining with PInf 5.0088740e-01 140s
296940 PPushes remaining with PInf 6.5721545e+00 145s
234653 PPushes remaining with PInf 1.8320119e+01 150s
187366 PPushes remaining with PInf 1.8157526e+01 155s
144426 PPushes remaining with PInf 1.9441613e+01 161s
112977 PPushes remaining with PInf 1.8668530e+01 165s
86548 PPushes remaining with PInf 1.7963693e+01 170s
66059 PPushes remaining with PInf 1.6281714e+01 175s
50732 PPushes remaining with PInf 6.5300781e+00 181s
7683 PPushes remaining with PInf 2.5140900e+00 190s
0 PPushes remaining with PInf 2.4984344e+00 191s
Push phase complete: Pinf 2.4984344e+00, Dinf 1.8864951e+06 192s
Root simplex log...
Iteration Objective Primal Inf. Dual Inf. Time
1368849 -1.4276164e+06 0.000000e+00 1.886495e+06 192s
1386504 -1.4276368e+06 0.000000e+00 1.218026e+05 196s
1400841 -1.4276454e+06 0.000000e+00 1.326249e+04 201s
1414842 -1.4276561e+06 0.000000e+00 1.533749e+03 209s
1424530 -1.4276592e+06 0.000000e+00 2.867505e+02 214s
1433795 -1.4276605e+06 0.000000e+00 8.606017e+00 219s
1441470 -1.4276612e+06 0.000000e+00 1.546383e+01 222s
1444616 -1.4276612e+06 0.000000e+00 1.411462e+01 225s
1456880 -1.4276612e+06 0.000000e+00 5.044502e-02 231s
1457284 -1.4276612e+06 0.000000e+00 0.000000e+00 233s
Concurrent spin time: 35.45s (can be avoided by choosing Method=3)
Solved with barrier
1457284 -1.4276612e+06 0.000000e+00 1.257648e+04 236s
1490572 -1.4276612e+06 0.000000e+00 0.000000e+00 240s
Extra simplex iterations after uncrush: 33288
Root relaxation: objective -1.427661e+06, 1490572 iterations, 174.97 seconds (125.25 work units)
Nodes | Current Node | Objective Bounds | Work
Expl Unexpl | Obj Depth IntInf | Incumbent BestBd Gap | It/Node Time
0 0 -1427661.2 0 201847 4.6494e+12 -1427661.2 100% - 359s
H 0 0 2.803203e+11 -1427661.2 100% - 372s
H 0 0 2.670130e+11 -1427661.2 100% - 539s
0 0 -1273323.5 0 190014 2.6701e+11 -1273323.5 100% - 680s
0 0 -1273323.5 0 189893 2.6701e+11 -1273323.5 100% - 684s
H 0 0 2.120251e+11 -1273323.5 100% - 708s
0 0 -1164363.3 0 192827 2.1203e+11 -1164363.3 100% - 947s
0 0 -1164363.3 0 192734 2.1203e+11 -1164363.3 100% - 951s
0 0 -1120486.6 0 212653 2.1203e+11 -1120486.6 100% - 1057s
0 0 -1120486.6 0 212604 2.1203e+11 -1120486.6 100% - 1064s
0 0 -1105919.4 0 226613 2.1203e+11 -1105919.4 100% - 1159s
0 0 -1105919.4 0 226581 2.1203e+11 -1105919.4 100% - 1164s
0 0 -1105616.9 0 245745 2.1203e+11 -1105616.9 100% - 1243s
0 0 -1105616.9 0 245733 2.1203e+11 -1105616.9 100% - 1254s
0 0 -1105589.8 0 246090 2.1203e+11 -1105589.8 100% - 1387s
0 0 -1105589.8 0 246057 2.1203e+11 -1105589.8 100% - 1398s
0 0 -1105588.9 0 246308 2.1203e+11 -1105588.9 100% - 1598s
0 0 -906500.33 0 242945 2.1203e+11 -906500.33 100% - 2214s
0 0 -906500.33 0 242424 2.1203e+11 -906500.33 100% - 2224s
H 0 0 1.393729e+11 -906500.33 100% - 2251s
H 0 0 1.233154e+11 -906500.33 100% - 2262s
0 0 -810384.35 0 242292 1.2332e+11 -810384.35 100% - 2696s
0 0 -764989.95 0 245103 1.2332e+11 -764989.95 100% - 3144s
0 0 -764989.95 0 245089 1.2332e+11 -764989.95 100% - 3180s
-
But from the log i can see the barrier method already solved something ?
What you see is the solution of the root node relaxation which usually only takes a fraction of the actual B&B algorithm.
Can I speed it up somehow ?
You could try experimenting with the Most important parameters for MIPs. In particular, you might want to experiment with the NoRelHeurTime parameter.
Could you please share the first log lines as well? From the objective values, it looks like your model have have some numerical issues. Please have a look at our Guidelines for Numerical Issues.
0 -
thank you for answering,
Here are the first log lines:##############################################################
##################### solving ################################
no of Eqs (single):113 (1124427)
no of InEqs (single):57 (1862208)
no of Vars (single):175 (2916382)
Solver script file: 'C:\Users\ADMINI~1\AppData\Local\Temp\2\tmptfg8l1mv.gurobi.script'
Solver log file: 'C:\Users\Administrator\Downloads\V1_geclustert(5)\V1_geclustert\results\2023-05-27_fullModel_solver.log'
Solver solution file: 'C:\Users\ADMINI~1\AppData\Local\Temp\2\tmp47c9u4g2.gurobi.txt'
Solver problem files: ('C:\\Users\\ADMINI~1\\AppData\\Local\\Temp\\2\\tmponjs38v3.pyomo.lp',)
Set parameter Username
Academic license - for non-commercial use only - expires 2023-11-17
Read LP format model from file C:\Users\ADMINI~1\AppData\Local\Temp\2\tmponjs38v3.pyomo.lp
Reading time = 10.93 seconds
x2916383: 2986636 rows, 2775820 columns, 10048902 nonzeros
Set parameter Threads to value 16
Set parameter MIPGap to value 0.1
Set parameter TimeLimit to value 86400
Gurobi Optimizer version 10.0.0 build v10.0.0rc2 (win64)
CPU model: AMD EPYC 7513 32-Core Processor, instruction set [SSE2|AVX|AVX2]
Thread count: 8 physical cores, 8 logical processors, using up to 16 threads
Warning: Thread count (16) is larger than processor count (8)
Reduce the value of the Threads parameter to improve performance
Optimize a model with 2986636 rows, 2775820 columns and 10048902 nonzeros
Model fingerprint: 0xb07529cf
Variable types: 2108236 continuous, 667584 integer (667584 binary)
Coefficient statistics:
Matrix range [3e-06, 3e+04]
Objective range [1e+00, 1e+00]
Bounds range [1e+00, 1e+10]
RHS range [1e-01, 4e+07]
Warning: Model contains large bounds
Consider reformulating model or setting NumericFocus parameter
to avoid numerical issues.
Presolve removed 1327984 rows and 1250447 columns (presolve time = 5s) ...
Presolve removed 1368188 rows and 1297915 columns (presolve time = 10s) ...
Presolve removed 1368188 rows and 1297915 columns (presolve time = 15s) ...
Presolve removed 1368188 rows and 1297915 columns
Presolve time: 15.80s
Presolved: 1618448 rows, 1477905 columns, 4367791 nonzeros
Variable types: 880593 continuous, 597312 integer (597312 binary)
Found heuristic solution: objective 4.649413e+12
Deterministic concurrent LP optimizer: primal simplex, dual simplex, and barrier
Showing barrier log only...
Root barrier log...
Ordering time: 0.12s
Barrier statistics:
AA' NZ : 1.713e+06
Factor NZ : 1.419e+07 (roughly 500 MB of memory)
Factor Ops : 7.818e+08 (less than 1 second per iteration)
Threads : 140 -
Thank you for the log snippet.
You can see 2 quite serious warnings.
Warning: Thread count (16) is larger than processor count (8) Reduce the value of the Threads parameter to improve performance
This warning means that you force Gurobi to use more threads than you have logical processors. This almost always has a negative effect on the performance because then multiple threads have to share one logical processors. Here, it is recommended to set Threads=8 or just leave it at its default value and let Gurobi decide.
Warning: Model contains large bounds Consider reformulating model or setting NumericFocus parameter to avoid numerical issues.
This is another quite serious warning. Given the large objective values encountered along the solution path and the wide coefficient and bound ranges, it is very likely that your model may run into numerical trouble. Please have a look at our Guidelines for Numerical Issues and try to re-scale your model if possible.
Maybe a stronger formulation of your model is possible, see Tech Talk - Converting Weak to Strong MIP Formulations.
Additionally, you should have a look at the Most important parameters for MIPs. In particular, the NoRelHeurTime and MIPFocus parameters.
If possible, you could try providing a MIP start.
Best regards,
Jaromił0
Please sign in to leave a comment.
Comments
3 comments