Power Flow issue with multiple generators connected to a slack bus

[jstuermer]

Hi,

I am working with a larger power grid test case (~2000 buses) that contains some buses with multiple generators and I've been using PowerModels.jl mostly to solve the DC power flow equations using run_dc_pf.

During my simulations, I sometimes noticed a strange behavior: While the solver reported convergence to an optimal solution in most cases, I noticed that generator dispatches sometimes unexpectedly changed or the solver did not manage to converge at all (e.g. it exited with "Iterates divering; problem might be unbounded.").
The cause for this inconsistent behavior was most probably that I used to always define a reference bus in every connected component by running correct_reference_buses!. I know that DC power flow does not require a reference bus to compensate losses, since there are none. However, I did not expect to run into problems, since I always made sure that the total active power generation matched the total demand in every connected component prior to running run_dc_pf. In the majority of cases all went well.

Only recently I noticed that the inconsistencies arise, if there are multiple generators connected to a reference bus. In fact, the JuMP model that PowerModels.jl builds in the background seems to become underdetermined in these cases. This makes sense, since the number of variables stays the same while a constraint for pg is dropped for every additional generator connected to the reference bus. I am not sure, whether this could also lead to problems in AC power flow calculations, but in the case of DC calculations this leads to avoidable convergence issues.
The inconsistencies seem to disappear, if only one generator is connected to the reference bus (e.g. by aggregating all connected generators to a single generator) or no reference bus is defined at all. Hence, I think that PowerModels.jl should at least print a warning message, if a reference bus with more than one generator is defined while trying to run run_dc_pf. This can also be easily overlooked, if one uses a data set that comes with predefined reference buses. What are your thoughts on this?

Alternatively, it could also help to have another type of reference bus for DC calculations - one that only comes with a voltage angle constraint without lifting the pg-constraints of connected generators. For example, I preferred to have reference buses defined to easily identify connected components in plotting functions that I wrote.

Thanks for the great package and I am looking forward to any thoughts on this!

PS: I could also provide a minimal script to reproduce my observations, if necessary.

[ccoffrin]

Thanks for bringing this up @jstuermer. In general, I agree with you that generating a warning in this situation would be appropriate.

I do need your help to demonstrate the issue so that I can debug what is going on. If you could please post here or e-mail me a minimal working example that would be very helpful.

I agree with you that a slack bus with multiple generators will be ill conditioned in the run_dc_pf case, and this may lead to convergence issues, but I have not observed this my self. Have you tried compute_dc_pf instead of run_dc_pf, the former may be more robust to this issue.

[jstuermer]

Thanks for the quick reply. I e-mailed you a minimal working example to reproduce the issue.

I have also quickly tested compute_dc_pf and it in fact seems to be more robust in the case that I have sent you. I will have to test, whether it is reliably more robust in other scenarios.

[ccoffrin]

To close the loop. This case highlighted a very subtle bug in how the JuMP-based power flow was implemented (not the Julia-native power flows). In all cases the Ipopt was converging and producing a valid voltage profile. However, the power injection of the generators at slack bus was degenerate and can grow to very large values. In particular, they grew to values like 3.071830898216968e18 and -3.071830898216968e18 on the computer I used for testing. When I compared the injection profile of both solutions the only difference was on these values. The core of the issue here is the limitations of 64-bit floating point numbers, they don't have the resolution to work with 18 orders of magnitude and hence this made it look like a power imbalance issue when it was a floating point computation issue.

The fix to make everything work consistently is to break this degeneracy in the build_pf model by fixing the injection of all but one generator at the slack bus, so that only two power injection variables remain free for solving the system of equations. This is the solution employed by PR #787