Skip to content
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

Add SCIP Persistent Support #3200

Open
wants to merge 39 commits into
base: main
Choose a base branch
from
Open

Add SCIP Persistent Support #3200

wants to merge 39 commits into from

Conversation

Opt-Mucca
Copy link

Fixes # .

None.

Summary/Motivation:

Adds support for SCIP persistent solving. Persistent solving uses the python interface to SCIP directly as opposed to the current standard that involves read and writing a temporary model file.

The new dependency that it introduces is PySCIPOpt

Changes proposed in this PR:

  • SCIPPersistent
  • SCIPDirect
  • Some new tests for the introduced features

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:

  1. I agree my contributions are submitted under the BSD license.
  2. I represent I am authorized to make the contributions and grant the license. If my employer has rights to intellectual property that includes these contributions, I represent that I have received permission to make contributions and grant the required license on behalf of that employer.

@Opt-Mucca
Copy link
Author

Two open questions left for this pull request:

  • Is the current standard usage of persistent solving through the APPSI? If so then I should consider adding that.
  • I avoided tinkering with the GitHub action workflow scripts. I'm not sure if it is appropriate to add a PySCIPOpt dependency there.

For info of how I tested the code:

  • pip install pyscipopt
  • python pyomo/solvers/tests/checks/test_SCIP{Persistent/Direct}.py

@mrmundt
Copy link
Contributor

mrmundt commented Mar 18, 2024

@Opt-Mucca - answering your questions:

  1. The current standard is APPSI, yes; however, the future standard is going to be using the persistent interface within pyomo.contrib.solver (the preview of the reworked solver interface system)
  2. If PySCIPOpt is needed in order to run tests, then yes, absolutely, it's appropriate. Happy to help with that if you'd like.

@Opt-Mucca
Copy link
Author

@mrmundt Thanks for the fast reply!

  1. After having a glance at pyomo.contrib.solver, it seems to overlap pretty heavily with the direct interfaces in pyomo.solvers.plugins. So that should save on work. I will probably avoid writing the APPSI functionality if there's soon to be a newer interface, but can do if there's demand.
  2. Help would be appreciated! I assumed the only changes needed were those that are present in the other PRs Added MAiNGO appsi-interface #3165 and [WIP] Add COPT support for Pyomo #2880 (replacing coptpy / maingopy with pyscipopt). If that's right then I can add those lines.

@mrmundt
Copy link
Contributor

mrmundt commented Mar 18, 2024

@Opt-Mucca - No problem!

  1. Sounds good! There will be inevitable changes for the new interface (e.g., configuration options, results object, solution statuses, etc.), but we hope that they aren't too miserable for porting.
  2. That's about it, yup! Make sure to consider both the pip and conda situations, though, because we test environments built by both types of package managers.

@Opt-Mucca
Copy link
Author

