DC Baselines, Constraints, and Inf

[ElPiloto]

Hello, I have some related questions about the DC OPF baselines.

1. It seems that for many of the typical operating conditions, the DC approximation better minimizes the cost than the full AC solution. Is this expected? Does this factor in any constraint violations?

2. In some of the small angle difference cases, the objective values for the DC approximation are listed as "Inf". Does that indicate a constraint violation?

[ccoffrin]

Good questions.

• It seems that for many of the typical operating conditions, the DC approximation better minimizes the cost than the full AC solution. Is this expected? Does this factor in any constraint violations?

This is usually the case because the the DC approximation does not include line power losses (which typically account for 1-10% of power consumption in the system). If you do a more careful accounting for line power losses in an approximate model then you will find the objectives of a linear approximation can be a much closer match the AC model.

• In some of the small angle difference cases, the objective values for the DC approximation are listed as "Inf". Does that indicate a constraint violation?

This means that there is solution to linearized power flow equations and network constraints using the DC approximation (i.e., it is infeasible). The implication here is that the DC approximation is not sufficiently accurate to model this particular dataset.

[ElPiloto]

Thanks for the prompt response! I think I understand, maybe you can tell me if I've got any of the points below wrong (some of the steps I'm filling in myself so likely I've got something wrong).

• The DC approximation only provides a "partial solution" to the AC OPF problem (e.g. the DC approximation doesn't output reactive power which is needed to specify a full AC OPF solution).
• You can evaluate the feasibility of a partial solution with respect to the DC constraints. But because you don't have all of the variables that go into the full AC OPF formulation you can't evaluate whether a DC approximation is "AC feasible."
• In your point above about "inf", the DC approximation failed to even satisfy the DC constraints (or failed to converge when trying to optimize the DC approximation).
• You can still evaluate the cost of the DC approximation's partial solution. That is the reported DC "$/hr" metric.
• However, it is not a like-for-like comparison to compare the DC solution's cost against the AC solution costs because one is a partial solution and the other is a full solution.

And I guess that if all of those points hold, then it doesn't really make sense to compute the optimality gap between the DC "partial solution" and the full AC OPF solution. And that's really what I've been trying to understand when looking at the baselines.md file. I naively thought that you should be able to compute whether a DC approximation is AC-feasible, but I'm not sure how you would get the missing values to complete the DC partial solution and being to compute AC-feasibility.

[ccoffrin]

What you outline here is mostly correct. The one clarification I would make is that making the DC solution AC feasible is more than just finding the "missing variables" you have to adjust the active power too, to make it feasible. The DC approximation is also not a relaxation of the AC equations. Relaxations are a specific mathematical property that does hold for approximations of some equations. You might find this tutorial video series helpful, https://arxiv.org/abs/1807.07227

[ElPiloto]

Thanks for the pointer to that video series (which I have watched) and thoughtful responses: this conversation has been really helpful! I'm going to close the issue now as we've definitely covered my questions.

I do have one final suggestion: is it possible to make available the script(s) that produce the baselines values? This will make it maximally transparent how these values are generated. That might be a tall order though.

[ccoffrin]

Glad to hear it.

Regarding replicating the baseline values. There is some documentation in the BASELINE.md about this. If you dig into the PowerModels docs you will see running the AC problem is basically,

# one time install
] add JuMP, PowerModels, Ipopt

# running a specific case
using JuMP, PowerModels, Ipopt
solver = optimizer_with_attributes(Ipopt.Optimizer, "tol"=>1e-6)
result = run_ac_opf("case_file.m", solver)

For the other models that are discussed the PowerModels documentation and technical report should be sufficient. If you want to replicate the timing results you need to setup Ipopt.jl with the suitable MA27 linear algebra library, which appears in the Ipopt.jl docs.

I prefer keeping this documentation in PowerModels, rather than here, to reduce the maintenance burden to keep the documentation accurate. Hopefully the log of this issue will help interested folks to connect the dots.

[yasirroni]

Hi @ccoffrin, Could you share a separate repo that contains all the scripts to produce the julia results? Preferable that produce the table without the need to copy paste. I'm not julia programmer and it would really help if we are able to just run scripts.

[ccoffrin]

Hi @yasirroni, I don't really have some simple script I can share. The instructions above are about as simple as it gets and setting up Ipopt with MA27 is some additional work see this, https://github.com/jump-dev/Ipopt.jl?tab=readme-ov-file#hsl

You may find this repo as a useful as well, https://github.com/lanl-ansi/rosetta-opf