Fix no results returned when no discrete variables are present in MindtPy

[bernalde]

Fixes #3855 .

Fixes #3855

Summary/Motivation:

This PR fixes an issue where MindtPy can short-circuit on “no discrete decisions” (LP/NLP) and then fails to reliably return a proper SolverResults and/or load primal values onto the input model, even when the direct LP/NLP solve succeeds. This behavior breaks downstream meta-solvers (e.g., GDPopt subproblem solves) that depend on Var.value to capture an incumbent.

Reference: #3855

MindtPy contains a validation/short-circuit path intended to directly solve models that do not require decomposition (e.g., LP/NLP, or models where all discrete variables are fixed). In this path, MindtPy may:

return None from solve() (bare return)

Changes proposed in this PR:

• Ensure MindtPy always returns a SolverResults object (never None) even when the model is handled by the LP/NLP short-circuit.
• Initialize and populate self.results before early exits, and propagate termination/status/message from the direct LP/NLP solve into MindtPy’s results.
• Add a standalone test/test_mindtpy_no_discrete.py script

Legal Acknowledgement

By contributing to this software project, I have read the contribution guide and agree to the following terms and conditions for my contribution:

1. I agree my contributions are submitted under the BSD license.
2. I represent I am authorized to make the contributions and grant the license. If my employer has rights to intellectual property that includes these contributions, I represent that I have received permission to make contributions and grant the required license on behalf of that employer.

[Toflamus]

Hi team,

I’ve investigated the current CI failures across Linux, macOS, and Windows. The failures in pyomo/contrib/solver/tests/solvers are not caused by the code changes in this PR.

The root cause is an expired GAMS license in the test environment. It appears the license might have expired a few days ago, which is why we are seeing identical failures across all platforms.

Interestingly, the tests for MindtPy are still passing (likely because they use different solver paths or have different fallback mechanisms), but the core solver tests are blocked.

Once the GAMS license is renewed in the CI environment, these tests should return to green.

[blnicho]

@Toflamus we are aware of the issue and discussed it during the developer call today. This is indeed an infrastructure issue and we're working on getting it fixed.

[codecov]

Codecov Report

❌ Patch coverage is 96.15385% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 89.93%. Comparing base (3d3ffae) to head (1abf71a).

Files with missing lines	Patch %	Lines
pyomo/contrib/mindtpy/algorithm_base_class.py	96.15%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3861      +/-   ##
==========================================
- Coverage   89.93%   89.93%   -0.01%     
==========================================
  Files         902      902              
  Lines      106393   106416      +23     
==========================================
+ Hits        95683    95703      +20     
- Misses      10710    10713       +3     

Flag	Coverage Δ
builders	29.18% <3.84%> (-0.01%)	⬇️
default	86.23% <96.15%> (?)
expensive	35.63% <3.84%> (?)
linux	87.38% <96.15%> (-2.04%)	⬇️
linux_other	87.38% <96.15%> (+<0.01%)	⬆️
oldsolvers	28.10% <3.84%> (-0.01%)	⬇️
osx	82.71% <96.15%> (+<0.01%)	⬆️
win	85.80% <96.15%> (-0.01%)	⬇️
win_other	85.80% <96.15%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jsiirola]

One question about results bounds, but otherwise, this looks good to me.

[jsiirola]

Doesn't that imply convexity? I feel like you are making a promise that may not hold for the actual model you are solving...

[Toflamus]

Good catch — the "primal==dual" phrasing is too strong. What this fallback actually relies on is not convexity but the solver's own claim: if the solver reports tc.optimal and didn't populate its own bounds, we use the objective value as the best available information for both bounds.

That said, you're right that for a local NLP solver like IPOPT, tc.optimal really only guarantees local optimality, so setting both bounds equal overstates what we actually know. Do you want me to fix the comment?

[bernalde]

Absolutely! Good catch. We cannot promise dual==primal, so in general we should inherit the dual and primal from the subsolver if they provide any. If they don't provide a dual (such as IPOPT) we only report the primal

[jsiirola]

I'll let others weigh in, but I think I would prefer to change the results to only return what we know; in this case, only return the objective value for the primal (feasible) bound and then return None for the dual (infeasible) bound.

[Toflamus]

Btw, just to mention, the "primal==dual" phrasing in the comment is admittedly loose, but the behavior here is safe. A few points:

1. prob is the result-reporting object (self.results.problem), not any subproblem bound used algorithmically. This code only runs in the short-circuit path (no discrete variables), so these bounds never feed back into any decomposition logic. It's purely for populating the solver results that get returned to the user. We're just filling in the lower_bound, upper_boundfields so the returned SolverResults isn't incomplete.

2. This only fires in the short-circuit path — when model_is_valid() detects zero discrete variables and solves the original model directly as an LP/NLP. MindtPy then returns False and never enters the decomposition loop. So these bounds don't influence any cuts or iterations.

3. The fallback only triggers when the solver claims tc.optimal but didn't populate its own bounds. We're just mirroring what the solver already told us — if it says optimal, using the objective value as the reported bound is the best available information.

[Toflamus]

Anyway, I agree that we should only keep what we know.

[emma58]

I have one question related to the conversation about bounds @jsiirola started, but otherwise this looks good to me.

[emma58]

I'm confused about this: Isn't the results object from the solver already reporting whatever bounds it got? Why can't you just pass those through? If it's local, it should only have the primal bound, and not the dual bound, which is exactly what you want.

[bernalde]

The code does pass through bounds from the solver first (lines 385-391). The fallback logic here only activates when the solver doesn't provide bounds at all. This happens with NLP solvers like IPOPT, which never populate lower_bound or upper_bound in their results objects (you can confirm this in sol.py - the sol reader sets constraint/variable/objective counts but never sets bounds). So the fallback is necessary to infer the primal bound from the objective value when the solver reports optimal but provides no bound information at all.

[emma58]

Looks like these could be consolidated.

[jsiirola]

This looks good. I do have a couple design questions to think about for the future:

• model_is_valid is a really expensive implementation. In particular, computing the polynomial degree for every expression is pretty much the same cost as doing a full LP/NL write. Is that duplicate effort really necessary?
• if the model is a QP, and the mip_solver can handle QPs, shouldn't we use it and not the nlp_solver?

I wonder if a future improvement would be to skip the polynomial degree checks and just try solving with the MIP solver. If that fails, then fall back on the NLP solver?