OLGA COMPANY HANDBOOK

EP/DEV/ED/ECP
OLGA COMPANY HANDBOOK
2 12/2014 General review

1 10/2005 Second Issue
0 - First Issue
Rev. Date Purpose
278ECP13
EP/DEV/ED/ECP OLGA Company Handbook
CONTENTS
1 INTRODUCTION ...................................................................................................... 3
2 MODEL LIMITATIONS ............................................................................................. 4
3 COMPANY RECOMMENDATIONS ......................................................................... 5
3.1 UNITS .................................................................................................................5

3.2 CALCULATIONS OPTIONS ...................................................................................... 5
3.3 TEMPERATURE & HEAT TRANSFER ....................................................................... 6
3.3.1 Calculation Options ..................................................................................... 6
3.3.2 Heat Transfer Coefficients .......................................................................... 7
3.3.3 Recommendations – Temperature & Heat Transfer .................................... 8
3.3.4 WALL Discretization .................................................................................... 9
3.3.5 Electrical heating......................................................................................... 9
3.3.6 Buried pipes ................................................................................................ 9
3.4 PVT FILE AND TWO OR THREE PHASE SIMULATIONS ............................................ 10
3.4.1 Generation of the PVT file ......................................................................... 10
3.4.2 Good Use of the PVT File ......................................................................... 11
3.4.3 General ..................................................................................................... 11
3.5 PIPELINE DESCRIPTION ...................................................................................... 12
3.6 TIME STEP AND INTEGRATION KEY .................................................................. 13
3.7 EXTENT OF THE SIMULATION ............................................................................... 14
3.8 BOUNDARIES ..................................................................................................... 14
3.8.1 Pressure boundary.................................................................................... 14
3.8.2 Source ...................................................................................................... 15
3.9 STEADY-STATE AND INITIAL CONDITIONS ............................................................. 15
3.9.1 Initializing a case....................................................................................... 15
3.9.2 Steady state results .................................................................................. 16
3.10 RESTART .......................................................................................................... 17
3.10.1 Purpose .................................................................................................... 17
3.10.2 Building a restart case............................................................................... 17
3.10.3 Using a RSW file ....................................................................................... 17
3.10.4 Time reference .......................................................................................... 18
3.11 SLUG TRACKING OPTION .................................................................................... 18
3.12 EMULSIONS ....................................................................................................... 19
3.13 COMPOSITIONAL TRACKING ................................................................................ 20
3.14 PUMP MODELING ............................................................................................... 21
3.15 PIG MODELING .................................................................................................. 23
3.16 OUTPUT FILES ................................................................................................... 24
3.17 CONTROLLERS .................................................................................................. 25
3.18 PARAMETRIC STUDY .......................................................................................... 26
3.19 READ STATEMENT ............................................................................................. 26
3.20 HYDRODYNAMIC MODEL ..................................................................................... 26
3.21 RELIABILITY AND MARGINS.................................................................................. 27
3.22 OVIP TOOLS ..................................................................................................... 27
3.23 PRACTICAL ASPECTS ......................................................................................... 28
3.23.1 File name and storage .............................................................................. 28
3.23.2 Low priority ............................................................................................... 28
3.23.3 Debugging ................................................................................................ 28
3.23.4 Launching Olga without the GUI ............................................................... 28
3.23.5 General Tips ............................................................................................. 29
EP/DEV/ED/ECP 1
4 TYPICAL POST-PROCESSING CASES................................................................ 30
4.1 LIQUID SURGE VOLUME EVALUATION .................................................................. 30

4.2 EROSION VELOCITY RATIO (EVR) CHECK ........................................................... 30
4.3 PRELIMINARY HYDRATE RISK EVALUATION .......................................................... 31
4.4 PRELIMINARY TOLC ANALYSIS ........................................................................... 31
4.5 FLOW REGIME MAP ........................................................................................... 32
4.6 OPERATING ENVELOPE ...................................................................................... 33
5 REFERENCES ....................................................................................................... 40
APPENDICES
Appendix 1 : Glossary
Appendix 2 : Getting Started
EP/DEV/ED/ECP 2
1 INTRODUCTION
OLGA is a one dimensional transient simulator used to simulate multi-phase flow in a pipeline
or a network of wells/pipelines. It calculates the velocity of the flow (gas, oil and free water), the
phases repartition, the pressure, the temperature, the flow regime etc along the geometry of the
system. It solves the energy and the momentum balances as well as the mass transfer
between the various phases; the fluid physical properties are read in an external PVT file
(name.tab) or could be computed internally via a compositional approach. Process equipments
such as separator, pump, compressor or valves can be included in the simulation.
The purpose of this note is not to duplicate the OLGA user manual prepared by SPT group
(now Schlumberger), but to give some recommendations or guide lines to the users and also to
clarify some points which could be misunderstood. It is possible to use OLGA either through the
GUI (graphical user interface) or by creating/modifying the keywords input file through a text
editor (thus by-passing the GUI). The GUI and the text editor format are both based on the
same keywords and use the same file (.inp). It appears however that most “new” users use the
GUI frequently because of its simplicity. This handbook is focused on Olga 5.3.2.4 which is the
recommended version in Total.
OLGA is a modular software with some modules requiring special licenses. In the TOTAL HQ
Process department (ED/ECP), the OLGA standard code and two additional modules: the
water module (for three-phase flow) and the slug tracking module are mainly used however
other very useful modules are available e.g. Pump, FEMTherm, Compositional tracking,
Advanced well, Drilling, Tuning etc.
Note: The use of any other Olga version apart from 5.3.2.4 must be based on specific advice
from the ED/ECP Flow Assurance or Thermodynamics & Simulation group. They should be
contacted in case of doubt or queries when using Olga. In addition, users should take
advantage of the Flow Assurance Sharepoint where up to date feedback and information is
made available.
EP/DEV/ED/ECP 3
2 MODEL LIMITATIONS
The following assumptions are made in the program:
- The gas and liquid phases are assumed to be in thermodynamic equilibrium at any
location and at any time (instantaneous equilibrium but constrained by the energy
balance)
- The temperature and pressure are equal in all phases and any interface mass
transfer occurs instantaneously
- A semi-implicit time integration is implemented- all the equations are not solved
simultaneously
- The fluid is supposed to be a mixture of components (Olga is not suitable for pure
components such as steam although a module performing calculations for such cases
with simplified assumptions exists)
- The fluid has a Newtonian behaviour (except in the complex fluid module)
- The axial heat conduction in the pipe wall is not taken into account as well as the pipe
materials compressibility
- It is a 1D model (an average value on the pipe cross-section is used for the phases
properties - including the velocities)
- There is no model for the natural thermal convection
- The flow is fully established/developed, thus a very short pipe (length <100 diameters)
is meaningless.
- The local effects of bends, restrictions, enlargements etc. are not modeled
Olga is not really suitable for applications where one of the previous assumptions is violated,
for instance:
- Single component fluid;
- Fast transient (such as emergency depressurization, JT effect through valves or water
hammer);
- Simulations on very short distances;
- Simulation of 2D / 3D dominated flows (tee, junction, bends …);
large networks
EP/DEV/ED/ECP 4
3 COMPANY RECOMMENDATIONS
In this part we will discuss some guide lines and recommendations to be applied when using
Olga.
3.1 Units
The default dimensional units in Olga are the SI system except for the temperature for which
default is °C. It means that, for instance, if no unit is specified the pressure has to be expressed
in Pa.
When using the text editor, the user should specify the unit. For instance, if the SOURCE
pressure is available in bars instead of Pa, it should be expressed as follows: SOURCE
pressure = 15 bara
With the GUI, the user can see directly the default unit and select another one (if desired)
among a list. Note that if the user has entered a value and then selects another unit, a
conversion is made automatically from the previous to the new unit. This is very helpful in most
cases but can lead to some error and as such the user should check that the input value is
consistent with the unit displayed in the GUI before proceeding to run the simulation.
3.2 Calculations options

On the OPTIONS key, the user has to specify if:
• The simulation is using a two or three-phase (gas, oil and water) approach for the
hydrodynamic model, sub-key PHASE
• How the temperature profile is calculated, sub-key TEMPERATURE
• If the preprocessor is used or if manual initialization is provided, sub-key STEADY STATE
• If the results of the postprocessor are to be given in the output file, sub-key
POSTPROCESSOR (POSTPROCESSOR = ON is recommended)
• If warning messages on the input (including the PVT file) have to be issued; sub-key
DEBUG (DEBUG = ON is recommended especially when starting a new job)
• If the axial convection is to be taken into account in a vertical pipe, it is not the case by
default (subkey = axialconvection).
The default values can be adopted for the other options.
EP/DEV/ED/ECP 5
3.3 Temperature & Heat Transfer

Proper modeling of heat transfer from the fluid to the ambient (external) medium is important as
it impacts the temperature results with consequence on other parameters as well.
3.3.1 Calculation Options
Olga offers the user several options for specifying how the temperature calculation is managed
among which the most often used are the “WALL” and “UGIVEN”. These two options are
described in more detail below in addition to some other options available. However it must be
noted that it is recommended to always choose WALL as temperature option unless the user
can show that any of the other options is better suited for the case under study (e.g. using
UGIVEN for screening of thermal insulations wrt criteria in steady state flowing conditions etc).
If TEMPERATURE = WALL (default) in OPTION, the radial heat transfer from fluid to wall,
between wall layers and from wall to the ambient is calculated. The wall radial heat conduction
and heat storage is accounted for.
The WALL option should always be used in a transient simulation involving changes in flowing
conditions. The energy balance performed by Olga takes into account the variation of the
kinetic energy, of the potential energy, the thermal inertia of the various layers as well as the
Joule-Thomson effect and the latent heat (vaporization or condensation). Another important
parameter for a WALL calculation is the number of layers that are considered in this WALL.
This is discussed in section 3.3.4.
It may be necessary to model a fluid as part of the pipeline WALL. By choosing TYPE = FLUID
for a material, OLGA will calculate the natural convection (the radial one not the axial one) in
this material. The viscosity and expansion coefficient of the fluid must then be given.
An approach also used to model a fluid as part of the pipeline WALL (typically the “air” layer for
pipe-in-pipe service) is to use an “equivalent” thermal conductivity for the air layer that takes
into account the effect of convection and specify the air layer as “TYPE = SOLID”. Typical air
equivalent thermal conductivities (in addition to specific heat capacities and densities) for
several PIP configurations have been evaluated and can be found in the document “Insulatech
poster” available on the FA sharepoint. WARNING: It must be noted however that Olga is not
suitable for rigorous modeling of this sort. Results therefore need to be properly analysed to
ensure that they are credible. CFD analysis may also be considered.
If TEMPERATURE = UGIVEN, convection at pipe walls is not considered/calculated within

Olga, transient thermal conduction in the wall is neglected and no wall temperatures are
calculated.
With the UGIVEN option selected, the UVALUE must be provided in the HEATTRANSFER
keyword. Considering that the convection at pipe walls is not calculated, the user needs to
provide a UVALUE that takes into account the inner and outer wall heat transfer coefficients in
addition to the wall resistances (see 3.3.2).
UVALUE is related to the inner diameter of the pipe and it must be noted that it is not very easy
to handle and as such it must never be used for cases such as depressurization, shut-down or
start up .It could only be used for preliminary calculations for steady state cases and slow flow
rate variation.
If TEMPERATURE = FASTWALL, the wall heat storage is not accounted for. This can be
useful to reach a thermal steady state quickly or to initialise complex simulations. However
knowing that the wall heat storage is not accounted for, this option must never be used for
cooldown or warm up simulations.
EP/DEV/ED/ECP 6
If TEMPERATURE = ADIABATIC, no energy exchange is considered with the pipeline wall.
If TEMPERATURE = OFF, temperature will not be calculated. The initial temperature will be
used in the simulation. This option can be used in case of no convergence with WALL because
of a bug in the program or when the temperature is disregarded. From a practical point of view,
it must never be used.
3.3.2 Heat Transfer Coefficients
Figure 1: Overall heat transfer in a 3 layered wall
Using the figure above as a typical example, it can be seen that there are 5 terms that describe
the “overall” heat transfer coefficient (OHTC). 3 of these terms are due to the thermal
resistances of the three different wall layers (A, B, C), while the other 2 terms represent the
convective heat transfer terms at the inner and outer walls respectively.
OHTC
How to handle the inner and outer wall heat transfer coefficients based on the selected
TEMPERATURE option is described below.
Inner Wall Heat Transfer Coefficient

This variable depends on the fluid in the pipe and the internal diameter and is represented by
h1 in Figure 1.
If TEMPERATURE = WALL; Olga would calculate the inner wall heat transfer coefficient (h1).
However, the final value applied depends on the “HMININNERWALL” (minimum h1) specified
under the HEATTRANSFER keyword. HMININNERWALL allows the user to control the
minimum value used by Olga when the fluid velocity is very low (close to natural convection).
EP/DEV/ED/ECP 7
If TEMPERATURE = UGIVEN; Olga would not calculate the h1, thus it must be calculated by
the user and included in the figure entered as UVALUE.
Outer Wall Heat Transfer Coefficient

This variable depends on the ambient fluid around the outer pipe wall and the pipe external
diameter. It is represented by h4 in Figure 1.
If TEMPERATURE = WALL; the coefficient must be specified using the “HOUTEROPTION”

under HEATTRANSFER. The HOUTEROPTION permits the user to either enter directly the
heat transfer coefficient (if known) by choosing “HGIVEN” (and entering the value under
HAMBIENT) or to simply choose the ambient fluid and subsequently specify its velocity thus
leaving the OLGA code to evaluate the heat transfer coefficient.
It is to be noted that default ambient fluid velocities for air and water (4m/s and 1 m/s
respectively) would be considered for the heat transfer coefficient calculation if the user does
not enter inputs for these variables.
If TEMPERATURE = UGIVEN; Olga would not calculate the h4, thus it must be calculated by
the user and included in the figure entered as UVALUE.
3.3.3 Recommendations – Temperature & Heat Transfer
1. For clarity, when communicating with others (external entities/suppliers and even within
TOTAL) on the terms “OHTC” and “U-value”, it is important to be sure that everyone has
the same understanding of what these terms represent. For instance:
a) When defining pipeline thermal specifications or in discussions with TEC/PLR

(or similar entities), the term “U-value” is typically used to represent only the
thermal resistances of the wall layers i.e. does not take into account the
convective terms. However (as described earlier) for use in Olga simulations,
the figure entered in the Olga UVALUE sub-key should take into account the
convective terms.
b) The OHTC and the “U-value” are evaluated based on the internal diameter of
the pipeline and not the external diameter as is sometimes done by some
external entities.
2. Dynamic simulations – Cooldown, Shutdown, Warm up etc.; Temperature = WALL must

be used
3. Steady state cases (during screening, preliminary and early stages of conceptual studies
were a lot of detail is not available on the pipeline); Temperature = UGIVEN can be
considered even though WALL is preferred.
4. Default value of HMININNERWALL i.e. 0 W/m2/C should be retained. This allows the
value calculated by Olga to be used for h1 when the WALL option is selected.
5. When ambient fluid velocity data is available, they should be used or the outer wall heat
transfer coefficient calculated and used. It could be acceptable to specify HAMBIENT = ∞
(i.e. ~106 ) in cases where the typical prevailing wind speed (or sea water currents) are
usually high.
It is interesting to note also that Olga variable “Q2” represents the OHTC as calculated by the
Olga code.
EP/DEV/ED/ECP 8
3.3.4 WALL Discretization
As far as temperature is concerned, the walls (insulation layers) have to be properly divided.
The wall is indeed divided into layers not only to reproduce the real layers but also to introduce
a discretization of this wall into several circular cells. This means that if a layer of 10 cm of
polypropylene is inside the wall this layer may be divided into 5 pseudo layers for numerical
purpose even if they, in fact, constitute only one physical layer. For steady state calculation, the
wall discretization has quite a small impact on the results but for transient simulation the impact
may be important, especially on the cooldown/warm up time in case of shut-down/restart. The
wall in a transient simulation has indeed an important inertia in terms of heat preservation.
The following rule should not be violated: A wall layer should not be thicker than ~30% of its
outer radius.
To help the user create the pseudo layers if some real layers are too thick, a small tool has
been added to OLGA and is called “automatic wall discretization”. This tool available in the
WALL keyword will sub-divide the wall so that the heat fluxes across each layers of the wall will
be more or less equal. Using this function is recommended.
On the other hand, very thin layers should be avoided, it is recommended to add them to a
neighbouring layer by adjusting the thickness and properties of that layer.
The temperature of each wall layer can be generated by specifying the output variable TW.
Temperature results for each wall layer (TW1, TW2 ....) can then be plotted. Also the
temperature of the inner wall surface can be generated by specifying the output variable TWS.
This could be useful especially when studying a cooldown case in which it is very important to
assess the wall temperature at different positions along the pipe and to also consider
specifically sections where only gas is present.
3.3.5 Electrical heating
Olga allows the user to specify electrical heating within the WALL keyword.
Sub-key “ELECTRICHEAT” is switched ON, and a value for POWERMAX (maximum power per
length of electrical heating) is specified in W/m. The WALLAYER on which the heating is to be
applied must be indicated (there are usually several MATERIAL layers making up the WALL).
Usually the heating is applied to the “steel” layer which is typically the first layer. However for a
more robust specification, it is recommended to add a 2mm layer of copper (which simulates
the heat trace wiring and serves as the second WALL layer) and then apply the heating to this
layer (therefore WALLAYER=2 is specified in the simulation).
It is advised to then use a manual controller to vary the power settings as required.
Note: FASTWALL Temperature option is not compatible with electrical heating.
3.3.6 Buried pipes
It may be necessary to model a partially or fully buried pipe in soil; however it is not possible to
define directly into Olga a buried pipe-line.
The user could use the FEMTHERM module or define the surrounding soil as several
concentric layers and evaluate an “effective soil thickness” which matches the overall heat
transfer coefficient of the soil.
The equations below can be used to evaluate an effective soil thickness of a fully buried
pipeline.
T = R2 – R1
R2 = R1*(Hy+ (Hy^2-1)^0.5)
EP/DEV/ED/ECP 9
Hy = D/R1 -1
Where, T = equivalent soil thickness (to be entered in WALL)

D = buried depth (from bottom of pipe to soil surface)
R1 = external radius of the pipe-line (concrete and insulation included)
R2 = external radius of the pipe-line (concrete, insulation and soil included)
It is to be noted that R2 calculated above is valid only for a buried depth from bottom of pipe to
the soil surface. For other burial configurations, some guidelines exist on the Flow Assurance
Sharepoint and the ECP-FA group could be consulted for advice.
Note: For a fully buried pipeline, the ambient temperature to be entered is the one in the soil at
the depth where the pipeline is located.
3.4 PVT File and Two or Three phase simulations

3.4.1 Generation of the PVT file
Before running OLGA, the fluid property files can be generated with the US4 module of ProII or
a commercial property table generator e.g. PVTSIM. The ECP Thermodynamics & Simulation
group should be contacted for their advice on the commercial generator and version to be
used.
Although Pro II or PVTSIM can be used, Pro II gives the user some flexibility as the fluid
definition/tuning (which takes into account the topsides process) as well as the fluid property file
generation can be done with the same software, thus preserving consistency in modeling.
To transfer fluid information from ProII to PVTSIM, it is recommended to use US12 which
extracts the fluid definition in a format that is easily applicable to PVTSIM.
Fluid Process/Pseudo process

It is important to ensure that the “base” fluid composition used to generate the fluid property
table is correct as an error at this step would compromise the OLGA simulation results that
would be obtained subsequently (see chapter 6.1 of GM EP ECP 114).
For most studies, a reference process/pseudo process scheme is available which enables the
user to obtain the correct product rates, GOR (or CGR) and water cut (or WGR) at stock tank
conditions. This needs to be respected when generating the “base” fluid composition if
GOR/CGR tuning is to be performed.
Due to the importance of this point, a dedicated document GM EP ECP 118 “Production Fluid
modelling for Process & Flow assurance studies” is under preparation to provide more
guidance.
PVT File formats

Two formats of TAB files are proposed by PVTSim & US4 of ProII:
• Fixed: This is the standard format and it generates a file that cannot be easily analyzed due
to its matrix structure - properties are given in a matrix, in a same line the temperature is
changed and in a same row the pressure is changed. Note that a line of the matrix can be
written on several lines in the tab file!
• Key: It is a format which gives the composition of the fluid and its properties at different
pressure and temperature in a very readable way. The key-format file presents indeed a list of
vectors constituted by a pressure, temperature and the values of the different properties at this
P, T condition. Moreover, it allows checking the composition associated to the PVT tables
(when re-using a tab file this can be very useful) and it is easily analyzed via Excel.
It is highly recommended to use the key-format.
EP/DEV/ED/ECP 10
3.4.2 Good Use of the PVT File
Two or Three Phase PVT File

If the fluid contains some water (aqueous phase), it is recommended to make one of the
following choices (although other combinations are possible, but must not be used):
• Two-phase PVT tables which will consider that the liquid is a homogeneous and fully
dispersed mixture of the oil and the aqueous phase and consequently select two-phase
option in OLGA which assumes no slip between the water and the oil.
• Three phase both for PVT tables and for the hydrodynamic model in OLGA, for cases with
a potential of significant liquid/liquid interface slippage (wet gas/ condensate applications).
If the three-phase option is used then the WATEROPTION module has to be defined. It is
recommended to check that WATERFLASH is ON (allowing water mass transfer from the gas
phase to the aqueous phase) and set WATERSLIP to ON (slippage between oil and water
taken into account). In addition, dispersion model can be chosen to consider oil/water emulsion
as far as viscosity is concerned (by default the correlation of Pal & Rhodes is used). See
section 3.12 on Emulsions.
It is to be noted that it is highly recommended to build PVT tables for the GOR and the water
cut under consideration and to use a mass source rather than varying the water cut in Olga, in
any case the GOR must not be adjusted in Olga.
PVT file Pressure and Temperature range

It is a common practise to use the “equidistant” option when generating the fluid tables file. This
approach requires a definition of a pressure and temperature range in addition to a certain
number of points (eg.50).
In a case where the P & T range is large, it is recommended to use adaptive steps i.e. fine
mesh around the actual operating points/conditions of interest and larger steps elsewhere.
In general it is advised to use a sufficiently wide range of P & T and account for occasional
peak values in the range to avoid simulation crashes.
If the outlet pressure is low (between 1 and 5 bars), it is preferable to use irregular spacing in
the pressures list as the fluid behaviour is not at all linear with pressure, thus to use for
instance: 0.1, 0.5, 1, 2, 5, 10, 20,... bars. Note however that there is greater uncertainty with
regards to flow modeling by Olga at very low pressures i.e. < 5 – 10bar.
Verifying the state of the PVT file

Once the fluid property files have been generated, it is necessary to verify that the physical
property trends are as expected. This can be done using the OLGA GUI by clicking on the
“TAB” icon (located next to the profile plot icon).
Several properties such as gas and liquid density, thermal conductivity, gas mass fraction,
viscosity, heat capacity, etc., can be plotted versus temperature or pressure. The intention here
is to ensure that there are no big discontinuities and that all trends can be explained.
3.4.3 General
The “PVTSIM handbook” available in ED/ECP provides further information and advice on
creating the fluid property file with PVTSIM.
Another handbook available in the TOTAL HQ Process department (ED/ECP), “Manual of
TOTAL UAS of ProII” provides details on how to use the US4 module of ProII to generate the
fluid property file and importantly how to tune the liquid viscosity by entering experimental dead
oil viscosity among other useful options.
EP/DEV/ED/ECP 11
3.5 Pipeline Description

The Olga model is built with a number of branches (FLOWPATH) characterised by a node at
each end. Branches are divided into pipes and each pipe is divided into sections. The
“boundary” variables (flowrates, velocities, flow pattern, etc.) are calculated at the boundary
between sections while the “volume” variables (pressure, temperature, holdup etc.) are
calculated at the middle of a section. Thus for more accurate results, it is advisable to have
short sections especially at the boundaries of the system (from where most results are
extracted) and for the sections where the SOURCES and LEAKS are located. But a very short
section will drastically reduce the time step and thus lead to much higher simulation time.
branch
node
Figure 1: Basic Network case
Process equipment e.g. valves, pumps, compressors, heat exchangers are located at the
section boundaries, while SOURCES and LEAKS are located at the middle of a section.
The discretization of the branches (definition of the calculation sections lengths) is a key issue
when building a new model. It can have a very large impact on the results (for example in case
of gas condensate at low flow rate). The user must spend time enough for this task.
The finer the grid that can be made in the discretization, the more accurate the results and
numerical instabilities can be avoided. However, this may cost some more time used by the
processor to run the simulation due to the smaller section volume, thus a compromise needs to
be made between the accuracy and the CPU time (see 3.6).
The following rules should not be violated when building the model:
• The change between the neighboring sections lengths should not exceed a factor of 2 ,
i.e., SEC(J-1)/SEC(J) < 2 if SEC(J-1) > SEC(J) or SEC(J)/SEC(J-1) < 2 if SEC(J) > SEC(J-1),
otherwise there could be numerical problems with the simulation. Violation to this criterion
is printed as a warning when DEBUG option is set to ON or LIMITED.
• It is recommended to have at least two sections for each pipe.
• If the available profile is very poor (straight line for example) it is recommended, at least for
gas condensate application (liquid content evaluation), to try to guess what could be the
actual profile before getting a detailed bathymetric profile. For this purpose, a tool has been
developed which creates some inclinations in the profile. An EXCEL workbook named
“Simplification route rev 6.xls” available on the FA Sharepoint has a dedicated worksheet
for this purpose which is referred to as “pipeline complexification”. It is based on the pipe
indicator which is more or less a measurement of the tendency of the pipe-line to
accumulate liquid at low flow rate.
• On the other hand, if the available profile is too detailed, it can be simplified with a
dedicated spreadsheet in the same excel workbook mentioned above. For gas condensate
EP/DEV/ED/ECP 12
pipelines, care must be taken when simplifying a profile. The user is advised to seek advice
and validation of the methodology used from the ECP/FA Group.
• Try to avoid having a valve or a separator at the first or last section of a branch.
• It would probably be better, for numerical reasons, to add a horizontal pipe (say 50 m long)
at each outlet of a separator, upstream the first pipe if vertical and downstream the last pipe
if vertical.
In contrast to US14, the diameter defined on the PIPE key is the internal diameter.
3.6 Time step and INTEGRATION key

There are several factors that impact both the speed (CPU time) and accuracy of a simulation.
Usually, the user’s objective is to guarantee simulation accuracy but within a reasonable
simulation time. Of these factors the time step used by Olga is very important.
The time step is chosen based on the principle that “no mass is transported across a whole
section in one time step”. This principle ensures that a mass transient is followed correctly.
For each section, the time needed to go across it is calculated with the fluid velocity of the
previous time step. The time step subsequently selected is the minimum of those previously
calculated. Olga will attempt to use this value as the time step, but this value can be overridden
depending on the MINDT and MAXDT values specified in the INTEGRATION key.
The relationship between the “calculated” time step and the MINDT and MAXDT values can be
summarised below:
o If MINDT< “calculated” time step < MAXDT, then “calculated” time step is used.
o If “calculated” time step > MAXDT, then MAXDT value is used.
o If “calculated” time step < MINDT, then MINDT value is used.
The following is recommended:
• While building the model, ensure that the section lengths are properly sized i.e. not
too long to lose accuracy with results obtained at the middle of sections or at
section boundaries, and not too short to result in a very small time step.
• Check the “Volume Global Error” using the VOLGBL variable. A value below 10 –
20% should be respected. This can be done by properly managing the MAXDT and
MINDT values. Note that the “HT” variable provides the time step finally used by the
simulation.
• For depressurisation simulations or similar cases in which the transient is quite fast,
MAXDT of 0.1s is advised. It can be relaxed to 0.5s and 1s values as the
depressurisation operation progresses (after the peak flow period) if necessary.
• For other transient simulations (pigging, rate changes etc.), MAXDT of 1s or up to
5s can be considered.
• For steady state cases, MAXDT of 10s can be used with a possible check at 5s to
verify that the parameters are stable.
• Verify that TREND DTPLOT (frequency of writing results to the .tpl file) is in line
with the selected MAXDT i.e. to benefit from the accuracy of a small time step, the
results need to be “written” very frequently as well e.g. 0.5 s for depressurisation
simulations.
• In cases where the user gets an error message of the type “pressure or
temperature below/above table values”, the pressure and temperature range of the
fluid PVT table should be verified and if this is ok, the user could continue
troubleshooting by reducing the MINDT (to as low as 1.10-6) and then gradually
reducing the MAXDT.
It is to be noted that values for MAXDT and MINDT can be given as a time series with time
points for changing MAXDT and MINDT given by time tables MAXTIME and MINTIME. This
EP/DEV/ED/ECP 13
feature could be useful to get more accurate results during a short transient operation eg.
depressurisation/restart by reducing the MAXDT, before continuing with the more “regular”
MAXDT for the subsequent operation which may not need such a fine time step.
An initial value of the time step (DTSTART) has to be provided; it must obviously be in the
range between MINDT and MAXDT.
With the INTEGRATION key the user has to define the start time and the end time of the
simulation (sub keys STARTTIME and ENDTIME). The scenario (source flow rate, outlet
pressure,...) has to be defined in this range of time. A CPU time limit is also given, this limit has
to be set to a very large value (3 days for instance). The restart file is created by default only at
ENDTIME.
3.7 Extent of the simulation

Like most simulators, the OLGA users have to have clearly in mind the objectives of the
simulation and to determine if a transient simulator is needed for answering the question he/she
has to solve.
The basic part of the simulation is the pipeline itself, but valves, separator and other process
equipment can be added.
The user must keep in mind that Olga is not suitable for calculations on very short distances
(not established flow). This implies that particularities such as bends, elbows should not be
considered (except in terms of additional length of the total line). The program always assumes
that the flow is fully established.
Most of the simulations run in the Process Department start at the well head (including or not
the choke valve) and goes up to the first stage separator (or slug catcher). The separator is not
always simulated however it could be beneficial to include it when stability flow problems are
anticipated. In this case, the control system of the separator is defined in the simulation input
data. Section 3.17 provides more details on using control systems/controllers in Olga.
Under certain circumstances the production /injection well is included in the simulation which
starts actually at the reservoir level. In this case, the well can be defined as a standard source
(mass flow rate provided) or with its performance index.
3.8 Boundaries
The general rule is to fix the pressure at the outlet of the model (BOUNDARY) and the flow rate
at its inlet (SOURCE). It is to be noted that for the US14 the pressure and the flow rate are
defined at the inlet.
3.8.1 Pressure boundary
For a PRESSURE boundary, in addition to the pressure, values must be given for the
temperature, the gas mass fraction and the water mass fraction. These parameters are used
when there is back flow at the outlet.
A back flow could occur (for example) in a shutdown case when no fluid is being introduced at
the pipeline inlet. Usually this back flow is only gas, with no liquid. Therefore,
GASFRACTION=1 and TOTALWATERFRACTION =0 are typically specified. Particularly, in
case of a backflow the value provided for the temperature can have an important impact on the
temperature results of the sections in close proximity to the pressure boundary and as such it is
recommended that realistic values of temperature be specified.
EP/DEV/ED/ECP 14
3.8.2 Source
The inlet boundary condition is typically a CLOSED node with a SOURCE located at the middle
of the first section of the associated pipe and is used to introduce fluid into the pipeline. With
more recent versions of Olga it is also possible to achieve this by using a “mass node”.
For the SOURCE, the user has to define the inlet temperature, the gas mass fraction, the total
mass flow rate and the water mass fraction.
Recommendation:
• Never use the standard volume flow rate but the mass flow rate, because the definition of
the volume flow rate (number of separation stages, P and T conditions of these stages) is
most of the time not relevant for the case under consideration and the properties at
standard conditions are most of the time not given in the PVT tables (especially with the
US4);
• Set GASFRACTION and TOTALWATERFRACTION to –1 (values taken from the PVT
tables). It means that the PVT tables have been created for the correct GOR and water cut.
Optionally, it is possible to specify the pressure of the source. In this case, the variation from
the given pressure to the pressure in the pipe section is taken into account for the temperature
calculations. Olga simulates the theoretical J-T effect through a valve located at the source
location, and the pressure range in the user’s fluid property file (PVT) is expected to cover the
source pressure value also. It is noted that the SOURCE pressure is not an initialization of the
inlet pipeline pressure and is not considered for pipeline pressure drop calculations.
GASMASSFRACTION is the ratio of the gas mass flow rate to the gas + oil mass flow rate.
WATERMASSFRACTION and TOTALWATERFRACTION are defined as the mass flow rate of
the aqueous phase divided by the total mass flow rate (oil + gas + water), the aqueous phase
could contain in addition to the water, polar components such as methanol, MEG and salt.
TOTALWATERFRACTION corresponds to the total water (in the aqueous phase and in the
gas) while WATERMASSFRACTION refers to the aqueous phase (or free water).
Warning: A set of PVT table is not associated to a source but to a branch. The fluid has
consequently not to be given in the SOURCE keyword but in the branch. This means that the
branch (the pipeline) can only produce one fluid and is the same all along the branch (only the
P, T conditions are changing).
There could be cases where the user may be required to include several SOURCEs in a model
or network of pipes. Special care must therefore be taken to properly specify the case.
On the FA sharepoint, there is a very useful presentation titled “How to create a multisource
model in OLGA” which provides guidelines to be respected in this case.
3.9 Steady-state and initial conditions

3.9.1 Initializing a case
A dynamic Olga case can be “initialized” i.e. initial values provided for the simulation by either
of the following means:
• Calculated using the steady-state preprocessor
• Given by the user
• Read from the final conditions of a previous case i.e. a restart file (see section 3.10)
With the OPTIONS keyword, a choice is made to specify the STEADYSTATE as “ON” (default)
or “OFF”. If STEADYSTATE = ON, the steady state pre-processor which is the same code as
OLGAS will be used.
EP/DEV/ED/ECP 15
Note: If there is a vessel in the simulation, it is recommended to provide values for “initoillevel”
and “initwaterlevel” in order to set the right levels in the separator at time 0. By default, the
program chooses 40 % for the oil and 20% for the water values that can lead to too high levels
and thus long stabilisation time to eliminate the oil/water in excess.
If STEADYSTATE = OFF, one must define the INITIALCONDITIONS (in terms of pressure
profile, temperature profile and void fraction profile) for further performing the dynamic
simulation. There are some cases in which using INITIALCONDITIONS is mandatory because
the conditions required for using the steady state pre-processor are not satisfied e.g. no source
at the inlet of the model. In these cases, a warning/error will be generated by Olga advising the
user on the inadequacy of the steady state pre-processor and thus the need to initialise the
case with INITIALCONDITIONS.
Notwithstanding, the user may also resort to using the INITIALCONDITIONS when the steady-
state pre-processor fails or is too slow to converge which could be the case with complex
networks, but it is very unusual.
3.9.2 Steady state results
In most simulation cases, it is required to determine the “steady state results”. This refers to the
conditions in the model when full steady state conditions have been established i.e. the
properties of the system (pipeline) are no longer time dependent. Steady state results could be
obtained by using either the steady state pre-processor and/or the Olga dynamic code however
the following must be understood:
• The steady state pre-processor generates results corresponding to a steady state at t =
0 i.e. the flow equations are solved without the time derivative.
• The Olga dynamic calculator needs to be initialized (INITIALCONDITIONS or the steady
state pre-processor).
• The pre-processor and the dynamic calculator will both calculate what they think is the
steady-state. Quite often the results will be different and the dynamic calculator is
expected to be more accurate and compatible with the transient scenario (less numeric
slugs).
If the dynamic code is to be used to generate the steady state results, sufficient simulation time
must be specified to ensure that the model conditions (pressure, temperature, liquid hold up,
flowrates at outlet etc.) have really attained “steady state” i.e. no more changing with time.
The results of steady state simulators such as Pipephase, PRO/II-US14 or Pipesim have to be
compared to those obtained by Olga at time 0s (results of the steady state preprocessor) and
not after stabilization.
The following should also be noted:

• There are some physical effects that the dynamic model handles better than the steady
state model, especially near angle changes in the pipeline. There are three main reasons
as follows:
 There are residuals in the error in the steady state pre-processor. Dynamic
simulation removes these errors.
 Dynamic code contains extra terms that are not handled in the steady-state code.
 For the slug tracking option, dynamic simulation is required, as there are no truly
steady-state conditions.
• The physical model can have several solutions, the dynamic scheme can choose
another root than the one determined by the steady state processor.
• The steady state pre-processor gives strange temperatures and pressures for some
cases. The reason is that the pre-processor has problems to handle, for example, a well
boundary, a pressure boundary, a negative source or whatever in a system. If one has
problem with the steady state pre-processor, one can set STEADYSTATE = OFF (in
OPTIONS definition to turn off the pre-processor) and use INITIALCONDITIONS instead.
EP/DEV/ED/ECP 16
• As mentioned above, the steady-state preprocessor will provide only an approximation of

the real solution. It is of good practice, before proceeding with the transient part of the
simulation case (e.g. depressurization, cooldown, change in boundary conditions etc.), to
verify that the steady state has been attained by running the Olga dynamic code during a
certain time at constant boundary conditions, otherwise it will be difficult to determine
whether a liquid slug is physical or numerical.
• Do not forget that in some cases the steady state does not exist (severe slugging for
example). Then the scenario (flow rate variation for instance) could be described in a
second case using the first one as restart file.
3.10 Restart
3.10.1 Purpose
The RESTART keyword should be used if the user wants to run a simulation considering the
results of another as the starting point of the second run (initial conditions). When using the
RESTART module, the user will indicate the file from which the case is restarted from (*.rsw).
3.10.2 Building a restart case
The geometry and the geometry-related keys cannot be changed in the RESTART simulation,
for example, pipes, nodes, branches, materials and walls.
All the definitions that one wants to re-define must be defined after the RESTART definition.
The definitions before the RESTART statement will be ignored in a RESTART simulation. If no
FILE statement is given after RESTART, the PVT file given in the previous simulation will be
applied.
Remember that all definitions from the first run, which are not re-defined, will continue in the
restart run. Watch out for time series of sources, chokes, etc.
For reasons of clarity, it is recommended when creating the input file with a text editor, to begin
the file of the second job with the “RESTART” key and to specify afterwards what is varying in
this simulation. But, when opening this simulation in the GUI, the geometrical profile will not be
displayed (the GUI does not find it in the input file and is not clever enough to read it from the
restart file).
If in theory Olga allows the changing of the fluid by specifying another PVT file in the second
file, this feature must not be used. In such a case the initial conditions of the second simulation
is using the final state of the first case but there will be a conflict between the mass and the
volume balance because the liquid and gas density changes artificially and the program will be
”lost”. This is not the case when a dummy fluid (drilling fluid) is injected into the flowline for
dead oil circulation purposes which is an acceptable practise although not really satisfactory.
3.10.3 Using a RSW file
When using the text editor, the RSW file must be located in the current directory alongside the
the input file and the fluid TAB file.
By default, the restart file (*.rsw file) is created for each simulation case with the values of the
various parameters available only at the ENDTIME of the case.
It is possible in the first case to specify the frequency the results have to be stored in the RSW
file. The restart key becomes something like:
restart dtwrite = 3600 s, write = append
In this situation, the case can be restarted (READTIME sub key) at times 1, 2, 3 … hours
otherwise the user can only restart the case from ENDTIME
EP/DEV/ED/ECP 17
3.10.4 Time reference
In a restart case i.e. a case that is being initialized by using an RSW file, STARTTIME must be
less or equal to ENDTIME in the preceding case.
This implies that the user could specify the subsequent case’s STARTIME as 0h even if the
RESTART READTIME=4h. This could be useful when the first case was actually a stabilization
run to reach the steady state.
3.11 Slug tracking option

The slug-tracking option should only be used in case of the hydrodynamic slugging. It must
never be used for a gas condensate pipe-line. Moreover its results have been more or less
validated only for horizontal line; it means that the results are questionable for deep off-shore
risers.
It is to be noted that the results are very sensitive to a slug initiation parameter called the “delay
constant” which is the number of pipe diameters a slug must travel before the slug model tries
to initiate another slug at the same boundary (default value = 150). This parameter is to be
entered by the user who generally has no idea of the correct value except in a case whereby
field data is available which allows matching. Sensitivity to this parameter must be performed
using a range of values including the value evaluated using the Shea correlation. It is noted that
the values given by this correlation are generally much higher than the default value thus
emphasising the need for the sensitivity check.
The user is advised to check that the liquid slug found by Olga has a realistic void fraction
(typically around 25 %).
The results can vary drastically depending on the sections declared as “illegal” (no liquid slug
generation in these sections). The use of such an option can lead to dramatically dampened
intermittent flows. It is recommended to use the default of the simulator, thus, not to use this
keyword. It is important to note that by default, the very first and last sections in a pipeline are
automatically set to “illegal” by the Olga code which implies that:
I. Slugs are not allowed to be generated at these points.

II. Slugs generated else-where may move into these sections, but are not allowed to pass
through. Thus slugs will be “destroyed” when both the front and tail are within the
section. This implies that a slug would not pass through a node (internal, split or merge)
but may be generated again in the sections after the node if the conditions are satisfied
for slug generation.
There are two kinds of initiation of liquid slugs, the level slug option (LEVEL) and the
hydrodynamic slug option (HYDRODYNAMIC). LEVEL should be switched on for cases of shut
down/start up, flow rate variation.
The following parameters can be chosen for slugs initiations:
DELAYCONSTANT = 150 (sensitivity with value determined with Shea correlation is

advised; for more detailed analysis, checks at other values of DC could be performed)
INITFREQUENCY = 100000 (in order not to take into account this criteria)
MAXNOSLUGS = 100000
It is not easy to analyze the results of this module. Depending on the case being studied, it
could be important to note the liquid and gas volume flow rates (instantaneous and cumulated)
at the outlet of the pipe/separator, the pressure fluctuations (amplitude and frequency) at the
pipeline departure, riser base etc. Some cases may require much more detailed analysis of the
EP/DEV/ED/ECP 18
results and so it is advised to seek advice from the ECP/FA Group if this is not obvious to the
user.
A document titled “Methodology to be applied for slugging analysis related to fatigue
calculations” (available on the FA sharepoint) provides a methodology used to characterise
slug flows in flowlines and more details on the Shea correlation. The user is advised to take
advantage of this document.
3.12 Emulsions
An emulsion consists of two, non-miscible liquids, with one of these being dispersed in the form
of fine droplets in the other liquid which forms the continuous phase. An emulsion which does
not break in a reasonably short time (~1 hour) without external intervention/treatment can be
referred to as a “stable” emulsion. Three conditions must prevail for a stable emulsion to form:
• Non-miscibility of the two liquids

• Adequate energy for one phase to be dispersed in the other (turbulence)
• Presence of an emulsifying agent
Formation of an emulsion in a line (w/o emulsion) generally leads to increase in liquid viscosity
and consequently higher pressure losses. The following points should be noted as to how Olga
handles emulsion modeling using the WATEROPTIONS module.
Dispersion Model: Keyword “DISPMODEL”. This keyword allows the user to choose the
dispersion model to be used. It is important to understand that the dispersion models serve
primarily to evaluate the viscosity of the emulsion and so depending on the model selected the
emulsion viscosity could be quite different.
Several emulsion models currently exist in Olga with the Pal & Rhodes model being the default
and most commonly used option within TOTAL. Note that this does not forbid the use of the
other models, however EXP/PRD/GFP need to be consulted for proper validation of the choice.
It is important to note that whatever the dispersion model selected, the model is only active
when “DISPERSIONVISC” = ON. If this keyword is “OFF”, the viscosity of the emulsion is
simply a weighted volume average of the water and oil viscosities.
Inversion water fraction: Keyword “INVERSIONWATERFRAC”. This important parameter

represents the “cut off” water cut used by the code to determine the possibility of either a “water
in oil” emulsion or an “oil in water” emulsion. Default value is 0.5. Thus water droplets are
entrained in oil if the water cut in the liquid film is less than the inversion water fraction and vice
versa.
Three phase modeling: Firstly the following settings must be selected: under OPTIONS,
PHASE = THREE; Keyword “WATERSLIP” = ON in WATEROPTONS.
It is to be noted that the degree of mixing of oil and water can vary from “fully separated” to
“fully dispersed”. There is a dedicated correlation within the Olga code which attempts to
predict this level of dispersion/entrainment depending on several parameters e.g. phase
velocities, density differences etc. Thus for a water in oil emulsion case (water cut < inversion
water fraction) the Olga code would determine the level of dispersion of water in oil. In this
case, the oil phase becomes the “emulsion” as some water is dispersed in it and then
subsequently the code will consider the water fraction in the “emulsion” to determine the
viscosity of the “emulsion” based on the emulsion model specified under “DISPMODEL”.
Therefore depending on the case being studied, there is a possibility of having some or no free
water flowing along with the “emulsion”.
EP/DEV/ED/ECP 19
Two phase modeling: Select under OPTIONS; PHASE = TWO with a two phase PVT TAB file.
In this case the PVT TAB file must have been previously created by taking into account the
emulsion viscosity as the liquid viscosity.
The following points which affect emulsion modeling are noted:
• The uncertainty on the water/oil entrainment correlation (used for 3 phase cases) is
large because the built-in correlation does not fully account for the surface chemistry of
oil and water (surfactant effects).
• The entrainment/deposition of water droplets is assumed to be in equilibrium at any
position in the line, so the kinetic process of coalescence and re-entrainment is not
modeled in OLGA.
• Olga is based on a two-fluid model (momentum equation written for gas and liquid) with
(somewhat empirical) correlations for droplet entrainment in the gas and oil/water slip.
All the variables displayed for oil, water and dispersed phases result from these
correlations, it means that the oil-water slippage is the most questionable result of Olga.
• WARNING: With a 3-phase approach, the dispersion prediction can be significantly
affected during a shut down condition (no flow) resulting in a total segregation of the oil
and water phases. This of course may not be the case in the field pipe-lines as
emulsions may remain “tight” for a considerable amount of time for certain oils leading
to high restart pressures which may not be captured by a simulation using a 3-phase
approach.
For certain cases (especially high viscosity oils), the pressure drop result could vary
significantly depending on whether a 2-phase or 3-phase approach is used. It is advised to at
least check the impact of a 2 phase approach on the results and discuss with concerned
entities e.g. EXP/PRD/GFP in order to agree on the best approach going forward which reflects
the tightness and stability of the emulsion.
In summary, care must be taken when modeling emulsions. The user must keep in mind the
limitations of Olga noted above, the difference between a 2 or 3-phase approach and discuss
with other entities before making a conclusion. A case by case approach is required.
3.13 Compositional Tracking

In normal use of Olga, each PVT file is prepared for one fluid composition, and when this file is
used in a BRANCH it is assumed that the total composition at every point and time in the
branch is the same. However, in reality the composition may vary significantly from one point in
a line to another due to slip effects, interfacial mass transfer etc. during operations like
blowdown, cooldown, start up etc.
The compositional tracking module helps to address these scenarios by tracking each
component (mass equations solved for each component in each phase) and thus is able to
account for the local compositional changes that may occur.
For networks models built with Olga, different PVT files considering differing fluid compositions
can be specified for each branch. The concept being to have a “mixture” composition after a
merge node that takes into account the composition and rates of the branches merging into it
(see section 3.8.2). It must be noted however that this “mixture” composition (especially for
branches with different fluids) is only valid if the ratio of flowrates from the merging branches
remains the same for subsequent simulation runs. If this is not the case, it may be required to
create a PVT tab file for each flowrate combination of the merging branches which could be
very time consuming. The compositional tracking module can be used in this case as Olga
would manage the composition in all the lines by respecting the inlet flowrates and fluid
EP/DEV/ED/ECP 20
compositions.
The extra level of precision given by compositional tracking compared to standard use of Olga
with PVT files comes at a cost in terms of simulation time as the material properties (density,
thermal conductivity etc) will be calculated continuously throughout the simulation based on the
flowing P, T conditions whereas these properties are simply read from the PVT tables with the
standard Olga approach.
From a practical point of view, the PVT tables approach is accurate enough in most cases.
Although it is preferred and advised to use components tracking for depressurization cases, the
user could resort to using the PVT tables approach but MUST take time to verify the validity of
the results obtained e.g. peak flowrate, wall temperature etc, and if in doubt use the
components tracking module or better adapted software. Recall that Olga in general is not
suitable for fast transients.
The following points are to be noted regarding the use of compositional tracking:
• Instead of using a PVT tab file (containing phase properties), a “feed” file has to be
generated using PVTsim and given as input to Olga. This file contains the fluid
composition.
• Physical limits for the P and T used in the PVT calculations cannot be changed by
the user and are given as 0.05 – 1000 bara and -200 – 500oC respectively
• Maximum number of components allowed in the feed file is 30.
See the SPT/SLB Olga manual for more details.
3.14 Pump Modeling

It could be required to model the transients associated with pump operation within a simulation
e.g. MPP restarts, shutdowns, ESP packing cases in wells etc.
There are several options available within Olga for pump modeling in general, each with
different levels of complexity and specificity. Some details are provided below.
Modeling Options:
1. Pressure boost
a. Very simplified model. It enables to set a pressure increase locally.
b. Very coarse modelling as the pressure increase is independent of flow!
2. Simplified Pump:
a. Intended for quick and approximate modelling and uses a linearized approximation of
the behaviour of a real centrifugal pump.
b. Only accurate for use across small excursions from specified operating point.
3. Centrifugal Pump:
a. Can be used for rigorous modelling of the real nonlinear transient operation of a
multiphase centrifugal pump.
b. Can be used to model ESPs and multiphase pumping
c. Requires that the pump curves (head vs flow etc) be entered in a specific
“homologous” (four quadrants) format which can be very tedious to construct.
d. There is a complete set of homologous curves tabulated into the Olga code which
are representative for typical centrifugal pumps.
e. The user can develop a set of pump homologous curves representing the specific
pump under study without using the built in curves.
EP/DEV/ED/ECP 21
f. The Olga manual and similar sofwares using the “homologous” pump approach state
that since the homologous curves are dimensionless, one set of curves (e.g. the built
in one) can be used to describe a variety of different pumps by specifying specific
rated values for density, head, flowrate, torque and speed. Although this approach
may introduce some loss off accuracy, this may be acceptable depending on the
case under study.
4. ESP :
a. Used to model single or multistage electric submersible pumps (ESPs) for use in
single or multiphase flow
b. The keyword “PUMPMODEL” allows the user to choose a pump model from the list
available in the database.
5. Framo Pump:
a. The FRAMOPUMP keyword is used to model specifically a FRAMO helicon-axial
pump, which can operate from 0-100% gas volume fractions.
Table 1 and Figure 4 below provide more detail on the models presented above.
recycle Curves
parallel/
Licensing/ & in four
Pump Models ∆P (Q) multiphase multistage
Availability bypass quadrants
operation
lines (1)
Not required/
Pressure boost Constant no no yes -
Olga 7 only
Not required/ GVF
Simplified Linear no no -
General
Available multiplier
Interpolation
btw 0% GVF
Pump Module/ Pump
Centrifugal yes yes curve & -
Available curves
degraded
curve
Wells & Pump Isothermal
ESP
ESP Module/ no yes ideal gas multistage
curves
Olga 7 only compression
Specific
MPP
Pump Module/ curves + Multiphase
Framo yes yes parallel
Olga 7 only upstream curves
mixer
Table 1 : Pump Models
(1) In order to represent all the possible pump operating points (normal and degraded) the
four quadrants curves characterization is necessary.
EP/DEV/ED/ECP 22
Figure 2: Basic Pumping Models
A few other pumping options exist in Olga, however from the options discussed above, it can
be seen that the Centrifugal pump is the most robust for our usual application considering that
the Framo pump is rather specific. However, it could be quite complex to specify in Olga. Thus
for simplicity, when the intention is to model the typical Flow vs ∆P relationship (increase in
back pressure resulting in reduction in flow rate), a well inflow model could be used (keyword
“WELL”) to introduce mass into the system or the use of a controller to manage this operation
could be considered.
3.15 Pig Modeling

For the frequently performed pigging simulation, some points are noted below to guide the user
in performing the simulation:
- The “PLUG” FA Model is typically used to specify a pig. Default values for the pig/plug
properties (STATIC FORCE, WALL FRICTION etc.) as already provided in OLGA can be
retained if more specific data is not available.
- The pig diameter is not provided in OLGA by default, however if this is not specified by
the user, OLGA will perform the calculation assuming that the pig diameter is equal to
the pipeline ID minus four times the wall roughness. Again this can be acceptable if no
more specific data is available.
- Pig launch and trap position must be defined. POSITIONs for each need to be created at
the selected PIPE locations and specified in the PLUG module.
- Pig Routing – If the Pig is expected to go through more than one FLOWPATH, then the
order of pig travel needs to be specified under the sub keyword “ROUTING”.
- Bypass pigging can be modelled with Olga in an attempt to reduce the surge volume
(see specific memo “Bypass Pig Modeling for Gas Condensate Pipeline Systems” on FA
SharePoint)
- It is indeed possible to avoid modelling a slug catcher (with controllers) in order to
determine the slug catcher maximum surge volume. In this case a fixed pressure node is
specified at the pipeline exit and the accumulated liquid volume TREND parameter
(ACCLIQ) is specified.
EP/DEV/ED/ECP 23
3.16 Output files

Four files are generated (in addition to the input file) when a case is launched:
• An output file (.out) containing the results on a tabular form

• A file with the profile of some variables along the pipe-line at given time (.ppl). It is to be
used through the GUI;
• A file with the profile versus time of certain variables (.tpl). It is to be used through the
GUI.
• A restart file (.rsw) that contains by default the values of the variables at the end of the
simulation.
The data stored in the files .out, .ppl and .tpl are defined by the user when preparing the case
(in the GUI or input file). By default, results are not provided and thus the definition of the
desired results is of primary importance: any omitted data will force the user to rerun the case.
For Olga the model results are classified into two separate groups:
• The volume variables: they are provided at the middle of a section, it is the case for
instance of the pressure and of the temperature. It means that the pressure at the inlet of
the pipe is not calculated;
• The boundary variables: they are calculated at the end of a section with the diameter of the
pipe ending there. This is the case for the velocity, the mass or volume flow for example.
Output: This keyword will allow the user to define which variables should be printed in the file
*.out. This file will first give a copy of the inputs and then will give some information about the
SOURCE, the separator and the time steps at different time of the simulation (frequency
defined by the user). In addition, the user can ask for the printing of variables like the pressure
or the temperature along the BRANCH. If the POSTPROCESSOR has been switched ON (in
OPTION keyword), useful global information on the job is printed at the bottom of the output
file, they are: average and maximum time steps, CPU time, the number of iterations, minimum
and maximum values of some variables. Using DEBUG = ON (in OPTION), OLGA will add
some comments and warnings at the beginning of the output file just after the copy of the input
file. It is recommended to use this option. Similarly it is also recommended to use the
PRINTINPUT key to get some information on how the input data supplied by the user is
understood by Olga.
Profile: This is another output file where variables are printed for each of the sections of the
BRANCH at a given time and so it allows the user to plot profile curves. The file has a .ppl
extension and its contents cannot be read with a text editor but can be viewed with the GUI.
Some users take advantage of specifically prepared Excel based macros (“OLGA Res Macro”
available on the FA Sharepoint) to extract the data directly to Excel for subsequent plotting and
viewing however it is also possible to copy and paste the data to Excel from the GUI.
Trend: this is the last file that can be generated by OLGA to present the results. This file gives
the values of some variables at a local point and as a function of the time. The file has a .tpl
extension and its contents can be exploited in a similar way as the .ppl file. Before running Olga
the user has to carefully define all the variables of interest. On the other hand, there is a size
limitation on the .ppl and .tpl files. If they are too large, their contents can no longer be exported
to/viewed with the GUI. This could occur if there are a lot of pipe sections in the simulation or if
the time step defined for storing the results (DTPLOT for TREND and/or PROFILE) is very
small e.g. 1 s for a simulation of several days.
When a simulated time is very long (over hundreds of hours), OLGA can’t plot all the data
contained in the *.tpl file, and discards the oldest ones. To avoid this situation, it is better to
divide the simulation in several shorter files, run one after the other by taking advantage of the
“RESTART”.
EP/DEV/ED/ECP 24
For trend plots, a good practice is to select very particular points (entry, exit, before and after
equipment, at geometrical change (lowest point, change in radius or insulation …) then to set
the plotting with a time step small enough to have a regular curve but not too small.
• For a simulation of 1 hour a plotting time step between 10 seconds and 1 minute should
be enough (remember that the plotting time step has to be superior to the minimal
integration time step). But if you are simulating a fast transient case, a smaller time step
may be necessary.
For profile plots, the plotting time step has to be quite high.
• For a simulation of 10 hours a writing time step of several minutes could be adopted,
however this frequency depends a lot on the phenomena the user is interested in.
The following are the main variables that should be stored in the .out file and plotted in every
case (in the PROFILE or in the TREND keys):
• PT, TM, PTMIN, PTMAX, TMMIN, TMMAX: pressure and temperature (+ min and max)
• AL, HOL (HOLHL, HOLWT), BE (resp. BEHL and BEWT): void fraction, liquid fraction
(oil and water) and liquid film fraction (oil and water fraction if three phases)
• ID, USG, USLTHL and USLTWT: regime indicator, superficial gas velocity and
superficial oil and water velocity
• LIQC (resp. OILC, WATC), LIQCNS (resp. OILCNS, WATCNS): liquid (or oil and
water) content in the branch or in the branch excluding the separator.
• QG, QLT, QLTHL,QLTWT : Actual flowing rates of the different phases
• ACCGAQ and ACCLIQ (resp. ACCOIQ and ACCWAQ) at exit: accumulated gas and
liquid (oil and water) volume flows at exit allow tracking for fluid re-entering).
• HTK, HTKO and Q2: heat transfer coefficients
• VISG, VISL (respectively VISHLEFF, VISWTEFF): viscosity (including dispersion
oil/water).
• HT, VOLGBL: Time step and the maximum volume error. It can help a lot to
understand the speed of the simulation and to also track for numerical instabilities
When using the slug tracking module, it is necessary to know the void fraction in the slug and
the liquid fraction in the bubble.
For separators, one should observe at least the levels of the different phases.
For a valve, the opening should be plotted.
3.17 Controllers
Regulation systems may be required to properly define a case (e.g. pressure/level control for a
separator) and this often has a major impact on the flow stability as they acts on the valve
openings and so on the pressure, flow etc. This regulation is based on controllers. These
controllers are totally different from the controllers in ProII.
OLGA controllers are for regulation in a transient simulation (PID or other) while ProII
controllers are introduced to adjust in steady state conditions an operating variable in order to
get the desired value for another variable.
There is more information about using controllers in the Olga Level II course and the Olga user
manual. On the FA SharePoint, the user can find two useful documents: “Controllers definition
in Olga and LedaFlow” & “PID Controller Tuning: A Short Tutorial”.
EP/DEV/ED/ECP 25
3.18 Parametric study

It is possible with the OLGA GUI to generate a “parameter” study which means to run several
cases in a row with some selected parameters changing in their respective inputs. This allows
the user to “quickly” determine the effect of one or more specific parameters on the results of a
simulation (among other functions) without having to create specific cases for each simulation
run.
A parametric study can be specified and launched quite easily by using the GUI. The option is
available under the “Tools” menu.
Although parametric studies have proved to be very useful, users must keep in mind however
that they are easily subject to errors as a result of erroneous user input (for example) and in
some cases “unexplained reasons” and so some double checks are needed to ensure that the
runs are all converged and stable i.e. are all doing what they are supposed to do. The user
could run one or two cases (without a parametric study defined) to confirm that the input data
has been properly taken into account and must rely on his understanding of the case to
determine if the results of the parametric study “make sense” and if not seek to understand
why.
3.19 Read Statement

It is possible to include a data file into the case data input file using a READ-statement
preceded by a (%) sign.
This feature can be useful in the cases, for instance, where the same geometry is used in several
input files. If the file geometry.dat contains this geometry, this is done by replacing the geometry
definition in the various input file by:
%read geometry.dat
The advantage is that if a modification has to be done in the geometry (other diameter for
example) it does not have to be duplicated in several input files but only done in geometry.dat.
This is particularly of interest for OLGA study with a huge number of simulations based on
same geometry but also heat transfer properties or valve, separator and so on.
3.20 Hydrodynamic model

The physical model used in Olga for the hydrodynamic calculations is not documented in the
various manuals since it results from proprietary R&D work over several decades. However,
based on the information available to TOTAL and from discussions with the code developers,
the following is understood:
• there is no annular model in horizontal;
• there is no model for large waves stratified flow regime (gas condensate at low velocity) in
OLGA standard;
• there is no model for churn flow in large diameter risers (8” and above); flow equations of
slug flow regime are used instead
• there is no mist flow as such but liquid entrainment in gas phase is accounted for by an
empirical parameter;
• there is no liquid entrainment in the gas bubble in slug flow;
• Transition between flow regimes is based on the minimum slippage between phases.
• The accuracy of the physical models for pressure gradient with viscous oils is significantly
poorer than for reasonably low viscosity oils (viscosity < 100 cP at operating temperature
conditions).
EP/DEV/ED/ECP 26
Note that the physical models are still under development and improvements are implemented
as results of ongoing R&D projects are validated in the OVIP (Olga Verification and
Improvement Program) in which TOTAL participates. The physical model updates are
responsible for the main changes observed between two versions of OLGA in terms of
pressure drop, liquid content etc.
3.21 Reliability and margins

Generally speaking it can be said that Olga is a good 1D multiphase flow simulator and is more
or less suitable for solving most of the problems a process engineer could encounter. But some
limitations and margins to be taken on the results have to be known.
OLGA is a transient “petroleum” flow software. Its main applications are the calculation of the
flow in the pipelines for different geometry, fluids and boundary conditions. In the Process
Department, our simulations can be offshore or onshore and can consider export lines or
production lines. Most of the time for production lines, the simulations performed go from the
well head up to the slug catcher and consider the reservoir fluid or the mixture of reservoir fluid
and gas lift.
Most of our cases respect the following:

• Pipe diameters between 1 and 42 inches for lengths between 500 meters to 500 km.
• Gas superficial velocity between 2 and 30 m/s and the liquid superficial velocity typically
between 0.01 and 3 m/s
• Temperature range between –50°C and +100°C (exceptionally 150°C for high temperature
cases)
• Pressure range usually between 1 and 400 bar absolute.
3.22 OVIP tools

With OVIP (the Olga Verification and Improvement Program), we get the OVIP tools. These are
2 small programs:
- The point model tool (Multiphase Toolkit)
- The comparison tool
The point model tool now referred to as the “multiphase toolkit” will calculate the results of
OLGAS (single point calculation), perform an angle sensitivity study, perform a parametric
study (one input evolving in a range) or draw the flow map. This tool can be useful if you need
to analyze what happens in a small portion of your pipeline. It can be launched from the “Tools”
menu of the GUI.
The comparison tool permits the user to compare the results of the OLGA point model
(OLGAS, which calculates the pressure in one cell) to the data acquired in OVIP. These data
are mainly experimental but a few are the results of measurements campaigns on real
installations. Given an investigation range for the input parameters, a repartition of the
measurements compared to the OLGAS results can be obtained. Pay attention when reading
the curves and do not hesitate to refer to the sheet “output text” to read the table presenting
the results in order not to misread the curve. Indeed what is presented in the curve is the
cumulated percent of the cases (in Y) in the band [-100%, x]! This can be useful to evaluate the
results you have with OLGA and appreciate your margins.
EP/DEV/ED/ECP 27
3.23 Practical aspects

3.23.1 File name and storage
It is strongly recommended not to use special character or leave spaces in the file name of the
simulation. In the same way, the path from the root to this file should not be too long and the
names of the directories should be self-explanatory but short and without special characters.
As the network could be very slow, it is recommended to run Olga from your hard disk
(C:), but from time to time, to copy the files on the network (W:) so in case of a crash of your
hard disk, you will not lose everything!
3.23.2 Low priority
During the simulation time, to go on working on your computer with reasonable computation
times for other applications, you could open the Task Manager of Windows; and under the
“processes” menu, right click on the Olga executable “olga-5.3.2.4.exe”, select “Set Priority”,
and choose “Low”.
3.23.3 Debugging
Before managing to run a simulation, the user will get several error messages from OLGA. This
is quite normal but can easily be boring. This is why it is recommended to look at the input file
in a text editor to check how the GUI has translated your input (since the GUI can generate
some errors) and to track your own missing inputs and errors. Then you can reload your input
file in the GUI (file – reload) and launch your simulation.
When there is no more error, it is highly recommended to analyze carefully the content of the
.out file that could contain warning messages or show that Olga did not understand the input
data as expected by the user.
3.23.4 Launching Olga without the GUI
There are several ways to launch a simulation without using the GUI, however the method
described below (with an example case) is relatively simple.
Example case name: Year2017Pigging.opi

Case location: C:\Local\Studies
• Select “OLGA Command prompt” from the Start menu (Start – All Programs - SPT
Group - OLGA 5 - Tools - OLGA Command Prompt). The prompt below should appear.
• Direct the cursor to the location of the olga case you want to run. In this example the
location is C:\Local\Studies. This can be done by typing the following:
o cd/ (to “initialize” the prompt) C:\Users\J0231894\AppData\Roaming\OLGA>cd/

o cd local C:\Local
EP/DEV/ED/ECP 28
o cd Studies C:\Local\Studies
• Run the case by typing opi Year2017Pigging.opi at the prompt (and clicking enter)
Other points:
1. The case does not have to be in .opi format. Other formats i.e. .inp, .geninp (Olga 5
formats) and .genkey, .key (Olga 7 formats) would also run. However the prefix must be
opi
eg. opi Year2017Pigging.inp
2. To run all cases in a folder use the opi *.opi command
3. All associated files (PVT TAB, restart files etc) need to be in the same folder.
Note that .geninp and .inp files are essentially the same. To “convert” a .geninp to a .inp file (in
order to open it with the GUI), the user simply needs to rename the .geninp file by deleting the
“gen” and thus the file becomes an .inp file.
There are other resources on the FA Sharepoint e.g. “How to run Olga in batch” that can be
consulted.
3.23.5 General Tips
The following tips can be useful to set up a simulation.

• Use DEBUG option (in Case Definition/Options) ON to identify any possible errors and
warnings.
• Always include a valve at the end of the line (riser) even if it is fully opened. This will
prevent creating unrealistic velocities at the outlet. In reality (field conditions) there will be
a valve and you may also use the same valve during the shutdown.
• Depending on the type of simulations adjust the time step for the trend and profile plots.
Keeping in mind that for the depressurization and slugging cases you will need very low
values for the TREND DTPLOT (as low as 1s in some cases).
• Always use the restart file when running transient cases. For example, if you have
simulated the steady state case, use its restart file (.rsw file) to initialize the shutdown
simulation. Do not try to repeat the steady state simulation within the shutdown simulation
because you will waste time unnecessarily.
• Name cases with as much information as possible to enable easy remembrance of the
objective of the case e.g. “01_Year2017_NoGL_SS.opi”
• Zipping your files allows you to save space on your hard disk.
• Take advantage of excel based macros to quickly extract and process your case results.
EP/DEV/ED/ECP 29
4 TYPICAL POST-PROCESSING CASES

Below are described some commonly performed analysis based on Olga simulation results.
4.1 Liquid Surge Volume Evaluation

It is usually necessary to determine the maximum liquid surge volume resulting at the first stage
separator (slug catcher) or the flare drum as a result of a transient operation (e.g. pigging, wells
ramp up, depressurisation etc.) in the upstream pipeline/riser. This result enables the user to
determine the required size of the slug catcher storage section or (by working in reverse)
determine the pipeline conditions that would result in a manageable surge volume (see GM EP
ECP 112 - Guideline for design of Multiple Finger Slug Catchers).
It is assumed that the user has successfully simulated the transient operation.
The surge volume is thus evaluated using an excel spreadsheet by processing the ACCLIQ
results while incorporating the drain rate/liquid outlet rate of the vessel (slug catcher etc). The
following equation is used:
Vsurgej+1 = MAX (0, Vsurgej + ACCLIQj+1 – ACCLIQj –Qdrain * (tj+1 – tj) )
Where Vsurge1 =0
Qdrain = Slug catcher liquid outlet rate.
It is also possible to determine the surge volume of the hydrocarbon liquid and water (aqueous)
phases independently. In this case the user will need to specify the ACCOIQ and ACCWAQ
variables respectively and then process the results in a similar manner as done above.
However for this specific analysis to be realistic, it must be confirmed that the process
arrangement allows such independent draining of oil and water (aqueous phases).
4.2 Erosion Velocity Ratio (EVR) Check

GS EP COR 004 “Limiting flow velocities calculations for erosion corrosion purpose” provides
detailed criteria relating to the acceptable maximum flow velocities for several scenarios (solid
free) and it is clearly noted that all the flow velocity limitations refer to the sum of superficial
velocities of all liquid and gas phases (referred to as “total velocity”) at the point under
consideration.
One of the criteria to be respected is the critical velocity (VAPI) defined by API RP 14E using the
“C” values as noted in the GS. Thus the fluid total velocity must not exceed the critical velocity.
VAPI = C / ρ0.5
The Olga variable “EVR” can be very useful in quickly checking whether the criterion has been
respected for a simulation case.
The “EVR” is calculated as follows by Olga;
EVR = Vtotal/ VAPI
Where VAPI is calculated using C = 100 (US units) or 122 (SI units) See GS EP COR 004 for details
EP/DEV/ED/ECP 30
So for a case where the “C” value specified by GS EP COR 004 is “100”, as long as the value
given by the EVR variable is below “1” the case respects the criterion. However, a similar case
in which the EVR value is greater than “1” implies that Vtotal > VAPI which is not permitted.
It is not possible to change the “C” value in the Olga code as it is clear that there are scenarios
in which the specified “C” value would be “130”, “160” or more. In these cases the user can
simply “update” the criteria used for checking the EVR result from Olga as follows:
• For C = 100, EVR limit = 1
• For C = 130, EVR limit = 1.3
• For C = 160, EVR limit = 1.6
Thus for a case requiring C=160 (US units), if the Olga EVR result = 1.4, it can be considered
that the criterion is not violated since it is below 1.6. This remains consistent as Vtotal < VAPI for
the case.
4.3 Preliminary Hydrate Risk Evaluation

It is possible to evaluate the risk of hydrate formation for the fluid in the pipeline.
This is done by checking the operating conditions of the fluid (P, T) at any given point in the
pipeline against the hydrate dissociation curve.
The user could extract the P, T at the desired location from the Olga output files and plot this on
the same axis (on an excel sheet) with the hydrate dissociation curve which would as a base
case include a 3oC margin.
Otherwise the user can enter the hydrate dissociation curve into the Olga case by using the
HYDRATE CHECK FA Model. In this case, quick interpretation of the results can be done by
plotting the variable DTHYD along the profile of the branch in question. This variable is the
difference between the hydrate dissociation temperature entered into OLGA (at the fluid
operating pressure) and the actual fluid operating temperature. Therefore a positive result for
DTHYD implies that the fluid is to the left of the hydrate dissociation curve i.e. within the
hydrate risk region.
A proper hydrate risk study should not be limited to the analysis of the DTHYD variable.
Comprehensive P-T hydrate dissociation curves and the operating P-T points should also be
prepared and analysed.
Note that these calculations are not very accurate with the PVT tables approach because of the
interpolations and also due to the assumption of constant composition made for building the
tables. However, with the components tracking approach, it is not possible to have the hydrates
dissociation temperature calculated.
4.4 Preliminary TOLC Analysis

Water condensation rate (WCR), which is a variable considered in determining the risk of top of
line corrosion (TOLC) could be evaluated using OLGA results. It is noted that TOLC is typically
a 2D or 3D phenomena and as such is poorly handled in Olga.
For the purpose of preliminary TOLC assessment, it is assumed that water condensing from
the vapour phase is only deposited on the upper half section of the pipe and thus the water
condensation rate is considered as the mass rate of condensed water vapour per 50% of the
pipe inner surface area and is expressed in units of g/s/m2.
The three phase option in OLGA must be used (and the water options FA model added) in
order to differentiate between the water and hydrocarbon liquid phases.
The variable “GWLV” in OLGA represents the mass flow rate of water vapour. The following
EP/DEV/ED/ECP 31
equation can then be used to calculate the WCR based on a material balance performed on
each section:
WCR = Min - Mout

0.5 x ∏ x D x L
Where:
WCR = water condensation rate in g/s/m2
Min= mass flow rate of water vapour at pipeline section inlet in g/s
Mout = mass flow rate of water vapour at pipeline section outlet in g/s
D = pipeline internal diameter in m
L = length of section in m
Note that the results are not very accurate when using the PVT tables approach due to the
interpolation that is performed within the table, components tracking is needed for better
accuracy.
4.5 Flow Regime Map

The flow regime map for a particular fluid flowing in a pipe of given diameter and inclination can
be easily plotted using the “multiphase toolkit” available on the GUI.
This allows the user to quickly visualise the operating point and to determine how close it is to
transition points i.e. boundaries to other flow regimes. This analysis can enable the user to
better understand and explain the flow behaviour of certain cases.
Below is a sample of a flow regime map generated with Olga.
An easy way to create the flow map is to take advantage of already existing samples and
modifying the parameters (File>Sample> 2phase cases or 3 phase cases). It is also possible to
specify directly the fluid with a PVT Tab file.
Once the necessary changes have been made, the map can be generated by simply clicking
on the “map” icon.
EP/DEV/ED/ECP 32
Figure 3: Flow regime map
4.6 Operating Envelope

This presentation method is very useful in highlighting the possible producing/operating cases
that have resulted from a study while having taken into consideration the constraints that must
be respected.
It is typical that each design study would have certain constraints (velocity, arrival temperature,
design pressure etc.), which could in some cases necessitate a review of some base
hypothesis taken during initial design e.g. insulation, pipe diameter etc.
By presenting the “Operating Envelope” as shown below, the presenter can pass this message
in a graphic and simple way while still showing all the constraints.
For the example in Figure 6, it can be seen that production profile data is not feasible for the
year corresponding to point “A” as the point is not within the operating envelope i.e. it exceeds
the design pressure constraint.
EP/DEV/ED/ECP 33
Operating Envelope – Typical example for Gas Condensate Pipeline
Figure 4: Operating Envelope
EP/DEV/ED/ECP 34
Appendix 1 : Glossary
EP/DEV/ED/ECP 35
The terminology used in Olga is not always self explanatory. The user has to be at minimum
familiar with it because the error messages issued by Olga use this terminology. The most
important words the user has to understand are presented here below.
Keywords: the keywords (or keys) can be considered as the name of a category of data (or
module) for example HEAT TRANSFER is a keyword and defines the block data or the window
where the user will define the ambient conditions.
Sub-keywords: Inside a keyword (or module) different parameters have to be defined. These
parameters are defined through sub-keywords (for example inside the HEAT TRANSFER
module HAMBIENT is a sub-keyword referring to the heat transfer coefficient between the
ambient and the pipe).
CPU time: The CPU time is the time used by the processor to run the simulation. The term
“““duration of the simulation””” can be confusing: in some cases it means the duration of the
scenario to simulate in other cases it refers to the CPU time.
The CPU time varies a lot from an application to the other: it varies with the duration of the
scenario but also with the equipment modeled (controller, separator) and the geometry
(refinement of the mesh) and the models (two or three phases, thermal calculation or T given
etc).
PVT file: OLGA uses a PVT file whose extension is .tab where the properties of the fluid are
given for different points of pressure and temperature. This file is usually generated by a
standalone software called PVTSIM and provided by CALSEP. Another way to generate this
file is to use the US4 of ProII (process software). The tab file is replaced by a .ctm file when
using the compositional tracking module.
GUI: GUI stands for Graphical User Interface and refers to the OLGA window allowing the user
to build a case, run it (either in batch mode or in interactive mode) and to plot the results. Using
the GUI has the strong advantage that the user does not have to know the key words and their
exact spelling.
Branch: In OLGA the term BRANCH is a keyword referring to a pipeline having only one entry
and one exit. Inside a BRANCH only one fluid can flow and this fluid has to be defined in the
tab file. The BRANCH is constituted by a series of PIPES.
Pipe: The term PIPE in OLGA does not refer to a pipeline (this is a BRANCH) but to a part of
the pipeline with a constant slope. This means that in OLGA a pipeline has to be represented
by a series of linear portions defined as PIPES. A curve should consequently be represented
by a series of PIPES. Each change in angle leads to the adding of a PIPE. The PIPE is defined
by its length and elevation but also by its inner diameter, its roughness and its wall (see below).
For the calculation purpose, a PIPE is divided into SECTIONS.
Section: a section is a calculation cell. It is also called a control volume. A PIPE is divided into
several sections that can be of same length or not. For each of these sections OLGA will solve
the problem and in particular calculate the temperature and pressure. The 1D mesh of the
simulation is defined by the series of PIPES and SECTIONS.
Wall: the term WALL is used to define the layers constituting the pipe. A WALL is defined by
two series: the first one is the list of materials (from the inner-most to the outer-most) and the
second one is the thicknesses of the layers. The internal diameter of the pipe-line is not given
in this keyword but is specified on the PIPE sub-keywords.
EP/DEV/ED/ECP 36
Appendix 2 : Getting Started
EP/DEV/ED/ECP 37
1. OLGA manuals
Olga user manuals are provided by the code developers for both the level I and level II courses.
Users are advised to review carefully these manuals as they contain very useful information:
2. Structure of an Olga input file
A standard OLGA input file is mainly constituted of 17 modules which appear in this order in
the input file:
1. CASE
2. OPTION
3. Water option
4. FILES
5. INTEGRATION
6. MATERIAL
7. WALL
8. GEOMETRY
9. NODE
10. BRANCH
11. POSITION
12. BOUNDARY
13. HEAT TRANSFER
14. SOURCE
15. PROFILE
16. OUTPUT
17. TREND
In CASE, the user gives some information for identification of the job purposes.
In OPTION, the user defines the main OLGA options.
The WATER OPTION module should be added to the input file in case of three-phase
simulation. In this module the user should turn ON the water flash option (water can be free or
vapor) and the water slip for the shearing. In addition, in this module the user can ask for
emulsion viscosity calculation.
In FILES, the user defines most of the time only one file. In this module the user will actually
give the name of the fluid file (PVT file).
In INTEGRATION, the user will have to define the properties of the simulation in terms of time
step and time period to be simulated. In addition, the user can state that if the CPU time
exceeds a certain value then OLGA should stop the calculations (useful to recover the
processor but can stop the simulation a bit too early).
In MATERIAL are defined the different materials used to constitute the WALLS.
In keyword WALL the various materials constituting the envelope of the pipeline (insulation,
concrete ...) can be defined.
In GEOMETRY, the length, elevations, radius and roughness of the pipeline can be defined. In
addition, the user is also defining the meshing used for the calculation i.e. sections
In NODE the user is defining special points of the pipeline or network. These points are special
for the calculation point of view. Three main types of NODES are used:
• The terminal node which indicates that this node is placed at the end of the line or
network.
EP/DEV/ED/ECP 38
• The merge node which is used to create a converging network (at such a node several
flows are mixed and the result is flowing into a downstream pipeline).
• The split node which is used to create a diverging network (at such a node the flow
coming from one upstream pipeline is split into at least two pipelines).
In BRANCH, the user defines the GEOMETRY and the fluid flowing inside the pipeline in
addition to the nodes at its extremities.
In POSITION, the user can identify particular points of the pipeline. These points are not
particular for the calculation (not boundary) but can be used to get a variable at this point or to
place equipment at this point.
In BOUNDARY, the user defines the boundary conditions of the line or network. Usually the
entry of the line is of type CLOSED (no flow is going through this boundary; the entry of the
fluid is made through a SOURCE placed in the middle of one cell). The exit is of type
PRESSURE, the back pressure is given there and also some parameters in case of a reverse
flow (entry of fluid through the exit). The pressure inside the line will be calculated to reach this
exit pressure.
In HEAT TRANSFER, the user gives the ambient conditions (mainly the temperature and the
external convection) so that OLGA can calculate the fluid temperature.
The temperature of the ambient along the pipeline is given here and also the heat transfer
coefficient. If the coefficient is not provided by the user then he can give the velocity of the
water or air or define some parameters allowing OLGA to calculate this coefficient.
In SOURCE the user will define the inlet fluid. This entry will be placed in the middle of a
SECTION (usually the first one) and the temperature and the mass rate have to be specified.
The SOURCE module can be replaced by a WELL module to simulate a well with its
performance index. Generally the simulations start downstream the well head valve and end at
the riser upper valve so the SOURCE is generally used and not the WELL module.
The PROFILE, OUTPUT and TREND modules are used to store some results of the simulation.
3. Other useful modules
Other modules are commonly used:

1. The valve
2. The separator
3. The controller
4. The slug tracking
For oil simulations, it is recommended to simulate the separator with its regulation
(CONTROLLER). This is quite difficult to define but is often of interest. If the separator is
included in the simulation its control system must be defined because of its potential backwards
effect on the flow stability.
EP/DEV/ED/ECP 39
5 REFERENCES
1. OLGA User manual Version 5

2. OLGA User manual Version 7.0
3. TOTAL - PVTSim Handbook
4. TOTAL – Manual of TOTAL UAS
5. GM EP ECP 112 – Guidelines for design of Multiple Finger Slug Catchers
6. GS EP COR 004 - Limiting flow velocities calculations for erosion corrosion purpose
7. PRODEM Chapter XXXI – Flow Assurance
8. Available on the FA Sharepoint http://collaboratif-sp2010.ep.corp.local/sites/Flow_Assurance/default.aspx:
a. How to create a multisource model in Olga
b. Methodology to be applied for slugging analysis related to fatigue calculations
c. “OLGA Res” excel macros
d. Controllers definition in Olga & Ledaflow
e. PID Controller tuning: A short tutorial
f. How to run Olga in batch
g. Bypass Pig Modeling for Gas Condensate Pipeline Systems
EP/DEV/ED/ECP 40

OLGA COMPANY HANDBOOK - Rev02

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OLGA COMPANY HANDBOOK - Rev02

Uploaded by

Copyright:

Available Formats

EP/DEV/ED/ECP

2 12/2014 General review

2 MODEL LIMITATIONS ............................................................................................. 4

3 COMPANY RECOMMENDATIONS ......................................................................... 5

3.1 UNITS .................................................................................................................5

4 TYPICAL POST-PROCESSING CASES................................................................ 30

4.1 LIQUID SURGE VOLUME EVALUATION .................................................................. 30

3.2 Calculations options

The default values can be adopted for the other options.

3.3 Temperature & Heat Transfer

3.3.1 Calculation Options

If TEMPERATURE = UGIVEN, convection at pipe walls is not considered/calculated within

If TEMPERATURE = ADIABATIC, no energy exchange is considered with the pipeline wall.

3.3.2 Heat Transfer Coefficients

Figure 1: Overall heat transfer in a 3 layered wall

Inner Wall Heat Transfer Coefficient

Outer Wall Heat Transfer Coefficient

If TEMPERATURE = WALL; the coefficient must be specified using the “HOUTEROPTION”

3.3.3 Recommendations – Temperature & Heat Transfer

a) When defining pipeline thermal specifications or in discussions with TEC/PLR

2. Dynamic simulations – Cooldown, Shutdown, Warm up etc.; Temperature = WALL must

3.3.4 WALL Discretization

3.3.5 Electrical heating

3.3.6 Buried pipes

Where, T = equivalent soil thickness (to be entered in WALL)

3.4 PVT File and Two or Three phase simulations

Fluid Process/Pseudo process

PVT File formats

3.4.2 Good Use of the PVT File

Two or Three Phase PVT File

PVT file Pressure and Temperature range

Verifying the state of the PVT file

3.5 Pipeline Description

Figure 1: Basic Network case

3.6 Time step and INTEGRATION key

The following is recommended:

3.7 Extent of the simulation

3.8.1 Pressure boundary

3.9 Steady-state and initial conditions

3.9.2 Steady state results

The following should also be noted:

• As mentioned above, the steady-state preprocessor will provide only an approximation of

3.10.2 Building a restart case

3.10.3 Using a RSW file

3.10.4 Time reference

3.11 Slug tracking option

I. Slugs are not allowed to be generated at these points.

The following parameters can be chosen for slugs initiations:

DELAYCONSTANT = 150 (sensitivity with value determined with Shea correlation is

• Non-miscibility of the two liquids

Inversion water fraction: Keyword “INVERSIONWATERFRAC”. This important parameter

The following points which affect emulsion modeling are noted:

3.13 Compositional Tracking

See the SPT/SLB Olga manual for more details.

3.14 Pump Modeling

Table 1 : Pump Models

Figure 2: Basic Pumping Models

3.15 Pig Modeling

3.16 Output files

• An output file (.out) containing the results on a tabular form

3.18 Parametric study

3.19 Read Statement