-
Notifications
You must be signed in to change notification settings - Fork 107
Forward-merge branch-25.05 into branch-25.08 #64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Only consider the first two fields in the client version. Without this change the service will report that the version is a bad format, which is not necessary in this case.
|
FAILURE - Unable to forward-merge due to an error, manual merge is necessary. Do not use the IMPORTANT: When merging this PR, do not use the auto-merger (i.e. the |
This PR fixes two bugs discovered while testing the AMPL interface: 1) We weren't correctly calculating the objective constant when presolve eliminated variables on a maximization problem. Thanks to Alice for the quick fix! 2) We had an undefined memory access on the number of nodes and simplex iterations when solving a MIP at the root node. --------- Co-authored-by: Ramakrishnap <[email protected]>
This PR aims at fixing the invalid operation while there is a graph capture we sometimes see when using batch solve. Solution is to use a regular instead of a non-blocking stream to make sure that if any operation (like a cudaFree from Thrust) is being launched on the default stream, it will wait for all other operations on other stream to finish first, preventing any cudaMalloc/Free while another stream might be doing a CUDA Graph capture.
This PR adds the string parameter CUOPT_USER_PROBLEM_FILE = "user_problem_file". By default the parameter is the empty string "". If the parameter is set by the user to something other than the empty string, we will write out an MPS file containing the LP or MIP. This is very useful when trying to debug interfaces like CVXPY where the interface between CVXPY and cuOpt may have performed transformation to the user problem. This allows us to reproduce failures on the engine side directly from the MPS file without needing Python scripts.
<!-- Thank you for contributing to cuOpt :) Here are some guidelines to help the review process go smoothly. 1. Please write a description in this text box of the changes that are being made. 2. Please ensure that you have written units tests for the changes made/features added. 3. If you are closing an issue please use one of the automatic closing words as noted here: https://help.github.com/articles/closing-issues-using-keywords/ 4. If your pull request is not ready for review but you want to make use of the continuous integration testing facilities please label it with `[WIP]`. 5. If your pull request is ready to be reviewed without requiring additional work on top of it, then remove the `[WIP]` label (if present) and replace it with `[REVIEW]`. If assistance is required to complete the functionality, for example when the C/C++ code of a feature is complete but Python bindings are still required, then add the label `[HELP-REQ]` so that others can triage and assist. The additional changes then can be implemented on top of the same PR. If the assistance is done by members of the rapidsAI team, then no additional actions are required by the creator of the original PR for this, otherwise the original author of the PR needs to give permission to the person(s) assisting to commit to their personal fork of the project. If that doesn't happen then a new PR based on the code of the original PR can be opened by the person assisting, which then will be the PR that will be merged. 6. Once all work has been done and review has taken place please do not add features or make changes out of the scope of those requested by the reviewer (doing this just add delays as already reviewed code ends up having to be re-reviewed/it is hard to tell what is new etc!). Further, please do not rebase your branch on main/force push/rewrite history, doing any of these causes the context of any comments made by reviewers to be lost. If conflicts occur against main they should be resolved by merging main into the branch used for making the pull request. Many thanks in advance for your cooperation! --> This adds jobs to push/publish nightly packages and also fixes nightly testing to wait for the build workflow to complete first.
…y documentation (#77) Adding details on third party modeling languages and providing details on how to install nightly packages for latest development build. --------- Co-authored-by: Chris Maes <[email protected]>
Forward-merge triggered by push to branch-25.05 that creates a PR to keep branch-25.08 up-to-date. If this PR is unable to be immediately merged due to conflicts, it will remain open for the team to manually merge. See forward-merger docs for more info.