lanl-ansi / powermodels.jl Goto Github PK

Report an error for edges that have the same to and from buses.

To make GenericPowerModel more extensible.

Possibly remove ext.

There is significant repeated code in expansion planning line constraints (i.e. _ne) and OTS on/off constraints (i.e. _on_off).

See if there is a clean way of avoiding this replication without excessive engineering.

Fix broken build.

Add naming conventions to constraints to assist users in understanding the JuMP model.

Add unit tests to test code snippets in docs.

For example, in the SOC relaxation, should the output Bus Phase Angles absent, NaN, 0?

Add TNEP to list of supported models, also use checkout instead of clone for to get the current development version.

To more readily support multi-time models.

I propose the following a standard naming convention for the polar and rectangular variable spaces, let "v" be a complex number, then:

• vm - magnitude of v
• va - angle of v
• vr - real component of v
• vi - imaginary component of v

When parsing .m files, if a generator bus type is incorrect (e.g. type 2 with no generators) fix it.

Key use case, is running an AC-PF solve on a non-NESTA Polish case (e.g. case2737sop.m).

make the "std gen cost: ..." message a warning instead of stdout.

Setup inline code documentation and ReadTheDocs integration.

add something reasonable here.

Functions that modify their inputs typically have an exclamation point at the end of their names, to help them stand out. I can make a PR if you would like to adopt this convention.

By default JSON.parse returns Dict{UTF8String, Any} and we typically use Dict{AbstractString, Any}.

1. Figure out why a function of Dict{AbstractString, Any} cannot accpt an argument of Dict{UTF8String, Any}.

2. Migrate code to a robust solution, no types?

3. remove special type cases from JSON.parse() calls

The variable_* functions should return some data structure including all of the variables they have added to the model.

The key challenge here is the type of data structure, as JuMP's @varaible macro can return a single variable, an array of variables, or a dict index-variable mapping.

Develop an example of using SLP in PowerModels.

Add Bibtex citations for the orginal proposal of specific formulations

See if caching parsed versions of the model data can improve the speed of running package tests.

Extend the split_line function in the Matpower parser to support splitting lines with multiple single-quoted string values.

Add unit tests for all Matpower parser error messages.

Update, objective_min_fuel_cost{T <: AbstractConicPowerFormulation}(pm::GenericPowerModel{T}) in objective.jl.

The key is to define the min on a norm form.

The various Int(x) calls may not be necessary.

When parsing .m files these fields are already parsed to Int. When parsing .json these values may come in as Int, Float, or Number. Needs to be investigated.

move some models over to open source integer solvers, such as Pajarito.jl

similar to variables.

Add flag for per-unit and transformer taps.

When reading in json, apply standardize_cost_order(data), unify_transformer_taps(data) or not, based on these flags.

In constraint_active_loss_lb, p_fr and p_to are defined identically:

    p_fr = getvariable(pm.model, :p)[f_idx]
    p_to = getvariable(pm.model, :p)[f_idx]

This is also the case for v_fr and v_to, and q_fr and q_to in constraint_reactive_loss_lb:

    v_fr = getvariable(pm.model, :v)[f_bus]
    v_to = getvariable(pm.model, :v)[f_bus]

    q_fr = getvariable(pm.model, :q)[f_idx]
    q_to = getvariable(pm.model, :q)[f_idx]

Once #9 is resolved, the number of elements returned from all variable_* calls should be exactly equal to the variables in the JuMP model. And a similar property should be true for the constraint_* calls.

A simple and generic way to test the return value implementation correctness is to test that the total number of returned constraints and variables are consistent with the internal JuMP model.

Once this is working test for Julia v0.6 compatibility.

Add to relaxation schemes.

It would be nice to be able to support mixtures of tabs and spaces. For example see.

Consider adding a helper function to do getvariable(pm.model, :loading)[i]. Along the lines of getvariable(pm, :loading, i)

In light of recent changes can constraint_complex_voltage_ne{T <: AbstractWRForm} be made cleaner? Like constraint_complex_voltage_on_off{T <: AbstractWRForm}?

Make an easy way to test if a solution is feasible for a given model.

This helps in the sparse application of input and output data files.

Use cases

• modifying the internal data after loading
• specifying solution data

Feature idea.

Optimal power models have traditionally only been done at the bulk power level. But with distributed generation and more advanced volt-var control, there's more opportunity to benefit from optimal models at the distribution level. To do that best, models need to include three phases and include single and two-phase lines and loads..

See if there is a clean but high performance way of doing this.

in, function constraint_active_ohms_yt_on_off{T <: AbstractDCPLLForm}(pm::GenericPowerModel{T}, branch) add c4 = @constraint(pm.model, p_fr + p_to >= 0).

Double check that a DC OPF with Line Losses is actually imposing losses.

See if this can be simplified and if the the generic per-unit / mixed-units functions can be applied.

Add checks to the appropriate constraints to check angle limits are within +/- pi/2.

Add a special documentation guide / tutorial for developing new variable formulations and problem specifications.

In Matpower data files, add support for having semicolons in strings.

Add parsing for bus_names in Matpower parser.

Add a test case with small asymmetrical angles, i.e. the outcome of bounds propagation.

Make sure SOC, QC, and SDP models work on this (i.e LNCs are not breaking stuff).