Simulation of a Multiphase Flow Sampling System

Greetings, everybody, and welcome. Today we're going to be going in depth on a multiphase flow metering solution that was achieved with, thanks to the power of MATLAB and Simulink. For those that aren't aware, multiphase flow metering is the measurement of the fluid flow rates at oil and gas well sites. These are the flow rates of crude oil, natural gases, and brine.

And these measurements are important for production and reservoir engineers who monitor and evaluate the productivity and efficiency of oil and gas wells. Before we explore the MATLAB and Simulink modeling on the upcoming slides, I would like to take a few moments to quickly explain the history of this challenge in order to place emphasis on what makes this topic so interesting.

The multiphase flow metering challenge has been around for nearly half a century since the development of the Coriolis meter in the 1970s, which can accurately measure two fluids in the same phase. So it can distinguish, for instance, water and oil flow rates. In the '80s and '90s, wellhead separators were, and still are, by the way, costly and bulky, and measurement technology began to improve.

So the industry became interested in the development of multiphase flow meters. Higher water content, together with depleting oil reserves, produced numerous cases where single phase metering was just too inaccurate to be useful. Eventually in the '90s, multiphase flow meters that can meet the industry needs were developed and made available commercially.

Much of the initial research was done in Norway at the Christian Mitchelson Research Center in Bergen. This is because there was a lot of subsidy development at that time and in that area. And several companies later expanded on that work, big names that you might recognize such as Schlumberger and Roxar.

Since then, commercial application in multiphase flow meters has seen exponential growth. This expansion is due to several causes, including improved performance, decreased costs, development of mobile systems, the needs of subsea metering, and of course, increasing oil prices.

Solutions have existed since the '90s for some of the narrow regions of flow compositions and rates. And all of these solutions have expanded and improved over the years, but none of the solutions currently in the market are truly ideal. In order to solve the problem, most multiphase flow meters combine several measurements. For instance, a meter may have an arrangement of instruments in various combinations of gamma densitometers, Venturi meters, pressure and temperature transducers, spinners, capacitive or resistive arrays, ultrasonic transducers, the list goes on and on.

To further complicate things, most sensors require a little help from operators in the form of what's known as PVT data for calibration. This is basically pressure, volume, and temperature data taken from various points in the pipeline. This is where most uncertainty in the measurement comes from. So what are the challenges involved in measuring three phase flow?

Firstly, fluid phases can slip past each other, meaning that individual phase velocities can vary. So water might be traveling slower than air or gas in a flow, for instance. The fluid can also be in any of several different flow regimes. Some measurement techniques only work under very specific conditions. Ideally you might want to be in a dispersed flow where the fluid is quite well mixed, for instance.

Also, a certain property of two fluids maybe similar, but this property for the third fluid is most often very different. For instance, the density of water and oil are quite close together, but they're both about 1,000 times greater than the density of most gases. The electrical permittivity for oil and gas is quite low, about an 80th of that of water. And the electrical resistivity similarly is high for oil and gas, about 10 to the 13 times higher than that of water.

The speed of sound for oil and water is quite high. It's about five times that of gas. And kinematic viscosity of oil and water are only about a tenth that of gas. So this list goes on and on, but because of this, measuring devices are often completely insensitive to one phase of the flow.

As an example of this, an ultrasonic transducer's impedance may be matched to the two liquids, but the gas will either reflect or completely scatter the signal based on the fluid flow regime. So this is basically sending a sound into the fluid and picking it up somewhere else, or picking up a reflection of that sound. But the presence of gas in the flow basically prohibits this from functioning properly.

Two measurements can't resolve three phase flow rates, so this is another issue. With a single phase flow, you know all of the fluid properties, but with a multiphase flow, you don't know how much of each fluid property is present. So you need three distinct measurements, three separate and distinct measurements to resolve the three phase flow rates.

If only density and superficial velocity are known, for example, how do the volume component and the flow rates of each phase? You can't. There's just not enough information there. So you need at least a third measurement, like a water cut measurement, for example, to resolve that.

So the idea that we propose to our colleagues in the Kingdom of Saudi Arabia is what we call the piston meter concept. So the core idea is that if a fluid flow doesn't feel any change in pressure, it will just continue to flow unperturbed. This device aims to capture a full flow sample of a fluid while ensuring at the same time that the pressure drop in the pipeline remains as unchanged as possible.

And once the sample is captured, the volumes are then measured and the flow rates of each phase are simply determined by their individual phase volumes over the time of the capture. So that's all flow rate is, is volume over time.

A pressure sensor at the entrance to the device continuously monitors and reports the pressure. And before the process begins, this pressure value is recorded as our target pressure. This is just the steady state pressure, what the flow wants to be at. This is the pressure that we want to maintain so that the fluid sees no change and the flow rates are preserved. To start the process of a capture, the normal flow direction valve is closed and the diverted flow direction valve is open.

So basically, instead of the fluid being allowed to flow straight through the normal flow path, we divert against the piston and into our measurement chamber. Instantly the pressure begins to rise, and as the piston has only just begun to accelerate, there's a quick change in the pressure at this point, which we want to mitigate as quickly as we can. But this change in pressure is measured and the actuator provides an assist to get the piston up to the appropriate speed and keep it there during the capture.

The real time pressure is constantly and repeatedly checked against the target pressure and adjustments to the actuator are made in real time. Once the piston is moving at the right speed, the pressure returns to normal and the flow rates of each phase return to their pre-capture values. And after sufficient volume is taken, the valves revert back to their original positions and the process may be repeated again and again and again.

So how is a system like this modeled in MATLAB? Well, it starts with an understanding of the physics of this problem. Even though the fluid may be a composition of multiple fluids with independent fluid properties, taken as a whole, these fluids in a mixture make a new fluid with distinct properties. In other words, the distributed properties within the flow average out on a large scale.

So in this view, the multiphase fluid acts as a single phase flow. And the system can be modeled as a transfer function or a state space model for linear operations. Given the knowledge of the current system states, such as pressure and flow rates, and the inputs driving the system, desired outputs can be derived from the model. If the images in the slide look like an electrical circuit, well, they should.

Fluid systems can be treated much like electrical circuits because their defining properties are analogous. I'll go into detail. So, pressure like voltage is the driving force behind current, or in this case, fluid flow. And in order for fluid to flow, there must be a pressure drop from point A to point B. And the rate of flow between those points is related to the resistance of the pipe.

This works exactly the way a resistor in an electrical circuit does for steady state flows. The fluid is also compressible, which means that it can store energy as pressure times volume. This is expressed here as capacitance or compliance, compliance of the fluid. The more gas that is present in the flow, the greater the compliance. And fluid that is flowing also has a momentum or kinetic energy as a function of its mass and velocity. This is termed inertance and is analogous to inductance in an electrical circuit. The higher the inductance, the more difficult it becomes to change the current over the same time period.

The same is true for fluid flows, and the higher the fluid inertance, the more energy is required to change its flow rate within a given time. I like to think of it like fluid flow economics, so the currency within the fluid is pressure and flow rate, which can be traded from place to place. But the tax on every sale is resistance in the pipe. So pipeline can be modeled in the same way you might want to model a transmission line.

The pipe is broken up into k number of segments and each segment holds a proportional amount of the lumped parameter values. If total pipeline resistance is, say, 100, and you break the pipe into 100 even pieces, then each piece holds a resistance of one. The same goes for compliance and emergence, since the fluid properties are assumed to be dispersed evenly along the pipeline over the duration of time required to make these measurements.

The upper image shows you how these segments are connected and the lower image shows the entire pipeline, with wellhead pressure as the source on the left and the pressure on the right being the pressure at the entrance to our meter. So we're able to neglect downstream piping because we're actually only interested in preserving the pressure drop of the upstream piping, because that's actually what's flowing into our meter. So we wish to preserve pressure drop between the source of the flow rate, which is usually the wellhead, and the entrance to the meter.

The transmission line model is then coupled to a simple mechanical model for the meter, so the pressure at the end of the transmission line is exerting a force on the body of the piston. Pressure from the downstream side exerts another force in the opposite direction. Because of some mechanical trickery, we're able to basically hold the pressure on the downstream side as a constant. This gives us a mechanical advantage where the actuator doesn't need to apply as much force.

Friction is considered as a constant force. And finally, the actuator on the system supplies the last force which would be acting on this body. So the equation of motion is written such that the acceleration of the body is a function of these forces and it is added to the state space model.

In the end, here's what the state space model looks like. So the first two rows of the model are the equations from the first loop in the transmission line model. The pressure from the source is an input to the system on the right hand side. And Y1 and Y2 from the lower matrix are the flow rate and pressures in that segment of the pipe, respectively. So each two rows represents one segment of the pipe.

The middle of this, no matter how big this matrix is, every two rows is identical, except that it just kind of walks diagonally down the matrix. So the reason they're identical is because each segment of pipe are modeled the same way and of equal length, so they each have the same equal proportional amounts of the lumped parameters.

And the last two rows are actually where the meter is coupled to the transmission line model, so the forces on the piston are circled in red on the right hand side. And everything that's in the output matrix is basically being outputted. So there's a 1 on every element. So we want to output every single pressure and flow rate for every single segment of the pipe. And the reason we're doing this is because it's easier to switch those on and off later in the state space model. I'll talk about that shortly.

Down at the bottom here is an example of some of the versatility of MATLAB. Because now that the system matrix is created, it just needs values. But with built-in tools in MATLAB we don't have to settle for just one set of values. We want to know how this meter will respond in all kinds of situations, so all gas flow rates, all liquid flow rates, the water cuts, different fluid types.

So not only can we build this matrix with as many nodes as we want, but we can also loop through any number of combinations of flow properties. For instance, we can vary the gas volume fraction, water cut, fluid velocity, source pressure. We can vary the piston size and mass. This ultimately gives us the ability to optimize the system for the greatest range of possible flows.

This is what the state space model that was used in Simulink actually looks like for this system. The state space model itself is centered in the middle of the page there, with signals flowing from left to right. So inputs come into the system on the left and outputs come out of the system on the right. And the one signal that moves from right to left is our single feedback variable, the local pressure.

Inputs to the state space model, just like in the previous slides, are the source pressure, actuator force, force of friction, and the force on the back of the piston body. And output selector is basically used to filter out signals that we don't need so that we're not outputting every single pressure and flow rate onto our state space model results.

Coming out of the right hand side are the interesting outputs of the system, so source flow rate is coming out and piped into a plot to compare it against the flow rate into the chamber, as well as a selection of flow rates upstream of the meter, just so that we can visualize what's happening to the fluid and the flow and see how the other meter affects the fluid flows upstream. And we're also outputting the piston position and velocity, and of course our feedback, which is the local pressure.

So this feedback pressure signal is compared against the target pressure signal, which is a constant value, and excuse the pun once again, it's piped over to a PID controller. And this is where all of the fun happens. So the PID controller attempts to generate an output, such that the difference between the pressure signal and the target pressure signal goes to zero.

This basically means that we've put the pressure back where it belongs. This output that it generates is the desired force on the piston body to accelerate it as quickly as possible to the appropriate flow rate and to constantly offset any resistance that the meter adds to the flow. Two constraints are applied to this output to make it more realistic.

Firstly, the output saturates because actuators can only produce a limited amount of force. And secondly, the signal is filtered to slow down the response to some realistic values because actuators can't just instantaneously switch their direction of applied force, for instance. Several outputs are plotted in the following slides from this model. But before we get into that, I'd like to talk about another key aspect of this effort, which was the PID tuning tool offered in Simulink Control Design.

With this tool, we were able to determine which PID gains were appropriate to the system, and really as a testament to the accuracy of this tool, the PID tuning values that were extracted from it for our laboratory prototype worked perfectly and the performance matched the simulations very, very well. So this saved us a lot of time because we didn't have to figure out our own tuning values from trial and error.

So here's some graphs showing us what's actually output. The first graph is the pressures. The blue line represents the target pressure that we're shooting for and the purple line is our local pressure in real time. So as we expect, the pressure initially spikes. The actuator starts to kick in instantly and there's some overshoot where the pressure dips below where it's supposed to be. This means that the piston's moving too fast and the flow rates are too high.

But the PID controller of course responds to this newly generated error as well. And eventually at around 0.8 seconds converges to within 2% of the target pressure and it just stays there. This is actually only a small time slice of the entire captures, so 95% of the time during the capture this pressure is converged.

The graph on the right shows us what we're actually interested in, the flow rates. So the dark blue line is the source flow rate, which should be the same everywhere in the pipe. So that's our target flow rate. The green line shows the flow rate into the chamber, so of course, initially, before the pistons had a chance to move there's zero flow rate.

But it quickly shoots up and overshoots the source flow rate and then eventually comes down and dovetails back to the source flow rate as the controller keeps improving the actuator force. And the orange line there is actually the moving average of that flow rate into the chamber.

So it's actually critical that the moving average converge as quickly as possible, because after the moving average of the flow rates converges to the source flow rate, this is basically when the measurement should be quite close and the uncertainty should be quite low, because at this point, you think that the average flow rates match up with the real flow rates. So we're measuring-- since we're measuring total volume, that's what we care about.

These two graphs are kind of fun. The first graph shows what the actuator is doing in the same exact test. So initially, it doesn't know it's supposed to do anything so it has zero force that registers, OK, the pressure is going up. And it starts applying as much force as it can. This output saturates at the limits of what this actuator can actually do.

And then it kind of oscillates after it settles where it's supposed to be to the amount of force required to combat the friction, that way this meter basically adds zero resistance to the circuit in general. And the purple line is the PID controller, what it wants to do. And the orange line is kind of what might actually happen, what actuators can really do.

The next graph shows flow rate into the chamber. And each following line is the flow rate just slightly upstream of that point, so going further and further upstream. So what we see here is that a, the flow rates are disturbed after a little bit at a time as you go further and further upstream.

So for instance, the source flow rate wouldn't really change at all because we're talking about hundreds of meters away from our piston meter. But these are only about 1.5% meters upstream, 3 meters upstream, 4.5 meters upstream, and so on.

And another thing that you will notice is that the amplitude of this change gets less and less and less and less. This is because there's quite a high gas volume fraction here, so the compliance of that gas absorbs a lot of that change.

Just a few conclusions that I would like to draw from this. Basically, one of the really cool things that we've done here is we've done some fluid flow analysis without CFD. A lot of people go straight to CFD as the answer. When dealing with multiphase flow it's quite a complicated system, and so you need something with a lot of power to interpolate what's going on with that flows.

But in our case, we're taking numerous discrete measurements and averaging those out. So we don't really need to zoom in on what's happening right at the entrance to the meter, because we know that any errors that are introduced from, let's say, slug flow or something like that, will average out over numerous captures. And another thing is really we wouldn't have been able to do this without the power of iteration.

The state space model just being able to operate that over and over and over again and just use brute force to extract information was really a huge advantage for us. And the ability to tune the PID system with Simulink control design, I've already mentioned it's a lifesaver, because we were able to get exactly the PID values that we need and help validate the concept as quickly as possible.

And most importantly, the simulated results from the Simulink model matched expectations very well. So it validated our concept, which is very important for a research team. So that's it and I'd like to open it up for questions and comments now. Thank you very much.