Problem Formulation Conventions

[ccoffrin]

Based on @frederikgeth's most recent PR, https://github.com/lanl-ansi/ThreePhasePowerModels.jl/pull/60, I am wondering if it would be better if the ThreePhase problem formulations adopted the following convention,

1. when we define an three-phase function (i.e. _tp_) then the conductors are handled inside that function
2. when we use a function from PowerModels or a function that is always separable by conductor, then we pass the conductor as an argument.

Below is an example of how this might work. For many formulations the _tp_ variants will likely just delegate to some PowerModels base function, but for the more advanced formulations they may do other things.

The goal here would be able to support a wide variety formulation variants with a shared problem specification, and reuse PowerModels base implementation, as much as possible. @frederikgeth if we adopted this convention, would you be able to eliminate the mat problem variants you propose in https://github.com/lanl-ansi/ThreePhasePowerModels.jl/pull/60?

Thoughts?

function post_tp_opf(pm::GenericPowerModel)
    variable_tp_voltage(pm)

    for c in PMs.conductor_ids(pm)
        PMs.variable_generation(pm, cnd=c)
        PMs.variable_branch_flow(pm, cnd=c)
        PMs.variable_dcline_flow(pm, cnd=c)
    end

    constraint_tp_voltage(pm)

    for i in ids(pm, :ref_buses)
        constraint_tp_theta_ref(pm, i)
    end

    for i in ids(pm, :bus), c in PMs.conductor_ids(pm)
        PMs.constraint_kcl_shunt(pm, i, cnd=c)
    end

    for i in ids(pm, :branch)
        constraint_ohms_tp_yt_from(pm, i)
        constraint_ohms_tp_yt_to(pm, i)

        for c in PMs.conductor_ids(pm)
            PMs.constraint_voltage_angle_difference(pm, i, cnd=c)

            PMs.constraint_thermal_limit_from(pm, i, cnd=c)
            PMs.constraint_thermal_limit_to(pm, i, cnd=c)
        end
    end

    for i in ids(pm, :dcline), for c in PMs.conductor_ids(pm)
        PMs.constraint_dcline(pm, i, cnd=c)
    end

    PMs.objective_min_fuel_cost(pm)
end

[pseudocubic]

I think this is a good idea if we will be relying more heavily on matrix formulations in constraints, which I strayed away from early on due to their inability to be used in NLconstraint (is this still the case? can matrix formulations still only be used in constraint?).

[frederikgeth]

I am also in favour of a shared problem definition! I'll update accordingly. I don't foresee any problems eliminating the mat constraint variants extending your updated problem definition to the BFM variant.

Matrix expressions are still not supported in @NLconstraint. But debugging an equivalent scalar formulation will be hard without having a baseline. So I prioritised this. Also, for supporting more than 3 conductors, the matrix-based formulations may make development a bit easier.

[ccoffrin]

Great.

As in PowerModels, we can have two branches in the type hierarchy one that targets conic / matrix formulations and the other that is QCQP/NLP.

I agree that having a baseline to compare to will help build and debug equivalent formulations.

[pseudocubic]

This seems to be resolved, closing

[ccoffrin]

Still work to be done. :-)

[pseudocubic]

Ah, I misread part of the original post just now. For future reference for myself, functions like constraint_ohms_tp_yt_from(pm, i, cnd=c) used in e.g. the tp_opf problem specification still need to be rewritten such that cnd=c is not passed as an argument, but handled inside of the function

[ccoffrin]

I am not 100% sure that is the best solution, this issue is reminder to think about this in general and try to find a clean and intuitive design.

[frederikgeth]

I'm experimenting here with how improve the matrix-based problem definition and the use of matrix variables for generators/loads and matrix equations for nodal KCL. I'll come back to this afterwards with lessons learned.