argonne-national-laboratory / maximinopf.jl Goto Github PK

Since Mosek is commercial, it is not the best one to use for the public release. Let's use SCS for solving the continuous relaxation, for example

model=MaximinOPF.MaximinOPFModel(pm_data, SparseSDPWRMPowerModel; enforce_int=false)

Note that we use enforce_int=false.

I'm noting this issue for now, though I'm not working on it right away. This issue builds on some recent thoughts of @kibaekkim regarding the reformulation of the voltage magnitude bounds as soft constraints.

For SDP forms, there could be merit in providing a utility for reforming the voltage magnitude bound constraints as soft constraints with exact penalty terms for solution approaches that relax dual PSD constraints. When the full PSD cone in the primal problem is feasible, particularly the origin, due to the soft constraint reformulation, this could translate to favorable boundedness properties for the dual problem. I'll think about this more later.

I am creating this to follow up the issue in MOI: jump-dev/MathOptInterface.jl#1074

For the initial implementation,
Adding Variables, Replacing Objective function, Adding Constraints for the SOCWRConicPowerModel case

Coding the Depender's model

The purpose of this issue is to describe local changes to third party code. Where appropriate, these are also cross-referenced with issues in the third party repository.

In PowerModels, src/form/wrm.jl:

For SDP relaxation (without chordal decomposition)

function constraint_model_voltage(pm::AbstractWRMModel, n::Int, c::Int)
    _check_missing_keys(var(pm, n, c), [:WR,:WI], typeof(pm))
    WR = var(pm, n, c)[:WR]
    WI = var(pm, n, c)[:WI]
    bus_ids = ids(pm, n, :bus)
    #JuMP.@constraint(pm.model, [WR WI; -WI WR] in JuMP.PSDCone())
    JuMP.@constraint(pm.model, [i=1:length(bus_ids),j=i:length(bus_ids)], WI[i,j]+WI[j,i]==0) ### ADDED 6 Jan 2020
    JuMP.@constraint(pm.model, Symmetric([WR WI; -WI WR]) in JuMP.PSDCone())  ### ADDED 6 Jan 2020
end

For SDP relaxation with chordal decomposition:

function constraint_model_voltage(pm::AbstractSparseSDPWRMModel, n::Int, c::Int)
    _check_missing_keys(var(pm, n, c), [:voltage_product_groups], typeof(pm))
    pair_matrix(group) = [(i, j) for i in group, j in group]
    decomp = pm.ext[:SDconstraintDecomposition]
    groups = decomp.decomp
    voltage_product_groups = var(pm, n, c)[:voltage_product_groups]
    # semidefinite constraint for each group in clique grouping
    for (gidx, voltage_product_group) in enumerate(voltage_product_groups)
        _check_missing_keys(voltage_product_group, [:WR,:WI], typeof(pm))
        group = groups[gidx]
        ng = length(group)
        WR = voltage_product_group[:WR]
        WI = voltage_product_group[:WI]
        # Lower-dimensional SOC constraint equiv. to SDP for 2-vertex
        # clique
        #if ng == 2
        if false  ### ADDED 6 Jan 2020
            wr_ii = WR[1, 1]
            wr_jj = WR[2, 2]
            wr_ij = WR[1, 2]
            wi_ij = WI[1, 2]
            wi_ji = WI[2, 1]
            # standard SOC form (Mosek doesn't like rotated form)
            JuMP.@constraint(pm.model, [(wr_ii + wr_jj), (wr_ii - wr_jj), 2*wr_ij, 2*wi_ij] in JuMP.SecondOrderCone())
            JuMP.@constraint(pm.model, wi_ij == -wi_ji)
        else
            #JuMP.@constraint(pm.model, [WR WI; -WI WR] in JuMP.PSDCone()) ### REMOVED 6 Jan 2020
            JuMP.@constraint(pm.model, [i=1:ng,j=i:ng], WI[i,j]+WI[j,i]==0) ### ADDED 6 Jan 2020
            JuMP.@constraint(pm.model, Symmetric([WR WI; -WI WR]) in JuMP.PSDCone()) ### ADDED 6 Jan 2020
        end
    end
...

These two code segment modifications are needed for applying the Dualization.jl package, which requires the MOI PSD constraints to be of triangular form. The modifications are not reflective of anything wrong with the PowerModels.jl code, and so an issue is not brought up here. Rather, an issue requesting added support for MOI PSD constraints in square form is warranted.

The test script should test writing files fro CBF and SDPA formats. The current file write functions are not working, although the commit comment says test passed.
Related to #26

I am adding code coverage tools. To do so, I have requested the group to authorize the apps.

Test with a different combination of the input

This is being factored into the robust minmax model.

Beginning documentation of ongoing issue to handle the reassigning of actual flow bounds defined in PowerModels.jl to the target flow bounds.

Test with multiple budgets

I have the following warning message from the socp model:

┌ Warning: MathOptInterface.VariablePrimalStart() is not supported by MathOptInterface.Bridges.Constraint.SingleBridgeOptimizer{MathOptInterface.Bridges.Constraint.QuadtoSOCBridge{Float64},MathOptInterface.Utilities.Model{Float64}}. This information will be discarded.
└ @ MathOptInterface.Utilities ~/.julia/packages/MathOptInterface/RmalA/src/Utilities/copy.jl:140

It may or may not be critical.

Test with multiple network cases

Please create "Todo" items in the project page as for your plan ideally with timeline.

We need to publish this package as a public Julia package to finalize this development cycle.

The function is not defined: https://github.com/Argonne-National-Laboratory/MaximinOPF.jl/blob/master/src/utils.jl#L164

Is there any reason that MinimaxOPFModel returns PowerModels instead of JuMP.Model? Function MaximinOPFModel returns a JuMP.Model.

Coding the Attacker's model

Generating test input/output to determine the pass condition of the package implementation.

I am figuring out how to do this for creating tests for the feasibility problems.

Apply Brian Algorithm for multiple cases such as
SDPWRMPowerModel
SOCWRPowerModel
QCRMPowerMode

Branch Package is disconnected from master branch. Please resolve this.

We can integrate the CI tools to show the status of the project.

We may be able to use Github's basic CI tools for building and documentation.

https://juliadocs.github.io/Documenter.jl/stable/index.html

Sam: Setup software environment and software engineering matter
Brian: Describe the algorithm and its interface

Goal: Verifying the output of solving the minmax model mathematically.

Current situation: We are able to predict the output of the minmax with specific test cases, but not able to cover generic case.

The output of the issue: We wish to develop a mathematical way to verifying the implementation of the minmax model.

Test the MaximinOPF module other than case9.m for V&V

Now I'm testing an instance of the feasibility problem with case 57 with lines 41 and 80 cut. I expect the objective value to be around 0.7772. The line flow variables, called p and q in PowerModels, do not have flow limits, so they are given bounds of -Inf and Inf through JuMP/MOI. But Mosek does not like this, throwing

MOSEK error 1390: The lower bound specified is not a number (nan)

A simple solution would be just to set the bounds to +/- some large bound, but this may be dodgy from a numerical standpoint. Or I could find an artificial bound of sensible size.

Test multiple PowerModel options to evaluate the possibility to fit in our algorithm and solvers.

Provide clarification on the formulations being modeled, what are their inputs, what are their outputs when solved.

As the algorithm does not consider the voltage angles on buses and lines, the following questions arise:

1. Do we need to consider the voltage angle for the feasibility problem?
2. If yes, how to formulate the voltage angle and magnitude to use the current algorithm?

Function arguments are not listed or described in our documentation. For example,

model=MaximinOPF.MaximinOPFModel(pm_data, SparseSDPWRMPowerModel; enforce_int=true, rm_therm_line_lim=true)

Here, enforce_int and rm_therm_line_lim are not documented. There may be more arguments and functions.