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

added example adapted from MOSEK manual #1370

Open
wants to merge 2 commits into
base: master
from

Conversation

@ulfworsoe
Copy link

commented Jul 10, 2018

NOTE: This only work with MOSEK 9.0 (since it requires power cones)

@codecov

This comment has been minimized.

Copy link

commented Jul 10, 2018

Codecov Report

Merging #1370 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master    #1370   +/-   ##
=======================================
  Coverage   89.51%   89.51%           
=======================================
  Files          24       24           
  Lines        3413     3413           
=======================================
  Hits         3055     3055           
  Misses        358      358

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 647f228...1cf962d. Read the comment docs.

@constraint(model, [ b[i] - (A[i,:]' * d) ; (A[i,:]'*C)'] in MOI.SecondOrderCone(n+1))
end

det_root(model,C,t)

This comment has been minimized.

Copy link
@blegat

blegat Jul 10, 2018

Member

It should work with the LogDetConeTriangle once #1362 is merged

This comment has been minimized.

Copy link
@ulfworsoe

ulfworsoe Jul 10, 2018

Author

That sounds great! It would simplify it a bit.

Also, it hardcodes the Mosek solver and uses mode=JuMP.Direct, which I'm not sure is so pretty. Is there a way to let JuMP choose the solver based on the model type?

This comment has been minimized.

Copy link
@blegat

blegat Jul 10, 2018

Member

No, automatically choosing the solver was removed during the update to Julia v0.6.
See JuliaOpt/MathProgBase.jl#151
The new approach is to let the user choose the solver and then try to automatically bridge the constraints to match the types of constraints supported by the solvers instead of automatically selecting a solver that supports the types of the constraints created by the user.

This comment has been minimized.

Copy link
@ulfworsoe

ulfworsoe Jul 10, 2018

Author

Probably a more solid approach. Is there any consensus on what examples should do?

This comment has been minimized.

Copy link
@blegat

blegat Jul 10, 2018

Member

I don't think so. Currently the examples pick a solver.
What I usually do with Jupyter is creating different cells. Each cell sets optimizer to a different value and the user can run the cell he prefers in order to choose the solver.
Cc @joaquimg

@mlubin

This comment has been minimized.

Copy link
Member

commented Feb 25, 2019

@blegat @ulfworsoe Any plans to tidy this up for merging?

@blegat

This comment has been minimized.

Copy link
Member

commented Feb 25, 2019

I felt it was blocked by JuliaOpt/MathOptInterface.jl#406
The idea is to show how to the choice of solver and root-det vs log-det affects how the problem is reformulated by the bridges.
@ulfworsoe what do you think ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.