-
Notifications
You must be signed in to change notification settings - Fork 0
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
Design Gurobi optimization worker #8
Comments
Mark is going to start this up again. Sebastiaan will send the startup info to Mark. We need someone from the (TNO) business to tag along as TNO will need to buy a license for its mapeditor environment. We will ask TPG to tag along as well. Stephan is going to ask around to see whom from TPG will accompany this process. Reason we will join: Gurobi has multiple license forms (standalone containers and each container has a license, embed Gurobi in one of our containers, use a central calculation server) and we need to see which ones we need and can support. |
We have evaluated Gurobi with a WSL license. In short, the license file allows a number of instances so this file may be shared by multiple containers. Also, overlap between usages (e.g. rolling updates, cancelling one task and starting a new one but the first session will overlap the next session) is allowed for a short time to. This solves any issues we may have for short overlaps. Main tasks that are still necessary to fit Gurobi in our architecture is:
|
Proposed design to handle multiple types of tasks at a single worker: At the internal SDK:
At the orchestrator:
At the optimizer worker:
At omotes system:
|
@MichielTukker Could you provide a review of this proposal? Thanks! |
As discussed offline. While it's a change in the worker function (from 1 workflow per worker to possibly multiple workflows per worker), this allows the party hosting the omotes backend to provide all Gurobi workflows with the minimum number of Gurobi licenses. 1 suggestion: I think the |
Good idea! Makes it more flexible as well as you could potentially have both highs & gurobi workflows in the same workflow (although it would be nonsensical in our situation) and it makes it simpler. This would be a pattern that is reusable across other workers as well. |
@MichielTukker Notes from Gurobi eval including the logs you requested (license expired & license missing). RuntimeError is used for all Gurobi exceptions caught/generated by Casadi in Python. We are going to need to parse the message partially to figure out which error happened... How to get it to work
Test performed with:
Questions:
Running too many instancesGurobi appears to provide a LOT of leeway, where it would allow a single license to utilize multiple sessions at once. Licensing sessions are 2xlicensed amount + 1 (so use 4 instances to break it!) and 30 minutes for 2x licensed amount. Support for centralized calculation server.
No license installed
Expired license installed
Resource usage comparisonPoC tutorial (small ESDL)
Ronald (medium ESDL)
graph_hdemand (larger ESDL)
Conclusions
|
Good to know. At least the RuntimeError message format is predictable, "Flag: : " can be parsed to present an informative error message for the user |
Ask Martijn to lead the purchase order for license.
The text was updated successfully, but these errors were encountered: