Fix non-rigorous crossed bound results

[bernalde]

Fixes #3947.

Summary/Motivation:

When GDPopt LOA is applied to a nonconvex problem, its linearizations are not valid relaxations, so the "dual bound" it accumulates is not a rigorous bound. If those bounds cross, GDPopt currently snaps the dual bound to the primal bound and reports optimal with LB == UB. That presents a non-rigorous result as a certified global optimum, which is the failure reported in #3947.

The fix reports what is actually known in that case: the incumbent is feasible, and no certified dual bound is available.

This is a replacement for #3948, which GitHub would not allow me to reopen after it was closed. The prior review discussion and history remain available there.

Changes proposed in this PR:

• Add a _crossed_bounds_are_certified class flag to _GDPoptAlgorithm (default True), set to False on GDP_LOA_Solver. GLOA keeps the existing certified behavior.
• When bounds cross on a solver whose bounds are not certified and the model is detected as possibly non-rigorous, terminate with feasible instead of optimal, and report the uncertified side of the bound as infinite rather than snapping it to the primal bound.
• Add _problem_may_have_nonrigorous_dual_bound() in pyomo/contrib/gdpopt/loa.py, which inspects the active objective and constraints: anything non-polynomial or of degree > 2 is treated as possibly non-rigorous, quadratic equalities are treated as possibly non-rigorous, and quadratic inequalities are classified by curvature against their bound sense.
• Classify quadratic curvature from the full symmetric Q matrix rather than diagonal terms only, so convex forms with cross terms such as x**2 + x*y + y**2 <= 4 are still certified.
• Use NumPy eigvalsh when available, with a pure-Python Jacobi eigenvalue fallback so the classification also works in Pyomo's NumPy-free test environments.
• Apply the same crossed-bound result semantics to MindtPy GOA.
• Add regressions in pyomo/contrib/gdpopt/tests/test_gdpopt.py and pyomo/contrib/mindtpy/tests/test_mindtpy_no_discrete.py covering crossed-bound reporting, non-polynomial detection, quadratic convexity classification (including the no-NumPy path), and preservation of certified GLOA behavior.
• Validation performed locally on this branch, rebased onto current main:
  • python -m pytest -q pyomo/contrib/gdpopt/tests/test_gdpopt.py pyomo/contrib/mindtpy/tests/test_mindtpy_no_discrete.py
    • Result: 96 passed, 19 skipped, 3 deselected in 43.01s
  • python -m black --check on the six changed files
    • Result: passed, 6 files would be left unchanged
  • typos --config ./.github/workflows/typos.toml on the six changed files
    • Result: passed, no findings

AI-Use Disclosure

• AI tools were NOT used during the preparation of this PR

or

• AI tools contributed to the development of this PR

  • AI tools generated documentation (including the PR description/comments, code comments, and/or Sphinx documentation)
  • AI tools generated tests (baselines, examples, and/or code)
  • AI tools generated code (apart from tests)

  Review process (select ONE):

  • Rewritten: All AI-generated content was rewritten by me before being committed.
  • Reviewed/verified: I retained AI-generated content and verified it before committing. Verification included (as applicable):
    • Ran the code and fixed issues
    • Added and ran tests
    • Checked correctness/logic of code and tests
    • Checked for alignment with the contribution guide
    • Considered security implications
  • As-is: AI-generated content was commited directly to the repository

Notes for reviewers (optional): This replacement PR carries over the implementation and tests from #3948 unchanged, then refreshes the branch against current main. The replacement PR description and branch-refresh workflow were prepared with AI assistance and reviewed before posting.

This is the largest of the four GDPopt fixes I have open and it changes reported termination conditions, so it deserves the closest look. Specific points where I would like reviewer judgement:

1. Behavior change in reported status. Nonconvex LOA runs that previously returned optimal with LB == UB will now return feasible with one bound infinite. That is the intent of GDPopt LOA reports non-rigorous nonconvex bounds as optimal LB=UB #3947, but it is user-visible and may affect downstream code that keys on optimal.
2. Asymmetry between GDPopt and MindtPy. GDPopt gates the new behavior on both not _crossed_bounds_are_certified and _problem_may_have_nonrigorous_dual_bound(model). The MindtPy GOA path in bounds_converged() gates only on not _crossed_bounds_are_certified, so any crossed bound there becomes feasible. I would like a decision on whether MindtPy should carry the same model-structure gate.
3. GLOA vs GOA. GDPopt GLOA keeps _crossed_bounds_are_certified = True while MindtPy GOA is set to False, even though they are the analogous global algorithms. That was deliberate — GLOA's certified behavior is covered by a regression test — but the inconsistency is worth an explicit maintainer decision.
4. Conservatism of the classifier. _problem_may_have_nonrigorous_dual_bound() is intentionally conservative: quadratic equality constraints and anything of degree > 2 or non-polynomial are all treated as possibly non-rigorous. Convex problems expressed in ways the classifier cannot certify will lose their optimal status.
5. The pure-Python Jacobi fallback. It exists so the classification works without NumPy. Sampled eigenvalues were checked against NumPy and a no-NumPy regression test is included, but the rotation cap (50 * order**2) returning None on non-convergence — which is then treated as "not certified" — is a heuristic worth confirming.

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.

[bernalde]

Pushed f4c13fd52 — this resolves review points 2 and 3 in the PR description above, which flagged an inconsistency between the GDPopt and MindtPy halves of this PR. Rather than leaving them for a reviewer to arbitrate, I traced the cause and generalized the mechanism.

The inconsistency

The two toolkits have matching algorithm pairs, and the distinguishing property is how each builds its relaxation:

Algorithm	Relaxation	Rigorous dual bound?	Previously in this PR
GDPopt LOA	linearize at trial points	only if convex	certified = False — correct
GDPopt GLOA	McCormick envelopes	yes	certified = True — correct
MindtPy OA	linearize at trial points (add_oa_cuts)	only if convex	certified = True — wrong
MindtPy ECP	linearize at trial points (add_ecp_cuts)	only if convex	certified = True — wrong
MindtPy GOA	McCormick envelopes (add_affine_cuts, use_mcpp = True)	yes	certified = False — wrong

The flag was on the wrong MindtPy solver. GOA is the McCormick-based algorithm — the direct analogue of GLOA, which this PR deliberately leaves certified — while OA and ECP are the analogues of LOA and were left untouched.

What changed

• Extracted the curvature/convexity classification out of GDP_LOA_Solver into a new shared module, pyomo/contrib/gdpopt/nonrigorous_bounds.py.
• Both algorithm base classes now implement _problem_may_have_nonrigorous_dual_bound() once: return False when the algorithm is certified, otherwise run the model check. Individual solvers only declare _crossed_bounds_are_certified, so no algorithm carries its own copy of this logic.
• Moved the MindtPy flag: GOA is certified, OA and ECP are not.
• Gave MindtPy the model-structure gate GDPopt already had, so a crossed bound only downgrades to feasible when the model itself could not be certified convex. Previously any crossed bound in MindtPy downgraded unconditionally.

A side benefit of routing through the flag: certified algorithms now skip the convexity scan entirely instead of relying on a base method that returned False.

Effect on reported results

For MindtPy this is a behavior change in both directions, and both directions look like the intended fix:

• GOA no longer downgrades to feasible on crossed bounds. Its bounds are rigorous, so a crossing is numerical and optimal is correct.
• OA and ECP now downgrade to feasible on crossed bounds, but only for models that fail the convexity check. Convex models are unaffected.

Tests

TestMindtPyGOAResults became TestMindtPyCrossedBoundResults and now covers OA and ECP downgrading, OA on a convex model staying optimal, GOA preserving certified behavior, the flag matrix itself, and certified algorithms skipping the model scan. The GDPopt no-NumPy test was repointed at the new module.

• pytest -q pyomo/contrib/mindtpy/tests/test_mindtpy_no_discrete.py pyomo/contrib/gdpopt/tests/ → 115 passed, 35 skipped, 5 deselected
• pytest -q pyomo/contrib/mindtpy/tests/ → 58 passed, 32 skipped
• black --check on all nine changed files → 9 files would be left unchanged
• typos --config ./.github/workflows/typos.toml pyomo/contrib/gdpopt/ pyomo/contrib/mindtpy/ → clean

Still worth a maintainer decision

1. Module location. nonrigorous_bounds.py sits under pyomo/contrib/gdpopt/ because MindtPy already imports from pyomo.contrib.gdpopt in eight modules, so this follows existing precedent. If a neutral location is preferred, it moves cleanly.
2. MindtPy_FP_Solver is left at the default (certified). The feasibility pump is a primal heuristic rather than a bounding algorithm, and it does not reference bounds_converged or the dual bound directly, so I did not classify it. Worth a second opinion.
3. The original crossing evidence. The GOA test in the previous revision used primal 1011.6577899409375 against dual 1000.0 — a crossing of roughly 11.7 against a 1e-6 tolerance, which is far too large to be numerical noise. If that came from a real GOA run, then GOA's dual bound was not rigorous in that instance, and the underlying cause is a separate bug in the McCormick cut generation rather than something this flag should paper over. I could not reproduce the run to confirm it, so I have preserved the number in the tests but classified GOA on the basis of what the algorithm is designed to do. If anyone recognizes that instance, it is worth chasing separately.

[bernalde]

Following up on open point 3 from my previous comment, where I flagged that the crossed-bound figures used in the tests (primal 1011.6577899409375 against dual 1000.0, a gap of roughly 11.7 against a 1e-6 tolerance) looked too large to be numerical noise, and asked whether they came from a real MindtPy GOA run that would indicate a non-rigorous GOA dual bound.

They did not. The point is resolved, and no code change is needed.

Tracing the provenance:

1. The value originates in the reproducer in GDPopt LOA reports non-rigorous nonconvex bounds as optimal LB=UB #3947, which is a GDPopt LOA reproducer. The issue text labels it explicitly — "This mimics a nonconvex LOA state" — and constructs the state by hand:

   solver.LB = 1011.6577899409375   # feasible incumbent from a local NLP subproblem
   solver.UB = 1000.0               # non-rigorous OA/discrete bound that has crossed it

   The precise LB is an incumbent objective from GDPLib's HDA model; the UB is an arbitrary round number chosen to force the crossing. It is a synthetic fixture for exercising the result-finalization path, not a measurement.

2. The same pair is used by _setup_crossed_bound_state() in the GDPopt tests here. The MindtPy test added in the previous revision reused those same two numbers in a GOA-shaped unit test. So it was the LOA fixture copied across, not an independent GOA observation.

3. The number appears nowhere else in Pyomo — only in tests introduced by this PR.

4. Searching Pyomo issues for reports of MindtPy GOA, or MindtPy generally, producing crossed bounds returns nothing.

5. Consistent with this, the GDPLib HDA tracking issue (Refactor hda to fix benchmark issues SECQUOIA/gdplib#67, referenced from GDPopt LOA reports non-rigorous nonconvex bounds as optimal LB=UB #3947) lists LOA among the strategies causing benchmark problems, while GLOA is not checked off.

So there is no evidence that a McCormick-based algorithm ever produced a genuinely crossed bound, and no separate cut-generation bug implied. The reclassification in f4c13fd52 — GOA certified, OA and ECP not — rests on what each algorithm's relaxation actually guarantees, and nothing in the record contradicts it.

The figures remain in the tests as a synthetic fixture, which is all they ever were. Open points 1 (module location) and 2 (MindtPy_FP_Solver left unclassified) from my previous comment still stand for maintainer input.