Execution times and objective values using Gurobi

[Sascha B]

Hello,

I'm using Optano.Modeling 3.3.0.474 and Optano.Modeling.Gurobi 9.0.1.23 with Gurobi 9.0.1 and implemented it in a .NET Core 2.1 Console App.

After I build the model and before I solve it, I print out its mps file.

When I solve the model set up by Optano and compare the time Gurobi takes for the mps file, I notice significant differences in runtime.

Here are two screenshots from the output of solving the same model with Gurobi 9.0.1.

The smaller output (47 lines) is the one when using the gurobi_cl command to solve the mps file.

The larger output (57 lines) is the output I get when I directly solve the model using Optano.

I want to highlight, that I run the GurobiSolver.Solve() method directly after exporting the mps file. The model does not change.

So, the basic questions are: (a) Why does GurobiSolver.Solve() needs more time than gurobi_cl and (b) why does it not find the real optimum.

GurobiSolver.Solve(...) calculates an optimum of 4.24e+06 (line 57), whereas gurobi_cl finds an even better optimum of 4.21e+06 (line 47).

The runtime of GurobiSolver.Solve() is higher. It explored 1 node with 25007 iterations in 9.13 seconds (line 51), whereas gurobi_cl explored 1 node with 19567 iterations in 3.68 seconds (line 41).

Since a past issue I mentioned in this forum, I set RestoreUserModelAfterSolve to false.

Besides this, I used the default gurobi and optano configuration settings to create the example mentioned above.

I didn't use the debug mode of Visual Studio; I released the application as a .exe and run it with cmd.

[OPTANO Team]

Hi,

that is a quite usual topic related to numeric issues. it's quite impossible to print the internal floating point into text files (the mps). when reading the "same" model from the file, it's slightly different.

You might experience comparable speedups by rising the numeric tolerance of the solver.

Best,

jp

[Sascha B]

Hi jp,

thanks for yuor answer.

Will this also affect the different solution values?

Best,

Sascha

[OPTANO Team]

Well, the gap on termination is different. please check if the result ist the same for mipgap == 0.0 in both cases.

[Sascha B]

I made a few runs.

Picture 1 shows, there are still different solution values, when I set the same mipgap for both cases.

In picture 3, I use a mipgap of 0.0001 and still get different results.

Picture 2 shows it's possible to get the same solution.

Could there be other tolerance related parameters that have different default values?

1) The execution output of gurobi_cl (left image) and Optano.GurobiSolver.Solve(...) (right image), both with MIPGap of 0.000

2) The execution output of gurobi_cl (left image) and Optano.GurobiSolver.Solve(...) (right image), both with MIPGap of 0.000 (the exact same setting)

3) The execution output of gurobi_cl (left image) and Optano.GurobiSolver.Solve(...) (right image), both with MIPGap of 0.004

[OPTANO Team]

There is plenty of tolerance parameters in gurobi. But it might lead the investigation in the wrong direction.

Confusing is, the optimal result of modeling is 4.210525, but the lower bound of the mps read version is 4.24066 in the second case. That looks broken. A difference in a magnitude of 10e-2 is largen that the usual settings.

Can you tell with objective value is acutually correct?

[Sascha B]

Assuming the MPS and LP files are generated correctly, the solver SCIP calculates 4201525, like gurobi_cl does every run.

MPS

SCIP Status        : problem is solved [optimal solution found]
Solving Time (sec) : 148.07
Solving Nodes      : 133 (total of 134 nodes in 2 runs)
Primal Bound       : +4.21052500000000e+06 (3 solutions)
Dual Bound         : +4.21052500000000e+06
Gap                : 0.00 %

LP

SCIP Status        : problem is solved [optimal solution found]
Solving Time (sec) : 144.56
Solving Nodes      : 139 (total of 140 nodes in 2 runs)
Primal Bound       : +4.21052500000000e+06 (5 solutions)
Dual Bound         : +4.21052500000000e+06
Gap                : 0.00 %

[OPTANO Team]

One of our developers drew my attention to another point.

The size is different in your gurobi compare examples. Could there have been a mix-up?

[Sascha B]

Hi,

I ran the again just a minute ago, watched for the timestamp of the mps file as well as the model size and can recreate the issue.

Both models have the original size of 78528 rows, but as a consequence of Optano's normalization, there are rows added before solving the model:

[OPTANO Team]

Hi

We'd like to work through this.

Is there any chance to run the code on our systems?

Do you know any mimimal sample, that we might use?

Best,

jp

[Sascha B]

This should be possible. I'll send you a mail :)