Follow-up: make WORK_LIMIT handling consistent in strong branching pseudo-costs
@kaatish is already working on this.
Since Jun 26, 2026.
- 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_LIMITis intended to be a usable Dual Simplex result, include it everywhere the code currently accepts other usable partial outcomes such asITERATION_LIMITandCUTOFF. - Ensure the objective value is computed and propagated for
WORK_LIMITin the same places where that status is considered mergeable/consumable. - Verify that the resulting pseudo-cost update paths no longer silently skip valid
WORK_LIMIToutcomes due toNaNobjectives.
Acceptance criteria
WORK_LIMITis 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_LIMITresult while leaving its objective asNaN. - The follow-up is handled separately from PR #1446 because this is a pre-existing issue.
Backlinks
- Reported from PR #1446: https://github.com/NVIDIA/cuopt/pull/1446
- Review discussion: https://github.com/NVIDIA/cuopt/pull/1446#discussion_r3453442541
Requested by @mlubin.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.