-
-
Notifications
You must be signed in to change notification settings - Fork 400
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
Unexpected interactions with JuMP.Parameter
(in QPs)
#3947
Comments
The fundamental thing to remember is that JuMP is not presolving parameters, as you noted they appear as variables in the MPS files. If you use POI, all (except example 2) your problems would be properly solved as it pre-solves the parameters, giving you a smaller problem that does not include variable products. This is exactly what you are asking for. About example 1:Your objective function, Q = [
0 1
1 0
] with eigenvalues: julia> eigvals(Q)
2-element Vector{Float64}:
-1.0
1.0 Hence, it is not positive semidefinite hence this QP is not Convex, so HiGHS is not guaranteed to work: As noted here, it may not be as explicit as it could be: https://github.com/jump-dev/ParametricOptInterface.jl HiGHS solves convex QPs. About example 2,To say more we might need HiGHS devs help, but your problems is still not guaranteed to work, but it might just work. It does not surprise me it worked. The solver might be taking a different and more lucky path in this second example. About example 3,MPS does not support writing parameters. Probably the correct behavior was for it to give a warning, at least. If you try to print what is inside HiGHS, it works as expected: model = Model(HiGHS.Optimizer)
@variable(model, p1, set = Parameter(1.0))
@variable(model, p2 == 1.0)
write_to_file(model, "model.mps")
optimize!(model)
highs = unsafe_backend(model).inner
tmp_filename = "model.mps"
HiGHS.Highs_writeModel(highs, tmp_filename) and you get:
About example 4,Use POI, it will do the presolve you want. I have not dug deep into this as it is less minimal. possible JuMP side improvements
|
Note that your example is very similar to the parameters limitations section: https://jump.dev/JuMP.jl/stable/manual/variables/#Limitations Which might be boosted by a link to POI |
3 is a bug: jump-dev/MathOptInterface.jl#2653 I think 1, 2, and 4 are "expected" behavior, but I'll take a look to see if we can better catch these in HiGHS.jl. |
Thanks for the quick replies! I'll try to keep it "short" 😀
I'm presolving the models manually anyways, which is less overhead (since it does not have to be generalized) than
Yes I know. My point was that I kind of expect either:
If the solver applies (2.), then I was assuming the "expected" behaviour to be that it returns a proper termination status. It currently prints an error and then claims optimality in the returned status code. For related models it fails with
Regarding example 1: This is kind of related to this comment on a previous
The constraint removal just indicated to me that at least some minimal preprocessing is done on the model before solving it. Eliminating Note: Yes |
Any of those that you think I should report over at |
Example 1This is expected behavior and working as expected. You cannot rely only on
Example 2 and 4Expected behavior. The HiGHS QP solver has a number things that could be improved. But I don't think that better presolve is on the list anytime soon. They're focused on the MIP solver. |
The action item could be: we should add a tutorial on the specifics of POI to the JuMP docs. |
Note:
I was unsure which parts of this belong to
JuMP
,MOI
,HiGHS
itself (or maybeHiGHS.jl
), if you can point that out I'll happily split/move this issue to the appropriate repos. Sorry for the "collection" in a single issue, but I also didn't want to flood everything with multiple ones.Brief summary/overview of examples provided:
HiGHS
when usingParameter
.Parameter
, when using fixed variables - and a weird workaround.write_to_file
for a QP withParameter
, when writing to MPS.dimension mismatch
errors (and extreme iteration overhead) inHiGHS
when solving a QP withParameter
.All examples are run after
with
and showing the following commit info:
HiGHS 1.9.0 (git hash: 66f735e60)
.Note: Not sure if these issues only appear for QPs, had no time to test with other problem types.
Example 1
This is a MWE showing a wrong solution being found by
HiGHS
, printing an error, but then communicating optimality.which results in
with the following (shortened) output from
HiGHS
Example 2
I suspected the issue to arise from the use of
Parameter
, but this example shows that even a "normal" variable with bounds fixed to1.0
fails in the same way... until a superfluous constraint is added thatHiGHS
will disregard anyways.which (only when adding the constraint) gives the correct solution
Example 3
Writing a
JuMP
model to a MPS file "forgets" about the parameters, not preserving the bounds. Not sure if that is a problem arising from theJuMP
orMOI
side of things.lead to the following bound section, where I assume that
p1
should actually get the same fixed bound:Example 4
Running a small QP previously written to
highs_qp.mof.json
by running
leads to
dimension mismatch
errors in the (shortened) output, that originate fromsolveL
infactor.hpp
:To investigate, I manually replaced all
Parameter
s by their current value:which then shows
Not only does the error not occur anymore, it also needs considerably less iterations to solve the model. Not sure if these iterations actual cost a lot, but since it's 29 iterations overhead with just ending up twice in
solveL
, I assume that may impact larger models.Note: Deleting all
ParameterRef
constraints and fixing the parameter variables usingfix
to their values, while also adding "auxiliary constraints" as in example 2, does not change anything here. I have no idea how presolve works for the QP solver inHiGHS
, nor how a fixed bound (orEqualTo
) is actually passed via the API, but "substituting" variables that are constrained to a specific value seems like an "easy" thing to do on the solver's side?The text was updated successfully, but these errors were encountered: