Formulations

The AC power flow equations are non-convex. Combined with binary switching variables, the exact problem is a MINLP — solvable, but slowly. The package therefore implements several formulations that trade exactness for tractability, and this page is about choosing between them.

Overview

AC polar (ACPPowerModel)

The exact non-convex formulation. Voltages in polar coordinates, full AC branch equations, DC grid in its exact quadratic form. Bilinear switch-voltage coupling constraints are reformulated with big-M so the continuous relaxation stays tractable.

Use it when: the case is small, or you need a reference solution to validate a faster model against.

Because the underlying NLP is non-convex, Juniper returns a local optimum. There is no global optimality guarantee, even when the solver reports success. The optimized topology is still valid and still reduces cost — it just may not be the best possible topology.

LPAC approximation (LPACCPowerModel)

The recommended default. Unlike the classical DC approximation, LPAC retains voltage magnitudes and reactive power, so it represents the physics well enough that its topologies survive an AC feasibility check. It uses a piecewise-linear approximation of the cosine term and a Taylor expansion for the remaining nonlinearities.

This is the Cold-Start variant: target voltages Ṽ = 1 p.u., with power flows expressed through the voltage magnitude change $\phi_{i}$ − $\phi_{j}$. In this package it is built as a convex-quadratic model, following the PowerModels.jl implementation, for solver efficiency.

Why it is the default:

• 10–200× faster than the exact MINLP on the published cases
• topologies are almost always AC-feasible
• captures most of the achievable saving

Being an approximation rather than a relaxation, its objective is neither an upper nor a lower bound on the true optimum, and its feasibility is not guaranteed. Always run the AC feasibility check.

DC approximation (DCPPowerModel) -> to be refined further

The classical active-power-only linearization. Constraint implementations exist in src/formconv/dcp.jl and src/formdcgrid/dcp.jl, but this path is not exercised by the reference paper and is not validated here.

The known problem with DC-based topology optimization is well documented in the literature: solutions frequently turn out AC-infeasible, and because the DC model is an approximation rather than a relaxation, its objective is not a valid bound either. If you need speed, LPAC gives you comparable tractability with far better physical fidelity.

SOC relaxation (SOCWRPowerModel) -> to be refined further

Lifts the voltage products into a higher-dimensional W-space:

{U^{m}_{i}}^{2} $\rightarrow$ W_{i}
{U^{m}_{i}}^{2} \cdot {U^{m}_{i}}^{2} $\rightarrow$ W_{ij}
{(U^{dc}_e)}^{2} $\rightarrow$ W^{dc}_{e}  
$U^{dc}_{e} \cdot U^{dc}_{f}$ $\rightarrow$ $W^{dc}_{ef}

which convexifies the branch flow equations into second-order cone constraints. Solvable by MISOCP solvers, and a valid lower bound on the exact problem.

In practice, on the published test cases, SOC-BuS does not find beneficial splits — it returns the original topology. It is useful for bounding, not for generating topologies.

QC relaxation (QCRMPowerModel) -> to be refined further

Uses the same W-space lifting plus convex envelopes around the trigonometric and bilinear terms, built with McCormick relaxations. Tighter than SOC, at higher computational cost.

For the DC part of the grid, the Bus Injection SOC and QC relaxations are mathematically equivalent, so the difference between the two shows up only on the AC side.

Same practical caveat as SOC: on the tested cases it leaves the topology unchanged.

Support matrix

~ = code exists, not validated. OTS is implemented only for the exact formulation; the same relaxation approach would apply, but it has not been done here.

Empirical comparison (from the main paper)

From the reference paper, case5_acdc.m with all AC busbars splittable:

Scaling to larger cases, AC busbar split:

At 3120 buses the exact model takes three and a half hours. LPAC takes nine minutes.

Choosing

• Small case, need a reference → ACPPowerModel
• Screening many busbars, or a large network, the one I built my PhD on → LPACCPowerModel + feasibility check
• Production workflow → LPAC for search, ACP to confirm the final candidate