DYNAMIC MULTIPHASE FLOW SIMULATOR

OLGA 2015
Version 2015.1

Submodelling guide

OLGA Submodelling guide TN-341010017509/20

Page i

OLGA Submodelling guide TN-341010017509/20

Page ii

TABLE OF CONTENTS: OLGA Submodelling guide

1.

INTRODUCTION

2.

COUPLING TWO OLGA MODELS (WELL MODEL AND PIPELINE MODEL)

3.

MAKING THE WELL AND PIPELINE MODEL READY FOR SUBMODELLING

3.1 Connection data flow overview
3.2 Enable the OPC server on all models
3.3 Add minimum global input/output on OPC server
3.4 Add server output for N-FLOWOUT and S-FLOWIN
3.5 Modifying N-FLOWOUT and S-FLOWIN
3.5.1 Convert N-FLOWOUT to submodelling pressure node
3.5.2 Convert S-FLOWIN to submodelling source
3.6 Make input keys available on OPC server
3.7 Optimize OPC server configuration by using the IO Configuration Tool

3
3
5
5
6
6
6
6
6
7

4.

MAKING A SUBMODELLING CASE THAT SIMULATES BOTH THE WELL AND

PIPELINE MODEL
8
4.1 Making a new case with a Scheduler
8
4.2 Appending submodelling flow connections to the case with Scheduler
8

5.

RUNNING THE SUBMODELLING CASE

10

6.

SIMPLIFYING THE SUBMODELLING CASE

11

7.

SUBMODELLING CONFIGURATION TIPS

12

8.

HIERARCHICAL SUBMODELLING
8.1 Making the Hierarchic Submodelling case

13
13

9.

SIGNAL CONNECTION OVER SUBMODELS

9.1 How to add a signal connection over two submodels
9.2 Send a signal from a transmitter to a controller across submodels
9.3 Interpolation (on the SIGNALIN keyword)

14
14
15
15

OLGA Submodelling guide TN-341010017509/20

1.

Page 1

INTRODUCTION
This document is a guide for creating OLGA submodelling cases. OLGA submodelling
allows for greater flexibility when it comes to engineering of large scale models
covering a scope from well inflow to processing facilities. Typically, engineering of the
different parts of a production system is done in different engineering teams. Examples
of such teams are; well engineering, flow assurance and process engineering. When
modelling and simulation of these subsystems have been done by separate teams, the
submodelling and scheduling functionality will provide an efficient method for
integrating such models into larger models covering the full production system scope.
A great advantage with submodelling is that it may also lead to a faster execution of
the OLGA simulation compared to putting such models in one large OLGA case.
Example: You have a Well model and a Pipeline model. The Pipeline model has more
sections and a coarser grid (longer section lengths) than the Well model. This mean
that the Well model requires a smaller time-step than the Pipeline model (CFL-criteria).
By putting the models in one large OLGA model, all the sections in the Pipeline model
will be run at a small time step. This will slow down the simulation. When running
submodelling, the individual models run on separate time-steps allowing for faster
simulation execution of the total model scope.

OLGA Submodelling guide TN-341010017509/20

2.

Page 2

COUPLING TWO OLGA MODELS (WELL MODEL AND PIPELINE

MODEL)
In this example, we will be looking at coupling two OLGA models; a Well model and a
Pipeline model:

The flow from the Well model will be connected to the Pipeline model. This can be
done by establishing a submodelling flow connection between the Pressure node NFLOWOUT (in the Well model) and Source S-FLOWIN (in the Pipeline model), and
running 3 separate OLGA processes: Well model, Pipeline model and a Scheduler.
The Scheduler may also run the Well/Pipeline model as an internal submodel and
there will be only 2 processes.
The Scheduler is responsible for:
1.

Time synchronization between the Well and Pipeline model

2.

Transferring flow connection data between N-FLOWOUT and S-FLOWIN

The communication between the two OLGA models will be done through the OLGA
OPC server functionality. The next chapters will go into details about the setup of this
simulation configuration.

OLGA Submodelling guide TN-341010017509/20

3.

Page 3

MAKING THE WELL AND PIPELINE MODEL READY FOR

SUBMODELLING
The Well and the Pipeline model are standalone OLGA cases. They will be modified
slightly so they can communicate with each other.

3.1 Connection data flow overview

The below picture shows which data should be transferred between the Pressure node
N-FLOWOUT and Source S-FLOWIN.

Please note that the submodelling connection variables HT and HTEXT are new in
OLGA 2015.1.
FLOWOUT (NODE EXPOSED variables):
HTEXT

External time step limitation. If HTEXT is less than or equal to zero, external timestep
limitation is disabled.

PRESSURE

Boundary pressure. For internal nodes, this key can be used in conjunction with
INITIALCONDITIONS to specify the initial pressure.

TEMPERATURE

Temperature of the inflow mixture on boundary nodes. For internal nodes, this key can be
used in conjunction with INITIALCONDITIONS to specify the initial temperature.

GASCMASS

Normalized gas masses for each component (volume fractions multiplied by density)

DPDGG

Pressure - gas mass flow differential

OILCMASS

Normalized oil masses for each component (volume fractions multiplied by density)

DPDGLTHL

Pressure - oil mass flow differential

WATERCMASS

Normalized water masses for each component (volume fractions multiplied by density)

DPGLTWT

Pressure - water mass flow differential

OLGA Submodelling guide TN-341010017509/20

Page 4

FLOWOUT (NODE SERVERDATA variables):

HT

Time step

PTBOU

Pressure at boundary node

TMBOU

Fluid temperature at boundary node

CGGBOU

Gas mass flow for each component at boundary node

DGGDPB

Gas mass flow derivative w.r.t. pressure at boundary node

CGLTHLBOU

Oil mass flow for each component at boundary node

DGLTHLDPB

Oil mass flow derivative w.r.t. pressure at boundary node

CGLTWTBOU

Water mass flow for each component at boundary node

DGLTWTDPB

Water mass flow derivative w.r.t. pressure at boundary node

FLOWIN (SOURCE EXPOSED variables):

DGLTWTDP

Water mass flow - pressure differential

WATERCMASSFLOW

Water mass flow rate. For compositional tracking its the flow rate of the water phase
for each component.

DGLTHLDP

Oil mass flow - pressure differential

OILCMASSFLOW

Oil mass flow rate. For compositional tracking its the flow rate of the oil phase for
each component.

DGGDP

Gas mass flow - pressure differential

GASCMASSFLOW

Gas mass flow rate. For compositional tracking its the flow rate of the gas phase for
each component.

TEMPERATURE

Mixture temperature of the mass flow rate at all points in time specified.

PRESSURE

Upstream pressure for a positive source (flow into pipeline). Downstream pressure
for a negative source. Required key if pressure driven source.

HTEXT

External time step limitation. If HTEXT is less than or equal to zero, external timestep
limitation is disabled.

FLOWIN (SOURCE SERVERDATA variables):

DPDGLTWTS

Pressure derivative w.r.t. water mass flow

CMLTWT

Mass in water phase. For compositional tracking its the mass of the water phase
for each component.

DPDGLTHLS

Pressure derivative w.r.t. oil mass flow

CMLTHL

Mass in oil phase. For compositional tracking its the mass of the oil phase for
each component.

DPDGGS

Pressure derivative w.r.t. gas mass flow

CMG

Mass in gas phase. For compositional tracking its the mass of the gas phase for
each component.

OLGA Submodelling guide TN-341010017509/20

TM

Fluid temperature

PT

Pressure

HT

Time step

Page 5

To make the submodel connection, it is necessary to add SERVERDATA keywords for

the required output variables and edit the EXPOSE key for NODE and SOURCE to
expose the required input keys on the OPC server.

3.2 Enable the OPC server on all models

The OPC server is enabled by adding the SERVEROPTIONS keyword to the Well and
Pipeline models. Note that each SERVERNAME has to be unique. The OPC servers
will automatically be started when the OLGA cases are run.
Well case:

Pipeline case:

3.3 Add minimum global input/output on OPC server

For both the Well and Pipeline case, this should be added:
EXPOSE=SIMULATIONSPEED (on INTEGRATION keyword)
VARIABLE=(SPEED, TIME, HT, SIMTIME, MAXSPEED) and DTPLOT=0 s (in a
global SERVERDATA keyword)
When running the two cases the SERVERDATA variables will be available as readonly tags on the OPC servers. The EXPOSE keys will be writable tags on the OPC
server.
DTPLOT=0 means that the output will be pushed to the OPC server every simulator
time step.
You can look at the OPC tags using any OPC client (e.g. OLGA Namespace Explorer).

OLGA Submodelling guide TN-341010017509/20

Page 6

3.4 Add server output for N-FLOWOUT and S-FLOWIN

In the Well case add the following variables using the four SERVERDATA keywords for
node N-FLOWOUT:
VARIABLE = CGGBOU, CGLTHLBOU and CGLTWTBOU
VARIABLE = PTBOU and TMBOU
VARIABLE = HT
VARIABLE = DGGDPB, DGLTHLDPB and DGLTWTDPB
In the Pipeline case add the following variables using four SERVERDATA keywords for
source S-FLOWIN:
VARIABLE = DPDGGS, DPDGLTHLS and DPDGLTWTS
VARIABLE = PT and TM
VARIABLE=HT
VARIABLE = CMG, CMLTHL and CMLTWT

3.5 Modifying N-FLOWOUT and S-FLOWIN

3.5.1 Convert N-FLOWOUT to submodelling pressure node
The pressure node, N-FLOWOUT, typically use keys like GASFRACTION,
WATERFRACTION. To use submodelling, you must change so that GASCMASS,
OILCMASS and WATERCMASS are used instead. These keys are normalized masses
with unit kg/m3. A good choice is to use the server output from the source S-FLOWIN:
CMG, CMLTHL and CMLTWT as input to GASCMASS, OILCMASS and
WATERCMASS.
3.5.2 Convert S-FLOWIN to submodelling source
The source, S-FLOWIN, typically use keys like MASSFLOW and GASFRACTION. To
use submodelling, you must change so that GASCMASSFLOW, OILCMASSFLOW and
WATERCMASSFLOW are used instead. A good choice is to use the server output
from the node N-FLOWOUT: CGGBOU, CGLTHLBOU and CGLTWTBOU as input to
GASCMASSFLOW, OILCMASSFLOW and WATERCMASSFLOW.

3.6 Make input keys available on OPC server

In the Well case, the EXPOSE key on the node, N-FLOWOUT, must include the
following variables: PRESSURE, TEMPERATURE, GASCMASS, OILCMASS,
WATERCMASS, DPDGG, DPDGLTHL, DPDGLTWT and HTEXT.
In the Pipeline case, the EXPOSE key on the source, S-FLOWIN, must include the
following variables: PRESSURE, TEMPERATURE, GASCMASSFLOW,
OILCMASSFLOW, WATERCMASSFLOW, DGGDP, DGLTHLDP, DGLTWTDP and
HTEXT.

OLGA Submodelling guide TN-341010017509/20

Page 7

Note that you can expose more variables on the node and source if needed for other
purposes.

3.7 Optimize OPC server configuration by using the IO Configuration

Tool
The steps for configuring the SERVERDATA and EXPOSE keys required for
connection flow between submodels described in the section above can be done
efficiently by using the IO Configuration Tool.
Please refer to the OLGA GUI manual for further help on using the IO Configuration
Tool.

OLGA Submodelling guide TN-341010017509/20

4.

Page 8

MAKING A SUBMODELLING CASE THAT SIMULATES BOTH THE

WELL AND PIPELINE MODEL
In the chapter Making the well and pipeline model ready for submodelling, the Well and
Pipeline cases were made ready for submodelling. They are still standalone OLGA
cases and can be run separately.
When the cases run, some input and output are available on the OPC servers, but
there is no communication between the models. This chapter describes how to make a
case that simulates both the Well and the Pipeline cases together as a flow network.

4.1 Making a new case with a Scheduler

From a new empty OLGA case, called ScheduleWellAndPipeline, the first step is to
add a SCHEDULER and a SERVEROPTIONS keyword.
The SCHEDULER keyword needs INITIALSTATE = RUNNING and MAJORTIMESTEP
= 10 s.
The key MAJORTIMESTEP is the initial synchronization interval. A more detailed
description is given in the OLGA user manual.
Keys under the added SERVEROPTIONS keyword could be equal to the values shown
as follow:

4.2 Appending submodelling flow connections to the case with

Scheduler
In the ScheduleWellAndPipeline case, the following steps should be carried out to set
the flow connection between the Well and Pipeline case:
1. Add a SUBMODEL network component, SUBMODEL_WELL, with CASEFILE =
Well.opi.

OLGA Submodelling guide TN-341010017509/20

Page 9

2. Add a SUBMODEL network component, SUBMODEL_PIPELINE, with CASEFILE

= Pipeline.opi.

3. Add a FLOWOUT keyword under SUBMODEL_WELL with NODE = N-FLOWOUT.

4.

Add a FLOWIN keyword under SUBMODEL_PIPELINE with SOURCE = SFLOWIN.

5. Connect the FLOWOUT to the FLOWIN using the Submodel Connections window
available from the Tools menu in the OLGA GUI.

Note: Be sure to get the labels of the SOURCE and NODE correct, because there is no verification
across different OLGA cases.

OLGA Submodelling guide TN-341010017509/20

5.

Page 10

RUNNING THE SUBMODELLING CASE

When running the submodelling OLGA case ScheduleWellAndPipeline, the Well and
Pipeline case will automatically start up. Then the scheduler in
ScheduleWellAndPipeline transfers data between node N-FLOWOUT and source SFLOWIN. The scheduler also ensures that the Well and Pipeline simulation follows the
same simulation speed.
Simulation results are available at the OPC servers and at the trend and profile output
of the Well and Pipeline simulation.

OLGA Submodelling guide TN-341010017509/20

6.

Page 11

SIMPLIFYING THE SUBMODELLING CASE

The three OLGA cases (.opi) for the submodelling example are shown below

To simplify this setup, the SCHEDULER, the SUBMODEL network components

(SUBMODEL_WELL and SUBMODEL_PIPELINE) and the SUBMODEL connection
can be moved from ScheduleWellAndPipeline.opi to Pipeline.opi. Then, there are now
two OLGA cases (instead of 3):

The Pipeline model is now an internal submodel. This means that that the LOCATION
key on the SUBMODEL SUBMODEL_PIPELINE must be changed to from LOCAL to
INTERNAL:

If you would like to retain the flexibility to run the Pipeline model and the Well model independently, the
Scheduler should be configured as a separate case as shown initially.

OLGA Submodelling guide TN-341010017509/20

7.

Page 12

SUBMODELLING CONFIGURATION TIPS

Running a submodelling case involves more than one OLGA case. The rule-check in the
OLGA GUI is only for single OLGA cases. To fix configuration errors when running
submodelling cases, the OLGA console window outputs have to be investigated. Below is a
list of the most common errors and how to fix them.
Verification errors for submodels.
Check that all submodels are possible to run standalone.
The scheduler complains about missing global items on the submodel.
Add global input and output on the submodel (see chapter 3.3).

The scheduler complains about missing node/source items on the submodel.

Check that the NODE given in FLOWOUT keyword match node label in the submodel
case.
Check that the SOURCE given in FLOWIN keyword match source label in the
submodel case.
Add server output for the submodelling node/source (see chapter 3.4).
Add server input for the submodelling node/source (see chapter 3.6).

The submodel console windows close so fast that the user does not see the error.
Set DEBUGOPTIONS=KEEP_CONSOLE_WINDOW on the submodels in the
Scheduler case.
One of the submodels crash directly after startup (Not when run standalone).
Steady state are not implemented for submodelling cases, so it is more difficult to set
good startup conditions. Possible to try different initial conditions or boundary
conditions.
Set the initial synchronization interval (MAJORTIMESTEP on SCHEDULER keyword)
to a low value (e.g. 0.1 seconds).
The Scheduler case made with OLGA2014 does not run with OLGA2015.1
The submodelling connection variables HT and HTEXT are new in OLGA2015.1.
HTEXT has to be exposed on all submodelling sources/nodes. All submodelling
sources/nodes has to have SERVERDATA keyword with variable HT.
The submodelling results look completely wrong.
For a submodel connection the units must match. The unit on the exposed key has to
match the unit used on the connected output variable.

OLGA Submodelling guide TN-341010017509/20

8.

Page 13

HIERARCHICAL SUBMODELLING
In this example, we will consider a system where the flow from one transport line:
Pipeline-1 and the flow from a well: Well-2 are joined into another transport line:
Pipeline-2:

In order to build the submodelling case as a hierarchical system, two schedulers are
required. The first scheduler will control connection between Well-1 and Pipeline-1
submodels and the second one will handle connection among Pipeline-2, Pipeline-1
and Well-1 submodels.
When two or more schedulers are required to run a submodelling case, you should
start the scheduler contained in the submodel located at the top level of the system (in
this case the scheduler in Pipeline-2 submodel), in which the whole flow of the system
converges.

8.1 Making the Hierarchic Submodelling case

Using the technique explained in chapter 0 recursively, the system can be modelled by
the following submodelling case:

The communication between Well-1 and Pipeline-1 is the same as in the simplified
submodelling case used in previous chapters and is handled by Scheduler-1.
Scheduler-2 handles the communication between Pipeline-1 and Pipeline-2, and
between Well-2 and Pipeline-2. Both Pipeline-1 and Well-2 will have a submodelling
pressure node at the end of the pipelines. Pipeline-2 will have two submodelling
sources. Due to stability reasons, the submodelling sources should not be located in
the same section.
Scheduler-2 will have 3 submodels. Pipeline-1 and Well-2 will be LOCAL submodels
while Pipeline-2 will be an INTERNAL submodel. There will be a submodel flow
connection between the submodelling pressure node at Pipeline-1 and the first
submodelling source at Pipeline-2. Another submodelling flow connection will exist
between the submodelling pressure node at Well-2 and the second submodelling
source at Pipeline-2.

OLGA Submodelling guide TN-341010017509/20

9.

Page 14

SIGNAL CONNECTION OVER SUBMODELS

Signal connections between submodels are suitable for reuse of controller logic across
submodel or signal communication between submodels
An example is a case with manual controller that gives ambient air temperature. This
controller value can be transferred to the submodels and used at the appropriate
places. If you change the value of the manual controller in a server simulation, the
change will propagate down to the submodels
.

9.1 How to add a signal connection over two submodels

Assuming two very simple cases: SubmodelSend and SubmodelReceive, both
containing a manual controller, it is desired to use the output signal of the controller
one as input to the controller two. The figure below shows the needed data connection.

To make the signal connection over the two submodels, the following steps should be
carried out:
1. Enable the OPC server for both SubmodelSend and SubmodelReceive cases
(see chapter 3.2).
2. Add minimum global input/output on OPC server for both cases (see chapter
3.3).
3. In SubmodelSend, add a SERVERDATA keyword containing the output variable
CONTR on MANUALCONTROLLER_1, then add a second SERVERDATA
keyword containing HT as output variable on the same controller.
4. In SubmodelReceive, expose the keys SETPOINT and HTEXT on
MANUALCONTROLLER_2.
5. Make a new scheduler case and name it SignalScheduler (see chapter 4.1).
6. In the scheduler case, add two new SUBMODEL network components which
references to the SubmodelSend and SubmodelReceive cases respectively
(see chapter 4.2).
7. Add a SIGNALOUT keyword under the SUBMODEL network component that
refers to SubmodelSend case and set TYPE = CONTROLLER, CONTROLLER
= MANUALCONTROLLER_1 and VARIABLE = CONTR.
8. Add a SIGNALIN keyword under the SUBMODEL network component that refers
to SubmodelReceive case and set MANUALCONTROLLER =
MANUALCONTROLLER_2.

OLGA Submodelling guide TN-341010017509/20

Page 15

9. Connect the SIGNALOUT to the SIGNALIN using the Submodel Connections

dialogue.

9.2 Send a signal from a transmitter to a controller across submodels

To make a connection between a transmitter in a case that sends the signal and a
controller in a case that receives it, you should:
1. Add a SERVERDATA keyword for the OUTPUT variable at the transmitter in
the case that sends the signal.
2. Under the SIGNALOUT keyword in the scheduler case, select TYPE =
TRANSMITTER and set TRANSMITTER equal to the label of transmitter
sending the signal.
3. Settings on the SIGNALIN keyword in the scheduler case are made in the
same way as in the previous chapter.

9.3 Interpolation (on the SIGNALIN keyword)

The scheduler holds two values for each output signal: the old value and the new
value with correct corresponding timestamps. When a submodel requests an input
signal, the return value is interpolated in time between the old and the new value. The
time to interpolate is when the submodel requests the input signal. Two types of
interpolation are possible:
LINEAR: Linear interpolation is done. If time to interpolate is less than the time stamp
for the old value, the old value is returned. If time to interpolate is greater than the time
stamp for the current value, the current value is returned. For values in between, a
linear interpolation is done. This type of interpolation is sometimes referred to as First
Order Hold.
STEPWISE: No interpolation is done. If time to interpolate is less than the time stamp
for the current value, the old value is returned. If not, the current value is returned. This
type of interpolation is sometimes referred to as Zero Order Hold.

Linear interpolation is the recommended option. No interpolation should be considered

if it is important for the simulation that
1. The controller should deliver discrete output values.
2. Change in the controller value should not be applied before the controller value
actually changes.

The interpolation is selected using the INTERPOLATION key in the SIGNALIN

keyword.