Copyright 2006, Pipeline Simulation Interest Group This paper was prepared for presentation at the PSIG Annual Meeting held in Williamsburg, Virginia, 11 October – 13 October 2006. This paper was selected for presentation by the PSIG Board of Directors following review of information contained in an abstract submitted by the author(s). The material, as presented, does not necessarily reflect any position of the Pipeline Simulation Interest Group, its officers, or members. Papers presented at PSIG meetings are subject to publication review by Editorial Committees of the Pipeline Simulation Interest Group. Electronic reproduction, distribution, or storage of any part of this paper for commercial purposes without the written consent of PSIG is prohibited. Permission to reproduce in print is restricted to an abstract of not more than 300 words; illustrations may not be copied. The abstract must contain conspicuous acknowledgment of where and by whom the paper was presented. Write Librarian, Pipeline Simulation Interest Group, P.O. Box 22625, Houston, TX 77227, U.S.A., fax 01-713-586-5955.

ABSTRACT This paper was prepared in response to a request by a respondent to the attendee questionnaire at the PSIG 2005 Annual Meeting in San Antonio, Texas. The request correctly implied that authors always talk about the great things provided by pipeline simulation, but never discuss the problems.

The author has been involved with many pipeline simulation projects over 30 years, and has had many things go wrong in the course of developing, using, or implementing pipeline simulators. This paper discusses many of the problems encountered by the author, following the format:

• Problem - Definition of the problem

• Cause – The reason for the problem

• Solution – What was done to solve the problem

• Notes – Rather subjective comments by the author with in the hope of aiding a general understanding of what is involved in successful pipeline simulation projects.

TYPES OF PROBLEMS Ultimately, all problems are management problems! However, the following factors are often not dealt with by management in time to prevent problems with the simulators: • Model Deficiencies – Model deficiencies are less common

than they were a few years ago. There are many

simulators available now that are essentially complete and correct. Problems still arise in setting proper time and distant steps, and in setting correct operating parameters. There are also still a few things about pipelines, such as the transition between laminar and turbulent flow, which are not completely understood.

• Bad Data – There will always be bad data, in the sense of instrumental or encoding errors. The issue is one of finding and correcting the errors, and designing the simulator so that it does not become hopelessly disabled in the meanwhile. There is also inaccurate information or assumptions about such things as ground thermal properties or pipeline roughness. The best real-time simulators can determine better values of these quantities by automatic tuning.

• Configuration Errors – There will also always be configuration errors. Finding and correcting such errors is a major part of any simulator implementation. It is essential that the user be able to readily create and change configurations.

• Unrealistic (Impossible?) Expectations – Both users and vendors are responsible for understanding and making clear the true capabilities of a simulator and applications based on it. Overselling will only work if there are customers wanting more than they can understand or are willing to pay for.

• Computer Problems – Computers are amazingly reliable. Most computer problems are caused by conflicting uses.

• Inadequate Instrumentation – This type of problem applies primarily to real-time simulations. If there are not enough measurements to provide boundary conditions, no unique solution can be found. If measurements are spaced too far apart, accuracy and response time will suffer. Generally, real-time models need additional measurements for tuning of unknown parameters, such as ground thermal properties. There are special situations, e.g. If the temperature of the fluid reaches equilibrium before the fluid reaches the end of the pipe, intermediate temperature measurements are needed.

• Operator Errors – There are always operator errors. They

PSIG 0606

What Can Go Wrong? Jerry L.Modisette, PhD

2 JERRY L. MODISETTE PSIG 0606

become serious problems when the operators refuse to recognize them. Simulators should provide straightforward means to recover from operator errors. Where possible, manual inputs should be avoided.

SPECIFIC PROBLEMS The remainder of the paper describes specific problems encountered by the author and some of his colleagues.

Impossible Performance Requirement Problem: One of the first real-time simulators I worked on, 28 years ago was for a leak detection system. I was still a professor writing models for a vendor. The president of the vendor company asked me to meet with him to discuss how they were going to meet the specification. He told me the minimum leak they were required to detect. A quick off-line simulation showed that the pressure change caused by a leak that size was smaller than the least significant bit in the SCADA encoding of the pressure measurement.

Cause: This is a clear case of overselling by the vendor. The problem with extravagant claims is that eventually, they must be met.

Solution: After first saying that the problem couldn’t be solved, I asked about the detection time specification. There was none. By averaging a sequence of measurements the pressure sensitivity could be increased, at the cost of a longer response time.

Note: This approach won’t work if the pressure is too stable. The averaging process depends on the pressure hunting back and forth over the least significant bit. This system is still in operation. It’s harder than it was twenty-five years ago to come up with technical fixes to overselling, for the simple reason that most of the easy fixes have been discovered and are in use.

Computer Bog-down Problem: The computer executing a real-time simulator ran slower and slower until it couldn’t keep up with real time. Cause: A memory leak in a commercial data base blocked off more and more memory until there wasn’t enough available memory for fast execution. The computer was busy swapping data and programs between memory and disk. Solution: A programmed automatic reboot at midnight cleared the memory and provided a temporary fix; this is obviously not a satisfactory long-term solution. We eventually got rid of data base manager. Note: The same thing happened on another pipeline, where an unrelated database was being executed on the same computer as the simulator. It caused a leak alarm to be missed. It’s a

good idea to have dedicated computers, especially for real-time simulators. Although one of today’s computers has the capability to handle many tasks, the damage that can be caused a programmer wandering around in a system, such as the SCADA database, that isn’t his business and for which he hasn’t been trained, far exceed any savings that might be achieved by eliminating a computer. Impossible Friction Factor Problem: The real-time simulator’s automatic tuning produced an impossible friction factor

Cause: The downstream pressure sensor reading was 300 psi too high.

Solution: Recalibrate pressure sensor

Note: The pressure error was not obvious to the operators because of large elevation changes along the pipeline. This type of problem is becoming common, because operators are covering more pipelines and have less experience.

False Alarms - Gas Problem: The real-time model-based leak detection system generated a false alarm every time an injection was stopped.

Cause: A leaking valve on the injection line was sending gas back to the supplier.

Solution: Fix the leaking valve.

Note: This was a happy problem, the solution of which saved pipeline money. They were buying the same gas over and over! Finding the leaking valve required open minds: a willingness on the part of both the vendor and the user to consider all the possibilities.

False Alarms - Liquid Problem: A false alarm was generated every time an intermediate delivery started.

Cause: The delivery, which was put in after the leak detection system was installed, had not been configured into model.

Solution: Update pipeline configuration.

Note: Pipeline personnel trained in configuration had left the company and no one else had been trained. A major general problem with pipeline simulators is unwillingness on the part of users to invest in training of their personnel.

Check Valve I Problem: The model showed surges upstream of check valves.

Cause: The simulated check valves opened and closed on pressure difference, and were closing when flow was still

PSIG 0606 What Can Go Wrong? 3

going through them.

Solution: Change the model to open and close check valves on flow direction.

Note: Because of inertia, the pressure drop across a check valve reverses before the flow direction changes.

Check Valve II Problem: The simulated check valve sometimes failed to open.

Cause: The model opened check valves on forward flow, but the closed check valve imposes a zero flow.

Solution: Change the model to close check valves on flow reversal; Open them on pressure difference.

Note: Physics wins again!!! These two check valve problems, actually two aspects of a single problem, are typical of problems in the early stages of development. One hopes that they don’t have to be solved over and over again as new simulators are developed.

Errors in Off-line Gas Model Problem: Large errors in small delivery flows in an off-line gas network model.

Cause: Small differences in pressure boundaries at delivery points caused large flow changes.

Solution: Use flow boundaries for small deliveries; calculate the delivery pressure.

Note: This is the type of simulator problem from which insight can be gained into pipeline operations. Small injection or delivery flows (compared to the main-line flow) don’t have much effect on pressure.

Pressure Drop Too Low Problem: Pressure drop in liquid pipe leg was unreasonably low

Cause: Configuration error (inferred)

Solution: Increase pipe diameter so pressure drop agreed with model

Note: This was a Sherlock Holmes type problem: When all likely causes have been eliminated, what remains must be the cause, however unlikely. The customer recalibrated pressure sensors, remeasured viscosity, resurveyed elevations, etc, etc. The only remaining solution was a looped line or a larger diameter. Customer didn’t want to dig up pipeline to see what was really there! A larger diameter was assumed because it was easier to configure.

Off-line Gas Model Wouldn’t Converge Problem: Solution not found after many iterations.

Cause: User was trying to control flow and pressure at the same point.

Solution: Educate customer; Add features to detect inconsistent boundary conditions.

Note: The user didn’t give up; he tried to control both flow and pressure several different ways, with control valves, compressor set points, boundary conditions. Finally his supervisor intervened.

Physics wins again!!!

Laminar/Turbulent Oscillations Problem: Near transition Reynolds number, model flow oscillated

Cause: Model was jumping back and forth between laminar and turbulent flow, with large changes in flow

Solution: Use cubic spline friction factor fit for smooth transition between laminar and turbulent flow

Note: Great care is needed for this type of problem; the oscillations could be real! This was a real-time model, and the flow changes weren’t happening on the pipeline.

Runaway Downstream Flow Problem: In an off-line model the flow at the end of a gas pipeline went supersonic when pressure was low.

Cause: Flow was so sensitive to downstream pressure that model was unstable.

Solution: Use smaller time and distance steps at downstream end of pipeline, or use flow boundary.

Note: This is a common problem for gas simulators. Modern models can automatically set time and distance steps to avoid such problems.

Projects Never Completed Problem: Major gas pipeline started multi-year, multimillion dollar software projects three times with three major vendors that were never completed.

Cause: Company structure changed before software was usable.

Solution: Require useful deliveries at short intervals.

Note: There have been many uncompleted simulator projects. Taking on too much is one of many causes. Poor planning and unrealistic expectations are others.

Poor Leak Detection Performance in Winter Problem: Pipeline crossing shallow bay had good leak detection except in winter.

4 JERRY L. MODISETTE PSIG 0606

Cause: Winter winds changed water temperature.

Solution; Add temperature sensor where pipeline came out of water

Note: Not a happy solution; Customers never like adding instruments to support models! Real-time ground thermal models usually determine effective thermal conductivity and ground temperature by automatic tuning. With only upstream and downstream temperature measurements, a radical change in properties at different points along the pipeline can’t be tuned effectively.

Smearing of Temperature Fronts Problem: Sharp temperature changes due to compressor starts are smoothed out as front moves downstream

Cause: Numerical dispersion

Solution: Use thermal tracking instead of solving transport (energy balance) equation.

Note: Composition fronts can have the same problem. So can velocity or pressure fronts, but they move much faster, so numerical dispersion is less.

Wrong Batches in Pipeline Problem: Batches misidentified and/or out of place, invalidating model.

Cause: Operator inputs the wrong batch ID or is delayed in making input.

Solution: Make new batch starts and IDs automatic from valve data.

Note: This is a Murphy’s Law situation: If anything can go wrong, it will! It’s a good idea to avoid operator input of data for real-time models where possible.

Unstable Flow with Pump or Compressor Starts Problem: Model goes unstable when unit starts

Cause: Flow and pressure changes are too fast for model to track.

Solution: Use smaller time and distance steps near discharge

Note: No model can track changes inside a time step!

Unable to Reach Mass Balance Problem: Model mass balance never happened

Cause: Flow meter was using the wrong temperature measurement.

Solution: Use the right temperature measurement.

Note: It took a lot of work to convince customer of the cause of the problem. The flow meter was for custody transfer, and no one wanted to face the consequences of having operated with errors in the flowmeter!

Impossible Performance Requirement Problem: Optimization impossible because pipeline had no degrees of freedom

Cause: Overselling by vendor

Solution: Terminate project

Note: Customer was very reasonable, figuring he should have known the pipeline couldn’t be optimized; Don’t count on this! Few customers are so reasonable!!

CONCLUSIONS The specific problems discussed occurred over a period of twenty-five years. This doesn’t mean there was only about one problem a year; these were the problems that came readily to the author’s memory, and many of them happened on more than one project.

The early problems mostly arose as model developers learned their trade. These types of problems still occur, hopefully at a higher level as simulator capabilities expand. The author sees little prospects for overselling by vendors to disappear, or for clients to stop trying to squeeze blood out of a turnip!

REFERENCES These anecdotes were drawn from the author’s experience. References would identify the pipelines or the vendors, which the author does not wish to do.

ACKNOWLEDGEMENTS The author thanks Randall Allen, Dr. Glenn Bernard, Beverly Modisette, Dr. Jason Modisette, Ed Nicholas, and Dr. Ray Whaley, all of whom have been involved in solving some of these problems, for helpful discussions and reminders.