Reduce presolve and decision time

[Mikhail]

Dear Robert !. I have a model where the presolve duration is > 1 minute and the gurobi solution is > 15 minutes. In my opinion, the task that I am solving is not so difficult that so much time was spent on it.

Can I send you a model for review in a private way? Can you advise on optimization ways that will help reduce presolve and decision time?

Thank you very much for the high level of support for this forum!

[Mikhail]

I am getting the following output after the Presolve stage:

Presolve eliminates 81 constraints.

Substitution eliminates 252793 variables.

Adjusted problem:

68310 variables:

        6831 binary variables

        61479 linear variables

68873 constraints, all linear; 834219 nonzeros

        68873 inequality constraints

1 linear objective; 68310 nonzeros.

and solver output:

Gurobi 9.1.1: optimal solution; objective 112382499.8

2724099 simplex iterations

23100 branch-and-cut nodes

plus 25723 simplex iterations for intbasis

5 integer variables rounded to integers; maxerr = 4.95005e-07

#                               incremental     total

#phase          seconds         memory          memory

#execute        74.0225         307394376       307394376

However, the duration of the solution by the solver is greatly underestimated relative to the actual duration(>30 minutes).

четверг, 28 января 2021 г. в 21:29:27 UTC+3, Mikhail:

[AMPL Google Group]

The "#execute" line reports time spent by the AMPL language processor in executing the most recent command, but it does not include time spent by the solver. For a non-trivial mixed-integer problem, "display _solve_elapsed_time;" gives the best measure of time that the solver took.

To get more help, there are some simple things that you can do. Before your solve, add the statement

option gurobi_options 'outlev=1';

(or, if you are already setting a gurobi_options string, add outlev=1 to it). Then you will get a detailed log of Gurobi's progress, which will suggest why your problem is difficult. To get more help, you can paste the entire listing into an email back to this forum (or copy the listing into a text file and attach the file).

Gurobi normally runs with a well-chosen set of default parameters for its algorithms. But sometimes other parameter settings are better. You can ask Gurobi to try to choose good parameters for your problem, by specifying

option gurobi_options 'tunebase=test outlev=1';

Then at the end of the run you will see a message like

Wrote 3 tuning parameter files "test1.prm" ... "test3.prm".

and you can check those files for suggestions of parameter combinations to use. For a problem that takes > 30 minutes to solve, the tuning run is likely to take many hours, but it may be worth trying once. (If you need help interpreting the .prm files, you can also post those here.)

--
Robert Fourer
am...@googlegroups.com

{#HS:1409410727-99358#}

On Fri, Jan 29, 2021 at 5:21 AM UTC, AMPL Modeling Language <am...@googlegroups.com> wrote:

I am getting the following output after the Presolve stage:
Presolve eliminates 81 constraints.
Substitution eliminates 252793 variables.
Adjusted problem:
68310 variables:
6831 binary variables
61479 linear variables
68873 constraints, all linear; 834219 nonzeros
68873 inequality constraints
1 linear objective; 68310 nonzeros.

and solver output:
Gurobi 9.1.1: optimal solution; objective 112382499.8
2724099 simplex iterations
23100 branch-and-cut nodes
plus 25723 simplex iterations for intbasis
5 integer variables rounded to integers; maxerr = 4.95005e-07
# incremental total
#phase seconds memory memory

#execute *74.0225* 307394376 307394376

However, the duration of the solution by the solver is greatly
underestimated relative to the actual duration(>30 minutes).

четверг, 28 января 2021 г. в 21:29:27 UTC+3, Mikhail:

[Mikhail]

ampl: model "1.71_1 copy.mod";

#                               incremental     total

#phase          seconds         memory          memory

#execute        0.0156001    115872          115872

#compile        0                     8280              124152

#genmod        0.296402      59222624     59346776

#merge           0                     4194312        63541088

#collect           0.109201      98373936      161915024

#presolve       0.624004       89969224       251884248

#solveout       68.4376         34232336       286116584

Presolve eliminates 81 constraints.

Substitution eliminates 252820 variables.

Adjusted problem:

68310 variables:

        6831 binary variables

        61479 linear variables

68873 constraints, all linear; 834219 nonzeros

        68873 inequality constraints

1 linear objective; 68310 nonzeros.

#presolve       0.0312002       0               286116584

#output         0.312002        0               286116584

#Total          69.826

Gurobi 9.1.1: outlev=1

Gurobi Optimizer version 9.1.1 build v9.1.1rc0 (win64)

Thread count: 2 physical cores, 4 logical processors, using up to 4 threads

Optimize a model with 68873 rows, 68310 columns and 834219 nonzeros

Model fingerprint: 0x5a827d76

Variable types: 61479 continuous, 6831 integer (6831 binary)

Coefficient statistics:

  Matrix range     [1e+00, 1e+04]

  Objective range  [1e+02, 9e+06]

  Bounds range     [1e+00, 1e+00]

  RHS range        [1e+00, 5e+04]

Found heuristic solution: objective 1.766425e+08

Presolve removed 6723 rows and 0 columns (presolve time = 5s) ...

Presolve removed 6723 rows and 0 columns

Presolve time: 8.18s

Presolved: 62150 rows, 68310 columns, 390731 nonzeros

Variable types: 61479 continuous, 6831 integer (6831 binary)

Deterministic concurrent LP optimizer: primal and dual simplex

Showing first log only...

Root simplex log...

Iteration    Objective              Primal Inf.          Dual Inf.               Time

       0         1.6707000e+08   1.447531e+04   5.910926e+09      9s

   41101    1.4394547e+08   2.254193e+01   1.871818e+10     10s

   95752    1.1669052e+08   0.000000e+00   2.260438e+08     15s

  113792   1.1272501e+08   0.000000e+00   5.513500e+07     20s

Concurrent spin time: 2.45s

Solved with dual simplex

Root relaxation: objective 1.117767e+08, 55663 iterations, 13.71 seconds

    Nodes    |    Current Node    |     Objective Bounds      |     Work

 Expl Unexpl |  Obj  Depth IntInf | Incumbent    BestBd   Gap | It/Node Time

     0     0 1.1178e+08    0    7 1.7664e+08 1.1178e+08  36.7%     -   22s

H    0     0                    1.123825e+08 1.1178e+08  0.54%     -   22s

     0     0 1.1178e+08    0   12 1.1238e+08 1.1178e+08  0.54%     -   39s

     0     0 1.1180e+08    0   12 1.1238e+08 1.1180e+08  0.52%     -   46s

     0     0 1.1180e+08    0   12 1.1238e+08 1.1180e+08  0.52%     -   47s

     0     0 1.1181e+08    0   13 1.1238e+08 1.1181e+08  0.51%     -   47s

...

     0     0 1.1184e+08    0    8 1.1238e+08 1.1184e+08  0.49%     -   89s

...

     0     0 1.1184e+08    0   15 1.1238e+08 1.1184e+08  0.48%     -  111s

...

     0     0 1.1185e+08    0    7 1.1238e+08 1.1185e+08  0.47%     -  118s

...

     0     0 1.1187e+08    0    8 1.1238e+08 1.1187e+08  0.45%     -  119s

...

     0     2 1.1189e+08    0   11 1.1238e+08 1.1189e+08  0.44%     -  147s

...

   782   648 1.1201e+08   22   16 1.1238e+08 1.1191e+08  0.42%  61.6  360s

...

   922   692 1.1211e+08   37   10 1.1238e+08 1.1192e+08  0.41%   242  460s

...

  1039   720 1.1238e+08   27   15 1.1238e+08 1.1193e+08  0.40%   258  506s

...

  1313   743 1.1220e+08   26   15 1.1238e+08 1.1194e+08  0.40%   239  558s

 ...

 19280  1529 1.1234e+08   44    3 1.1238e+08 1.1234e+08  0.04%   126 2465s

 19614  1395 1.1236e+08   45   16 1.1238e+08 1.1234e+08  0.04%   125 2481s

 20010  1247     cutoff   44      1.1238e+08 1.1234e+08  0.04%   123 2499s

 20166  1247     cutoff   37      1.1238e+08 1.1234e+08  0.04%   123 2500s

 20366  1085     cutoff   35      1.1238e+08 1.1235e+08  0.03%   122 2519s

 20678   907     cutoff   45      1.1238e+08 1.1235e+08  0.03%   122 2540s

 21142   711     cutoff   39      1.1238e+08 1.1235e+08  0.03%   120 2561s

 21614   495     cutoff   40      1.1238e+08 1.1236e+08  0.02%   118 2586s

 22119   264     cutoff   41      1.1238e+08 1.1236e+08  0.02%   117 2609s

 22628     2 1.1237e+08  107    2 1.1238e+08 1.1237e+08  0.01%   115 2628s

Cutting planes:

  Gomory: 58

  Cover: 3

  MIR: 19

  GUB cover: 4

  Inf proof: 16

Explored 23100 nodes (2724099 simplex iterations) in 2628.40 seconds

Thread count was 4 (of 4 available processors)

Solution count 6: 1.12382e+08 1.12382e+08 1.12382e+08 ... 1.76643e+08

Optimal solution found (tolerance 1.00e-04)

Best objective 1.123824998323e+08, best bound 1.123822945905e+08, gap 0.0002%

Gurobi Optimizer version 9.1.1 build v9.1.1rc0 (win64)

Thread count: 2 physical cores, 4 logical processors, using up to 4 threads

Optimize a model with 68873 rows, 68310 columns and 834219 nonzeros

Model fingerprint: 0xab0dd328

Coefficient statistics:

  Matrix range     [1e+00, 1e+04]

  Objective range  [1e+02, 9e+06]

  Bounds range     [2e-07, 1e+00]

  RHS range        [1e+00, 5e+04]

Iteration    Objective       Primal Inf.    Dual Inf.      Time

       0    1.0756000e+08   9.992188e+03   0.000000e+00      0s

   24991    1.1238250e+08   1.457031e+02   0.000000e+00      5s

   25723    1.1238250e+08   0.000000e+00   0.000000e+00      5s

Solved in 25723 iterations and 5.39 seconds

Optimal objective  1.123824998e+08

Gurobi 9.1.1: optimal solution; objective 112382499.8

2724099 simplex iterations

23100 branch-and-cut nodes

plus 25723 simplex iterations for intbasis

5 integer variables rounded to integers; maxerr = 4.95005e-07

#execute        0.109201        22133264        308249848

### 1.71_1 copy.mod:66(5853)   display ...

POWER [*] :=

 1 17250.000      7 34500.000     13 28750.000     19 31050.000

 2 17250.000      8 28750.000     14 28750.000     20 31050.000

 3 17250.000      9 28750.000     15 46000.000     21 31050.000

 4 17250.000     10 28750.000     16 46000.000     22 31050.000

 5 17250.000     11 28750.000     17 46000.000     23 31050.000

 6 34500.000     12 28750.000     18 31050.000

The model uses a 4-dimensional matrix of variables. 2 indices of which are very sparse. This is why the model has so many variables.

пятница, 29 января 2021 г. в 18:29:19 UTC+3, AMPL Google Group:

[AMPL Google Group]

Gurobi finds its best solution (objective value 1.123824998323e+08) after only 22 seconds. But then it spends a long time trying to prove optimality of this solution. It only stops when it has proved a lower bound (1.123822945905e+08) that is within 0.01% of the upper bound.

There are no sure ways of reducing execution time, because so much depends on the structure of your particular formulation and on how it affects Gurobi's complex algorithms. I can recommend the following possibilities, however, which you can test out to see whether they are effective for your application:

• Look for binary variables in your formulation that have large coefficients (like 10000). If you find any, consider whether the model could use smaller coefficients. (The message "5 integer variables rounded to integers" is a sign that this might be an issue.)
• Set a stopping gap greater than 0.01%. For example, add mipgap=0.001 to the gurobi_options string to stop when the gap falls to 0.1%. This increases the possibility that Gurobi will stop with a slightly suboptimal solution; but for your particular application, the solutions may be optimal anyway, or a slightly suboptimal solution might be acceptable.
• Set Gurobi's mipfocus option to put more emphasis on getting a good bound and proving optimality. Adding either mipfocus=2 or mipfocus=3 to the gurobi_options string may help; try each one separately.
• Try the "tuning" option that I previously suggested

--
Robert Fourer
am...@googlegroups.com

{#HS:1409410727-99358#}

[url=]am...@googlegroups.com

On Fri, Jan 29, 2021 at 3:28 PM UTC, AMPL Google Group <am...@googlegroups.com> wrote:

The "#execute" line reports time spent by the AMPL language processor in executing the most recent command, but it does not include time spent by the solver. For a non-trivial mixed-integer problem, "display _solve_elapsed_time;" gives the best measure of time that the solver took.

To get more help, there are some simple things that you can do. Before your solve, add the statement

option gurobi_options 'outlev=1';

(or, if you are already setting a gurobi_options string, add outlev=1 to it). Then you will get a detailed log of Gurobi's progress, which will suggest why your problem is difficult. To get more help, you can paste the entire listing into an email back to this forum (or copy the listing into a text file and attach the file).

Gurobi normally runs with a well-chosen set of default parameters for its algorithms. But sometimes other parameter settings are better. You can ask Gurobi to try to choose good parameters for your problem, by specifying

option gurobi_options 'tunebase=test outlev=1';

Then at the end of the run you will see a message like

Wrote 3 tuning parameter files "test1.prm" ... "test3.prm".

and you can check those files for suggestions of parameter combinations to use. For a problem that takes > 30 minutes to solve, the tuning run is likely to take many hours, but it may be worth trying once. (If you need help interpreting the .prm files, you can also post those here.)

--
Robert Fourer
am...@googlegroups.com

[Mikhail]

Dear Robert !. It works! Thank you very much for your advice.

1. Reducing the coefficients of binary variables from 10000 to the minimum - allowed to remove the message (5 integer variables rounded to integers "). However, the duration of the solution changed slightly (-3%)

2. Increasing the gap value up to 0.1% saved 5% of the calculation duration.

3. The introduction of the 'mipfocus = 2' setting into the model reduced the calculation time by 80%.

Now I can try gurobi with "tunebase = test"

понедельник, 1 февраля 2021 г. в 18:29:09 UTC+3, AMPL Google Group:

[Azadeh]

Hello everyone,

I have a question that seems to be relevant to the discussion in this thread. I am solving a relatively large MIP problem. I wrote it in AMPL and I am solving it w/ Gurobi. 

Going through the log file of Gurobi, I can see the following msg in a few minutes: "Best objective 1.407490814907e+09, best bound 1.407435617078e+09, gap 0.0039%". However, Gurobi does not stop and will continue until the Timelim=240 is reached. This happens despite the fact that I have increased the Gurobi's mipgap parameter from the default value of 0.0001 to 0.1. I was wondering why the increase in the MIPgap does not terminate the search? Please kindly find the Gurobi's log file attached to this email.

I have used the following instructions for the AMPL and Gurobi's parameters:

option show_stats 1, solver_msg 1;

option gurobi_options 'mipgap=0.1 TimeLim=240 logfile=MyLogfile_Gurobi_Gap outlev=1 return_mipgap=3 bestbound=1';

Thank you in advance for your guidance.

[Azadeh]

Hello again,

I also have a question about AMPL's presolve and its impact on the resolution time. My goal is to find out how important/critical it is to use AMPL presolve in addition to Gurobi's presolve. So, I tried to set presolve=0 and compare the resolution time with the test where presolve had its default value of 10.

AMPL's presolve=0

Presolve eliminates 0 constraints and 4511716 variables.

Adjusted problem:

3249580 variables:

2641 binary variables

39240 integer variables

3207699 linear variables

650532 constraints, all linear; 13243324 nonzeros

546278 equality constraints

104062 inequality constraints

192 range constraints

AMPL's presolve=10 (default)

Presolve eliminates 52866 constraints and 5702724 variables.

Adjusted problem:

2058572 variables:

4607 binary variables

37274 integer variables

2016691 linear variables

597666 constraints, all linear; 8243902 nonzeros

504277 equality constraints

93389 inequality constraints

1 linear objective; 1 nonzero.

I now have three questions:

1) Why AMPL's presolve eliminated 4511716 variables, despite the fact that I had set:  option show_stats 1, solver_msg 1, presolve 0;?

2) I can see that a huge portion of my variables are eliminated (73%) during the AMPL's presolve. Can I have any useful interpretation with respect to this observation? For example, does it necessarily mean that the model is not efficient or it might be simply relevant to the input data (case specific)?

3) In both tests, Gurobi's timelim=240. Looking at each tests' Gurobi log file, I do not see any significant difference. Can I interpret this as Gurobi's presolve is so good that AMPL's presolve does not make a big difference? However, technically despite presolve=0 4.5 million variables are eliminated; so probably I need to find a way to deactivate AMPL's presolve completely and then see how Gurobi will perform. What do you suggest?

