Fix lower bound calculation during ramp-up phase in parallel B&B #625
Conversation
During the ramp-up phase in parallel B&B, cuOpt was using the root objective as the global lower bound when the heap was empty. This is a pessimistic estimation that doesn't reflect the actual lower bounds calculated by active threads during ramp-up. Changes: - Use get_lower_bound() instead of root_objective_ fallback at end of solve() - Use get_lower_bound() in ramp-up logging instead of root_objective_ The get_lower_bound() function properly considers: - lower_bound_ceiling_ (updated during ramp-up) - Heap top (if heap is not empty) - All local_lower_bounds_ from active threads This ensures the lower bound accurately reflects the work done by active threads during ramp-up, not just the root objective.
|
@nguidotti please review |
|
Unfortunately, the calculation of the lower bound in the ramp-up phase cannot be solved by a simple code change (note that So, next time, please verify the effects of your changes before submitting a PR instead of copying the output of a LLM. Thank you. |
|
I wrote this patch myself, no generated code was used. The PR only replaces root_objective_ with get_lower_bound() in the ramp-up log and the final bound. I appreciate the technical feedback (I agree the change doesn’t solve the ramp-up issue and can mis-handle completed trees), but please keep review comments focused on the code, not personal assumptions. I’ll address the logic concerns in an updated revision. Thank You! |
|
I am sorry that I assume that you used a LLM (the way that you write seems like a LLM response). In any case, you should check the correctness of your changes by running the MIPLIB dataset and attaching the relevant logs. |
3 participants
Description
Fixed the lower bound calculation during the ramp-up phase in parallel Branch and Bound. Previously, cuOpt was using the root objective as the global lower bound when the heap was empty, which is a pessimistic estimation that doesn't reflect the actual lower bounds calculated by active threads during ramp-up.
Changes Made:
heap_.size() > 0 ? heap_.top()->lower_bound : search_tree.root.lower_boundtoget_lower_bound()root_objective_toget_lower_bound()in ramp-up loggingWhy This Fix Works:
The
get_lower_bound()function properly considers all sources of lower bound information:lower_bound_ceiling_(updated during ramp-up when threads encounter numerical issues)local_lower_bounds_from active threads (updated as threads solve nodes during ramp-up)This ensures the lower bound accurately reflects the work done by active threads during ramp-up, not just the pessimistic root objective.
Example Impact:
During ramp-up, if threads have solved nodes with lower bounds better than the root objective, the global lower bound will now reflect these improved bounds instead of falling back to the root objective.
Issue #445
Checklist
I am familiar with the Contributing Guidelines.
Testing
Documentation