What do you do when the power flow of a model does not converge? change parameters until it works somehow? not anymore! This article aims at explaining the most common issues and their solution when the power flow of an electrical grid model does not converge.

## Introduction

Let's provide some base concepts to be sure we are speaking in the same terms.

### What is the power flow study?

The power flow study, contrary to its name , aims at computing the nodal voltages that satisfy the nodal power balance condition. This means that the computed power injections using the aforementioned voltages are close to the specified nodal power injections (The given generation minus the given load) After the voltages are obtained, the branch flows are computed once. This study provides the steady state electrical magnitudes of a power system, so it is most useful in situations where we can assure that the power system is steady. An example of a situation when this is not true is a large disturbance such as a short-circuit.

### What does convergence mean?

To "converge" means that the nodal power balance condition has been satisfied up to a certain numerical threshold. A good numerical threshold is 0.000001, a threshold used in practice is 0.001 for speed, and sometimes because the model is not as good as it should be and the numerical methods get stuck at higher errors.

## Issues

### 1. Nonsense data issue

The first issue I'd like to bring up is the presence of nonsense data. But how can you know what is nonsense? Some hints:

**Zero branch reactance**. All branches should have some meaningful reactance value. In the case of DC branches, there should be some resistance value.**Very low branch reactance values**. Sometimes, exists the temptation to model switches and jumpers with very low reactance values like 0.0000001. This hurts the model condition number, thus its convergence properties. Those branches should be removed from the model with a topological process.**Not in per-unit**. Most power system models require the impedances to be provided in per-unit. If not, the values will not make sense.**Out of range values**. Some parameters only admit values in a certain range. For instance, does it make sense to have a -0.05 p.u. resistance? no it doesn't. Ideally, the software should only allow values in range because the users are not always aware of what sensible ranges are.**Reversed ranges**. When specifying a range it is clear that the lower value has to be actually lower than the upper value. Sometimes the range is reversed by mistake.**NaN values**. This is an obvious one, but not to be underestimated.*Not-a-Number*is not a valid number anywhere, hence, no input field should ever be*NaN*. The same applies to empty numerical values.

There may be other parameters that might contain harmful data that is not immediately obvious. In those cases a histogram of the values is a very useful tool to find outliers. __GridCal__ features automatic detection of nonsense values and provides histograms of the most influential magnitudes in its model inspection and fixing tool.

### 2. Active power imbalance issue

This one is very common, and easily overlooked. As we mentioned, the power flow study computes the steady state values of a circuit. For a circuit to be in steady state, there must be an exact balance between the load and the generation. In the numerical power flow study we need to leave a free generator, located at the "slack" node. This generator can provide any amount of power, but that does not mean that the grid can transport it anywhere. In transmission grids, the balance should typically be within a 3% error margin, less is even better. In distribution grids there might not be any balance at all if there are no generators. In those cases the slack will provide all the power, but unlike the transmission grids, the distribution grids are designed for that situation and the power transport from a single entry point is not an issue.

**Solution:** To solve the active power imbalance, the typical solution is to run an optimal power flow where the generation is dispatched according to their cost. This produces the generation values that satisfy the demand with good enough criteria to be able to satisfactorily solve the power flow problem. Alternatively, one could just scale the generation to match the load.

### 3. Voltage guess issue

This one is less obvious and it is solely related to the numerical methods used to solve the power flow; The gold standard algorithm to solve the power flow study is the Newton-Raphson algorithm. First reported to solve the power flow problem in 1967 by William. F. Tinney and Clifford E. Hart, it has quadratically convergence properties. However, the Newton-Raphson algorithm and most of the state of the art algorithms, rely on an initial guess of the solution to iterate until reaching the convergence.

We know that in the real world, only one solution exists for each loading state. But since we are dealing with a mathematical model, it has been proven that the solution space of the power flow equations contains more than one solution that is mathematically possible. So how do we know if we are getting to a meaningful solution? In my experience a meaningful solution is one such that the voltages are not in collapse state (given that we have no nonsense values and balanced power injections) these are voltages in the range (0.9 , 1.1) p.u.

Back to the issue at hand; Sometimes we need to run a sequence of power flow studies, and experience shows that if we use the last state solution as the initial point for the new state, the algorithm converges faster. This is a good practice if both loading states are similar like the voltage solution at 10AM might be a good initial point for the situation at 11AM. However, if the loading states are very different, using one of the voltage solutions as an initial guess for the other might lead to a garbage solution or to no solution at all.

**Solution**: Use the plain voltages profile. This is 1.0 p.u. for all *PQ* nodes, and the generator set point voltage for the *PV* nodes and the *slack* node. In the rare event that this does not lead to a solution, a voltage initial guess from a close situation might help. However experience shows that if this is the case there are other problems to consider.

### 4. Transformers virtual taps issue

If you connect a transformer end rated at 11kV to a bus-bar rated at 10 kV, it is because by design you expect to have 11 kV / 10 kV = 1.1 p.u. voltage at the bus bar. However if you connect a 132 kV transformer end to the same 10 kV bus-bar, the voltage would be 13.2 p.u. and that is probably not a good decision. In fact it is an error. This is a very common error that slips under the radar, because sometimes despite the wild virtual taps generated, the numerical algorithm finds a solution.

**Solution:** Check that the difference between the transformer ends' voltage ratings and the buses voltage rating are not too different, say a 10% maximum. Most likely the transformer is connected backwards, so flip it.

### 5. Reactive power transport issue

Sometimes the reactive power is not generated close enough to where it is needed and the grid cannot transport it efficiently enough. In these cases, the numerical algorithm cannot find a solution and it is quite difficult to tell why.

**The obvious solution** is to provide more reactive power close to where it is needed. For instance, locating capacitor banks or generators with reactive power capability.

**But believe it or not, there is an easier solution;** Does your load characterize the reactive power properly? Sometimes not. Specially in models used in planning where the reactive power is derived from the active power using a simple rule. Ensure that there are loads that generate reactive power as well as loads that consume it, because that is what happens in real life.

### 6. Incompatible controls

What if you have a transformer controlling the voltage of a bus and a generator controlling the voltage of a bus nearby and it is almost impossible to transport the necessary active and reactive power to satisfy that control situation? Then the algorithm will not find a solution, or the convergence properties deteriorate greatly. **To avoid this we need to**:

Avoid concurrent controls. This is, avoid having more than one device controlling the same magnitude.

Avoid nearby controls that control the same magnitude to different values.

In general, avoid having too many controls. The power flow algorithm is an optimization function and sometimes it can stagnate or fail to converge with too many controls.

### 7. Singular Jacobian matrix

Sometimes you may be notified by the power flow program that the Jacobian matrix is singular, hence the power flow is not solvable. *What does this mean?*

The Jacobian matrix is a matrix composed by the derivatives of the power flow equations with respect to the voltage module and the voltage angle. This matrix is used to solve a linear system to compute the voltage magnitude and angle increments in the Newton-Raphson (and Newton-Raphson like) algorithms. This is done at each iteration to determine the next step, so if the linear system is not solvable, there is no next step to be found.

In practice, this means that the power system is in voltage collapse, but how? This happens if the load exceeds what the grid can transport by the declared impedances. So here there are only two things to consider:

Is the load way too high? If so, consider grid reinforcements. But most likely, the issue is with the next item.

Are the impedances correct? This one relates to the rest of this article where bad data, wrong transformer connections and the likes may be playing a part in the Jacobian matrix singularity.

## Final thoughts

The more hands that touch a model (of any kind) the greater the risk of bugs. That sentence could probably be set in stone, but calls the question, can we do any better? I believe we can if we use expert rules like the ones described before in conjunction with computer software that oversees the models creation. This is not a new idea and in computer programming languages, such tools are called linters. So, can we create a linter for power systems? Yes we can, and we definitely should.

## Comments