Thank you in advance for your guidance.

[AMPL Google Group]

After Gurobi finds a solution within the mipgap tolerance, the search is terminated, but the AMPL-Gurobi interface performs one last step: the integer variables are fixed at their optimal values, and a linear programming algorithm (usually dual simplex) is run to compute accurate values of the continuous variables. There are some good reasons for this last step, but in cases like yours it can take an excessive amount of time, and you should suppress it by adding basis=0 to your gurobi_options string.

--
Robert Fourer
am...@googlegroups.com

{#HS:1409410727-99358#}

On Thu, Jul 8, 2021 at 4:47 PM UTC, AMPL Modeling Language <am...@googlegroups.com> wrote:

Hello everyone,
I have a question that seems to be relevant to the discussion in this thread. I am solving a relatively large MIP problem. I wrote it in AMPL and I am solving it w/ Gurobi.

Going through the log file of Gurobi, I can see the following msg in a few minutes: "Best objective 1.407490814907e+09, best bound 1.407435617078e+09, gap 0.0039%". However, Gurobi does not stop and will continue until the Timelim=240 is reached. This happens despite the fact that I have increased the Gurobi's mipgap parameter from the default value of 0.0001 to 0.1. I was wondering why the increase in the MIPgap does not terminate the search? Please kindly find the Gurobi's log file attached to this email.

I have used the following instructions for the AMPL and Gurobi's parameters:

option show_stats 1, solver_msg 1;
option gurobi_options 'mipgap=0.1 TimeLim=240 logfile=MyLogfile_Gurobi_Gap outlev=1 return_mipgap=3 bestbound=1';

Thank you in advance for your guidance.

On Tue, Feb 2, 2021 at 3:17 AM UTC, AMPL Modeling Language <am...@googlegroups.com> wrote:

Dear Robert !.
It works! Thank you very much for your advice.
1. Reducing the coefficients of binary variables from 10000 to the minimum - allowed to remove the message (5 integer variables rounded to integers "). However, the duration of the solution changed slightly (-3%)
2. Increasing the gap value up to 0.1% saved 5% of the calculation duration.
3. The introduction of the 'mipfocus = 2' setting into the model reduced the calculation time by 80%.
Now I can try gurobi with "tunebase = test"

On Mon, Feb 1, 2021 at 3:28 PM UTC, AMPL Google Group <am...@googlegroups.com> wrote:

Gurobi finds its best solution (objective value 1.123824998323e+08) after only 22 seconds. But then it spends a long time trying to prove optimality of this solution. It only stops when it has proved a lower bound (1.123822945905e+08) that is within 0.01% of the upper bound.

There are no sure ways of reducing execution time, because so much depends on the structure of your particular formulation and on how it affects Gurobi's complex algorithms. I can recommend the following possibilities, however, which you can test out to see whether they are effective for your application:

• Look for binary variables in your formulation that have large coefficients (like 10000). If you find any, consider whether the model could use smaller coefficients. (The message "5 integer variables rounded to integers" is a sign that this might be an issue.)
• Set a stopping gap greater than 0.01%. For example, add mipgap=0.001 to the gurobi_options string to stop when the gap falls to 0.1%. This increases the possibility that Gurobi will stop with a slightly suboptimal solution; but for your particular application, the solutions may be optimal anyway, or a slightly suboptimal solution might be acceptable.
• Set Gurobi's mipfocus option to put more emphasis on getting a good bound and proving optimality. Adding either mipfocus=2 or mipfocus=3 to the gurobi_options string may help; try each one separately.
• Try the "tuning" option that I previously suggested

--
Robert Fourer
am...@googlegroups.com

[AMPL Google Group]

(1) Even with presolve 0, AMPL eliminates some kinds of variables: ones that are not used in any constraint, and ones that are fixed by use of a "fix" or a "problem" command.

(2) A large number of eliminated variables can indicate that your model formulation is inefficient, and it can indicate that a lot of the variables are trivial or unnecessary in your particular data case. In general it is best to just let presolve take care of eliminating variables, but if you start to run into problems with presolve taking excessive time or memory, then you may want to look for obvious ways of reformulating your model to reduce the size of the problem. As a start, you can use commands like the following to show the names of all variables that are fixed and that are unused:

display {j in 1.._nvars: _var[j].status = "fix"} (_varname[j],_var[j].status) >fix.out;
display {j in 1.._nvars: _var[j].status = "unused"} (_varname[j],_var[j].status) >unused.out;

(I have shown these with the output redirected to a file, because it might be long.)

(3) Setting presolve 0 is the most that you can do to inactive AMPL's presolve. Then, since all of the presolve tests in AMPL are also in Gurobi, the presolving that would have been done in AMPL will be done in Gurobi instead. (Also Gurobi may do some additional, more specialized presolving that reduces the problem size even more.) After you set basis=0 as in my previous comment, Gurobi will stop much sooner and you will be able to get a better idea of the amount of time it spends in presolve.

--
Robert Fourer
am...@googlegroups.com

{#HS:1409410727-99358#}

On Fri, Jul 9, 2021 at 5:31 PM UTC, AMPL Google Group <am...@googlegroups.com> wrote:

After Gurobi finds a solution within the mipgap tolerance, the search is terminated, but the AMPL-Gurobi interface performs one last step: the integer variables are fixed at their optimal values, and a linear programming algorithm (usually dual simplex) is run to compute accurate values of the continuous variables. There are some good reasons for this last step, but in cases like yours it can take an excessive amount of time, and you should suppress it by adding basis=0 to your gurobi_options string.

--
Robert Fourer
am...@googlegroups.com

On Thu, Jul 8, 2021 at 4:47 PM UTC, AMPL Modeling Language <am...@googlegroups.com> wrote:

Hello everyone,
I have a question that seems to be relevant to the discussion in this thread. I am solving a relatively large MIP problem. I wrote it in AMPL and I am solving it w/ Gurobi.

Going through the log file of Gurobi, I can see the following msg in a few minutes: "Best objective 1.407490814907e+09, best bound 1.407435617078e+09, gap 0.0039%". However, Gurobi does not stop and will continue until the Timelim=240 is reached. This happens despite the fact that I have increased the Gurobi's mipgap parameter from the default value of 0.0001 to 0.1. I was wondering why the increase in the MIPgap does not terminate the search? Please kindly find the Gurobi's log file attached to this email.

I have used the following instructions for the AMPL and Gurobi's parameters:

option show_stats 1, solver_msg 1;
option gurobi_options 'mipgap=0.1 TimeLim=240 logfile=MyLogfile_Gurobi_Gap outlev=1 return_mipgap=3 bestbound=1';

Thank you in advance for your guidance.

On Tue, Feb 2, 2021 at 3:17 AM UTC, AMPL Modeling Language <am...@googlegroups.com> wrote:

Dear Robert !.
It works! Thank you very much for your advice.
1. Reducing the coefficients of binary variables from 10000 to the minimum - allowed to remove the message (5 integer variables rounded to integers "). However, the duration of the solution changed slightly (-3%)
2. Increasing the gap value up to 0.1% saved 5% of the calculation duration.
3. The introduction of the 'mipfocus = 2' setting into the model reduced the calculation time by 80%.
Now I can try gurobi with "tunebase = test"

On Mon, Feb 1, 2021 at 3:28 PM UTC, AMPL Google Group <am...@googlegroups.com> wrote:

Gurobi finds its best solution (objective value 1.123824998323e+08) after only 22 seconds. But then it spends a long time trying to prove optimality of this solution. It only stops when it has proved a lower bound (1.123822945905e+08) that is within 0.01% of the upper bound.

There are no sure ways of reducing execution time, because so much depends on the structure of your particular formulation and on how it affects Gurobi's complex algorithms. I can recommend the following possibilities, however, which you can test out to see whether they are effective for your application:

• Look for binary variables in your formulation that have large coefficients (like 10000). If you find any, consider whether the model could use smaller coefficients. (The message "5 integer variables rounded to integers" is a sign that this might be an issue.)
• Set a stopping gap greater than 0.01%. For example, add mipgap=0.001 to the gurobi_options string to stop when the gap falls to 0.1%. This increases the possibility that Gurobi will stop with a slightly suboptimal solution; but for your particular application, the solutions may be optimal anyway, or a slightly suboptimal solution might be acceptable.
• Set Gurobi's mipfocus option to put more emphasis on getting a good bound and proving optimality. Adding either mipfocus=2 or mipfocus=3 to the gurobi_options string may help; try each one separately.
• Try the "tuning" option that I previously suggested

--
Robert Fourer
am...@googlegroups.com

[Azadeh]

Thank you very much for your explanations and guidance Robert! Very much appreciated. I will run the model w/ basis=0 and observe how it behaves.

Azadeh