Building Models

The purpose of this section is to discuss the basics of computer simulation of natural gas pipeline systems. It is written for the person who is familiar with the terminology and concepts of a pipeline, but who is new to modeling pipeline systems. First let’s define what pipeline simulation is. Pipeline simulation is the process whereby a computer model of a pipeline is used to simulate an actual pipeline system. The idea is to have the computer model duplicate or predict what is occurring in the actual pipeline system. The ability to predict what is going to happen with an actual pipeline system can be extremely useful in a number of ways.

From an operational standpoint, pipeline simulation programs can be used to test operating changes on the model before implementing them on the actual pipeline system. Typical changes that can be tested with the model are variations in flow rate, set pressures, and compressor performance. You can also see what the effect of taking a line section out of service or turning off a compressor will be, by first trying it on the computer model. What it boils down to is that if you are unsure of something, you can experiment with the computer model of the pipeline system instead of the actual pipeline system itself.

Another major use of pipeline simulation programs is in the design of pipeline systems. Pipeline simulation programs can be used to design a pipeline system from scratch or used to design an expansion to an existing system. While there are a few general rules you can follow when designing a pipeline system or expansion, there is still a lot of room for experimentation. Using a pipeline simulation program as an aid not only speeds up the design process, but also gives you more time to test different ideas and configurations which in turn will usually result in a more efficient design. When you consider the high cost of buying and installing compressor units and pipe, even a small improvement in the design can yield considerable savings.

Steady state simulation is the process of simulating a pipeline system under steady state conditions, which simply means that the conditions are assumed to not change with time. Of course pipeline systems do not operate under perfectly steady conditions, but some pipeline systems do remain steady enough so that steady state simulation can be used to adequately model their behavior.

Also, steady state simulation is usually used when designing pipeline systems or expansions. The design process can be pretty tedious even under steady state conditions and to further add the complication of changing conditions can make it extremely time consuming (depending on the complexity of the system).

Even if a pipeline does not exhibit steady state characteristics, steady state simulation can still be used to get a rough estimate in a short period of time. Steady state simulation runs are not only simpler to set up, but also take less time to execute than transient runs.

Transient simulation (sometimes called unsteady state) is the simulation of a pipeline system under changing conditions. Naturally this complicates the modeling process by introducing the additional factor of time. In transient simulation you not only have to specify flow and pressure set points as they are when you begin the simulation but also how they vary with time. When a transient run is made, it is usually used to model the system over a set period of time (for example 24 or 48 hours). Some transient programs however also let you run the program interactively so that you can make changes to the system as the run is being made.

Another use of transient simulation is in real time modeling, where the computer model is used to monitor the pipeline system by constantly calculating what the pipeline should be doing and then comparing that to what the pipeline is actually doing. This can be useful for detecting abnormal operating conditions in the system or for detecting leaks in the system. Real time models must be hooked in to a SCADA system to obtain the information needed to maintain up-to-date calculations. Potential problems with real time systems can come from the data acquisition system (and the effort needed to keep the sensors calibrated enough to be useful to a computer model).

Transient simulation is very useful from an operational point of view. It can yield more accurate results when used as a predictive tool in systems that have time varying characteristics. A good transient model with interactive capabilities can also be used to train dispatchers or engineers who are unfamiliar with the system (as stated before, it is much safer to experiment with a computer model than it is to experiment with the actual pipeline system).

The drawbacks of transient simulation modeling are the additional complexity of the model and the additional amount of data that must be provided (both of which contribute to increased chances of making a mistake), as well as the additional computer resources needed to make a run.

Simulating a pipeline system requires three steps. The first is to set up a mathematical configuration of the system in a computer file so that the simulation program will know what the system being modeled looks like. Usually in the same file, you must also specify the boundary conditions. Boundary conditions describe what is already known about the system, and what is not known (what the program needs to calculate).

The second step is to actually make the simulation run and let the program solve for the unknowns. The simulation program will read the input data from the data file, perform the necessary calculations, and write the results either to a new file or to the same file that held the input data.

The third step is to examine and interpret the results, and check for errors.

The simulation program itself is just a file residing in the computer system. It contains instructions that tell the computer how to read the data from the data file, how to perform the necessary tasks needed to solve for the specified unknowns, how to write the results to the output file, and so on.

Before you can make a simulation run, you must first create the data that describes your system. This is the area in which simulation programs differ the most in that user interfaces can vary widely. One thing that most pipeline simulation programs do have in common is the method used to represent a pipeline system. When you build a system, you must not only describe the system in terms of how many pipe sections there are, what their lengths and diameters are, and so on, but you must also be able to describe how these sections are interconnected and be able to describe input and output points into your system. This is done with the use of NODES and LEGS.

Any pipe section, compressor, valve, or other element in the system is called a leg. The connections between legs are called nodes. Each leg must have one node at each end. Nodes are also volumetric input/output points.

Some simulation programs may use a different terminology and call a pipe section a leg but not compressors or valves. Others may call a leg a “node connecting element”. The term “node connecting element” provides a good description but is a little wordy. For the Gregg products a leg is defined as some element (pipe, compressor, valve, etc.) that connects two nodes.

For example let’s look at one of the simplest systems possible: a single section of pipe. In terms of nodes and legs, there would be one leg (the pipe section), with one node at each end. We’ll call the upstream node, Node #1 and we’ll call the node at the downstream end Node #2.

Obviously a single section of pipe must be able to receive gas at the upstream end and be able to deliver it at the downstream end. This is represented in our node/leg model by saying that there is a positive InFlow; coming in at node #1 and a negative InFlow leaving at node #2.

Looking at node #1, since the only thing hooked up to it is the pipe section, then it follows that all of the node InFlow coming in at the node will go into the upstream end of the pipe. By the same token, all flow leaving at node #2 will have to come from the downstream end of the pipe section.

Now let’s add another pipe section to the end of our small system. The upstream end of the second pipe section will be attached to the downstream end of the first pipe. Since they are attached, then the downstream node of the first pipe section is the same as the upstream node of the second pipe section and is represented as node #2. Since we now have two pipe sections, we’ll refer to the first one as leg #1 and refer to the second pipe section as leg #2. We will represent the downstream end of leg #2 as node #3.

As before, all of the flow coming in at node #1 must go into leg #1, but as you can see, the flow coming into node #2 from leg #1 can either leave the system at node #2 as an output flow out of the system, or it can continue down the system and enter into leg #2 and eventually leave out of node #3.

This is how we can represent delivery points; along the system. Now lets use actual flow rates. We’ll assume that the flow coming in at node #1 is 50 mmscfd and that the delivery leaving at node #2 is 20 mmscfd. Therefore it follows that the remaining 30 mmscfd will travel down leg #2 and leave the system at node #3.

Let’s go further in our description of the system and say that the first pipe section is 16″ in diameter and 25 miles long and that the second section also has a diameter of 16″ but is 35 miles in length.

A typical pipeline simulation data set would now look like the following:

The data shown describes not only the pipe lengths and diameters, but also how they are interconnected. This constitutes the pipeline configuration. The data also shows the flow rates going into and out of the system, although this type of data would be classified as set point data or boundary condition data.

Note that the terms upstream and downstream are only arbitrary and do not necessarily define the direction of flow. If the leg flow; happens to be going from the upstream end of a leg to the downstream end, then the flow is positive. If however the flow is going from the downstream end to the upstream end, then the flow will be negative.

Compressor stations, valves, and other legs types are described in much the same way as the pipe sections. For example, let’s now add a 1000 HP compressor station to node #2 so that the gas being delivered will be compressed before leaving the system:

Now a typical project data set would contain data similar to the following: 

The data shown here is just the bare minimum. In an actual project data file, you would include other factors. For example, with compressor stations, you might include the compressor efficiency or other descriptive data. What you can or cannot include of course depends on what the simulation program can understand and how sophisticated it is.

The type of data needed to describe a pipe section naturally includes length and diameter. There are also a few other parameters that should be included such as the type of equation to be used, the pipeline efficiency, and the ground temperature and heat transfer coefficient for temperature calculations.

