Разница между счетчиком порезов Gurobi Lazy и собственным счетчиком - PullRequest
Новая
       17

Разница между счетчиком порезов Gurobi Lazy и собственным счетчиком

0 голосов
/ 21 апреля 2019

Я реализую B & C и использую счетчик, который суммирует 1 после каждого добавления Lazy Constraint. После решения есть большая разница между тем, что я считаю, и тем, что Gurobi извлекает как ограничения Lazy. Что может быть причиной этой разницы?

Спасибо. 

Changed value of parameter LazyConstraints to 1
   Prev: 0  Min: 0  Max: 1  Default: 0
Optimize a model with 67 rows, 442 columns and 1154 nonzeros
Variable types: 22 continuous, 420 integer (420 binary)
Coefficient statistics:
  Matrix range     [1e+00, 1e+00]
  Objective range  [1e-01, 5e+00]
  Bounds range     [1e+00, 1e+00]
  RHS range        [1e+00, 1e+01]
Presolve removed 8 rows and 42 columns
Presolve time: 0.00s
Presolved: 59 rows, 400 columns, 990 nonzeros
Variable types: 1 continuous, 399 integer (399 binary)

Root relaxation: objective 2.746441e+00, 37 iterations, 0.00 seconds

    Nodes    |    Current Node    |     Objective Bounds      |     Work
 Expl Unexpl |  Obj  Depth IntInf | Incumbent    BestBd   Gap | It/Node Time

     0     0    4.18093    0   20          -    4.18093      -     -    0s
H    0     0                      21.2155889    4.18093  80.3%     -    0s
     0     0    5.91551    0   31   21.21559    5.91551  72.1%     -    0s
H    0     0                      18.8660609    5.91551  68.6%     -    0s
     0     0    6.35067    0   38   18.86606    6.35067  66.3%     -    0s
H    0     0                      17.9145774    6.35067  64.6%     -    0s
     0     0    6.85254    0   32   17.91458    6.85254  61.7%     -    0s
H    0     0                      17.7591641    6.85254  61.4%     -    0s
     0     0    7.20280    0   50   17.75916    7.20280  59.4%     -    0s
H    0     0                      17.7516768    7.20280  59.4%     -    0s
     0     2    7.91616    0   51   17.75168    7.91616  55.4%     -    0s
*   80    62              30      17.6301180    8.69940  50.7%  10.7    0s
*  169   138              35      16.3820478    9.10423  44.4%   9.9    1s
*  765   486              22      14.6853796    9.65509  34.3%   9.2    2s
* 1315   762              27      14.6428113    9.97011  31.9%   9.4    3s
* 1324   415              14      12.0742408    9.97011  17.4%   9.4    3s
H 1451   459                      11.8261154   10.02607  15.2%   9.7    4s
  1458   463   11.78416   15   58   11.82612   10.02607  15.2%   9.6    5s
* 1567   461              33      11.6541357   10.02607  14.0%  10.6    6s
  4055   906   11.15860   31   36   11.65414   10.69095  8.26%  12.4   10s

Cutting planes:
  Gomory: 4
  Flow cover: 1
  Lazy constraints: 228

Explored 7974 nodes (98957 simplex iterations) in 14.78 seconds
Thread count was 4 (of 4 available processors)

Solution count 10: 11.6541 11.8261 12.0742 ... 17.9146

Optimal solution found (tolerance 1.00e-04)
Best objective 1.165413573861e+01, best bound 1.165413573861e+01, gap 0.0000%


My Lazy constraints counter: 654

1 Ответ

1 голос
/ 22 апреля 2019

Отображаемая статистика по плоскостям резания после того, как оптимизация завершилась (или остановилась), показывает только количество плоскостей резания, которые были активны в окончательном разрешении LP, которое было решено.В частности, число ленивых ограничений, которые активны для этого последнего узла, может быть меньше, чем общее количество ленивых ограничений, которые были добавлены в обратном вызове.Например, Gurobi может добавить внутренние плоскости резания во время оптимизации, которые доминируют в исходном ленивом ограничении, или использовать ленивое ограничение из обратного вызова для получения других срезов вместо добавления исходного.

...