NVIDIA / NVIDIA/cuopt

Follow-up: make WORK_LIMIT handling consistent in strong branching pseudo-costs

Open
#1,471 3 comments 0 reactions 1 assignee View on GitHub

@kaatish is already working on this.

Since Jun 26, 2026.

awaiting response
Dominant language
Cuda
Stars
1k
Forks
233
Avg merge
4d 4h
Merged PRs (30d)
95

Description

Summary

There is a pre-existing inconsistency in cpp/src/branch_and_bound/pseudo_costs.cpp around how dual_status_t::WORK_LIMIT is handled in strong-branching and reliability-branching code paths.

Today, some merge/validation logic treats WORK_LIMIT as a usable Dual Simplex outcome, but the corresponding objective-computation paths do not consistently compute and propagate an objective for that status. That can lead to a WORK_LIMIT result being selected as a Dual Simplex contribution while still carrying a NaN objective, which then prevents the expected pseudo-cost update.

Why this matters

Strong branching and reliability branching rely on consistent status/objective handling to produce valid pseudo-cost updates and branch scoring. If WORK_LIMIT is considered a valid partial result, the code should compute and carry the corresponding objective everywhere that status is accepted.

Affected area

  • cpp/src/branch_and_bound/pseudo_costs.cpp

Relevant logic includes:

  • is_dual_simplex_done(...)
  • strong branching result handling in strong_branch_helper(...)
  • trial branching result handling in trial_branching(...)
  • merge logic in merge_sb_result(...)

Requested follow-up

Make WORK_LIMIT handling consistent across all Dual Simplex strong-branching paths in cpp/src/branch_and_bound/pseudo_costs.cpp.

Specifically:

  • If WORK_LIMIT is intended to be a usable Dual Simplex result, include it everywhere the code currently accepts other usable partial outcomes such as ITERATION_LIMIT and CUTOFF.
  • Ensure the objective value is computed and propagated for WORK_LIMIT in the same places where that status is considered mergeable/consumable.
  • Verify that the resulting pseudo-cost update paths no longer silently skip valid WORK_LIMIT outcomes due to NaN objectives.

Acceptance criteria

  • WORK_LIMIT is handled consistently in status validation, objective computation, and merge logic for the affected strong-branching code paths.
  • No path can merge/select a Dual Simplex WORK_LIMIT result while leaving its objective as NaN.
  • The follow-up is handled separately from PR #1446 because this is a pre-existing issue.

Backlinks

Requested by @mlubin.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.