I have now added:

  • Some automatic documentation for SCIPPersistent similar to other solver interfaces
  • The pip instructions to the .github/workflows. (I avoided conda because I'm not familiar with it. I also only added PySCIPOpt via pip when using CPython)

Copy link
Contributor

@mrmundt mrmundt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for submitting this PR! Some comments from a quick pass.

Comment on lines 456 to 460
if not flag:
raise RuntimeError(
"***The scip_direct solver plugin cannot extract solution suffix="
+ suffix
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Design question: is it better to raise an error or to log (or print loudly) that other requests are being ignored?

(Note: I don't have a strong preference either way.)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would lean slightly towards the print loudly option, but can see the potential danger for users. As a larger preference though, I would like to stick to similar behavior with the other interfaces.

Comment on lines +32 to +37
try:
import pyscipopt

scip_available = True
except ImportError:
scip_available = False
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I theorize that @jsiirola may want this logic instead put in the import attempt code: https://github.com/Pyomo/pyomo/blob/main/pyomo/common/dependencies.py#L1037

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will ping @jsiirola again about this thought.

Comment on lines +33 to +38
try:
import pyscipopt

scip_available = True
except ImportError:
scip_available = False
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I theorize that @jsiirola may want this logic instead put in the import attempt code: https://github.com/Pyomo/pyomo/blob/main/pyomo/common/dependencies.py#L1037

@mrmundt
Copy link
Contributor

mrmundt commented Mar 19, 2024

@Opt-Mucca - Please make sure you're on the most recent version of black and run (in the root): black . -S -C --exclude examples/pyomobook/python-ch/BadIndent.py

@Opt-Mucca
Copy link
Author

@mrmundt Black should be run and all the issues responded to.

@mrmundt
Copy link
Contributor

mrmundt commented Mar 19, 2024

@Opt-Mucca - Spelling is the new failure. (You are suffering the same issue as all the core devs... The auto-linter and spell checker.)

@Opt-Mucca
Copy link
Author

@mrmundt TIL there are auto-linters that double as spell checkers. (I'll fix the spelling errors that come up each time the test fails. If it's just the two errors then I'm properly amazed.)

@mrmundt
Copy link
Contributor

mrmundt commented Mar 19, 2024

@Opt-Mucca - If you could have heard the griping in our weekly dev call when I introduced the spell checker...

@Opt-Mucca
Copy link
Author

@mrmundt I can imagine (would probably be guilty of griping even if makes sense)

For the currently failing runs: I've added a fix that should work, but I will ask some colleagues tomorrow. (I'm not the greatest the warm start code). The fixes raise some warning where a loaded solution has variables of incorrect values (this may stem from non specified variables having a default value of 0)

The current reason of the pipeline failure: SCIP was trying to load an invalid solution before checking for feasibility (I think this is a longstanding python error with the interface and one of the functions)

The added solution: I simply added a check on the feasibility of the solution before adding it to the solution storage.

I will check with colleagues, but I'm not sure on how SCIP handles partial solutions. I am not familiar or don't know if we have any functionality like Gurobi that tries to complete the solution. This also holds for trying to repair a given infeasible solution.

@Opt-Mucca
Copy link
Author

Support for partial solution loading is now added. The failed tests are now passing locally too.

@mrmundt
Copy link
Contributor

mrmundt commented Apr 9, 2024

@Opt-Mucca - If you need help with your tests, please let us know. We tend to ignore PRs until the tests are passing.

@mrmundt
Copy link
Contributor

mrmundt commented Jun 13, 2024

@Opt-Mucca - Our general thought process is "protect users from themselves." I would recommend converting them but also log / alert the user so they know the conversion is happening.

@Opt-Mucca
Copy link
Author

Opt-Mucca commented Jun 13, 2024

@mrmundt I've added a warning now for each time a constraint is added and the RHS / LHS needs to be changed.
I had to use type(x) == y because isinstance(x, float) also passes for np.float (didn't know that). The failed tests are now passing.

@Opt-Mucca
Copy link
Author

@mrmundt I'm not sure if the failing tests are because of my changes. Can I get a second opinion on that?

@Opt-Mucca
Copy link
Author

The latest change is pretty minor, but would mean that it's not backwards compatible to pyscipopt versions from years ago (I think compatibility would now be the last 2-3 releases). There was some basic missing functionality for retrieving the original constraints after starting / ending the solving process, and the Pyomo implementation was then giving some incorrect statistics.

@mrmundt mrmundt self-requested a review November 26, 2024 20:05
Comment on lines +32 to +37
try:
import pyscipopt

scip_available = True
except ImportError:
scip_available = False
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will ping @jsiirola again about this thought.

Copy link
Contributor

@mrmundt mrmundt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I meant to click "Approve" - whoops. I left a few comments but none of them are so substantial that they should hold up this PR. They are mostly stylistic.

Copy link

codecov bot commented Feb 19, 2025

Codecov Report

Attention: Patch coverage is 76.01547% with 124 lines in your changes missing coverage. Please review.

Project coverage is 88.56%. Comparing base (bb5f993) to head (d0df2fc).
Report is 12 commits behind head on main.

Files with missing lines Patch % Lines
pyomo/solvers/plugins/solvers/scip_direct.py 75.93% 109 Missing ⚠️
pyomo/solvers/plugins/solvers/scip_persistent.py 76.56% 15 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3200      +/-   ##
==========================================
- Coverage   88.62%   88.56%   -0.07%     
==========================================
  Files         880      882       +2     
  Lines      100661   101178     +517     
==========================================
+ Hits        89214    89608     +394     
- Misses      11447    11570     +123     
Flag Coverage Δ
linux 86.14% <76.16%> (-0.06%) ⬇️
osx 76.20% <75.19%> (-0.01%) ⬇️
other 86.66% <76.16%> (-0.06%) ⬇️
win 84.62% <75.58%> (-0.05%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@mrmundt
Copy link
Contributor

mrmundt commented Feb 19, 2025

FYI, the doc build/doc test failures are NOT RELATED. I have #3479 open to resolve it.

@Opt-Mucca
Copy link
Author

I added a minor change: I no longer check what type the LHS of a constraint is. I added it originally because pyomo supports numpy floats and ints being passed, and I observed some crashes in SCIP's model creation. I looked into this a month or two ago, and concluded that it only happens from np.version() < 2 and for LHS values. So I've just removed the check for the RHS. This should save many users getting spammed with warnings. Associated issues if anyone wants to help: scipopt/PySCIPOpt#937

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants