Beruflich Dokumente
Kultur Dokumente
Pipeline Modelling
Willy Postvoll, Gassco AS
Svein Birger Thaule, Gassco AS
Gunnar Flaten, Statoil AS
Olav Urdahl, Statoil AS
Richard Spiers, Energy Solutions International
Jonathan Barley, Energy Solutions International
Abstract
Operation of the Huldra field commenced on November 2001. It is a gas condensate
field, which has been developed with a not normally manned wellhead platform remotely
controlled from the existing, manned Veslefrikk B platform. A first stage separation
process is installed at the platform to separate gas and liquid.
Two pipelines emanate from the Huldra field a 93.2-mile [150 Km] 20 inner diameter
pipeline transporting wet gas from Huldra to the Heimdal platform and an 8 inner
diameter 9.9-mile [16 Km] pipeline transporting unstabilised condensate, including water,
to the Veslefrikk platform.
Due to the hydrocarbon mixture, the flow through these pipelines exhibits multiphase
behaviour and therefore requires a multiphase real-time simulation model for surveillance
and optimised control.
Statoil was responsible for development of the Huldra field and is the field operator. The
transient multiphase code OLGA has been an important tool in all phases of the project
from the decision to develop the field and into the production phase. The design of the
Huldra wet gas pipeline was a significant improvement in multiphase flow transport
technology due to the long large diameter pipeline which should be tied-in to the existing
Heimdal platform with restricted liquid processing capacity. For the condensate line
efficient and good environmental hydrate and wax control methods are selected.
This paper describes the requirements of the simulation engine and the pipeline
modelling system. This leads to a clear split between the functionality that is necessarily
encapsulated in the simulation engine and the functionality that can be incorporated
within the wider On-Line System environment developed by Energy Solution International
for gas pipeline modelling. The aim is to provide a common level of functionality
throughout the system. Functions for multiphase flow pipelines, such as: model tuning,
leak detection, liquid accumulation, and composition tracking need to be considered as
well. A brief description of the approach to these issues is given. The strategy for
operating the pipeline and its impact on extending the functionality of the existing OLS
system is presented.
This paper gives a brief description of the initial operational experiences with the realtime model.
Page 1 of 30
Introduction
In November 2001, the Huldra field commenced production. Design and start-up of the
transport system for wet gas and condensate from Huldra is an extension of current
experience. Statoil, as the operator of the Huldra field, awarded Gassco contracts for
operational support for the condensate and wet gas pipelines. Valuable experience
related to operational aspects and real-time modelling of large-scale multiphase flow
systems has been gained after start-up of production.
Huldra is a gas/condensate field located in the North Sea at a water depth of 410 ft [125
meters]. After a first stage separation the rich gas containing water and MEG is routed
93.2 miles [150 km] to the Heimdal platform for further processing. Unstabilised
condensate is routed 9.9 miles [16 km] to the Veslefrikk platform for further processing. A
Direct Electrical Heating (DEH) system is employed in the condensate pipeline to avoid
hydrate formation during shut-ins. Figure 1-1 displays an illustration of the infrastructure.
The Huldra field originally had an estimated in place gas reserve of 685 GSft3 [19.4
GSm3] and a condensate reserve of 46.5 MBBLS [7.4 MSm3]. Measured reservoir
conditions are 9,795 psi and 277 degrees Fahrenheit [675.5 barg/136 degrees Celsius].
The field is developed as a not normally manned wellhead platform. As from July 2002,
Huldra has become remotely controlled from Veslefrikk. The well streams are routed to a
production separator. Gas from the production separator is cooled and liquids are
removed in a scrubber. The gas saturated with water is fiscally metered, inhibited with
MEG and routed to Heimdal for further treatment. Liquid production, i.e. condensate and
produced water, from the production separator and the scrubber are mixed and
transported to Veslefrikk, for further treatment.
At Heimdal the flow from Huldra is received by a three-phase free water knock out
vessel. Capacity of this vessel is limited to handle 1413 ft3/h [40 m3/h] condensate and
35.3 ft3/h [1 m3/h] water. Liquid storage capacity of the vessel is 247 ft3 [7 m3]. Further on,
gas from Huldra, the Vale field and the Heimdal reservoir are processed together to
comply with the sales gas specification.
The Veslefrikk platform receives and separates the condensate and gas arriving from
Huldra. The condensate pipeline is equipped with direct electric heating to avoid hydrate
and wax formation at low production rates or during shutdowns.
It was considered necessary to install a real-time multiphase pipeline model as an
operational support tool. Statoil in cooperation with Energy Solution International
designed, developed and set the model in operation.
Gassco AS was established the 14th May 2001 under the provisions of a Norwegian
White Paper. Operational responsibility in the new, regulated gas transport regime
commenced on January the 1st 2002. Gassco is assigned all the operators
responsibilities warranted in the Norwegian Petroleum Law and related Regulations.
Gassco is the operator of about 3,853 mile [6200 km] of large diameter, high-pressure
gas pipelines, gas processing facilities and terminals. Up to 7,770 MSft/d [220 MSm3]
gas is delivered to the gas buyers daily. Further, on behalf of Statoil, Gassco have
contracts for operational support for 416 mile [670 km] of oil/condensate and multiphase
flow pipelines, including the pipelines from Huldra. The pipelines operated by Gassco
connect 60 installations including 4 locations where the gas flows can be blended to
Page 2 of 30
ensure correct gas qualities. About 6000 telemetry signals are transmitted to the Gassco
control centre twice a minute.
Design Requirements
Functional requirements for the real-time multiphase model were established to provide
for safe and stable operational conditions. The following parameters were embraced by
the functional assessment of the multiphase flow pipelines to Heimdal and Veslefrikk:
Wet gas pipeline
Liquid transport in the pipeline and into the Heimdal process during
production turn-down, production start-up and production increase
Instrument accuracy
Page 3 of 30
Condensate pipeline
Instrument accuracy
A phase diagram for the wet gas transported to Heimdal was established to determine
the liquid fraction at various pressures and temperatures, as shown in Figure 2-1.The gas
that leaves Huldra is saturated and located at the dew point of the phase envelope, and
the condensate transported to Veslefrikk leaves Huldra in the liquid phase. In the
pipelines the flowing conditions give two HC phases as the pressure and temperature
decrease along the lines.
10000
2500
8000
2000
6000
1500
Pressure [psi]
Pressure [psi]
4000
500
2000
0
-400
1000
-200
200
400
600
Temperature [ F]
Vap/liq frac = 0.999
Vap/liq frac = 0.995
Vap/liq frac = 0.980
800
0
-150
-100
-50
50
100
150
200
Temperature [oF]
Vap/liq frac = 1.000
Figure 2-1 Predicted Phase Diagrams of the Well Fluid and Wet Gas
The main challenge for operation of the transport lines from Huldra is to keep control of
the liquid accumulation in the wet gas pipeline, and to control the liquid transport into the
Heimdal process when gas production rates are changed. Figure 2-2 shows the liquid
content in the transport line when stable conditions have been reached as predicted by
the simulator (not tuned based on operational experiences). It was seen that for flow
rates below about 6 MSm3/d the liquid accumulated in the pipeline would be difficult to
Page 4 of 30
50
Liquid content
9000
45
40
7000
35
6000
30
5000
25
4000
20
3000
15
2000
10
1000
8000
0
0
10
12
Figure 2-2 Predicted Liquid Content and Condensate Accumulation Rate in the
Huldra-Heimdal Pipeline for Various Gas Flow Rates
2.1
Condensate rate
Gassco Transport Control Centre (TCC) is equipped with state-of-the-art data handling,
surveillance systems and pipeline modelling systems. Currently, 24 pipeline systems are
modeled and are running real-time. The TCC computer network is shown in Figure 2.3.
The gas, oil and condensate pipelines are modeled in real-time using the single-phase
transient simulation engine TGNET embedded in the Energy Solutions On-Line system
environment (OLS). For real-time modeling the multiphase lines it was required to use a
multiphase transient simulation engine. The transient multiphase simulation engine
selected was OLGA.
The OLGA simulator facilitates transient multiphase simulation features. The governing
equations describe mass balances for each of the phases, momentum balances and
energy balances. Interactions between the phases are computed based on semiempirical models. Physical properties of the fluids are pre-tabulated using the PVTpackage PVTSIM. OLGA also features a flow regime estimation function that
automatically computes the transition between various flow regimes, depending on the
pipeline conditions. Flow regimes accommodated by OLGA are the following: stratified
flows, annular flow, slug flow and bubble flow.
Page 5 of 30
Known Functionality
Facilitate maintenance
data from both single and multiphase models without the need to specifically identify the
model type.
3.1
Design Basis
Given that the existing system is modular, a number of possible approaches to the
integration were considered:
Using an independent modelling system receiving its own data from SCADA
and its own independent suite of displays.
The first was discounted, as it did not meet the conditions for providing an integrated
environment for the operators.
The second would use the existing SCADA interface and instrument data processing
tools, but would provide a separate suite of displays and display management for the
multiphase pipelines. Further, the existing modelling system displays provide access to
all aspects of the model from the initial instrument data processing to the simulation
results. Thus, two sets of display management would be involved for accessing the
model data. To the operators, this would not appear as an integrated system.
The third approach allows the system to be run as an integrated unit, provided that the
multiphase simulation engine can be run alongside the single-phase engine. It also
requires that similar data structures be adopted for both engines. This further enables
similar displays and display management to be adopted for both simulation engines.
However, there remains the problem of displaying single and multiphase data in identical
layouts so that switching between the models in the system remains transparent to the
user. This problem was resolved by adopting a preferred phase for each of the
multiphase models as follows:
Separate displays would be provided for each of the gas, hydrocarbon liquid
and water phases.
Page 7 of 30
Common displays, although new displays were required for the individual
phase and total flow data.
Disadvantages were:
All models, regardless of simulation engine type, required the same data
structures.
New data structures were required for handling individual phase information.
Batch, where the user executes a simulation of his model for a given set of
parameters. The parameters are provided as part of the input data. This is
typical of offline processing.
For the first mode, the user need only provide a single input file, while the results are
available in a series of output reports or graphical presentations.
For the second mode, OLGA is provided as a server process. Communication between
the client and the server is provided through a standard TCP/IP protocol. Control, input
and output data are passed to the simulator via a sequence of messages using a simple
request/reply paradigm. The content of the messages may range from a single command
to a complete picture of the current state of the simulation and this allows the OLGA
simulator to be integrated into an existing on-line system.
The OLGA server provides the following functionality:
Initialisation
Page 8 of 30
Thus, to set up a real-time simulation using the OLGA server, it is necessary to provide a
client program that communicates with the server process using the TCP/IP protocol and
the correct sequence of messages to achieve the desired result. Such a process has
been designed and built to integrate the OLGA simulation engine into the existing OnLine System (OLS).
A further advantage of the use of a client-server approach to the simulation engine is that
it allows independent updating of the server software, providing that no changes are
made to the messaging structures.
4.2
A major advantage of the OLS system when considering the integration of the OLGA
server is its use of independent processes for each real-time, look-ahead and predictive
model. One, and only one, process being used to execute each model. Such a structure
enables a real-time process to be replaced with a client-server pair. This has the added
advantage that future engine developments can be readily incorporated into the OLS
system.
With the requirement to provide an integrated simulation engine, the opportunity was
taken to revise the management of the simulation processes within OLS. In previous OLS
systems, it was a requirement that a real-time model process be available before, during
and after execution of the real-time simulation itself. There was a similar requirement for
the look-ahead simulation. This normally required the system administrator to ensure that
such processes were started before the model configurations or simulation tasks were
started. It was a requirement that equal numbers of real-time and look-ahead processes
were started at the same time. If additional processes were required, then they had to be
started manually. Where a large number of simulation processes were required the
management of such a system required a considerable amount of care.
With the requirement to be able to execute different simulation engines within the OLS
structure, it becomes necessary for the correct process be available for each
configuration. Such a requirement could be accomplished manually, but would require
intense system management. Alternatively, provided that the simulation engine
requirements could be identified a priori, it would a relatively simple matter to start the
required engine for the task demanded. Thus, original OLS type configurations would
request the original simulation engine; OLGA type configurations, an OLGA engine.
Having established the correct simulation engine for the model, the correct processes
must be started and monitored. For an OLGA type simulation, both the client and OLGA
server processes must be started and communication established between the pair.
These two processes must then act as a co-operating pair. The pair must be present and
correctly initialised before a model can be loaded and run.
The sequence for starting a model process becomes:
Page 9 of 30
Start the necessary process. For OLGA simulations, both the client and
server processes must be started.
Initialise the process. For the OLGA client-server pair, this includes
establishment of communications.
In the event of the simulation being stopped or a failure occurring and resulting in the
shutdown of a simulation process, the system flag is unset to indicate loss of the process.
For the OLGA client-server pair, the failure of either must result in the shutdown of both.
An overview of the integrated system including the process control watchdog is given in
Figure 4-1, Integrated System Overview.
Process
Management
SCADA Interface
SCADA
Data
Instrument Data
Validation
Instrument
Data for
RTM1
RTM1
Instrument
Data for
RTM2
RTM2
(client)
Instrument
Data for
RTM3
RTM3
Instrument
Data for
RTMn
RTMn
Display
Management
4.3
Data Mapping
One of the key areas enabling the integration of the OLGA engine into the OLS
environment is the data mapping between the different systems. The OLS has been
Page 10 of 30
developed over many years using a single (single phase) simulation engine. The
configuration data and the data structures for storing state and other variables within OLS
are centred on the (single phase) simulation engine. For the integration of the OLGA
engine, both of these areas needed to be addressed.
4.3.1
Both the OLGA simulation engine and the OLS environment require configuration
information, such as pipeline geometry. However, the configuration information that is
common to OLGA and OLS is limited to:
Process Equipment
Both OLGA and OLS use a similar approach to entering configuration data into the
system i.e. they both use an ASCII input file that has a keyword type structure. Indeed,
the keyword structure in OLGA is similar, though not identical, to that employed by OLS.
The OLS configuration input file provides much more information than just the
configuration data. Many on-line parameters and application options are defined within
configuration input file. In particular, the connectivity and location of the instrumentation
necessary to drive the Real-Time Model are defined. For this reason it was required to
merge the configuration data from the OLGA input file into the OLS configuration file prior
to processing the OLS configuration file. However, the integrity of the OLGA input file
must be maintained in the above process as both sides of the client/server interface use
this file to define the pipeline geometry. This file merging approach is also
advantageous in terms of system maintenance as it means that changes to the
configuration need be applied to one file only.
4.3.2
During the execution of the multiphase real-time simulation, data are passed between the
client and server processes. Typically control data are passed to the server and state
data are returned from the server. Data passing in either direction requires manipulation
of the data for the following reasons:
1. OLGA uses a different set of internal physical units to OLS.
2. OLGA data distributions are by a contiguous, ordered set of pipe legs
(BRANCH). However, OLS data distributions are by a non-contiguous, nonordered set of pipe legs (profile line).
3. OLGA data are generally cell-centred with flux based data defined at the cell
boundaries. OLS data are always defined at computational cell boundaries and
therefore some redistribution of OLGA data is required to map OLGA data into
OLS data structures.
4. OLGA uses a slightly different set of primary variables to OLS. However, the
primary variables used in OLS may be derived directly from OLGAs primary
variables.
Page 11 of 30
5. Many OLS data structures are derived from knot-based structures dynamically
during the course of simulation. For OLGA data returned to OLS these
derivations are required to be performed explicitly to populate the non knot-based
OLS data structures.
Figure 4-2 provides an overview of the data processing that is required to transfer an
OLGA data set into an OLS data set.
OLGA
Variable
Unit
Conversion
Generate Mapping
from Profile Line to
Knot Array
Redistribution of
Discretized Data
Calculate and
Populate Ancilliary
Knot Based Data
Structures
Populate Ancilliary
Non-Knot Based
Data Structures
OLS
Variable
4.3.3
The majority of simulation control parameters (such as simulation end time and tuning
parameters) were already supported in the OLS environment. For those parameters that
were not supported it was a simple matter of including storage and access to the
parameters within OLS.
The OLGA (transient) simulation is driven by pressure and mass flow instrument data. As
OLS already uses these variables as input to the (single phase) simulator the only
requirement is to convert the data from OLS internal units to OLGA internal units prior to
data being sent to the OLGA server. As well as boundary flow and pressure variables,
the transient control variables for valve opening/closing and wall heating are passed to
the OLGA engine
4.3.4
Data Structures
In order to integrate the OLGA engine within the OLS framework, it is necessary to
support certain OLGA simulation data within the OLS data structures. This enables the
system to provide the required ancillary functionality such as displaying (and modifying)
simulation parameters through existing MMI screens, instrument connectivity, and
applications such as Inventory Analysis, Leak Detection, etc. Indeed, from a User
perspective, the aim of the integration is to allow data from a configuration to be
displayed in the same manner on the same screen no matter which engine originated the
data. To accomplish this, the existing OLS data structures were extended to include data
that is specific to multiphase pipeline operations. This extension of the data structures
requires a set of data mapping functions to enable data conversion, re-ordering and
redistribution of data.
Page 12 of 30
5.1
Error Sources
Solution errors resulting from erroneous input data, e.g., field measurements.
Page 13 of 30
5.2
Line pack calculations require knowledge of the phase splits, line pressures
and temperature to accurately predict liquid hold-up, etc. That is, the
calculations rely on the multiphase correlations and the thermodynamic
modelling.
Leak Detection
Model-based leak detection methods rely on the comparison of measured and calculated
(simulated) values from the pipeline. The measured values are obtained from the
instrumentation and consist of pressure, flow, temperature and fluid properties. The
instrumentation is typically located at the ingress and egress.
The pipeline models provide complete real time profiles of pressure, flow, temperature
and density along the pipeline accounting for variations due to the operation. Thus
changes in operation cause "expected" variations in flow and pressure ideally with no
deviations between calculated and measured values. Leaks, however, cause an
"unexpected" variation and a well-defined pattern of deviations between calculated and
measured values develops. These patterns can be detected and assessed to determine if
a leak is present.
Unexpected variations in pressure and flow can be calculated depending on the controls
applied to the model. Where the pressure is applied as the control measurement, an
unexpected variation in flow (UF) can be expected. Similarly, where the flow is
controlling, an unexpected variation in pressure (UP) will be seen.
5.2.1
Before the unexpected flow (UF) and pressure (UP) responses can be used for leak
detection, thresholds must be established. Thresholds are determined for both flow (UF)
and pressure (UP) uncertainties. It is important to note that thresholds derived from the
UF and UP responses are applicable to steady-state flow. To avoid false alarms during
transient, it is usually necessary to raise the thresholds. Thresholds must be raised
immediately on detection of a transient, but can then be returned slowly towards the
steady-state values after the transient has passed. Such behaviour can be achieved by
the use of a threshold filter factor.
5.2.2
Leak detection using pressure and flow discrepancies requires the model to be an
accurate representation of the actual operating pipeline. Such requirements are not met
under the following conditions:
All data used in the calculation of the discrepancies (UP and UF responses)
are bad or invalid
Page 14 of 30
The model has been initialized but not yet attained a suitably tuned state
the cold start period.
Changes have been made in the configuration of the leak subsections the
warm start period.
Under any one of these conditions leak detection will become unavailable (inhibited). If
only some of the leak subsections are affected, then only those leak subsections will
have leak detection inhibited. Once the condition has cleared, leak detection will be reenabled. If the condition causing inhibition was bad data, the condition must have cleared
for longer than the warm start period.
Leak detection is also inhibited if slugging is detected from the OLGA model. Inhibition
may be avoided if the leak detection thresholds can be raised to a sufficiently high level.
Once slugging has passed, the thresholds would be returned to normal using the
threshold filter factor.
5.2.3
Leak Location
Once the onset of a leak has been determined, the leak location can be determined by
comparing the pressure profiles of models of the pipeline. The two models required are
based on:
1. Measured downstream pressure as downstream pressure set point
Measured upstream flow (estimated) leak flow rate as upstream flow set
point
2. Measured upstream pressure as upstream pressure set point
Measured downstream flow + (estimated) leak flow rate as downstream flow
set point
In the presence of a leak the pressure profiles of the above simulations will cross at a
point this point is a good estimate of the location of a leak (see Figure 5-1).
A similar argument can be used to determine leak location if the underlying pipeline
model is upstream pressure controlled.
Page 15 of 30
130
120
110
100
90
80
70
PipeLine Pressure Profile
QP Model
PQ Model
60
50
40
0
10
20
30
40
50
60
70
80
90
100
Px =
where
k=
(k
x k 2 r 3 s )
(1)
m
f
is the mass flux, ghx = s is the pipe gradient, and r =
is the friction
A
2D0
term.
Assuming that the process is isothermal then we can derive a solution for the pressure
distribution along the pipeline. Equation (1) can then be integrated exactly to provide the
distance (x) along the pipe as a function of pressure, P. Assuming that this function is
invertible then we have implicitly a function for P in x.
Alternatively, if the phase densities and thermodynamic quality are available for each
pipe segment, the homogeneous density can be calculated, and (1) integrated
numerically along the pipe to provide the information above.
Page 16 of 30
5.3
Imbalances
Imbalances arise from the hydraulic simulation as the differences between measured and
calculated values. The location of the imbalances depends on the choice of boundary
conditions. For a simple point-to-point pipeline model whose pressure is set at the
egress, flow at the inlet, and pressure and flow measurements are available at both inlet
and outlet, the following imbalances are present:
1. Pressure imbalance at the ingress
2. Flow imbalance at the egress.
Only when a model has been operating for longer than the characteristic time period of
the pipeline will the imbalances be truly representative of the actual errors in the pipeline
instrumentation. It is the task of tuning to reduce these imbalances to a minimum while
trying to recognise potential errors in the instrument values.
By making the assumptions and using the equations for the pressure drop described
above, it possible to predict inlet pressures and outlet flows (They are also available from
the OLGA solution.). Hence expressions can be derived for the pressure and flow
imbalances at the pipeline inlet and outlet respectively. It is now required that a pipe
roughness be found that minimises the pressure and flow imbalances. The actual
roughness to be used is obtained by combining the previous roughness with the new
value and applying a change limit and a suitable filter factor.
5.4
Tuning
In multiphase flow, there are a number of other factors that are not known exactly and
may be adjusted to ensure matching of measured and calculated pressure drop. The
OLGA Server provides access to the following variables for tuning purposes:
Pipe diameter
Entrainment rate
Ambient temperature
Of these, only the Pipe Diameter, Pipe Wall Roughness and Ambient Temperature have
been considered for estimation and automatic adjustment. The other factors may be
tuned manually.
Page 17 of 30
5.4.1
Roughness
The purpose of roughness tuning is to try to improve the modelled pressure drop against
the measured pressure drop by adjusting the pipe wall roughness.
From Moody friction factor charts, it is clear that, for typical pipeline conditions,
roughness only becomes a significant factor in the friction factor at Reynolds Numbers
5
above ~10 . For liquid pipelines this implies that the friction factor is not greatly influenced
by the roughness. Such conditions will apply to the condensate line even if small volumes
of gas are present. For the wet gas line, pressure drop will be dependent on the amount
of liquid in the pipeline and how it is distributed. Since liquid dropout occurs at low flows,
it is likely that roughness will not be a major factor in determining the pressure drop under
these conditions. As the flow increases and the amount of liquid decreases, roughness
will become a more influential factor.
If we assume that our modelled and measured pressure drops are close and that the
average pressure in the model is in some sense close to the average pressure in the
actual line then we can use (1) to determine the change required in the variable r (related
to the roughness) to correct the difference in the modelled and measured pressure drop.
If Px =
P
P
is the modelled pressure drop and Px =
is the observed pressure drop,
L
L
then
Px =
(k
x k 2 r 3 s )
and
Px =
(k
x k 2 (r + r ) 3 s )
where r+r is the friction factor term above required to match the measured pressure
drop.
Then, the change, r, required in r is by:
r=
k2
(P
Px )
(2)
From equation (2), we can calculate the change in the friction factor required and hence,
from Colebrook-White, the required change in the roughness. The maximum change in
roughness is bounded and the actual value applied filtered.
At low flows, i.e., low Reynolds Numbers, roughness tuning may become insensitive to
changes in pressure and flow. Under such conditions it may be preferable to switch to
another tuning parameter, such as pipe diameter, or undertake tuning manually. A flow
limit is available, below which automatic tuning is discontinued and any parameter
changes can only be made manually.
5.4.2
Ambient Temperature
Temperature tuning uses those temperature measurements that are not used as
boundary conditions within the model, e.g., outlet temperatures. This assumes that such
temperatures are representative of the temperature as seen by the pipeline.
Page 18 of 30
For each subsection the temperature imbalance is determined. This may then be used to
calculate the incremental ambient temperature. The applied increment is subjected to
filtering, maximum change, and temperature limits
Applications
6.1
Overview
For any on-line modelling system, it is important that simulation results can be analysed
and presented in a variety of ways. For OLS this is achieved through the various
applications modules, which are executed as part of the simulation. These take the basic
simulation results of pressure, flow and temperature and perform further calculations or
checks on the results. Typical applications are:
Inventory Analysis
Scraper/Pig Tracking
Quality Alarming
Two-Phase Alarming
Hydrate Alarming
Since these applications are general, it is not unreasonable to assume that they can be
used with almost any pipeline simulation engine. They simply require the necessary
simulation results. However, additional facilities were required in individual applications to
account for multiple phases in place of a single-phase gas or liquid.
OLGA also performs a number of detailed calculations in addition to the basic multiphase
hydraulic simulation. Typical of these calculations are:
6.2
Two-Phase Applications
From an operational point of view it is of great importance to detect the presence of slug
flow. The OLGA Server provides information in the form of an index indicating the flow
regime at each calculation point. The simple application generates alarms or events if
slug flow is indicated in any part of the network. A profile plot of the flow regime indicator
together with the elevation profile is provided in the MMI. This is annotated with the
interpretations of the flow regime indicator. The condensate pipeline is designed to
operate outside the slug flow region, and warning must be given if slug flow conditions
are predicted in the pipeline.
OLGA contains an optional slug-tracking module. If this has been activated and slug flow
is present, the OLGA slug-tracking module calculates the numbers, lengths and positions
of the slugs. Of particular concern are the approach of slugs to the risers and the
possibility of slug flow therein. An extension of the alarming application considers the
Page 19 of 30
approach of slugs to the riser base or the presence of slugs in the riser itself. Using the
slug front velocity the time to reach the riser base can be estimated.
6.3
Hydrate Alarming
The prediction of the formation of hydrates within the pipelines is considered as follows:
6.3.1
The OLS is already provided with a hydrate alarming function based on either calculated
hydrate formation temperatures using the gas composition or the provision of tables of
hydrate dissociation. Alarms are generated for any part of the network where the fluid
temperature falls below or to within a pre-defined limit of the hydrate dissociation
temperature.
6.3.2
Hydrate Prevention
The condensate line from Huldra to Veslefrikk is provided with electrical heating for the
pipeline section between the spool pieces in order to avoid hydrates and wax. The aim is
to maintain the fluid temperature above the hydrate formation temperature during
unplanned shutdowns and low flow conditions. Insulation is provided to minimise the use
of electricity. As the heating system does not cover the end zones, hydrates will be
prevented in these sections by using traditional inhibitors during shutdowns.
The OLS hydrate prevention application calculates the electrical power requirements
based on fluid temperature and hydrate formation temperature. The calculations are
performed in the Real-Time Model using current temperature profiles and hydrate
formation temperatures.
Following a shut-in, the velocities in the pipeline will rapidly decay to zero. Under such
conditions, it can be assumed that cooling of the pipe and contents will be mostly by
conduction. If it is also assumed that the heat flow from segment to segment due to the
longitudinal profile is small, each segment can be considered of uniform temperature. If
the fluid is considered to be a single homogenous phase, then, prior to hydrate formation,
the temperature in the shut-in pipe will cool exponentially. The initial segment
temperatures reflect the flowing conditions immediately prior to shut-in. Such a model,
using the flow heat transfer model for the transfer of heat from the fluid to the pipe wall,
provides reasonable estimates of the cool-down and heating periods under all flowing
conditions also. Thus, temperature approaches and estimates of when to turn electrical
heating on/off and the power requirements can be determined.
Although primarily concerned with the initiation of electrical heating, the model also
predicts when electrical heating can be discontinued following the resumption of flow in
the pipeline.
Page 20 of 30
Warnings or alarms are issued to alert the operator to the time when hydrate inhibitor
injection and/or electrical heating is required. Warnings or alarms on the time remaining
to the start of operation of these features are given also.
No total liquid rate metering for the flow into the condensate line at Huldra
One of the aspects that were followed closely is the liquid content and distribution in the
Huldra-Heimdal pipeline. A view of these features together with the process diagram and
the corresponding measured and modelled instrument values can be seen in Figure 7-1.
Page 21 of 30
The transport conditions for the period March to May 2002 can be viewed in figures 7.2
and 7.3. Figure 7.3 displays the monitored pressure drop and the corresponding gas flow
rate in the wet gas pipeline to Heimdal, and Figure 7.3 displays the monitored pressure
drop and the corresponding liquid flow rate in the condensate pipeline to Veslefrikk.
35
25
30
25
20
30
20
15
15
10
10
1-mar
11-mar
21-mar
31-mar
10-apr
20-apr
30-apr
10-mai
20-mai
30-mai
2002
Huldra Pressure
Figure 7-2 Monitored Pressure Drop and Flow Rate in the Huldra-Heimdal Pipeline
H uldra-V eslefrikk D elta P ressure and Flow R ate
Veslefrikk Flow Rate
400
30
350
20
300
10
250
200
-10
150
-20
100
-30
50
-40
Pressure [barg]
Veslefrikk Pressure
40
01.03
11.03
21.03
31.03
10.04
20.04
30.04
10.05
20.05
30.05
2002
Figure 7-3 Monitored Pressure Drop and Flow Rate in the Huldra-Veslefrikk
Pipeline
For the wet gas pipeline the measured and modeled pressure drops during stable
production periods are within 10% as seen from figure 7-4.
With regard to prediction of liquid accumulation in the wet gas line improved metering
accuracy at Heimdal is required to verify the predictions.
Page 22 of 30
The pressure and temperature drop estimates in the condensate have fairly large
inaccuracy. The flow measurement accuracy must be verified before tuning of the
model can be performed.
P re s s u re D ro p H u ld ra -H e im d a l - D e s ig n v s . M e a s u re m e n ts
30
25
20
15
10
5
0
2
10
11
F lo w r a t e [ M S m / d ]
M e a s ur e m e nt s
G r a vita t io n d o m ina te d
F r ic t io n d o m ina t e d
Figure 7-4 Comparison of simulated and measured pressure drop across the wet
gas pipeline.
Scandpower has extensively verified OLGA against field data. Moreover, Statoil has
verified the predictions using in-house field data. The pressure drop predictions will for
most field data be within 10-20%. For liquid accumulation predictions for large
diameter pipelines the predictions are within +-20-30% for frictional dominated flow. For
gravity dominated flow the uncertainty in the predictions is large; +- 40-50%.
Conclusions
The development of the Huldra pipeline system has been an interesting and technically
challenging experience.
The pressure drop predicted by OLGA for the wet gas line is within 10% of measured
values without parameter tuning. For verification of the liquid predictions for the wet gas
line and pressure and temperature drop predictions for the condensate line the flow
meter accuracy must be verified/improved.
8.1
The OLGA engine has been successfully integrated to run in parallel with
another pipeline simulator and is providing the operator with critical
operational information.
There is minimum duplication of input data between the two systems, with no
impact on OLGAs input data requirements.
All displays and other output data requirements have been integrated to a
common basis.
Page 23 of 30
8.2
Operational Requirements
The models used for supervision must be tuned using the operational data.
Acknowledgements
The authors appreciate the permission to publish this paper given by the Huldra license with the
partners Statoil, TotalFinaElf, Conoco, Svenska Petroleum, Petoro and Paladin Resources.
Page 24 of 30
Authors Biographies
Dr. Svein Birger Thaule
Executive Officer Technology,
Gassco AS, NORWAY.
Svein Birger started his professional career with Norsk Hydro Oil and Gas in 1981 where he worked with
offshore field development projects. In 1985 he joined Statoil where he had various positions in development
projects, operations and research. From 2002 he has been Executive Officer Technology in Gassco AS.
Education
MSc Fluid Mechanics, University in Trondheim (NTH), Norway
Dr. Ing., Computational Fluid Dynamics, University in Trondheim (NTH), Norway.
Publications
Thaule, S.B. and Herle, E., Etzel Gas-Lager, Storage facilities and preparation for operations, Gas
th
Processors Association, European Chapter 10 Continental Meeting, Paris June 1993.
Thaule, S.B., Etzel Gas Storage, Operational and Predictive Model for Gas Withdrawal, International Gas
Union, 19th World Gas Conference, Milan 20/23 June 1994.
Thaule, S.B. and Gentzsch, L., Experience with Thermophysical Modelling of Gas Cavern Operations in Etzel,
SMRI-Fall Meeting 1994, Hannover, Germany.
Thaule, S.B., Lagring av Naturgass, Commett Seminar, Haugesund October 1994.
Thaule, S.B., Computational Analysis of Thermophysical and Flow Characteristics in Cylindrical Gas Cavern,
Dr. Ing. thesis December 1994 (NTH 1995-15), Trondheim, Norway.
Thaule, S.B., Computational Analysis of Thermophysical and Flow Characteristics in a Cylindrical Gas
Cavern, ASME/JSME joint thermal conference, Hawaii March 1995.
Thaule, S.B. and Fosse, A.P., Experience with large withdrawal rates from Etzel gas storage, SMRI-Fall
Meeting 1995, San Antonio, TX, U.S.A.
Thaule, S.B. and Lokna, T., Commercial implications of European pipeline developments, Transport & Trading
in UK & European Gas, London September 1996.
Thaule, S.B. and Postvoll, W., Experience with computational analyses of the Norwegian Gas Transport
Network., PSIG Annual Meeting, San Francisco, CA, U.S.A.
Thaule, S.B. and Postvoll, W., Experience with computational analyses of the Norwegian Gas Transport
Network, International Gas Union, 20th World Gas Conference, Copenhagen 9/13 June 1997. Also published
in Oil&Gas Journal, March 23. 1998.
Thaule S.B. Computational analysis of thermophysical and flow characteristics in gas caverns, SMRI-Fall
Meeting 1997, El Paso TX, U.S.A.
Andresen, M. and Thaule, S.B., Vectors Demonstrates How Simulations Save Cost of Gas Storage
Operations, SMRI-Fall Meeting 1998, Rome, Italy.
Page 25 of 30
Willy Postvoll
Specialist, Gas Technology
Gassco AS, Norway
Willy started his professional career with Statoil in 1983 where he worked as a Reservoir Engineer in the Oil
and Gas Field Development division. After spending some time as a Senior Engineer providing technical
support for reservoir simulation he joined the Transport Division specializing in Real-Time Systems, Transport
Control and Supervision. From 2002 he has been the Real Time Systems Specialist in Gassco AS.
Education:
1983:
B.Sc.
1985:
M.Sc.
Publications:
PSIG San Francisco 1997: Experience with Computational Analysis of the Norwegian Gas Transport Network
IGU WGC Nice 1998: Operational experience with gas transport in Zeepipe
Oil & Gas Journal, March. 1998: Flexibility need prompts installation of Zeepipe modeling system.
BHR Multiphase Technology Cannes 1999: Pig Velocity Control - Method, Simulations and Field Measurements
Page 26 of 30
Education:
1985:
M.Sc.
1991:
Dr.Sc.
Publications:
M.Sc. thesis 1995: Wave diffraction from two-dimentional bottom elevations.
Dr.Sc. thesis 1991: Wave dissipation and diffraction of surface waves due to permeable obstacles.
Costal Engineering 1991: Dispersive shallow water waves over a porous sea bed.
Multiphase 97 in Cannes: Evaluation of the dynamic behaviour for the Petroboost system.
Multiphase01 in Cannes: Experiences and improvement work for the bundle from the Gullfaks South field.
Page 27 of 30
Education
Cand. Scient, Physical Chemistry, University of Bergen, Norway, 1990
Dr. Scient., Surface and Colloid Chemistry, University of Bergen, Norway, 1993.
Publications
Iun the period 1990 to 2001 Olav has published 37 papers on topics related to multiphase flow, gas hydrates, fluid
characterization and liquid-liquid separation.
The latest ones are
O. Urdahl, N. Wayth, T. Williams, A. Bailey and H. Frdedal, "Compact Electrostatic Coalescer Technology", in
Encyclopedic Handbook of Emulsion Technology (J. Sjblom, Ed.), Marcel Dekker, p. 679-694, (2001).
O. Urdahl, K.H. Nordstad, P. Berry, N.J. Wayth, T. Williams, A.G. Bailey and M.T.Thew, "SPE 69169; Development of a
new Electrostatic Coalescer Concept", SPE Production Facilities, February, p. 4-8, (2001)
E.E. Johnsen, H. Frdedal and O. Urdahl, "An improved approach for measuring viscosity of water-in-crude oil emulsions
under flowing conditions", Journal of Dispersion Science and Technology, 22(1), p. 33-39, (2001).
Page 28 of 30
Education:
BSc(Eng) Chemical Engineering, University College London, 1969
PhD, Chemical Engineering, University of Bradford, 1977
Publications:
1974
1974
1975
1977
1978
1982
1982
1984
Page 29 of 30
Education
BSc (Hons) Mathematics II(i) University of York, 1985
PhD, Computational Fluid Dynamics, University of Reading 1989
Publications:
1989
1990
1992
1992
1993
1996
"The Role of Pipeline Monitoring Software in the Allocation and Nomination of North Sea Gas
J. J. Barley, H.W. Robinson, A. Spence
th
PSIG9609 in proceedings of the 29 Pipeline Simulation Interest Group, 1996
Page 30 of 30