-
-
Notifications
You must be signed in to change notification settings - Fork 395
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
Better error for unsupported constraint when the optimizer is provided at optimize!
#1504
Comments
Why don't bridges work when the optimizer is provided in |
Because the bridges are applied on top of the CachingOptimizer. So when constraints are added and no optimizer is set yet, the caching optimizer says that everything is supported and nothing is bridged. One solution is to make bridging also work through the Allocate-Load API in which case, bridges will also work on-the-fly for solvers not supported |
CachingOptimizer was intended to be the JuMP The allocate-load API is not nearly as well documented as the rest of MOI and intrinsically more complicated which together make it about 5x harder to understand than the plain |
Yes, we could do that but it would be nice to have a way to check whether the optimizer supports |
That seems like a reasonable feature to add. Maybe a trait that the optimizer can implement? |
Yes, we could even (optionally?) have no caching optimizer at all if the solver implement the trait. |
Will be fixable once jump-dev/MathOptInterface.jl#561 is merged and MOI is released. |
When the optimizer is given in the
Model
constructor, unsupported added constraint are either bridged or throw an helpful error:https://github.com/JuliaOpt/JuMP.jl/blob/500945cac4949dfd9e30cb0ca68450f19f4ff34d/src/constraints.jl#L202
If it is given in the
optimize!
call, a cryptic error is thrown instead.See jump-dev/SCS.jl#112
The text was updated successfully, but these errors were encountered: