Predicting Liquid Surge in Real Time: Why We Had to Build Our Own Tool
Comparing our Pontem Model for Liquid Surge with a commercial tool
A valve closes somewhere on a large onshore pipeline network. Pressure spikes, flow reroutes and equipment is at risk. As an engineer you need to know what is happening in real-time, not after running a manual simulation on a desktop tool.
That is the problem we set out to solve. We built a tool that could be embedded, automated and deployed at scale. One that simulates the pressure surge and flow rerouting caused by a valve closure, and delivers those answers as it happens.
But to understand why that matters, we need to start with the physics.
What is Liquid Surge?
You may know this phenomenon as water hammer however, in the pipeline industry, we refer to it as liquid surge.
Liquid Surge is the sudden pressure surge that occurs when a valve closes and abruptly changes the flow of moving liquid.
You've probably heard it before, it's the thump! you hear when you shut off a tap too quickly. The moving water suddenly has nowhere to go, so it pushes back. That pushback is a pressure wave, and in a large pipeline network, it can be powerful enough to damage pipes, fittings, and equipment.
How Do We Simulate It?
The basic way to observe it is simple. A pipe, a valve, a stopwatch and a pressure sensor. Let the water flow, then shut the valve in half a second. The sensor spikes and that's liquid surge.
For complex pipeline networks however, you can't just run physical tests every time you want to understand a closure event. That's where simulation tools come in. They allow engineers to model these transient events without being on-site.
A Note on the Math
Most commercial tools use Method of Characteristics (MOC) , and it’s the industry-standard mathematical technique for simulating transient flow (sudden changes in pressure and flow) in liquid pipelines. This approach discretises the pipe into spatial segments and solves for pressure and flow at each segment, at every timestep.
Liquid flow in a pipe is governed by two equations describing how pressure and flow change over distance and time. Solving these directly across a whole network is computationally expensive.
MOC sidesteps this by transforming these complex equations into simpler ones that can be solved step by step along the pipe. The trick is that these simpler equations only hold along specific paths called characteristic lines, which correspond exactly to the speed at which pressure waves travel through the liquid. By marching along these paths at each timestep, MOC efficiently tracks how a pressure wave propagates and reflects through an entire network.
Commercial simulation tools for liquid surge are mature and reliable. They have been used by pipeline engineers for decades and they do the job well.
So why build our own?
The answer is not accuracy. It is deployability.
Tools like these are designed to be run manually by an engineer sitting at a desktop. You build the model, you run the simulation, you read the results. That works perfectly for one off analysis. It does not work when you need a system that can predict pressure surge events automatically, in real time, embedded inside a live pipeline management platform.
That is what we needed. And that is what we built.
Our Pontem Model implements the core hydraulic equations using MOC to simulate pressure and flow efficiently across large networks. Critically, it models the entire network simultaneously. When a valve closes, we can track not only the pressure surge at that point but also how flow redistributes across the rest of the system in real time.
This is the tool we put to the test.
Putting It to the Test
To validate the Pontem Model against a commercial simulation tool, we started with the simplest possible configuration a single flat pipeline with pressure boundaries at both the inlet and outlet set to 300 psig, achieving a steady-state flow of approximately 1,000 barrels per day.
A control valve was placed just upstream of the outlet. Once steady-state flow was established, the valve was closed and pressures were recorded at two points the pipe inlet and just upstream of the valve. The same network was built independently in both tools and run under identical conditions.
Seven experiments were run in total, each isolating a different variable:
Baseline - flat pipe, 0.5s valve closure
Elevation - pipe inclined 500ft upward and downward
Closure time - 10s and 30s closures
Flow rate - increased to 3,000 bbl/d
Outlet pressure - reduced to 150 psig
The Results
We started simple. A single flat pipe, a fast valve closure, identical conditions in both tools. The results came back almost identical.
Steady-state flow matched to within 0.2%. Peak surge pressure was essentially the same. For a first test, that was encouraging. But a flat pipe with a fast closure is about as easy as it gets. So we pushed harder.
We then introduced elevation. First a 500 ft descent, then a 500 ft climb. We increased the flow rate to 3,000 bbl/day. We dropped the outlet pressure to 150 psig. In every case, the two models tracked each other closely.
Then we slowed the closure down.
A 0.5 second closure is violent. The water has no time to adjust and the pressure spike is immediate. A 30 second closure should be gentle by comparison.
That assumption did not fully hold up.
The surge rise difference jumped to 12.7% for the 30 second case. At first glance that looks like a problem. But the absolute difference was only 2.5 psia. As a percentage of actual peak pressure the difference was 0.7%, consistent with every other experiment. The number looks large because surge rise is a small quantity to begin with.
The real explanation is in how each tool handles valve behaviour. The Commercial Model closes linearly over time. The Pontem Model uses a butterfly style curve, staying nearly fully open through most of its travel before choking sharply at the end. For fast closures this distinction does not matter. For slow closures it does. Not a flaw, just a known difference between the two approaches.
One final observation. The Pontem Model’s pressure peak consistently arrives slightly later than the Commercial Model across all experiments. For fast closures the offset is around 1.1 seconds. For slower closures it is 2.74 seconds. The magnitude is right. The timing is off. That is worth investigating further.
Scaling Up
Phase 1A proved the model works on a single pipe. The real test was always going to be a network at scale, and that is exactly where the Pontem Model is being deployed today, on a large onshore pipeline network.
At this scale, the model provides real-time insight into system pressures and flow routing during normal operation. That alone is not a small task for a network of this size.
Where it becomes genuinely useful is during valve closure events. The model indicates the maximum pressures expected across the network, and critically, how flow reroutes once that valve closes, including whether the rest of the network can handle the extra flow being pushed its way.
The model runs directly through the client's existing analytics platform. Engineers do not need a separate tool or a separate login. The insight is exactly where they are already working.
What’s Next…Future Work
Phase 1A and the work on the large onshore pipeline, give us confidence that the Pontem Model holds up, both in controlled conditions and at scale in the field. But there is more to validate.
Phase 1B will test a more complex network geometry, with two outlets instead of one, to confirm the model handles flow routing correctly when there is more than one path for liquid to take. From there, the goal is to keep expanding into more complex topologies, including converging and diverging pipelines, while continuing to refine how the model performs against real field data.
But the bigger picture goes beyond liquid surge. This work is part of a wider Pontem capability to build and deploy physics based models that run online, embedded directly into the platforms operators already use. Not models you run manually and interpret offline, but tools that sit inside your workflow and give you answers as conditions change.
We did not set out to replace commercial software. We set out to solve a problem it was not built for. A validated model, running on a live pipeline network, giving operators the answers they need when it matters most. And that is the kind of work we deliver.
If you made it this far, thank you! This is the kind of work we find genuinely exciting at Pontem, and we hope it was useful to read.