For compressor station legs, additional data includes a compressor type or station data. Many simulation programs let you choose among a variety of compressor models to use in representing compressor units and let you build sophisticated station models with multiple detailed units operating in series, parallel, or various arrangements of series and parallel. For detailed unit descriptions, you must enter all detailed data that is relevant to that unit type.

Most simulation programs also contain a variety of valve models from which to choose. They usually are just the main line valve, check valve, and regulator valve.

You should not include every valve in the system into your model. The reason being, that most of them may never be needed. If a valve stays open year round under normal operating conditions, then you should leave it out of the model. If at some time you need to make a run with the valve closed, then you can add it in to your model at that time on a temporary basis.

The reason for this is that adding extra legs and nodes that aren’t needed not only take up more file space, but can add considerably to the amount of computer time that is needed to execute a run. If you tried to include every single valve and pipe section into your model, you would wind up with a huge project file that would accurately model your system, but you could probably model the system with just as much accuracy with a project file one tenth of that size.

Also keep in mind that in most cases it is unnecessary to model your entire system with every run. For example, if you just want to calculate a pressure on a small lateral, you usually don’t have to model your entire system in the process. It makes more sense to split your system up into sections and have a file for each section, and use these smaller files when you can. You should also have a large file containing as much of your system as possible, but only use it when you have to. If your system is a very large distribution system, you may need to split your system up into different files anyway, since it is possible that the simulation program may not be able to execute your entire model in a timely manner.

Experiment – If you are new to modeling, experiment with very small systems. Rather than just jumping in and trying to build a model of your actual system, instead just create very simple 3 or 4 node systems and get them to run. Experiment with changing set points, turning a station on or off, modifying the loads and pressures. Experiment at length with Knowns and Unknowns to get a good feel for them. Experiment with opening and closing a valve (and quickly discover the concept of Isolated Sections). The idea is to become comfortable with the basic concepts of modeling and know what you can play around with and what you should avoid. In many cases, users who bypass this simple learning step and instead jump right into creating a complex model, tend to be paralyzed in that they are afraid to change anything in the model for fear of crashing it, and suffer from tunnel vision in that they only know how to run the model one way – all good and fine if conditions never change, but what if a station goes down and you have to use the model to figure out a brand new way of operating the system?

Start Small – Rather than trying to build a huge model from scratch and then try and get it to run, start building just a small section of the system and get that to run. Then add in another section and get that to run, and keep adding sections and getting the model to run after each addition. It is much easier to debug a model in which you know the general area of where the bad data or set points reside.

Make Backups – Always make backups of your models, especially those that run. It is very easy to get carried away and make changes to the model, then more changes, and more changes, and before you know it, the model crashes and you can’t remember everything that you did in order to get it back to its original state. It is always a good idea to load in an original model, then save it under a different name to create a working copy, and then play around with the working copy rather than the original. As you make changes, save the model frequently under new names so you have an archive of models that you can go back to, to retrace your steps. You might start out with Sample1, and in the process of working with the model wind up with Sample1-05-30-03-002, Sample1-05-30-03-003, Sample1-05-30-03-004, and so on (time stamping model names is also a good idea). Remember that hard disk space is cheap, but your time is not, and the money spent on wasting a few hours trying to recover lost work could have bought a nice sized hard disk.

Minimize Model Size – Consider how much detail you want to put into your model. A detailed model with every valve, check valve, cross over pipe, and twist and turn might look great and model your system right down to the last one hundredth of a psi, but it might take ten minutes to run instead of ten seconds, and become so difficult to debug that no one can get it to run at all. It also makes it more difficult to sift through the data to get the results you are looking for. A compromise has to be reached between how detailed the model really needs to be verses how fast it needs to run and how flexible it needs to be. More detail might mean more accuracy, but it also translates into longer run times, more difficulty in debugging problem models, and less flexibility. A key issue is also: how accurate is the data being fed into the model. If the input data going into the model is for example forecast data or estimated data and is only accurate to within 5%, then trying to eke out the last ½ % of accuracy with a large detailed model is a complete waste of time. Starting out as simple as possible is always the best way to go. If it turns out it is too simple, and you need more detail, then add in the details a little bit at a time until you have achieved satisfactory results.