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

Incorrect Improvement in Solution After Adding a Cut in Iterative Process #1954

Open
sertalpbilal opened this issue Sep 27, 2024 · 10 comments
Open

Comments

@sertalpbilal
Copy link

sertalpbilal commented Sep 27, 2024

Hi,

I'm encountering an unexpected behavior when using the HiGHS solver. In a two-step iterative process, I solve a problem and then add a cut in the second iteration. Theoretically, this should result in the same or a worse solution compared to the first iteration, as all the original constraints remain unchanged and the cut adds an additional restriction. However, the solver returns a better solution after adding the cut, which clearly seems incorrect.

I attached both MPS files in a zip file.
mps_files.zip

HiGHS Version

1.7.2 (Windows)

Steps to Reproduce:

  • Solve both MPS files using HiGHS.
  • Observe that the first file (with _0.mps) gives an objective value of -288.521, while the second one (_1.mps) gives -288.654

Relevant Details

  • I use an options file with only mip_rel_gap = 0 in it. But, the issue happens regardless of this file.
  • CBC solver gives an objective value of -289.269406 for both files.

Logs

Solve 1:

Status            Optimal
Primal bound      -288.5210454
Dual bound        -288.5210454
Gap               0%
Solution status   feasible
-288.5210454 (objective)
0 (bound viol.)
3.5527136788e-15 (int. viol.)
0 (row viol.)
Timing            302.57 (total)
0.40 (presolve)
0.00 (postsolve)
Nodes             1104
LP iterations     452760 (total)
206095 (strong br.)
13946 (separation)
28275 (heuristics)

Solve 2:

Status            Optimal
Primal bound      -288.6548272
Dual bound        -288.6548272
Gap               0%
Solution status   feasible
-288.6548272 (objective)
0 (bound viol.)
0 (int. viol.)
0 (row viol.)
Timing            82.14 (total)
0.98 (presolve)
0.00 (postsolve)
Nodes             101
LP iterations     223069 (total)
132909 (strong br.)
7133 (separation)
23063 (heuristics)
@odow
Copy link
Collaborator

odow commented Sep 27, 2024

CBC solver gives an objective value of -289.26906 for both files.

Gurobi concurs with -289.269406

@jajhall jajhall self-assigned this Sep 27, 2024
@jajhall
Copy link
Member

jajhall commented Sep 27, 2024

Sorry about this. Probably due to an error in presolve. I'll investigate further in due course

@sertalpbilal
Copy link
Author

Looks like it works with HiGHS 1.2.0. I am able to get the same objective (-289.269406).

Solving report
  Status            Optimal
  Primal bound      -289.269406
  Dual bound        -289.269406
  Gap               0%
  Solution status   feasible
                    -289.269406 (objective)
                    0 (bound viol.)
                    1.16018306073e-13 (int. viol.)
                    0 (row viol.)
  Timing            72.25 (total)
                    0.42 (presolve)
                    0.00 (postsolve)
  Nodes             208
  LP iterations     221430 (total)
                    133567 (strong br.)
                    5321 (separation)
                    20564 (heuristics)

@jajhall
Copy link
Member

jajhall commented Sep 27, 2024

This is probably because bug fixes to the MIP presolve since 1.2.0 have caused the 1.7.2 MIP presolve to take a different path and exposed a bug. In other words, it's very unlikely to be a regression.

What happens with random_seed=1?

@sertalpbilal
Copy link
Author

With random_seed=1 I still get the incorrect objective (-288.5210454)

@jajhall
Copy link
Member

jajhall commented Sep 27, 2024

And if you switch off presolve?

@sertalpbilal
Copy link
Author

When presolve is off (version 1.7.2), I get the correct result, so you are right, it looks like a presolve issue. It takes much longer (2181 seconds) to solve as expected, but finds the same solution as CBC and Gurobi.

Solving report
  Status            Optimal
  Primal bound      -289.269406
  Dual bound        -289.269406
  Gap               0%
  Solution status   feasible
                    -289.269406 (objective)
                    0 (bound viol.)
                    6.76125821997e-14 (int. viol.)
                    0 (row viol.)
  Timing            2181.20 (total)
                    0.03 (presolve)
                    0.00 (postsolve)
  Nodes             4552
  LP iterations     2350958 (total)
                    798769 (strong br.)
                    97653 (separation)
                    135297 (heuristics)

@fwesselm
Copy link
Contributor

@sertalpbilal I am trying to investigate this, but the reproduction examples are rather large. By any chance do you have a smaller instance to reproduce this? The answer is most probably no, but I wanted to ask anyway...

@sertalpbilal
Copy link
Author

@fwesselm I have attached 5 iterations from a smaller solve (~1.8 MB each) and pasting the objectives (score column) we get below. Iter_0 should be without a cut, Iter_1 is after cutting the best solution, and so on.

iterations.zip

image

@fwesselm
Copy link
Contributor

@fwesselm I have attached 5 iterations from a smaller solve (~1.8 MB each) and pasting the objectives (score column) we get below. Iter_0 should be without a cut, Iter_1 is after cutting the best solution, and so on.

iterations.zip

image

Thank you. For iter_0 the problematic presolve reduction is number 2454. I will continue investigating.

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

No branches or pull requests

4 participants