add cuopt direct solver #3620
Open
add cuopt direct solver #3620
+468
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3620 +/- ##
==========================================
- Coverage 89.19% 88.95% -0.24%
==========================================
Files 892 893 +1
Lines 103100 103339 +239
==========================================
- Hits 91956 91922 -34
- Misses 11144 11417 +273
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
mrmundt
reviewed
Jun 17, 2025
|
@Iroy30 - We've been able to make cuopt available on our internal testing machines. Can you please add tests to this PR? |
Iroy30
force-pushed
the
add_cuopt_direct_solver_plugin
branch
from
5dbf9dd to
6f64094
Compare
|
@mrmundt Thanks! We have added tests by enabling testing cuopt with LP and MILP capabilities in tests/solvers.py. Let us know if:
The following is the testing output I get relevant to cuOpt |
mrmundt
reviewed
Jul 2, 2025
Comment on lines
+60
to
+62
| t0 = time.time() | ||
| self.solution = cuopt.linear_programming.solver.Solve(self._solver_model) | ||
| t1 = time.time() |
There was a problem hiding this comment.
This is fine, but just so you're aware, we have this lovely little utility called TicTocTimer that you may want to consider using: https://pyomo.readthedocs.io/en/latest/api/pyomo.common.timing.TicTocTimer.html
|
@mrmundt What do you think about including this solver interface in pyomo.contrib.solvers? Would it make sense to pull-in new solver interfaces there, since that's where the new solver API is evolving? |
@whart222 - I am evenly split. Because we are still messing with what the new solver interfaces are going to actually do / how they will handle input and present output, I don't know if we want to put "new" solvers there or just "well-established" ones that we can robustly test / really know what they are supposed to do and return. |
|
@Iroy30 - I forgot to post this last week, but all of the failures are of the variety: |
|
@Iroy30 - Two more things:
|
Co-authored-by: Miranda Mundt <[email protected]>
…into add_cuopt_direct_solver_plugin
|
There are active improvements and fixes in cuOpt that are being worked on for the next release. I have skipped two above mentioned tests temporarily. The CI tests are passing for me locally. Hopefully all runs successfully in the pipeline as well. |
|
@mrmundt How do I trigger the CI ? |
I needed to click "Approve" on it, which I have now done! |
|
Looks like it is failing as cuOpt is not available in CI? I can reproduce the CI error when cuOpt package is not available in the environment. |
|
cuOpt is not available on GHA because the GHA runners (to our knowledge) do not have GPUs. The Jenkins job will run on machines with GPUs and cuOpt, and should exercise this interface. Regardless, solver interfaces must be able to be imported and instantiated (to check for availability) without a hard dependency on any "external" packages. A quick look at you implementation:
|
…into add_cuopt_direct_solver_plugin
|
@jsiirola Thanks John, aded the guards and updated version, hopefully this should fix the fails when cuopt isn't present. Should we re-run CI? |
|
@mrmundt I don't think the fail we see is cuOpt related. Can you confirm? |
|
We are gearing up for launch of cuopt 25.10, it would be great if we could review this PR before the new release so that pyomo & cuopt are in sync |
|
This is very close to the top of my list. When is the cuopt release? |
|
Thanks @michaelbynum ! It is October 10th |
mrmundt
requested changes
Sep 25, 2025
There was a problem hiding this comment.
Thanks, @Iroy30 , for this PR! I have done an initial review. Some high-level things to consider:
- Logging -
loggeris created but then never used. Consider places it may be helpful - "Magic" numbers - there are quite a few instances of numbers that aren't defined being used. We love documentation!
| extract_reduced_costs = False | ||
| for suffix in self._suffixes: | ||
| flag = False | ||
| if re.match(suffix, "dual"): |
There was a problem hiding this comment.
I could very well be wrong, but isn't this backwards? I thought it worked like:
# re.match(pattern, string), e.g.,
re.match("Hello", some_string)
There was a problem hiding this comment.
This logic is fragile, and is being reworked in the contrib.solver effort. It really doesn't need to use re at all and can just use ==.
That said, this logic was copied from other direct solvers (I saw it in CPLEX.py and GUROBI.py). It would be good to rework this, but given that it is consistent with the (questionable) behavior in other solvers, I will not complain if we leave it as is.
Comment on lines
+213
to
+217
| if not flag: | ||
| raise RuntimeError( | ||
| "***The cuopt_direct solver plugin cannot extract solution suffix=" | ||
| + suffix | ||
| ) |
There was a problem hiding this comment.
It might be better to log loudly than to raise an error here (no strong feelings either way, just wanted to offer an alternative option).
jsiirola
requested changes
Sep 29, 2025
Comment on lines
+189
to
+199
| for sub_block in block.block_data_objects(descend_into=True, active=True): | ||
| obj_counter = 0 | ||
| for obj in sub_block.component_data_objects( | ||
| ctype=Objective, descend_into=False, active=True | ||
| ): | ||
| obj_counter += 1 | ||
| if obj_counter > 1: | ||
| raise ValueError( | ||
| "Solver interface does not support multiple objectives." | ||
| ) | ||
| self._set_objective(obj) |
There was a problem hiding this comment.
This could be made simpler / more efficient:
Suggested change
| for sub_block in block.block_data_objects(descend_into=True, active=True): | |
| obj_counter = 0 | |
| for obj in sub_block.component_data_objects( | |
| ctype=Objective, descend_into=False, active=True | |
| ): | |
| obj_counter += 1 | |
| if obj_counter > 1: | |
| raise ValueError( | |
| "Solver interface does not support multiple objectives." | |
| ) | |
| self._set_objective(obj) | |
| objectives = list( | |
| block.component_data_objects(Objective, descend_into=True, active=True) | |
| ) | |
| if len(objectives) > 1: | |
| raise ValueError("Solver interface does not support multiple objectives.") | |
| elif objectives: | |
| self._set_objective(objectives[0]) |
| extract_reduced_costs = False | ||
| for suffix in self._suffixes: | ||
| flag = False | ||
| if re.match(suffix, "dual"): |
There was a problem hiding this comment.
This logic is fragile, and is being reworked in the contrib.solver effort. It really doesn't need to use re at all and can just use ==.
That said, this logic was copied from other direct solvers (I saw it in CPLEX.py and GUROBI.py). It would be good to rework this, but given that it is consistent with the (questionable) behavior in other solvers, I will not complain if we leave it as is.
Comment on lines
+273
to
+274
| self.results.problem.upper_bound = solution.get_primal_objective() | ||
| self.results.problem.lower_bound = solution.get_primal_objective() |
There was a problem hiding this comment.
This implies convergence to a MIP gap of 0... I think this needs to be something like (assuming get_dual_objective() is a real thing):
Suggested change
| self.results.problem.upper_bound = solution.get_primal_objective() | |
| self.results.problem.lower_bound = solution.get_primal_objective() | |
| if self._solver_model.maximize: | |
| self.results.problem.upper_bound = solution.get_dual_objective() | |
| self.results.problem.lower_bound = solution.get_primal_objective() | |
| else: | |
| self.results.problem.upper_bound = solution.get_primal_objective() | |
| self.results.problem.lower_bound = solution.get_dual_objective() |
|
The errors we are seeing on Jenkins are segfaults: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #3626
Summary/Motivation:
Add cuOpt math optimization (includes LP and MILP) solver backend to Pyomo so users can solve pyomo models with cuOpt
Changes proposed in this PR:
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: