Skip to content

Conversation

@odow
Copy link
Member

@odow odow commented Oct 7, 2025

Basic

  • version field of Project.toml has been updated
    - If a breaking change, increment the MAJOR field and reset others to 0
    - If adding new features, increment the MINOR field and reset PATCH to 0
    - If adding bug fixes or documentation changes, increment the PATCH field

Documentation

  • Add a new entry to docs/src/changelog.md, following existing style

Tests

@odow
Copy link
Member Author

odow commented Oct 8, 2025

The Juniper and Pavito failures are super interesting and they are caused by #2857

  • They have z --> {f(x) in S}, z in {0, 1}
  • They have an outer solver that covers z in {0, 1}. They pass z --> {f(x) in S}, z == a to the inner solver. The inner solver says, sure, I know how to reformulate --> assuming z is binary. But z is fixed and isn't {0, 1}. The reformulation is still valid though, which is why the tests were passing before.

Maybe we should revert #2857 and add a check at the JuMP level?

Or maybe the bridge needs to say: I added a ZeroOne constraint even though I didn't just so we validate that an indicator can't be bridged by a continuous solver.

Or maybe we need to convert the error() AddConstraintNotAllowed.

@odow
Copy link
Member Author

odow commented Oct 9, 2025

@odow
Copy link
Member Author

odow commented Oct 9, 2025

@odow odow requested a review from blegat October 9, 2025 03:40
@odow
Copy link
Member Author

odow commented Oct 13, 2025

Hearing no objections?

@blegat
Copy link
Member

blegat commented Oct 14, 2025

The Juniper and Pavito failures are super interesting and they are caused by #2857

* They have `z --> {f(x) in S}, z in {0, 1}`

* They have an outer solver that covers `z in {0, 1}`. They pass `z --> {f(x) in S}, z == a` to the inner solver. The inner solver says, sure, I know how to reformulate `-->` assuming `z` is binary. But `z` is fixed and isn't `{0, 1}`. The reformulation is still valid though, which is why the tests were passing before.

Maybe we should revert #2857 and add a check at the JuMP level?

Or maybe the bridge needs to say: I added a ZeroOne constraint even though I didn't just so we validate that an indicator can't be bridged by a continuous solver.

Or maybe we need to convert the error() AddConstraintNotAllowed.

Pavito and Juniper shouldn't support Indicator constraints so that it's bridged before they pass it down. It doesn't make sense for them to pass down an indicator constraints to a non-MIP solver. It's not like there is a chance for these non-MIP solvers to support indicator constraints.

@blegat
Copy link
Member

blegat commented Oct 14, 2025

Maybe this should be fixed before we release ?

@odow
Copy link
Member Author

odow commented Oct 14, 2025

Already done in #2868

@odow
Copy link
Member Author

odow commented Oct 15, 2025

Latest failures in Alpine and PowerModels are because of jump-dev/HiGHS.jl#302

@odow
Copy link
Member Author

odow commented Oct 16, 2025

@blegat can you confirm you're okay with my changes with the ToMILPBridge?

@blegat
Copy link
Member

blegat commented Oct 20, 2025

Already done in #2868

Ok so the issue was that Juniper said that it supported indicator because it was redirecting to the inner solver which said it was supporting it. Now with https://github.com/jump-dev/MathOptInterface.jl/pull/2868/files, the inner solver says it does not support indicator so Juniper says the same so it is bridged in the bridge outer of Juniper, that's an elegant fix.

@odow
Copy link
Member Author

odow commented Oct 20, 2025

that's an elegant fix.

Yip, although it isn't a perfect fix.

On the outside, Juniper fixes z to either 0 or 1. This flows to the inner solver, so the MIP reformulation would have been valid even without z in {0, 1}. But detecting that either z is ZeroOne, or that it has fixed bound of 0 or 1, or that it is integer and has bounds [0, 1], or that it is a constant, or that there is some other equality constraint that 1.0 * z == 1 (or that there's a constraint like z * (1 - z) = 0) seems like it is out-of-scope for the bridge.

@odow odow merged commit ec8434e into master Oct 20, 2025
31 checks passed
@odow odow deleted the od/v1.46.0 branch October 20, 2025 21:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants