Introduction to OLGA

Introduction

Page 1 of 19

Introduction OLGA is the industry standard tool for transient simulation of multiphase petroleum production. The purpose of this manual is to assist the user in the preparation of the input data for an OLGA simulation.

In this manual you can find



a general introduction to OLGA



an overview of the required and the optional input to OLGA. It also describes in some detail different simulation options such as wax deposition, corrosion etc.



a detailed description of all input data and the required fluid property tables



a description of the output

The sample cases presented with the installation of OLGA are intended to illustrate important program options and typical simulation output. A description of the sample cases are also included in this manual.

OLGA comes in a basic version with a number of optional modules;FEMTherm, Multiphase Pumps, Corrosion, Wells, Slug Tracking, Wax Deposition, Inhibitor Tracking, Compositional Tracking, Single Component Tuning, Hydrate Kinetics and Complex Fluid.

In addition there is a number of additional programs like the OLGA GUI and the FEMThermViewer for preparation of input data and visualisation of results.

These optional modules and additional programs are available to the user according to the user's licensing agreement with SPT Group.

See also:

Background OLGA as a strategic tool OLGA Model Basics How to use in general Graphical User Interface Simulation model Input files Applications Threaded Execution

Background OLGA 6 is the latest version in a continuous development which was started by the Institute for Energy Research (IFE) in 1980. The oil industry started using OLGA in 1984 when Statoil had supported its development for 3 years. Data from the large scale flow loop at SINTEF, and later from the medium scale loop at IFE, were essential for the development of the multiphase flow correlations and also for the validation of OLGA. Oil companies have since then supported the development and provided field data to help manage uncertainty, predominantly within the OLGA Verification and Improvement Project (OVIP). OLGA has been commercially available since the SPT Group started marketing it in 1990.

OLGA is used for networks of wells, flowlines and pipelines and process equipment, covering the production system from bottom hole into the production system. OLGA comes with a steady state pre-processor included which is intended for calculating initial values to the transient simulations, but which also is useful for traditional steady state parameter variations. However, the transient capabilities of OLGA dramatically increase the range of applicability compared with steady state simulators.

file://C:\Users\c108637\AppData\Local\Temp\~hh504A.htm

20/02/2012

Introduction

Page 2 of 19

OLGA as a strategic tool

OLGA is applied for engineering throughout field life from conceptual studies to support of operations. However the application has been extended to be an integral part of operator training simulators, used for making operating procedures, training of operators and check out of control systems. Further, OLGA is frequently embedded in on-line systems for monitoring of pipeline conditions and forecasting and planning of operations.

OLGA can dynamically interface with all major dynamic process simulators, such as Hysys, DynSim, UniSim, D-SPICE, INDISS and ASSETT. This allows for making integrated engineering simulators and operator training simulators studying the process from bottom hole all the way through the process facility in a single high fidelity model.

Note that the OLGA flow correlation has been implemented in all major steady state simulators providing consistent results moving between different simulators.

OLGA Model Basics OLGA is a three-fluid model, i.e. separate continuity equations are applied for the gas, for the oil (or condensate) and water liquids and also for oil (or condensate) and water droplets. Gas is always assumed to be lighter than oil and water in OLGA, but oil may be both lighter or heavier than water[1].

These fluids may be coupled through interfacial mass transfer. Three momentum equations are used; one for each of the continuous liquid phases (oil/condensate and water) and one for the combination of gas with liquid droplets. The velocity of any liquid droplets entrained in the gas phase is given by a slip relation. One mixture energy equation is applied; assuming that all phases are at the same temperature. This yields seven conservation equations and one equation of state to be solved: the seven conservation equations are three for mass, three for momentum, and one for energy, while the equation of state is for pressure.

Two basic flow regime classes are recognised ; distributed and separated flow. The former comprises bubble and slug flow [2], the latter stratified and annular mist flow.

file://C:\Users\c108637\AppData\Local\Temp\~hh504A.htm

20/02/2012

Introduction

Page 3 of 19

Figure A Flow patterns in horizontal flow

Transition between the regime classes is determined by the program on the basis of a minimum slip concept combined with additional criteria.

To close the system of equations, fluid properties, boundary and initial conditions are required.

The equations are linearised and a sequential solution scheme is applied. The pressure and temperature calculations are de-coupled i.e. current pressure is based on previous temperature.

The semi-implicit time integration implemented allows for relatively long time steps, orders of magnitudes longer than those of an explicit method (which would be limited by the Courant Friedrich Levy criterion based on the speed of sound).

The numerical error is corrected for over a period of time. The error manifests as an error in local fluid volume (as compared to the relevant pipe volume).

[1] Note that

the OLGA model has only been verified and tuned for fluids where oil is lighter than water.

[2] In

standard OLGA a slug unit model is applied which calculates average liquid hold-up and pressure, but which does not give any details about individual slugs. To follow individual slugs through the system the slug tracking module must be applied.

How to use in general Numerics OLGA applies one global time-step for the time integration and there is an automatic time-step control based on the limitation that a fluid particle should not spend less than one time-step on passing through any numerical section length of a pipe (the Courant Friedrich Levy (CFL) criterion based on the fluid velocity). The user controls the time integration by specifying simulation period in time, time-step parameters such as initial time-step and maximum and minimum time-step values. The latter overrules the automatic control. There is also an option for using the second-derivative of pressure as a time step controlling criterion. Some functions in OLGA, e.g. slug-tracking, take control of the time-stepping in order to ensure a successful simulation.

The spatial integration is performed on a user-defined grid. There are tools available to facilitate the gridding. There are no formal limitations on the numerical section lengths, but it is considered good practice to keep all neighbour section length ratios between 0.5 and 2:

0.5 ≤ Dxi/Dxi+1 ≤ 2 for all i

Additionally it is recommended that each pipe should have at least two sections.

Due to the numerical solution scheme, OLGA is particularly well suited for simulating rather slow mass flow transients. This is important for the simulation of long transport lines and thermal calculations, where typical simulation times in the range of hours to several days, and sometimes years, will require long time steps, to obtain efficient use of the computer.

OLGA is also being used successfully for fast transients such as water hammer and pressure surges in general. Certain precautions w.r.t. spatial grid and time-stepping may be needed in order to keep the numerical error within acceptable limits.

The de-coupling of temperature from pressure would normally give a pressure wave propagation velocity in gas which would be about 15% too low. However, a quasi implicit correction of temperature reduces this error considerably.

Critical flow calculations are performed in the OLGA valve model, only. A valve with cross section equal to the pipe should then be positioned on e.g. a pipe outlet if choked flow is expected.

file://C:\Users\c108637\AppData\Local\Temp\~hh504A.htm

20/02/2012

Introduction

Page 4 of 19

Temperature OLGA is particularly well suited for sophisticated thermal simulations. Since OLGA is one-dimensional (calculates along the pipe axis) any 2 and 3dimensional effects must be modelled explicitly. The basic OLGA thermal model calculates the inner wall heat transfer coefficient. The built-in correlations are valid for natural- and forced convection and also for the transition between them. Flow pattern is accounted for. The user may specify pipe walls with material properties, including emissivity to account for radiation, and must give the ambient properties, i.e. temperature and heat transfer coefficient. Based on this the fluid temperature is calculated.

Special features like Annulus, Solid- and Fluid bundles make it possible to simulate very complex structures of pipe-in-pipe and parallel pipes within structures of various solid materials. Taking into account that temperature is calculated along the pipes one obtains a combination of two-dimensional convective heat transfer within 3-dimensional heat conducting structures.

Solid bundle cross section of 4 vertical tubes within rock – neighbour tubes are 2.5 m apart. The black "line" is a temperature iso-line. One clearly sees how the area between the tubes is subject to intertube heating.

Initial Conditions The requirement for initial conditions is a fundamental difference between a transient and a steady state model, e.g. the results of a steady state calculation may serve as the initial condition (at t=0 ) for a transient simulation.

With OLGA the user decides, and later specifies in the input, whether the simulation is to start from a user defined condition (for instance a specific shut-in condition), or from a steady state multiphase flowing situation calculated by the program. The steady state pre-processor in OLGA can be used to provide good initial values for most production situations.

In addition, the user may specify the initial condition in detail, for example for a shut-in system, by defining the initial values for pressures, temperatures, mass flow and gas fractions. Tools for interpolation are available, for filling in the initial values in all numerical sections of the system.

Finally, the restart capability may be used to start a simulation from conditions saved during a previous simulation.

Boundary Conditions The boundary conditions define the interface between the simulated system and its surroundings and they are crucial to the relevance to any type of simulations. For a network of pipelines and wells there are several options available, but basically flow rate or pressure, in addition to temperature and gas-

file://C:\Users\c108637\AppData\Local\Temp\~hh504A.htm

20/02/2012

Introduction

Page 5 of 19

liquid ratio must be specified at each flow path inlet and outlet boundary (at least one pressure must be given).

The boundary conditions, e.g. a pressure, can be given as time series to model a certain transient situation.

Moreover, the ambient temperature along the flow paths and ambient heat transfer coefficient (film heat transfer resistance) must be specified and OLGA provides a number of options for this, including water and air velocity profiles and seasonal variations of temperature.

Inflow from reservoirs to well-bores define the most important boundary in a petroleum production network. In addition to various well-inflow correlations and options OLGA comes with an implicit coupling facility to the OLGA Rocx module which is a complete 3-D, 3-phase reservoir simulator.

Separators, pumps, compressors and valves, all with controllers, can be modelled to improve the relevance of the outlet boundaries.

Fluid properties The necessary fluid properties (gas/liquid mass fraction, densities, viscosities, enthalpies etc.) are normally assumed to be functions of temperature and pressure only, and have to be supplied by the user as tables in a special input file. Thus, the total composition of the multiphase mixture is assumed to be constant both in time and space for a given part of the network. The user may specify different fluid property tables for each flow path, but has to ensure that a realistic fluid composition has been used to make a table for a flow path with a fluid mixture coming from two or more pipeline branches merging upstream.

It is also possible to perform simulations using Compositional Tracking, where the basic information on the chemical components is provided in a separate text file and then OLGA calculates the fluid properties internally with PVT routines provided by Calsep A/S. This means that the total composition may vary both in time and space, and that no special considerations are needed for the downstream system.

Special models are also available for tracking hydrate inhibitors like MEG and methanol.

OLGA is generally able to handle multi component fluid systems, but there are some restrictions and assumptions in the use of fluids. For a more detailed description, please see Limitations in the use of fluid properties.

Rheology The standard OLGA flow models assume a Newtonian rheology (viscosities are well defined fluid characteristics).

Dispersions and non-Newtonian behavior are quite common in petroleum production and OLGA provides several semi-empirical models to account for more complex rheologies. In some cases the model takes care of the rheology with a minimum of user interference (e.g. for oil-water dispersions and also for waxy oils). For other systems the user needs to specify the various parameters for such fluids to describe e.g. Bingham or power law non-Newtonian behavior.

file://C:\Users\c108637\AppData\Local\Temp\~hh504A.htm

20/02/2012

Introduction

Page 6 of 19

Network In OLGA the network comprises flow paths coupled with nodes which have a volume. General networks with closed loops can then be modelled, see below. The flow paths have a user defined direction but the flow is invariant to direction as such and any fluid phase may flow co-currently or countercurrently with respect to the pre-defined direction at any time and position.

Pipe-bends are not accounted for as such (except for differences in static head). The user may apply pressure loss coefficients at boundaries between numerical sections.

Equipment is positioned on the flow path – usually on a pipe-boundary. However, the separator in OLGA is a network component similar to a node.

Controllers are specified as integral parts of the simulation model and they have their own network formalism.

Threaded Execution Pipe sections belonging to the same branch may be updated in parallel. Suppose a branch has 100 sections, and that two threads are available to the OLGA engine: Section 1 and section 51 will be updated simultaneously, then section 2 and section 52 are updated, and so on. Depending on the computer hardware, this method can drastically reduce the time OLGA takes to advance one time-step. Normally, you do not need to change the default settings of neither OLGA nor your operating system. Parallel updating of segments is usually activated in the OLGA engine if your PC supports it.

Controlling the degree of parallelism The Windows operating system decides how many threads will be used. If your PC is equipped with a quad-core CPU, typically four threads will be simultaneously running to update four sections in parallel. Is your CPU a single-core Intel Xeon processor with "hyper-threading" (HT), probably two engine threads will be used. It is possible to overrule the choice of the operating system by setting the environment variable OMP_NUM_THREADS; use Windows' Control Panel to do this. However, the preferred way to change the degree of parallelisation is do so from the OLGA menu system. Setting the value here takes precedence over the OMP_NUM_THREADS environment variable.

A situation where you might want to reduce the number of threads, arise if you execute parametric studies. Given that your license permits, it would be preferable to spend the CPU's cores on simultaneous simulations, rather than on speeding up each simulation in the study. Another situation could be when you don't want OLGA to consume all your computing power, e.g., if you want to write a report while OLGA is working.

Most large cases will benefit from the parallelisation. Still, please note that some of your PC's cache memory will be used for forking and joining the threads, and doing the necessary book-keeping. As a consequence, special cases will run faster with a single engine thread.

Parallel speed-up The parallelisation encompasses heat calculations in section walls, updating fluid properties and flashing, and, most importantly, calls to the flow model which decides friction factors, liquid holdup and the flow regime. If the flow model calculations dominate the overall simulation, the utilization of the CPUs is most efficient.

file://C:\Users\c108637\AppData\Local\Temp\~hh504A.htm

20/02/2012

Introduction

Page 7 of 19

Monitoring the OLGA process The Task Manager can be used to check how OLGA loads your CPU. When the number of engine threads equals the number of cores (or equals two on a single core HT-CPU) you should see the CPU usage being clearly over fifty percent when OLGA is simulating.

In the Task Manager's list of processes it is possible to view the number of threads for each process. With 1 engine thread, it uses a total of 5 threads in batch mode, and 8 threads while running under control of the GUI. With 2 engine threads allowed, the task manager would display 6 threads for a batch run and 9 threads for a GUI run; with 4 engine threads the total number of threads would be 8 and 11, respectively.

Applications When the resources become more scarce and complicated to get to careful design and optimisation of the entire production system is vital for investments and revenues. The dimensions and layout of wells and pipelines must be optimised for variable operational windows defined by changing reservoir properties and limitations given by environment and processing facilities.

OLGA is being used for design and engineering, mapping of operational limits and to establish operational procedures. OLGA is also used for safety analysis to assess the consequences of equipment malfunctions and operational failures.

REFERENCES contains a list of papers describing the OLGA model and its applications.

Design and Engineering OLGA is a powerful instrument for the design engineer when considering different concepts for hydrocarbon production and transport - whether it is new developments or modifications of existing installations.

OLGA should be used in the various design phases i.e. Conceptual, FEED [2] and detailed design and the following issues should be addressed:

• Design 

Sizes of tubing and pipes



Insulation and coverage



Inhibitors for hydrate / wax



Liquid inventory management / pigging



Slug mitigation



Processing capacity (Integrated simulation)

• Focus on maximizing the production window during field life 

Initial



Mid-life



Tail

• Accuracy / Uncertainty management 

Input accuracy



Parameter sensitivity

• Risk and Safety

Normally the engineering challenge becomes more severe when accounting for tail-end production with reduced pressure, increasing water-cut and gas-oil ratio. This increase the slugging potential while fluid temperature reduces which in turn increase the need for inhibitors and the operational window is generally reduced.

file://C:\Users\c108637\AppData\Local\Temp\~hh504A.htm

20/02/2012

Introduction

Page 8 of 19

Operation 

OLGA should be used to establish



Operational procedures and limitations



Emergency procedures



Contingency plans



OLGA is also a very useful tool for operator training



Training in flow assurance in general



Practicing operational procedures



Initial start up preparations

Some typical operational events suitable for OLGA simulations are discussed below.

Pipeline shut-down If the flow in a pipeline for some reason has to be shut down, different procedures may be investigated. The dynamics during the shut-down can be studied as well as the final conditions in the pipe. The liquid content is of interest as well as the temperature evolution in the fluid at rest since the walls may cool the fluid below a critical temperature where hydrates may start to form.

Pipeline blow-down One of the primary strategies for hydrate prevention in case of a pipeline shut-down is to blow down. The primary aim to reduce the pipeline pressure below the pressure where hydrates can form. The main effects that can be studied are the liquid and gas rates during the blow-down, the time required and the final pressure.

Pipeline start-up The initial conditions of a pipeline to be started is either specified by the user or defined by a restart from a shut-down case. The start-up simulation can determine the evolution of any accumulated liquid slugs in the system. A start-up procedure is often sought whereby any terrain slugging is minimised or altogether avoided. The slug tracking module is very useful in this regard.

In a network case a strategy for the start-up procedure of several merging flow lines could be particularly important.

Change in production Sometimes the production level or type of fluid will change during the lifetime of a reservoir. The modification of the liquid properties due to the presence of water, is one of the important effects accounted for in OLGA.

A controlled change in the production rate or an injection of another fluid are important cases to be simulated. Of particular interest is the dynamics of network interactions e.g. how the transport line operation is affected by flow rate changes in one of several merging flow lines.

file://C:\Users\c108637\AppData\Local\Temp\~hh504A.htm

20/02/2012

Introduction

Page 9 of 19

Process equipment Process equipment can be used to regulate or control the varying flow conditions in a multi-phase flow line. This is of special interest in cases where slugging is to be avoided.

The process equipment simulated in OLGA includes critical- and sub-critical chokes with fixed or controlled openings, check-valves, compressors with speed and anti- surge controllers, separators, heat exchangers, pumps and mass sources and sinks.

Pipeline pigging OLGA can simulate the pigging of a pipeline. A user specified pig may be inserted in the pipeline in OLGA at any time and place. Any liquid slugs that are created by the pig along the pipeline can be followed in time. Of special interest is the determination of the size and velocity of a liquid slug leaving the system ahead of a pig that has been inserted into a shut-down flow line.

Hydrate control Hydrate prevention and control are important for flow assurance. Passive and active control strategies can be investigated: Passive control is mainly achieved by proper insulation while there are several options for active control which can be simulated with OLGA: Bundles, electrical heating, inhibition by additives like MEG.

Wax deposition In many production systems wax would tend to deposit on the pipe wall during production. The wax deposition depends on the fluid composition and temperature. OLGA can model wax deposition as function of time and location along the pipeline.

Tuning Even if the OLGA models are sophisticated models made for conceptual studies and engineering will be based on input and assumptions which are not 100% relevant for operations. Therefore OLGA is equipped with a tuning module which can be used on-line and off-line to modify input parameters and also critical model parameters to match field data.

Wells - Flow stability e.g. permanent or temporary slugging, rate changes - Artificial lift for production optimization - Shut-in/start-up - water cut limit for natural flow - Cross flow between layers under static conditions - WAG injection - Horizontal wells / Smart wells - Well Clean-up and Kick-off - Well Testing - Well control and Work-over Solutions

Safety Analysis Safety analysis is an important field of application of OLGA. OLGA is capable of describing propagation of pressure fronts. For such cases the time step can be limited by the velocity of sound across the shortest pipe section.

OLGA may be useful for safety analysis in the design phase of a pipeline project, such as the positioning of valves, regulation equipment, measuring devices, etc. Critical ranges in pipe monitoring equipment may be estimated and emergency procedures investigated.

Consequence analysis of possible accidents is another interesting application. The state of the pipeline after a specified pipe rupture or after a failure in any process equipment can be determined using OLGA.

file://C:\Users\c108637\AppData\Local\Temp\~hh504A.htm

20/02/2012

Introduction

Page 10 of 19

Simulations with OLGA can also be of help when defining strategies for accident management, e.g. well killing by fluid injection.

Finally it should be mentioned that the OLGA model is well suited for use with simulators designed for particular pipelines and process systems. Apart from safety analysis and monitoring, such simulators are powerful instruments in the training of operators.

[2] Front End Engineering and Design

Input files The OLGA simulator uses text files for describing the simulation model:



.opi; generated and used by the OLGA GUI



.inp; input format used by OLGA 5 and earlier versions



.key; input format used by OLGA

The .key format has been introduced as the new input file format for the OLGA engine. The OLGA GUI will automatically generate files in this format (with the extension .genkey). The .key format reflects the network model described in the simulation model and should be the preferred format.

In addition to the simulation file, OLGA handles input in several other formats as described in Data files.

Simulation description The input keywords are organised in Logical sections, with Case level at the top, followed by the various network components and then the connections at the end.

Case level Case level is defined as the global keywords specified outside of the network components and connections. Case level keywords can be found in the CaseDefinition, Library, FA-models and Output sections.

The following keywords must or can be defined at Case level:



CaseDefinition; CASE, FILES, INTEGRATION, OPTIONS, DTCONTROL, RESTART



Library; MATERIAL, WALL, SHAPE, TABLE, DRILLINGFLUID, HYDRATECURVE



Compositional; COMPOPTIONS, FEED, BLACKOILOPTIONS, BLACKOILCOMPONENT, BLACKOILFEED, SINGLEOPTIONS



FA-models; CORROSION, FLUID, WATEROPTIONS, SLUGTRACKING, TUNING, SLUGTUNING



Output; OUTPUT, TREND, PROFILE, PLOT, OUTPUTDATA, TRENDDATA, PROFILEDATA



Drilling; TOOLJOINT

CASE PROJECT="OLGA Manual", TITLE="Example case", AUTHOR="SPT Group AS" INTEGRATION STARTTIME=0, ENDTIME=7200, DTSTART=0.1, MINDT=0.1, MAXDT=5 FILES PVTFILE=fluid.tab

MATERIAL LABEL=MAT-1, DENSITY=0.785E+04, CAPACITY=0.5E+03, CONDUCTIVITY=0.5E+02 WALL LABEL=WALL-1, THICKNESS=(0.9000E-02, 0.2E-01), MATERIAL=(MAT-1, MAT-1)

file://C:\Users\c108637\AppData\Local\Temp\~hh504A.htm

20/02/2012

Introduction

Page 11 of 19

Network components The network components are the major building blocks in the simulation network.

Each network component is enclosed within start (NETWORKCOMPONENT) and end (ENDNETWORKCOMPONENT) tags as shown below. Each data group belonging to this network component will be written within these tags.

NETWORKCOMPONENT TYPE=FlowPath, TAG=FP_BRAN ... ENDNETWORKCOMPONENT

The following network component keywords can be specified (see links for further details on each component):



FlowComponent;FLOWPATH, NODE



ProcessEquipment;PHASESPLITNODE, SEPARATOR



Controller;CONTROLLER



ThermalComponent;ANNULUS, FLUIDBUNDLE, SOLIDBUNDLE

FLOWPATH Piping

The flowpath can be divided into several pipes, which can have an inclination varying from the other pipes in the flowpath. Each pipe can again be divided into sections as described above. All sections defined within the same pipe must have the same diameter and inclination. Each pipe in the system can also have a pipe wall consisting of layers of different materials.

The following keywords are used for Piping:



BRANCH; Defines geometry and fluid labels.



GEOMETRY; Defines starting point for flowpath.



PIPE; Specifies end point or length and elevation of a pipe. Further discretization, diameter, inner surface roughness, and wall name are specified.



POSITION; Defines a named position for reference in other keywords.

BRANCH LABEL=BRAN-1, GEOMETRY=GEOM-1, FLUID=1 GEOMETRY LABEL=GEOM-1 PIPE LABEL=PIPE-1, DIAMETER=0.12, ROUGHNESS=0.28E-04, NSEGMENT=4, LENGTH=0.4E+03, ELEVATION=0, WALL=WALL-1

Boundary&Initialconditions

For the solution of the flow equations, all relevant boundary conditions must be specified for all points in the system where mass flow into or out of the system. Initial conditions at start up and parameters used for calculating heat transfer must also be specified.

The following keywords are used for Boundary & Initial conditions:



HEATTRANSFER; Definition of the heat transfer parameters.



INITIALCONDITION; Defines initial values for flow, pressure, temperature and holdup. INITIALCONDITIONS is not required when a steady

file://C:\Users\c108637\AppData\Local\Temp\~hh504A.htm

20/02/2012

Introduction

Page 12 of 19

state calculation is performed. 

NEARWELLSOURCE; Defines a near-wellbore source used together with OLGA Rocx.



SOURCE; Defines a mass source with name, position, and data necessary for calculating the mass flow into or out of the system. The source flow can be given by a time series or determined by a controller.



WELL; Defines a well with name, position and flow characteristics.

HEATTRANSFER PIPE=ALL, HAMBIENT=6.5, TAMBIENT=6, HMININNERWALL=0.5E+03 SOURCE LABEL=SOUR-1-1, PIPE=1, SECTION=1, TIME=0, TEMPERATURE=62, GASFRACTION=-1, TOTALWATERFRACTION=-1, PRESSURE=70 bara, DIAMETER=0.12, SOURCETYPE=PRESSUREDRIVEN

Process Equipment

In order to obtain a realistic simulation of a pipeline system, it is normally required to include some process equipment in the simulation. OLGA supports a broad range of different types of process equipment, as shown below.

It should be noted that the steady state preprocessor ignores the process equipment marked with (*) in the list below.

The following keywords are used for Process equipment:



CHECKVALVE (*); Defines name, position and allowed flow direction for a check valve.



COMPRESSOR (*); Defines name, position and operating characteristics of a compressor.



HEATEXCHANGER; Defines name, position and characteristic data for a heat exchanger.



LOSS; Defines name, position and values for local pressure loss coefficients.



LEAK; Defines the position of a leak in the system with leak area and back pressure. The leak can also be connected to another flowpath to simulate gas lift etc.



PUMP (*); Defines name, type and characteristic data for a pump.



TRANSMITTER (*); Defines a transmitter position.



VALVE; Defines name, position and characteristic data for a choke or a valve.

VALVE LABEL=CHOKE-1-1, PIPE=PIPE-1, SECTIONBOUNDARY=4, DIAMETER=0.12, CD=0.7, TIME=0, OPENING=1.0

Output

OLGA provides several output methods for plotting simulation results.

The following keywords are used for Output:



OUTPUT(DATA); Defines variable names, position and time for printed output.



PLOT; Defines variable names and time intervals for writing of data to the OLGA viewer file.



PROFILE(DATA); Defines variable names and time intervals for writing of data to the profile plot file.



TREND(DATA); Defines variable names and time intervals for writing of data to the trend plot file.

TRENDDATA PIPE=1, SECTION=1, VARIABLE=(PT bara, TM, HOLHL, HOLWT) PROFILEDATA VARIABLE=(GT, GG, GL)

file://C:\Users\c108637\AppData\Local\Temp\~hh504A.htm

20/02/2012

Introduction

Page 13 of 19

NODE Boundary&Initialconditions 

PARAMETERS; A collection keyword for all node keys. This keyword is hidden in the GUI.

Output

OLGA provides several output methods for plotting simulation results.

The following keywords are used for Output:



OUTPUTDATA; Defines variable names, position and time for printed output.



TRENDDATA; Defines variable names and time intervals for writing of data to the trend plot file.

NETWORKCOMPONENT TYPE=Node, TAG=NODE_INLET PARAMETERS LABEL=INLET, TYPE=CLOSED ENDNETWORKCOMPONENT

NETWORKCOMPONENT TYPE=Node, TAG=NODE_OUTLET PARAMETERS LABEL=OUTLET, GASFRACTION=-1, PRESSURE=50 bara, TEMPERATURE=32, TIME=0, TOTALWATERFRACTION=-1, TYPE=PRESSURE, FLUID=1 ENDNETWORKCOMPONENT

PHASESPLITNODE Boundary&Initialconditions 

PARAMETERS; A collection keyword for all phase split node keys. This keyword is hidden in the GUI.

Output

OLGA provides several output methods for plotting simulation results.

The following keywords are used for Output:



OUTPUTDATA; Defines variable names, position and time for printed output.



TRENDDATA; Defines variable names and time intervals for writing of data to the trend plot file.

SEPARATOR Boundary&Initialconditions 

PARAMETERS; A collection keyword for all separator keys. This keyword is hidden in the GUI.

Output

OLGA provides several output methods for plotting simulation results.

file://C:\Users\c108637\AppData\Local\Temp\~hh504A.htm

20/02/2012

Introduction

Page 14 of 19

The following keywords are used for Output:



OUTPUTDATA; Defines variable names, position and time for printed output.



TRENDDATA; Defines variable names and time intervals for writing of data to the trend plot file.

CONTROLLER Boundary&Initialconditions 

PARAMETERS; A collection keyword for all controller keys. This keyword is hidden in the GUI.

Output

OLGA provides several output methods for plotting simulation results.

The following keywords are used for Output:



OUTPUTDATA; Defines variable names, position and time for printed output.



TRENDDATA; Defines variable names and time intervals for writing of data to the trend plot file.

NETWORKCOMPONENT TYPE=ManualController, TAG=SetPoint-1 PARAMETERS SETPOINT=(2:0.1,2:0.2,0.3), TIME=(0,2000,2010,4000,4010) s, STROKETIME=0.0, MAXCHANGE=1.0 ENDNETWORKCOMPONENT

ANNULUS Initialconditions 

PARAMETERS; A collection keyword for all annulus keys. This keyword is hidden in the GUI.

AmbientConditions 

AMBIENTDATA; A collection keyword for specifying the Annulus ambient conditions.

AnnulusComponents 

COMPONENT; A component to place within the annulus definition.

Output 

PROFILEDATA; Defines variable names and time intervals for writing of data to the profile plot file.



TRENDDATA; Defines variable names and time intervals for writing of data to the trend plot file.

FLUIDBUNDLE Initialconditions 

PARAMETERS; A collection keyword for all fluid bundle keys. This keyword is hidden in the GUI.

AmbientConditions

file://C:\Users\c108637\AppData\Local\Temp\~hh504A.htm

20/02/2012

Introduction



Page 15 of 19

AMBIENTDATA; A collection keyword for specifying the fluid bundle ambient conditions.

BundleComponents 

COMPONENT; A component to place within the fluid bundle definition.

Output 

PROFILEDATA; Defines variable names and time intervals for writing of data to the profile plot file.



TRENDDATA; Defines variable names and time intervals for writing of data to the trend plot file.

SOLIDBUNDLE Initialconditions 

PARAMETERS; A collection keyword for all solid bundle keys. This keyword is hidden in the GUI.

AmbientConditions 

AMBIENTDATA; A collection keyword for specifying the solid bundle ambient conditions.

BundleComponents 

COMPONENT; A component to place within the solid bundle definition.

Output 

PROFILEDATA; Defines variable names and time intervals for writing of data to the profile plot file.



TRENDDATA; Defines variable names and time intervals for writing of data to the trend plot file.

Connections The CONNECTION keyword is used to couple network components, such as a node and a flowpath.

Each flowpath has an inlet and an outlet terminal that can be connected to a node terminal. Boundary nodes (i.e. CLOSED, MASSFLOW, PRESSURE) has one terminal, while internal nodes has an arbitrary number of terminals where flowpaths can be connected to.

CONNECTION TERMINALS = (FP_BRAN INLET, NODE_INLET FLOWTERM_1) CONNECTION TERMINALS = (FP_BRAN OUTLET, NODE_OUTLET FLOWTERM_1)

Separator and PhaseSplitNode has special handling of terminals.

The CONNECTION keyword is also used for coupling signal components.

CONNECTION TERMINALS = (FP_BRAN SOUR-1-1@INPSIG, SETPOINT-1 OUTSIG_1)

See also connecting the controllers for more information.

file://C:\Users\c108637\AppData\Local\Temp\~hh504A.htm

20/02/2012

Introduction

Page 16 of 19

Example file The keyword examples shown above can be combined to an OLGA .key file.

CASE PROJECT="OLGA Manual", TITLE="Example case", AUTHOR="SPT Group AS" INTEGRATION STARTTIME=0, ENDTIME=7200, DTSTART=0.1, MINDT=0.1, MAXDT=5 FILES PVTFILE=fluid.tab

MATERIAL LABEL=MAT-1, DENSITY=0.785E+04, CAPACITY=0.5E+03, CONDUCTIVITY=0.5E+02 WALL LABEL=WALL-1, THICKNESS=(0.9000E-02, 0.2E-01), MATERIAL=(MAT-1, MAT-1)

NETWORKCOMPONENT TYPE=FlowPath, TAG=FP_BRAN BRANCH LABEL=BRAN-1, GEOMETRY=GEOM-1, FLUID=1 GEOMETRY LABEL=GEOM-1 PIPE LABEL=PIPE-1, DIAMETER=0.12, ROUGHNESS=0.28E-04, NSEGMENT=4, LENGTH=0.4E+03, ELEVATION=0, WALL=WALL-1 HEATTRANSFER PIPE=ALL, HAMBIENT=6.5, TAMBIENT=6, HMININNERWALL=0.5E+03 SOURCE LABEL=SOUR-1-1, PIPE=1, SECTION=1, TIME=0, TEMPERATURE=62, GASFRACTION=-1, TOTALWATERFRACTION=-1, PRESSURE=70 bara, DIAMETER=0.12, SOURCETYPE=PRESSUREDRIVEN VALVE LABEL=CHOKE-1-1, PIPE=PIPE-1, SECTIONBOUNDARY=4, DIAMETER=0.12, CD=0.7, TIME=0, OPENING=1.0 TRENDDATA PIPE=1, SECTION=1, VARIABLE=(PT bara, TM, HOLHL, HOLWT) PROFILEDATA VARIABLE=(GT, GG, GL) ENDNETWORKCOMPONENT

NETWORKCOMPONENT TYPE=Node, TAG=NODE_INLET PARAMETERS LABEL=INLET, TYPE=CLOSED ENDNETWORKCOMPONENT

NETWORKCOMPONENT TYPE=Node, TAG=NODE_OUTLET PARAMETERS LABEL=OUTLET, GASFRACTION=-1, PRESSURE=50 bara, TEMPERATURE=32, TIME=0, TOTALWATERFRACTION=-1, TYPE=PRESSURE, FLUID=1 ENDNETWORKCOMPONENT

NETWORKCOMPONENT TYPE=ManualController, TAG=SetPoint-1 PARAMETERS SETPOINT=(2:0.1,2:0.2,0.3), TIME=(0,2000,2010,4000,4010) s, STROKETIME=0.0, MAXCHANGE=1.0 ENDNETWORKCOMPONENT

CONNECTION TERMINALS = (FP_BRAN INLET, NODE_INLET FLOWTERM_1) CONNECTION TERMINALS = (FP_BRAN OUTLET, NODE_OUTLET FLOWTERM_1)

CONNECTION TERMINALS = (FP_BRAN SOUR-1-1@INPSIG, SETPOINT-1 OUTSIG_1)

ENDCASE

file://C:\Users\c108637\AppData\Local\Temp\~hh504A.htm

20/02/2012

Introduction

Page 17 of 19

Simulation model An OLGA simulation is controlled by defining a set of data groups consisting of a keyword followed by a list of keys with appropriate values. Each data group can be seen as either a simulation object, information object, or administration object.

Logical sections

The different keywords are divided into logical sections: ·

CaseDefinition; administration objects for simulation control

·

Library; information objects referenced in one or more simulation objects

·

Controller; controller simulation objects

·

FlowComponent; network simulation objects

·

Boundary&InitialConditions; simulation objects for flow in and out of flowpath

·

ProcessEquipment; simulation objects for flow manipulation

·

ThermalComponent; thermal simulation objects

·

FA-models; administration objects for flow assurance models

·

Compositional; administration and information objects for component tracking

·

Output; administration objects for output generation

·

Drilling; drilling simulation object

·

OLGA Well; OLGA Well simulation object

Network model

A simulation model is then created by combining several simulation objects to form a simulation network, where information objects can be used within the simulation objects and the administration objects control various parts of the simulation. The simulation objects can again reference both information and administration objects.

The network objects can be of the following types: ·

Flowpath; the pipeline which the fluid mix flows through

·

Node; a boundary condition or connection point for 2 or more flowpaths

·

Separator; a special node model that can separate the fluid into single phases

·

Controller; objects that perform supervision and automatic adjustments of other parts of the simulation network

·

Thermal; objects for ambient heat conditions

The simulation model can handle a network of diverging and converging flowpaths. Each flow path consists of a sequence of pipes and each pipe is divided into sections (i.e. control volumes). These sections correspond to the spatial mesh discretization in the numerical model. The staggered spatial mesh applies flow variables (e.g. velocity, mass flow, flux) at section boundaries and volume variables (e.g. pressure, temperature, mass, volume fractions) as average values in the middle of the section.

The figure below shows a flow path divided into 5 sections.

file://C:\Users\c108637\AppData\Local\Temp\~hh504A.htm

20/02/2012

Introduction

Page 18 of 19

Each flowpath must start and end at a node, and there are currently three different kinds of nodes available: ·

Terminal; boundary node for specifying boundary conditions

·

Internal; for coupling flowpaths (e.g. split or merge)

·

Crossover; hybrid node for creating a closed-loop network

The figure below shows a simple simulation network consisting of three flowpaths and four nodes.

The flowpath is the main component in the simulation network, and can also contain other simulation objects (e.g. process equipment, not shown in the figure above).

It is also possible to describe the simulation model with a text file. See Input files for further descriptions.

OPC Server If asked for in the OLGA model, OLGA will run a server for OPC Data Access. OPC Data Access (OPC DA) is a specification for continuous communication of real-time data from a device to a receiving process. In the case of the OGLA OPC Server, the device is always the simulation of the current OLGA model, and the receiver could be a scheduler, a display or a simulator that implements a client for OPC DA. With the OPC Server, it is possible to interact with the running model. An OPC DA client connected to the OLGA OPC Server, may read output from the running simulation, and may also write values to the simulation. Through OPC, a process simulator or a user interface is allowed to connect to the OLGA simulation, and manipulate valve openings, well pressures, the setpoint of a PID controller or the massflow from a source. The OLGA OPC Server also have some special writeable items that serve as commands. By toggling SaveSnap or Stop, OLGA loads a snap file (i.e., a restart file) or stops, respectively. One uses the SERVEROPTIONS keyword to set up the OPC Server. Output is specified with the SERVERDATA keyword, which is very similar to TRENDDATA, and can be used with both trend and profile output variables. Input can be configured for certain subkeys in the keywords NODE, SOURCE, VALVE, WELL, and controllers; these subkeys form a set of parameters for the OLGA model being simulated.

file://C:\Users\c108637\AppData\Local\Temp\~hh504A.htm

20/02/2012

Introduction

Page 19 of 19

There are two modes for controlling OLGA's time-stepping: SIMULATOR and EXTERNAL. When the OLGA OPC Server is in SIMULATOR mode, one sets a speed relative to the computer's clock (say, ten times faster than real-time), and OLGA slows down its time-stepping process to try and keep this speed. When in EXTERNAL mode however, OLGA reads a time from the OPC Server, and steps forward until it reaches that time. The client updates the time on the server, and so the client takes control over the time-stepping. OPC DA relies on DCOM security, which can be difficult. A good understanding of DCOM security may be necessary to set up communication between a server at one computer and a client at another computer. Since OLGA owns the OPC Server, and removes it when it stops, it is not possible to set specific DCOM security for the OLGA OPC Server -- one has to rely on the general, default settings. It is usually quite easy to establish the connection when server and client is run on the same computer, by the same user, and both server and client is run as administrator. The SPT Group encourages all users who have access to an OPC client, to experiment with the OPC Server; please try the OPC sample cases. For all users it can be great fun to work interactively with a running OLGA model. For some users the ability to connect OLGA to a display or to another simulator can be great value. The OLGA OPC Server is available from version 6.2.6. See the document OLGA OPC Server User Guide, found with the OLGA documentation, for further reference.

file://C:\Users\c108637\AppData\Local\Temp\~hh504A.htm

20/02/2012