translate to standard conic form

[madeleineudell]

Fill in the functions in conic problem.jl to correctly translate between three different standard cone formats, and from the Problem form into each standard cone form:

1) ConicProblem, following the standard described here

2) IneqConicProblem, following the same standard but allowing generalized inequality constraints Gx \leq h, so the indices in the variable cones refer to constraints rather than variables.

3) ECOSConicProblem, which is described here. (A translation from Problem to ECOSConicProblem is already implemented.)

[karanveerm]

I am not sure why we're doing this. I thought the goal of having a unified conic interface through mathprogbase was to make CVX.jl agnostic of issues like these? If anything, ECOS.jl, SCS.jl etc should have to worry about this and not us.

As such, we need to rethink certain design decisions anyway when we move to supporting exponential, SDP constraints etc and I am not sure how this would make it any easier.

[davidlizeng]

I think the Problem interface should stay the way it currently is. The job of the Problem type is to parse the problem into a canonical form that we think makes sense. We should however, separate solver specific functionality like stuffing matrices into different files. It makes sense to have something that translates from the canonical forms stored in problems to ECOS specific arguments or to some standard Conic interface that MathProgbase may want to see. These solver specific items should probably go under the solvers folder and not under problems.

In the far, far future, we may need to have different ways of building canonical forms, such as if we want to be able to use an ADMM based backend. When we get to that point, we will probably have to redesign the Problem type. But not until then.

[madeleineudell]

Yes, I think ultimately the code currently in conicproblem.jl should reside in MathProgBase. But we want our problem.jl interface to be solver agnostic, which currently it is not. (Witness the number of functions beginning with "ecos_" in that file.) For now, to factor out ECOS from our problem.jl file, it seems like we need our own translator back to ECOS format. It will also be important to be able to perform that translation to hook in SCS. Ideally, we can ultimately contribute our translator as a PR to MathProgBase.

[madeleineudell]

Ultimately, the solve method should abstract the solver away as much as possible. It could look something like this:

function solve!(problem::Problem, method=:ecos)
  # maximize -> minimize
  if problem.head == :maximize
    problem.objective = -problem.objective
  end

    cproblem, mapping_to_standard_form = ConicProblem(problem)

    if method == :ecos
        solution = solve(ECOSConicProblem(cproblem))
    elseif method == :glpk
        solution = MathProgBase.???(cproblem)
    else
        println("method $method not implemented")
    end

  # minimize -> maximize
  if (problem.head == :maximize) && (solution.status == "solved")
    solution.optval = -solution.optval
  end

    # Populate the problem with the solution
    problem.optval = solution.optval
    problem.status = solution.status
    problem.solution = solution

    if problem.status == "solved"
        populate_variables!(problem, mapping_to_standard_form)
        populate_constraints!(problem, mapping_to_standard_form)
    end
end

We should make sure that the solver specific functionality (any ecos_ function) lives in solvers/ecos.jl. Right now, it's gross that the mapping to conic form goes via "create_ecos_matrices". We need a generic version that targets the standard cone form we agreed on with the MathProgBase team:

type ConicProblem
    c::Array{Float64, 1}
    A::Array{Float64, 1}
    b::Array{Float64, 1}
    cones::Array # Array of (Symbol,Range) or (Symbol,Array{Integer}) tuples
end

We can get this as a translation from ECOSConicProblem, but it will be at the cost of introducing as many new variable as we had constraints. Which is maybe not so bad for now.

[IainNZ]

Hey CVX.jl team, Chatted to Miles and Joey today about how we can help you out. I'm going to give the following a go some time in the next week

1. Implement the abstract conic interface in MathProgBase
2. Implement said interface for https://github.com/jfsantos/ECOS.jl
3. (ambitious) hack CVX to use it. My goal is to replace src/solve/ecos.jl with this interface, and pull ECOS out of CVX entirely.
4. (only if I have time) add the conic interface to some of the existing Julia-wrapped solvers we have so CVX can at least solve LPs with them.

I think this is probably the most efficient use of everyones time, and once you have this you'll be able to copy-paste it/expand on it for SCS.

One other thing: I'd really like to move ECOS.jl to the JuliaOpt organization (if this is OK with @jfsantos) as it makes it easier for us to collaborate on and keeps all solver wrappers in one place. I personally don't have a problem with CVX.jl staying in cvxgrp, but if you ever want to move it over that'd be cool too. It'll be on the JuliaOpt site regardless.

[jfsantos]

I am completely fine with moving ECOS.jl to JuliaOpt. Unfortunately I still did not had the opportunity to work in the conic interface, but I am still interested in collaborating.

[IainNZ]

No problem @jfsantos , you've done plenty :)

[madeleineudell]

This issue is moot; conic form interfaces now live in MathProgBase.