Exporting dual solution

[mtanneau]

PowerModels doesn't export duals by default, which we need. Unless PM implements that functionality, the fastest way for us to have it is to re-implement the ACOPF model ourselves.

Tracker: https://github.com/lanl-ansi/PowerModels.jl/issues/409

[ccoffrin]

I am definitely open to adding this into PowerModels. It will increase the maintenance burden to some extent, so I want to learn a little bit more about the use case before putting the required time into this.

If you would like to move forward without an update in PowerModels, a from scratch implementation of the canonical AC-OPF problem that is constructed by PowerModels can be found here, https://github.com/lanl-ansi/PowerModelsAnnex.jl/blob/master/src/model/opf.jl#L7-L134

A simpler version of the model which matches the PGLib spec can be found here, https://github.com/lanl-ansi/rosetta-opf/blob/main/jump.jl

[mtanneau]

We use the full dual solution for multiple things, such as:

• studying & learning active sets of constraints, for which the dual information is valuable
• learning dual solutions
• evaluating lagrangian functions

[mtanneau]

It's not a bad thing to have a full ACOPF formulation implemented here. I'll take the implementation from rosetta-OPF so that we stay as close to PGLib as possible.

[mtanneau]

@ccoffrin is there a convention/documentation of the keys/names you use when exporting dual solutions in PowerModels?

Looking at https://github.com/lanl-ansi/PowerModels.jl/blob/master/test/output.jl, I see things like"lam_kcl_r" / "lam_kcl_i" and "mu_sm_fr" / "mu_sm_to". I'd like to stick as close as possible to the conventions in PowerModels.

[ccoffrin]

@mtanneau we have not established a clear cut convention on these yet, so very much open to your suggestions in this regard. Looking at these they are also not updated to the latest PowerModels naming convention.

The draft idea was the following, {lam,mu}_{constraint short name}

The idea for {lam,mu} was to indicate the duals for equality and inequality constraints respectively. Maybe not a good idea.

For the power balance constraints (called kcl here), I would now use, lam_pb_real and lam_pb_imaginary following the latest conventions (pb being short for power balance). mu_sm_from and mu_sm_to seem reasonable to me given the latest naming conventions but we could also consider mu_tl_from where tl is short for thermal limit.

There is unfortuently no clear doc on the naming conventions but looking at these two files can give a good impression of what is used,

https://github.com/lanl-ansi/PowerModels.jl/blob/master/src/core/variable.jl https://github.com/lanl-ansi/PowerModels.jl/blob/master/src/core/constraint_template.jl

[mtanneau]

Thanks! As long as it's documented and not too unintuitive, I'm fine :)

Distinguishing between equality and inequality constraints might actually be a good idea. I can see that being useful, e.g., when using dual solutions to study active sets. For buses, we will have power balance (active/reactive), and voltage magnitude (& angle?) lower/upper bounds. Seeing a lambda and a mu is likely to reduce the risk of confusion over which is which.

Since we store duals at the component level, e.g., each bug/generator/branch has its own dual variable in the solution, I think short constraint names are also fine. I'll go over the current PR and adjust the names to match what you describe above.

[mtanneau]

The solution format has been implemented in #16.

primal/dual variable identifiers are described here.