-
Notifications
You must be signed in to change notification settings - Fork 24
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 behavior switching between Mosek and SCS solvers -- different optimal values #269
Comments
For reference, here's the full output when run with Mosek:
and with SCS:
|
One more followup, explaining the example a little bit -- In the example we have 5 symbolic variables, Note that this optimization problem has a nearly-feasible solution with For fun, I ran with CSDP as well; it agrees (more or less) with SCS. Here's the output:
So, CSDP doesn't solve all the way, but it says that opt should be between 2.01 and 2.25, which is consistent with SCS but inconsistent with Mosek. |
It seems Mosek doesn't converge, the
|
Maybe I'm misreading the output of |
The bits to read are:
Mosek failed. It didn't find an optimal solution, and it isn't sure what the current solution values represent. Typically, we'd expect
|
a) thanks for the quick attention -- I really appreciate it!! |
In most cases, I would say trust Mosek over SCS and CSDP. If Mosek can't solve it and SCS and CSDP are reporting solutions, then it's likely that the solutions they report are incorrect, and that Mosek is "correct" in it being a difficult SDP to solve. |
Hi @samhopkins. Not sure if this helps, but regarding the output from the second-order solvers: we can't use the objective values early on to conclude that the optimal objective value is in some interval. It's normal for the primal/dual objectives to oscillate throughout the solve. |
Closing because this is not a bug in SumOfSquares.jl. Mosek doesn't converge for this problem. |
I am working on a problem involving optimizing a polynomial over an ideal. I've put together an SoS-style SDP for this, using SumOfSquares.jl. I'll give a full example replicating this behavior below, but the flavor of the thing is:
The weird thing is: I get different optimal values if i use
SoSModel(SCS.Optimizer)
versusSoSModel(Mosek.Optimizer)
. Unless I am misreading the outputs of Mosek and SCS, the difference in optimal values is well outside the error tolerance/duality gaps. I would love some help diagnosing this issue -- is this a bug in SoSTools? JuMP? My code?Here's the smallest counterexample I have so far:
On my machine, using SCS I get objective value
2.039893
, while using Mosek I get objective value2.9999121506536075
(i.e., 3, up to numerical error).Please let me know if there's anything else I can provide. In the meantime I'll start looking for a smaller counterexample.
The text was updated successfully, but these errors were encountered: