Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems in retrieving the solution when setting a MIP gap #815

Open
matteodefelice opened this issue Jan 8, 2024 · 3 comments
Open

Problems in retrieving the solution when setting a MIP gap #815

matteodefelice opened this issue Jan 8, 2024 · 3 comments
Labels

Comments

@matteodefelice
Copy link

I am using PyPSA 0.26 and Linopy 0.2.6 on Windows.
I have a unit commitment problem that takes some time and I have decided to stop the simulation setting a MIP gap (~3%, but the number is not important, I have the same issue when setting a maximum time limit).

If I do this with GLPK (using mipgap), when the simulation stops I get a status unknown:

RELATIVE MIP GAP TOLERANCE REACHED; SEARCH TERMINATED
Time used:   192.1 secs
Memory used: 24.5 Mb (25731394 bytes)
Writing MIP solution to 'C:\Users\matte\AppData\Local\Temp\linopy-solve-frk1ifkm.sol'...
WARNING:linopy.solvers:Dual values of MILP couldn't be parsed
WARNING:linopy.constants:Optimization failed: 
Status: unknown
Termination condition: unknown
Solution: 12072 primals, 0 duals
Objective: -9.17e+01
Solver model: not available
Solver message: integer non-optimal

If I use cbc with ratioGap the status at the end is warning but I cannot access the solution:

WARNING:linopy.constants:Optimization failed: 
Status: warning
Termination condition: unknown
Solution: 0 primals, 0 duals
Objective: nan
Solver model: not available
Solver message: Optimal (within gap tolerance) - objective value -98.51841458


Probing was tried 18 times and created 38 cuts of which 105 were active after adding rounds of cuts (0.151 seconds)
Gomory was tried 27 times and created 480 cuts of which 0 were active after adding rounds of cuts (0.434 seconds)
Knapsack was tried 18 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.167 seconds)
Clique was tried 18 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.009 seconds)
MixedIntegerRounding2 was tried 27 times and created 145 cuts of which 0 were active after adding rounds of cuts (0.110 seconds)
FlowCover was tried 18 times and created 1 cuts of which 0 were active after adding rounds of cuts (0.024 seconds)
TwoMirCuts was tried 27 times and created 505 cuts of which 0 were active after adding rounds of cuts (0.374 seconds)
ZeroHalf was tried 1 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.022 seconds)

Result - Optimal solution found (within gap tolerance)

Objective value:                -98.51841458
Lower bound:                    -100.789
Gap:                            0.02
Enumerated nodes:               4
Total iterations:               6629
Time (CPU seconds):             10.53
Time (Wallclock seconds):       10.53

Total time (CPU seconds):       10.66   (Wallclock seconds):       10.66

Instead with gurobi (and MIPGap) I get as final status ok and I can access eventually the solution:

Optimal solution found (tolerance 1.00e-01)
Best objective -9.292689386415e+01, best bound -1.022148217206e+02, gap 9.9949%
WARNING:linopy.solvers:Dual values of MILP couldn't be parsed
INFO:linopy.constants: Optimization successful: 
Status: ok
Termination condition: optimal
Solution: 12072 primals, 0 duals
Objective: -9.29e+01
Solver model: available
Solver message: 2

INFO:pypsa.optimization.optimize:No shadow prices were assigned to the network.

Is this a bug?

@Alex-Neve
Copy link

Hello Matteo,

I googled a bit your issue as both GLPK and Gurobi find almost the same objective value.
Here is what I found:
https://groups.google.com/g/pulp-or-discuss/c/axSgo9bJmpM?pli=1

Looks like setting the MIPgap in GLPK results in a solution whose status is not well returned by GLPK, whereas it is properly handled by Gurobi. Hence the unknown status with GLPK.

Is your GLPK up to date? If yes, I think the above link may give clues on what needs to be fixed in GLPK.

@matteodefelice
Copy link
Author

I have the version 5.0, that post is more than 10 years old, I hope they solved that in the meantime :)
However, I have the same issue with cbc, I will try to understand what is happening.

@matteodefelice
Copy link
Author

I want to add that it works with HiGHS, I can set mip_rel_gap and I get back a solution at the end.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants