System Balancing

For example in our previously described two node system consisting of a single pipe section, let’s assume that we know that the inlet flow at the upstream node is 50 mmscfd.

The 50 mmscfd is a boundary condition. It can be used to find an unknown value in the sense that we now know that the outlet flow at node #2 must be -50 mmscfd.

One way to look at this is to say that since the flow into node #1 is 50, then the flow going through the pipe must be also be 50. And, since the flow going through the pipe is 50, the flow leaving node #2 must also be 50.

This way of looking at it is handy for a person, but it is not necessarily the way a simulation program would see it. In fact many simulation programs do not treat the leg flow as a primary variable. Instead it is absorbed into the equations and never really shows up during the primary solution of the system.

Thus the simulation program, after making substitutions could make the direct correlation: since the flow coming into node #1 is 50 then it follows that the flow leaving node #2 is 50.

If we were to let a simulation program solve this system, we would specify the InFlow at node #1 as +50 mmscfd and then say that the outlet flow at node #2 is unknown. Obviously, this is such a simple problem that you don’t need a program to solve it for you, but what if you had a 100 node system and you knew what the inlet/outlet InFlows were at 99 of those nodes. The program would solve for the flow at the 100th node using the same principle that was used in the 2 node problem above. It would add up the flows from the known 99 nodes and then say that the negative value of the result is the in/out InFlow at the 100th node.

The principle used here is that the total InFlow going into a system must be equal to the total InFlow going out of the system. Since the InFlows going out of a system are represented with negative numbers, they will cancel any InFlows coming into the system (positive numbers), thus the principle can be restated as: the sum of all InFlows into a system must equal zero.

This same principle can and is used by simulation programs to solve for flow balances at nodes. For example, let’s say we have three pipe sections that are hooked together at a node. Let’s also assume that there is a flow going out of the node as a delivery.

Let’s assume that one pipe section is feeding 15 mmscfd into the node and that flow is leaving the node into the two other pipe sections at the rates of 4 and 8 mmscfd respectively. We can now use the same flow balancing principle to solve for the delivery flow leaving the system. The equation would look like:

15 + (-4) + (-8) + x = 0

This equation essentially says that the sum of all flows going into the node must equal zero. Since two of the pipe flows coming into the node are actually leaving the node, they are represented as negative numbers.

The delivery flow is represented by x. From the equation, we can calculate that x = -3. Since the flow is negative, we know that it is a delivery. Had it been a positive number, it would have been an input into the system.

For a steady state system, if we perform node flow balancing at each node in the system, then this will automatically balance the entire system. In other words, if the sum of the flows at each node is equal to zero, then the sum of the flows into the system will also equal zero.

There is another method for balancing flows in a system, that uses loop flow balancing rather than node flow balancing but we will not cover it here. The node balancing method is a little easier to visualize and tends to be the preferred method.

Now let’s look at pressures as boundary conditions. With the majority of pipeline simulation programs, when you specify a pressure, you are referring to a node pressure. Looking at our single pipe section again, let’s say that we know that the pressure at the upstream end of the pipe is 300 psig.

This constitutes a boundary condition since we can now solve for the downstream pressure using the general flow formula.

In this system we have two known values: the upstream node pressure and the upstream node InFlow, and we have two unknown values: the downstream node InFlow and the downstream pressure. Note that there are two unknowns and that the system is a two node system. This is no coincidence.

The number of unknowns in a system must always be equal to the number of nodes. This boils down to the basic algebraic tenet that the number of unknowns must be equal to the number of equations.

If we were to now enter the system configuration data and the boundary conditions into a file format for a simulation program, it might look like the following:

The unknown values are specified at 0 since we don’t know what they are, and are flagged with a U so that the program knows that they are unknown. The known values on the other hand are flagged with a K.

The above file contains all of the necessary information needed to run the system. If you had a simulation program that accepted the above format, you could plug in the data and then run it. The program would solve for the unknown InFlow at node #2 (that’s an easy one) and for the unknown pressure at node #2 (not so easy).

Now let’s look at another example. In this case the upstream pressure is known at 300 psig, and the downstream pressure is also known and is 250 psig.

In this case both of the node InFlows are unknown. There are still two unknowns which is the correct number for a two node system. You can calculate the flow rate going thru the leg using the general flow formula and then use the node flow balance equations to find the in/out InFlows at nodes 1 and 2 (a fairly easy procedure in a simple system like this one).

With simple two node systems, setting boundary conditions is simple. With more complex systems however, you can run into problems, because just having the number of unknowns equal to the number of nodes is not the only prerequisite needed for a successful simulation run.

You must set up the knowns and unknowns in such a manner that the solution is possible.

This is probably the area that gives most people trouble. In a large and complex system, even experienced users can (and do) run into problems by setting the knowns and unknowns up so that the system is “inconsistent”. What exactly does this mean? Let’s look at the system shown below and assume that it is a steady state system (not changing with time).

In this system, there are the proper number of unknowns (two), but the system cannot be solved. If we apply the node balance equation to the upstream node, we find that the flow traveling through the pipe is 50. If we apply the node balance equation to the downstream node however we find that flow traveling through the pipe is 75, which contradicts what we had previously found.

Thus we have two known values that instead of helping us solve for the two unknowns, wind up contradicting each other and contributing nothing towards our ability to solve for the two unknowns.

What if we had set the downstream node flow to 50 instead of 75? This would still constitute a bad set up, not because the node flows contradict each other (they don’t), but because they could.

Furthermore, they still don’t contribute anything towards our ability to solve for the two unknown pressures. Even if we could assume that the flow rate through the leg is 50, we don’t know what the pressure level is.

We could estimate an approximate pressure drop (let’s assume 10 psi), but we don’t know whether that drop applies to a low pressure system (for example 35 psig down to 25 psig) or to a high pressure system (500 psig down to 490 psig).

There are no hard and fast rules that you can use to avoid running into the problem of an “inconsistent” system, although with experience, it happens less often.

In simple systems, you can usually track down the bad boundary conditions; without too much trouble by using logic (if I know this value I can calculate this value which in turn let’s me calculate this other value, and so on, all the way through the system until you find the contradiction).

In very large and complex systems however, it sometimes comes down to just changing the boundary conditions by trial and error until you obtain a successful run. While this is certainly not the recommended procedure, you will undoubtedly find yourself using it every once in a while.

Simulation programs that encounter the above problem of inconsistency will typically exit with an error message saying that no pivot element was found, that the pivot element is zero, or that an unexpected row or column of zeroes was encountered.

The easiest way to avoid inconsistencies and set up the boundary conditions correctly, is to model the system in exactly the same way that the pipeline is operated in real life.

This usually means setting a Known value at all control legs such as compressor stations and regulators, setting all InFlows to Known, with the exception of at least one node which must have a Known Pressure and Unknown InFlow.

It is also a wise idea to avoid setting nodes to both a Known Pressure and Known InFlow, or Unknown Pressure and Unknown InFlow, except in the case where that node is connected to a control leg.

This is not absolutely necessary for steady state modeling, and once you become experienced, you can start to change the boundary conditions to solve for specific values that would normally be Known, but keep in mind that this only applies to steady state.

For transient modeling, you must follow the above rules or you will get incorrect results.

So far the examples we have looked at have only involved pipe sections, and the knowns or unknowns were either node InFlow or node pressure.

By introducing compressor stations, we complicate things by adding a new type of known/unknown, which is the compressor station’s performance.

In most simulation programs, this performance can be treated as either a known value in which it can be used to find some other variable such as the discharge pressure, or it can be treated as an unknown in which case maybe the discharge pressure is set as a known value and used to calculate how the compressor station should be running.

Where most simulation programs differ is in how they represent the performance of the compressor. For the sake of simplicity, we will just look at the horsepower as being the measure of a compressor station’s performance. Thus for any compressor station in the system, the horsepower will be either known or unknown.

In the Gregg Products compressors are added in a system just like pipe sections. They must have an upstream node and a downstream node.

The compressor is treated just like any other leg except that the equations governing it are different: they involve pressure rises rather than pressure drops and include a horsepower variable.

Now let’s look at an example:

In this case the compressor station horsepower is unknown. If we used a simulation program, we would be asking it to calculate what horsepower would be required to compress 50 mmscfd from 200 psig to 300 psig. As you can see, there are still the proper number of unknowns (2 unknowns for a 2 node system).

Another example:

In this case we would be asking the simulation program to calculate what discharge pressure the compressor station could compress 50 mmscfd to, using 1000 HP and with a suction of 200 psig. This simply involved switching the unknown from the compressor horsepower to the discharge pressure.

With simple open/closed valves or check valves, there are no additional boundary conditions to worry about.

With regulators however you can have the pressure drop across the regulator as a known or unknown for pressure control regulators and the flow across the regulator as a known or unknown for flow control regulators.

The concepts are no different than those involved with compressors and pipes, so we won’t go over the details.