lanl-ansi / powermodels.jl Goto Github PK

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

Use cases

• modifying the internal data after loading
• specifying solution data

Add to relaxation schemes.

add something reasonable here.

To make GenericPowerModel more extensible.

Possibly remove ext.

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

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

Add unit tests to test code snippets in docs.

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

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

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

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

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

Setup inline code documentation and ReadTheDocs integration.

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).

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.

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

Add unit tests for all Matpower parser error messages.

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

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

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.

Add parsing for bus_names in Matpower parser.

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.

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

Develop an example of using SLP in PowerModels.

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.

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

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

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

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

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

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.

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

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.

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.

Fix broken build.

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).

Add Bibtex citations for the orginal proposal of specific formulations

similar to variables.

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]

To more readily support multi-time models.

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

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

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

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

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..

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