Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

possible issue with computation of branch flow estimates #3

Open
rdzman opened this issue May 22, 2024 · 2 comments
Open

possible issue with computation of branch flow estimates #3

rdzman opened this issue May 22, 2024 · 2 comments

Comments

@rdzman
Copy link
Member

rdzman commented May 22, 2024

In #1, @aldalahmeh implements a new way to compute branch power flow estimates.

From what I understand, the original code that computes the flows straightforwardly from the voltages using ...

Sfe = V(f) .* conj(Yf * V);
Ste = V(t) .* conj(Yt * V);

... does not yield results that match those given in Example 6.17 in the 2nd edition of "Computational Methods for Electric Power Systems" by Mariesa Crow, but the proposed updated method does. Note: I do not have a copy of the book handy to confirm this.

The question is, which is correct?

While I confess that I do not understand the theory/logic behind the computations done by the proposed cmptSmat() function, I did make the following interesting observations.

  • The results computed by cmptSmat() with line charging capacitance included are identical to those computed by the original code with line charging capacitance ignored.
  • The results computed by cmptSmat() with line charging capacitance included are identical to those computed by cmptSmat() with line charging capacitance ignored.

I am certain that the original code is computing correctly the complex flows at the branch endpoints as functions of the voltage (otherwise MATPOWER has been giving incorrect results for 25+ years). Furthermore, the fact that the presence or absence of line charging capacitance has no effect on the output of cmptSmat(), proves that it is computing something other than the complex flows at the ends of the branch. I would conjecture that what it is computing is the complex flows through the series portion of the line pi-model. This would not be the correct value to use as the branch flow estimate, except in the case where line charging is neglected.

So, my current conclusion is that the results for Example 6.17 in the book were computed while neglecting the line charging capacitance, and I believe the original code is correct.

@aldalahmeh, do you have an alternative explanation that makes sense of the above observations?

@aldalahmeh
Copy link

The cmpSmat() function compute the following power flow equations in a vectorized way
image

I am not sure how the Yf (Yt) in the original code reflect the above equations.

I believe that if we reconcile the math with the code, the observations you made can be explained. So, I suggest looking at the book's example again and the related theory.

If there is a problem in the code it will be in the state estimation part only. As I have said earlier, I tried MATPOWER for flow calculation and verified the example 3.9 in the book. So, there is no problem in the core. In contrary, MATPOWER is known to be the de facto tool for power analysis in academia and research.

@rdzman
Copy link
Member Author

rdzman commented Jun 10, 2024

The original code should be consistent with the above equations.

I believe the issue is in the interpretation of the Y_ij in equations (3.115) and (3.116). The original code treats these as the (i, j) entries of the full bus admittance matrix, which includes the line charging capacitance in the diagonal elements.

I suspect that cmpSmat() is effectively cancelling these diagonal components resulting in a Y_ij that corresponds to the off-diagonal terms only, i.e. the series admittance of the branch between buses i to j.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants