Resolve Complete

Petroleum Experts
User Manual
IPM
RESOLVE
Version 4.5
December 2010
RESOLVE
IPM - Controller OVERVIEW
by Petroleum Experts Ltd.
RESOLVE
December 2010
Table of Contents
0
Part 1 Technical Overview
1 RESOLVE:
...................................................................................................................................
An Introduction
2
2 RESOLVE:
...................................................................................................................................
How does it work?
5
3 RESOLVE:
...................................................................................................................................
Summary of Capabilities
7
4 What's...................................................................................................................................
New in RESOLVE?
12
5 Linux ...................................................................................................................................
distribution
19
6 IT Requirements
................................................................................................................................... 20
Part 2 User Guide
24
1 What is
...................................................................................................................................
in this guide?
24
2 Contacting
...................................................................................................................................
Petroleum Experts
25
3 Introduction
................................................................................................................................... 29
How to Use This
..........................................................................................................................................................
Guide?
29
RESOLVE Glossary
..........................................................................................................................................................
of Term s
30
4 Getting
...................................................................................................................................
Started with RESOLVE
31
Basic Model Setup
..........................................................................................................................................................
- Guidelines
31
The RESOLVE..........................................................................................................................................................
User Interface
35
User Interface
......................................................................................................................................................... 35
Shortcut Icons
.........................................................................................................................................................
Toolbar
37
Main Display
.........................................................................................................................................................
Window
41
HelpView er
.........................................................................................................................................................
Window
50
System Window
......................................................................................................................................................... 50
5 "File" ...................................................................................................................................
Menu
51
"File" Section .......................................................................................................................................................... 51
RESOLVE Archives
.......................................................................................................................................................... 53
File Preferences
.......................................................................................................................................................... 55
6 "Drivers"
...................................................................................................................................
Menu
57
"Drivers" Section
.......................................................................................................................................................... 57
RESOLVE Architecture
.......................................................................................................................................................... 57
Driver Registration
.......................................................................................................................................................... 58
7 "Wizards"
...................................................................................................................................
Menu
62
"Wizards" Section
.......................................................................................................................................................... 62
IT Setup Wizards
.......................................................................................................................................................... 64
DCOMUTIL.EXE
......................................................................................................................................................... 64
ECLCONFIG.EXE
......................................................................................................................................................... 64
Engineering Wizards
.......................................................................................................................................................... 64
Voidage Replacement
......................................................................................................................................................... 64
Voidage replacement
.........................................................................................................................................
- Method
64
Voidage replacement
.........................................................................................................................................
- Setup
66
Voidage replacement
.........................................................................................................................................
- Script
69
Voidage replacement
.........................................................................................................................................
script - Declarations
70
Voidage replacement
.........................................................................................................................................
script - PreSolve
71
December 2010
Contents
II
Voidage replacement
.........................................................................................................................................
script - PostSolve
74
Voidage replacement
.........................................................................................................................................
script - StartOfTimestep
75
Drilling Queue
......................................................................................................................................................... 76
OpenServer
.........................................................................................................................................................
w izards
82
Perform GAP
.........................................................................................................................................................
- Eclipse Validation
84
GIRO Optimiser
.........................................................................................................................................................
Performance
86
Execute OpenServer
.........................................................................................................................................................
Statement
89
8 "Options"
...................................................................................................................................
Menu
90
System Options
.......................................................................................................................................................... 90
Lum ping / Delum
..........................................................................................................................................................
ping
93
PVT Within.........................................................................................................................................................
RESOLVE: Importance of PVT Consistency in Full-Field Models
94
Recommendations
.........................................................................................................................................................
for PVT Characterisations
100
Lumping /.........................................................................................................................................................
Delumping Technical Overview
101
Compositional
.........................................................................................................................................................
PVT Models Description
102
More Lumping
......................................................................................................................................................... 106
Lumping /.........................................................................................................................................................
Delumping Module Fluid Characterisations
110
Process Independence
..........................................................................................................................................................
in Resolve m odels
113
Introduction
......................................................................................................................................................... 113
Setup of Process
.........................................................................................................................................................
Independent Models
115
Further considerations
......................................................................................................................................................... 116
9 "Edit ...................................................................................................................................
System" Menu
117
"Edit System..........................................................................................................................................................
" Menu
117
Connection
.........................................................................................................................................................
Wizard
119
Target Connections
......................................................................................................................................................... 121
Set System
.........................................................................................................................................................
State
126
Setting up RESOLVE
..........................................................................................................................................................
Model - Specific Elem ents for external applications
127
Connection
.........................................................................................................................................................
to GAP - GAP driver Details
128
GAP Driver Configuration
......................................................................................................................................... 128
Loading and Editing
.........................................................................................................................................
a GAP Case
129
Loading and Editing
...................................................................................................................................
a GAP Case : Overview
129
GAP Driver : General
...................................................................................................................................
Section
131
GAP Driver : Sources
...................................................................................................................................
and Sinks Section
133
GAP Driver : Wells
...................................................................................................................................
/ Inflow s IPR Section
136
GAP Driver : Compositional
...................................................................................................................................
Section
138
Publishing GAP variables
......................................................................................................................................... 140
Optimisation
......................................................................................................................................... 147
Other functions ......................................................................................................................................... 152
Setting up the GAP
.........................................................................................................................................
Case : Additional Information
154
Setting up a case
...................................................................................................................................
in GAP
154
Source/Sink items
...................................................................................................................................
in GAP
155
Connection
.........................................................................................................................................................
to REVEAL - REVEAL driver Details
156
REVEAL Driver Configuration
......................................................................................................................................... 156
Loading and editing
.........................................................................................................................................
a REVEAL case
157
Publishing Reveal
.........................................................................................................................................
variables
164
Other functions ......................................................................................................................................... 167
Setting up a case
.........................................................................................................................................
in Reveal : Additional Information
169
Connection
.........................................................................................................................................................
to IPM-OS - IPM-OS driver details
170
IPM-OS driver configuration
......................................................................................................................................... 170
Loading and editing
.........................................................................................................................................
an IPM-OS case
172
Publishing IPM-OS
.........................................................................................................................................
variables
175
Other functions ......................................................................................................................................... 177
Setting up a case
.........................................................................................................................................
w ith IPM-OS: Additional Information
178
Connection
.........................................................................................................................................................
to Eclipse - Eclipse driver Details
179
RESOLVE User's Manual
II
III
RESOLVE
December 2010
Eclipse pre-requisites
......................................................................................................................................... 179
The use of MPI to
.........................................................................................................................................
connect to Eclipse
179
Setting up MPI ......................................................................................................................................... 180
Setting up Verari
...................................................................................................................................
MPI
181
Setting up Intel ...................................................................................................................................
MPI
186
Setting up the Linux
...................................................................................................................................
MPI softw are
191
Driver Configuration
......................................................................................................................................... 191
Running Eclipse...................................................................................................................................
on Citrix
194
Loading and Editing
.........................................................................................................................................
an Eclipse case : Overview
195
Eclipse Driver: Case
.........................................................................................................................................
Details Section: Overview
197
.........................................................................................................................................
Details Section: Parallel options
199
Eclipse Driver: Case Details Section: Loading Grid Topography Overview
......................................................................................................................................... 201
.........................................................................................................................................
Details Section: Loading Grid Topography - Step 1
202
.........................................................................................................................................
203
.........................................................................................................................................
205
.........................................................................................................................................
206
.........................................................................................................................................
210
.........................................................................................................................................
212
Eclipse Driver: Control
.........................................................................................................................................
Data Section
214
.........................................................................................................................................
Data Section: IPR Generation Options
217
.........................................................................................................................................
Data Section: Group Controls
222
Eclipse Driver: Miscellaneous
.........................................................................................................................................
Section
224
Eclipse Driver: Advanced
.........................................................................................................................................
Options Section
227
Publishing Eclipse
.........................................................................................................................................
variables
231
Other functions ......................................................................................................................................... 234
'Best practice' for
.........................................................................................................................................
Eclipse coupling
236
Further Technical
.........................................................................................................................................
Elements on the Eclipse - RESOLVE link
239
PVM legacy notes
......................................................................................................................................... 241
Connection
.........................................................................................................................................................
to IMEX/GEM - IMEX/GEM driver Details
245
IMEX/GEM Overview
......................................................................................................................................... 245
IMEX/GEM case .........................................................................................................................................
setup guidelines
245
Loading and Editing
.........................................................................................................................................
an IMEX/GEM case
249
IPR models
................................................................................................................................... 252
IMEX/GEM driver.........................................................................................................................................
configuration
254
Connection
.........................................................................................................................................................
to PSim - PSim driver Details
255
PSim Overview ......................................................................................................................................... 255
PSim case setup.........................................................................................................................................
guidelines
256
Introduction ................................................................................................................................... 256
Preparing a PSim
...................................................................................................................................
simulation deck
256
Driver configuration
................................................................................................................................... 260
Setup and configuration
...................................................................................................................................
of mpich
261
PSim model setup
......................................................................................................................................... 263
IPR models
................................................................................................................................... 266
Well controls ................................................................................................................................... 268
Advanced options
................................................................................................................................... 269
Other functions ......................................................................................................................................... 270
Further Techical.........................................................................................................................................
Elements regarding the PSim / GAP connection
270
Connection
.........................................................................................................................................................
to Hysys - Hysys driver Details
273
Use of the Hysys
.........................................................................................................................................
driver
273
Configuring the Hysys
.........................................................................................................................................
driver
275
Loading and editing
.........................................................................................................................................
a Hysys case
276
Publishing Hysys.........................................................................................................................................
variables
279
Other functions ......................................................................................................................................... 282
December 2010
Contents
IV
Optimisation ................................................................................................................................... 284

Output variables
................................................................................................................................... 288
Scheduling
................................................................................................................................... 288
Object brow ser................................................................................................................................... 290
Setting up a case
.........................................................................................................................................
in Hysys : Additional Information
293
Connection
.........................................................................................................................................................
to UniSim - UniSim driver Details
294
Use of the UniSim
.........................................................................................................................................
driver
294
Configuring the UniSim
.........................................................................................................................................
driver
295
Loading and editing
.........................................................................................................................................
a UniSim case
296
Publishing UniSim
.........................................................................................................................................
variables
300
Other functions ......................................................................................................................................... 303
Optimisation ................................................................................................................................... 305
Output variables
................................................................................................................................... 309
Scheduling
................................................................................................................................... 309
Object brow ser................................................................................................................................... 311
Setting up a case
.........................................................................................................................................
in UniSim : Additional Information
314
Connection
.........................................................................................................................................................
to Excel - Excel driver Details
315
Excel Driver : Overview
......................................................................................................................................... 315
Loading and Editing
.........................................................................................................................................
a Case
315
Loading and Editing
...................................................................................................................................
an Excel case : Overview
315
Excel Driver : Excel
...................................................................................................................................
Details
316
Excel Driver : Input
...................................................................................................................................
Data
319
Excel Driver : Output
...................................................................................................................................
Data
321
Excel Driver : Macros
................................................................................................................................... 324
Publishing Excel.........................................................................................................................................
variables
325
Optimisation
......................................................................................................................................... 328
Connections..........................................................................................................................................................
in RESOLVE: Further Details
331
Connection
.........................................................................................................................................................
Rules
331
Models and
.........................................................................................................................................................
Loops
333
Composition
.........................................................................................................................................................
Tables
334
Direct Connections
.........................................................................................................................................................
betw een instances
336
10 "Module
...................................................................................................................................
Variables" Menu
341
"Module Variables"
..........................................................................................................................................................
Menu
342
Import Application
.........................................................................................................................................................
Variables
342
Transfer optimisation/imported
.........................................................................................................................................................
variables
345
11 "Program
...................................................................................................................................
Functions" Menu
347
"Program Functions"
..........................................................................................................................................................
Menu
347
12 "Schedule"
...................................................................................................................................
Menu
348
"Schedule" Menu
.......................................................................................................................................................... 348
Schedule Setup
..........................................................................................................................................................
Workflow
349
Tim estep Control
.......................................................................................................................................................... 351
Timestep .........................................................................................................................................................
Control Setup
351
Adaptive .........................................................................................................................................................
Timestep
354
WAG
.......................................................................................................................................................... 356
Event Managem
..........................................................................................................................................................
ent
361
Event Management
.........................................................................................................................................................
Overview
361
Event driven
.........................................................................................................................................................
scheduling
363
Event Driven Scheduling
.........................................................................................................................................
Overview
363
Event actions ......................................................................................................................................... 366
Ranking of event
...................................................................................................................................
actions
368
Event driven scheduling
.........................................................................................................................................
- example
370
Scenario Manager
.......................................................................................................................................................... 376
Scenario .........................................................................................................................................................
Manager Overview
376
IV
RESOLVE
December 2010
Adding a .........................................................................................................................................................
scenario
378
Editing a scenario
......................................................................................................................................................... 378
Deleting a.........................................................................................................................................................
scenario
379
Scenario .........................................................................................................................................................
examples
379
Basic
......................................................................................................................................... 379
Changing global.........................................................................................................................................
model data (e.g. model files)
381
Changing a script
......................................................................................................................................... 383
13 "Optimisation"
...................................................................................................................................
menu
385
RESOLVE Optim
..........................................................................................................................................................
isation : Overview
385
RESOLVE Optim
..........................................................................................................................................................
isation: Sequential Linear Program m ing
387
Troubleshooting
......................................................................................................................................................... 387
RESOLVE Optim
..........................................................................................................................................................
isation: GIRO
388
Introduction
......................................................................................................................................................... 388
Formulating
.........................................................................................................................................................
an Integer Problem in RESOLVE
392
Example1:.........................................................................................................................................................
Well Routing Problem
393
Example2:.........................................................................................................................................................
Ful Field Routing Optimisation
418
Example3.........................................................................................................................................................
- Compressor prediction optimisation
438
How to avoid optimising
.........................................................................................................................................
at each time step
451
Main Menu : ..........................................................................................................................................................
Optim isation Section
454
Optim isation..........................................................................................................................................................
setup
455
Optim isation:
..........................................................................................................................................................
m ultiple optim isers
459
Optimisation
.........................................................................................................................................................
summary
463
Edit Optimiser Control
.........................................................................................................................................
Variables
466
User optim isers
.......................................................................................................................................................... 468
14 "Scripting"
...................................................................................................................................
Section
468
Scripting : An..........................................................................................................................................................
Introduction
468
"Script" Section
.......................................................................................................................................................... 471
Scripting: IPM5
..........................................................................................................................................................
vs IPM4
472
15 Running
...................................................................................................................................
the RESOLVE Model
474
"Run Menu" .......................................................................................................................................................... 474
Calculation Order
.......................................................................................................................................................... 476
Edit Loops .......................................................................................................................................................... 479
Running Multiple
..........................................................................................................................................................
Scenarios
482
Running Scenarios
.........................................................................................................................................................
on a Cluster: Overview
484
Window ed
.........................................................................................................................................................
and non-w indow ed modes
484
Clustering.........................................................................................................................................................
basics
486
Running scenarios
.........................................................................................................................................................
on a Window s cluster
489
Use of LSF Cluster
......................................................................................................................................... 489
Overview
................................................................................................................................... 489
Cluster view ing...................................................................................................................................
and configuration
490
Cluster View ing................................................................................................................................... 490
Cluster Configuration
................................................................................................................................... 492
Manual Cluster ...................................................................................................................................
Configuration
492
Automation of the
...................................................................................................................................
cluster configuration
494
Running the scenarios
...................................................................................................................................
in batch
496
Monitoring the scenario
...................................................................................................................................
runs
499
Aborting the scenario
...................................................................................................................................
runs
501
Cluster administrative
...................................................................................................................................
tasks
501
Cluster troubleshooting
................................................................................................................................... 504
Use of PXCluster
......................................................................................................................................... 506
Overview
................................................................................................................................... 506
Architecture ................................................................................................................................... 506
Installation and ...................................................................................................................................
Maintenance
508
December 2010
Contents
VI
Installation pre-requisites
................................................................................................................................... 508
PxCluster setup...................................................................................................................................
utility
508
Troubleshooting................................................................................................................................... 512
PxCluster test utility
................................................................................................................................... 512
Adding/removing
...................................................................................................................................
nodes
514
Editing the configuration
...................................................................................................................................
file
514
Installing new IPM
...................................................................................................................................
builds
515
Running scenarios
.........................................................................................................................................................
on a mixed cluster
515
16 Analysing
...................................................................................................................................
and Reporting the Results
517
"Results" Section
.......................................................................................................................................................... 517
Tables of Results
.......................................................................................................................................................... 519
Plotting the Results
.......................................................................................................................................................... 520
Optim isation..........................................................................................................................................................
Results
525
Loop Results.......................................................................................................................................................... 528
17 "Window"
...................................................................................................................................
Section
529
18 "View"
...................................................................................................................................
Section
530
19 Appendix
................................................................................................................................... 530
Further Technical
..........................................................................................................................................................
Elem ents - OpenServer
530
Overview......................................................................................................................................................... 530
Top Level.........................................................................................................................................................
Variables
532
Top Level Variables
.........................................................................................................................................
: Overview
532
Module variables......................................................................................................................................... 534
Module Variables
...................................................................................................................................
: Overview
534
Module internal...................................................................................................................................
driver variables
536
GAP internal driver
...................................................................................................................................
variables
537
Reveal internal ...................................................................................................................................
driver variables
540
Hysys internal driver
...................................................................................................................................
variables
540
UniSim internal ...................................................................................................................................
driver variables
541
Eclipse internal...................................................................................................................................
driver variables
543
Excel internal driver
...................................................................................................................................
variables
551
IMEX/GEM internal
...................................................................................................................................
driver variables
552
PSim internal driver
...................................................................................................................................
variables
560
Module Optimisation
...................................................................................................................................
variables
562
SrcSnk variables
................................................................................................................................... 564
PubVar variables
................................................................................................................................... 565
Equip variables................................................................................................................................... 566
Driver variables ......................................................................................................................................... 567
ModLink variables
......................................................................................................................................... 568
Schedule variables
......................................................................................................................................... 568
Connection variables
......................................................................................................................................... 570
Properties variables
......................................................................................................................................... 570
Optimiser parameter
.........................................................................................................................................
variables
571
Optimiser schedule
.........................................................................................................................................
variables
572
Event driven schedule
.........................................................................................................................................
variables
572
Event driven schedule
...................................................................................................................................
action variables
574
Scenario manager
.........................................................................................................................................
variables
576
Variable link variables
......................................................................................................................................... 577
Commands
......................................................................................................................................................... 578
Sample macros
......................................................................................................................................................... 582
Creating a Resolve
..........................................................................................................................................................
optim iser in Excel
582
How to create
.........................................................................................................................................................
a RESOLVE optimiser in Excel
582
Know n issues
.......................................................................................................................................................... 584
Know n Issues
......................................................................................................................................................... 584
VI
VII
RESOLVE
December 2010
Further Technical
..........................................................................................................................................................
Elem ents for Distributed Applications
584
Distributed
.........................................................................................................................................................
Applications
584
Running IPM
.........................................................................................................................................................
instances on a remote PC
584
Running Hysys,
.........................................................................................................................................................
UniSimDesign, and Excel on a remote server
597
Running an
.........................................................................................................................................................
Eclipse instance on a remote computer
598
RESOLVE.........................................................................................................................................................
controlled remote Eclipse runs on a Linux cluster
599
History
......................................................................................................................................... 600
Overview
......................................................................................................................................... 600
Pre-requisites ......................................................................................................................................... 601
Installation
......................................................................................................................................... 602
Setting up the Linux
.........................................................................................................................................
(client) side - running the daemons
614
MPICH
................................................................................................................................... 615
Scali MPI (SMC)................................................................................................................................... 616
Intel MPI
................................................................................................................................... 616
LSF daemons ................................................................................................................................... 618
Administering the
.........................................................................................................................................
daemons
619
Troubleshooting......................................................................................................................................... 622
How the softw are
.........................................................................................................................................
w orks
625
Setting up the Window
.........................................................................................................................................
s (Resolve) side
628
Upgrading the Linux
.........................................................................................................................................
softw are
629
Running IMEX/GEM
.........................................................................................................................................................
on a remote computer
630
Running PSim
.........................................................................................................................................................
on a remote computer
634
RESOLVE.........................................................................................................................................................
controlled CMG/PSim runs on a Linux cluster
635
Overview
......................................................................................................................................... 635
Installation
......................................................................................................................................... 636
Administering the
.........................................................................................................................................
lxresolve daemon
643
Part 3 Examples Guide
647
1 Worked
...................................................................................................................................
Examples - Overview
647
2 Worked
...................................................................................................................................
Examples - Index
647
3 Example
...................................................................................................................................
Section 1: Getting Started
657
Getting Started
..........................................................................................................................................................
- Overview
657
Getting Started
..........................................................................................................................................................
- Step 1
658
Getting Started
..........................................................................................................................................................
- Step 2
660
Getting Started
..........................................................................................................................................................
- Step 3
665
Getting Started
..........................................................................................................................................................
- Step 4
668
Getting Started
..........................................................................................................................................................
- Step 5
669
Getting Started
..........................................................................................................................................................
- Step 6
670
Getting Started
..........................................................................................................................................................
- Step 7
672
Getting Started
..........................................................................................................................................................
- Step 8
676
4 Example
...................................................................................................................................
Section 2: Connections to Reservoir Simulation Tools
689
Exam ple 2.1: ..........................................................................................................................................................
GAP - REVEAL Connection
689
GAP-REVEAL
.........................................................................................................................................................
: Overview
689
GAP-REVEAL
.........................................................................................................................................................
: Step 1
690
GAP-REVEAL
.........................................................................................................................................................
: Step 2
691
GAP-REVEAL
.........................................................................................................................................................
: Step 3
693
GAP-REVEAL
.........................................................................................................................................................
: Step 4
698
GAP-REVEAL
.........................................................................................................................................................
: Step 5
699
GAP-REVEAL
.........................................................................................................................................................
: Step 6
703
GAP-REVEAL
.........................................................................................................................................................
: Step 7
705
GAP-REVEAL
.........................................................................................................................................................
: Step 8
706
GAP-REVEAL
.........................................................................................................................................................
: Step 9
708
December 2010
Contents
VIII
Exam ple 2.2: ..........................................................................................................................................................

GAP - REVEAL Connection w ith Script
716
GAP-REVEAL-Scripted
.........................................................................................................................................................
: Overview
716
GAP-REVEAL-Scripted
.........................................................................................................................................................
: Step 1
718
GAP-REVEAL-Scripted
.........................................................................................................................................................
: Step 2
719
GAP-REVEAL-Scripted
.........................................................................................................................................................
: Step 3
721
GAP-REVEAL-Scripted
.........................................................................................................................................................
: Step 4
722
Exam ple 2.3: ..........................................................................................................................................................
GAP - REVEAL Connection w ith Event Driven Scheduling
724
GAP-REVEAL
.........................................................................................................................................................
Event Driven Scheduling: Overview
724
GAP-REVEAL.........................................................................................................................................................
Event Driven Scheduling : Step 1
726
GAP-REVEAL.........................................................................................................................................................
727
GAP-REVEAL.........................................................................................................................................................
732
GAP-REVEAL.........................................................................................................................................................
739
GAP-REVEAL.........................................................................................................................................................
Event Driven Scheduling: Step 5
740
Exam ple 2.4: ..........................................................................................................................................................
GAP - REVEAL Connection w ith Scenario Managem ent
742
GAP - REVEAL
.........................................................................................................................................................
Scenario Management: Overview
742
GAP - REVEAL
.........................................................................................................................................................
Scenario Management : Step 1
743
GAP - REVEAL
.........................................................................................................................................................
744
GAP - REVEAL
.........................................................................................................................................................
769
GAP - REVEAL
.........................................................................................................................................................
Scenario Management: Step 4
771
Exam ple 2.5: ..........................................................................................................................................................
GAP - Eclipse Connection
776
GAP-Eclipse
.........................................................................................................................................................
: Overview
776
GAP-Eclipse
.........................................................................................................................................................
: Step 1
777
GAP-Eclipse
.........................................................................................................................................................
: Step 2
778
GAP-Eclipse
.........................................................................................................................................................
: Step 3
780
GAP-Eclipse
.........................................................................................................................................................
: Step 4
782
GAP-Eclipse
.........................................................................................................................................................
: Step 5
783
GAP-Eclipse
.........................................................................................................................................................
: Step 6
785
GAP-Eclipse
.........................................................................................................................................................
: Step 7
792
GAP-Eclipse
.........................................................................................................................................................
: Step 8
794
GAP-Eclipse
.........................................................................................................................................................
: Step 9
796
GAp-Eclipse
.........................................................................................................................................................
: Step 10
798
5 Example
...................................................................................................................................
Section 3: Connection to Process Modeling Tools
802
Exam ple 3.1: ..........................................................................................................................................................
GAP - Hysys Connection
802
GAP-Hysys
.........................................................................................................................................................
: Overview
802
GAP-Hysys
.........................................................................................................................................................
: Step 1
803
GAP-Hysys
.........................................................................................................................................................
: Step 2
804
GAP-Hysys
.........................................................................................................................................................
: Step 3
807
GAP-Hysys
.........................................................................................................................................................
: Step 4
810
GAP-Hysys
.........................................................................................................................................................
: Step 5
812
GAP-Hysys
.........................................................................................................................................................
: Step 6
815
GAP-Hysys
.........................................................................................................................................................
: Step 7
817
GAP-Hysys
.........................................................................................................................................................
: Step 8
818
GAP-Hysys
.........................................................................................................................................................
: Step 9
822
Exam ple 3.2: ..........................................................................................................................................................
GAP - Hysys Connection w ith Script
825
GAP-Hysys-Scripted
.........................................................................................................................................................
: Overview
825
GAP-Hysys-Scripted
.........................................................................................................................................................
: Step 1
826
GAP-Hysys-Scripted
.........................................................................................................................................................
: Step 2
827
GAP-Hysys-Scripted
.........................................................................................................................................................
: Step 3
830
GAP-Hysys-Scripted
.........................................................................................................................................................
: Step 4
831
Exam ple 3.3.:..........................................................................................................................................................
GAP - Hysys Connection w ith Optim isation (1)
834
GAP-Hysys-Optimisation1
.........................................................................................................................................................
: Overview
834
.........................................................................................................................................................
: Step 1
835
.........................................................................................................................................................
: Step 2
838
.........................................................................................................................................................
: Step 3
840
VIII
IX
RESOLVE
December 2010
.........................................................................................................................................................
: Step 4
841
Exam ple 3.4.:..........................................................................................................................................................
GAP - Hysys Connection w ith Optim isation (2)
845
.........................................................................................................................................................
: Overview
845
.........................................................................................................................................................
: Step 1
846
.........................................................................................................................................................
: Step 2
849
.........................................................................................................................................................
: Step 3
850
.........................................................................................................................................................
: Step 4
854
.........................................................................................................................................................
: Step 5
858
.........................................................................................................................................................
: Step 6
860
.........................................................................................................................................................
: Step 7
863
.........................................................................................................................................................
: Step 8
868
6 Example
...................................................................................................................................
Section 4: Connection to Excel
871
Exam ple 4.1: ..........................................................................................................................................................
GAP - Excel Connection
872
GAP - EXCEL
.........................................................................................................................................................
: Overview
872
GAP - EXCEL
.........................................................................................................................................................
: Step 1
873
GAP - EXCEL
.........................................................................................................................................................
: Step 2
874
GAP - EXCEL
.........................................................................................................................................................
: Step 3
876
GAP - EXCEL
.........................................................................................................................................................
: Step 4
880
GAP - EXCEL
.........................................................................................................................................................
: Step 5
882
GAP - EXCEL
.........................................................................................................................................................
: Step 6
884
7 Example
...................................................................................................................................
Section 5: Advanced RESOLVE Examples
885
Exam ple 5.1: ..........................................................................................................................................................
Black Oil Delum ping Exam ple
885
Black Oil Delumping
.........................................................................................................................................................
Example : Overview
885
Black Oil Delumping
.........................................................................................................................................................
Example : Step 1
886
Black Oil Delumping
.........................................................................................................................................................
Example : Step 2
887
Black Oil Delumping
.........................................................................................................................................................
Example : Step 3
888
Black Oil Delumping
.........................................................................................................................................................
Example : Step 4
890
Black Oil Delumping
.........................................................................................................................................................
Example : Step 5
891
Black Oil Delumping
.........................................................................................................................................................
Example : Step 6
892
Black Oil Delumping
.........................................................................................................................................................
Example : Step 7
894
Black Oil Delumping
.........................................................................................................................................................
Example : Step 8
904
Black Oil Delumping
.........................................................................................................................................................
Example : Step 9
905
Black Oil Delumping
.........................................................................................................................................................
Example : Step 10
907
Exam ple 5.2: ..........................................................................................................................................................
Lum ping/Delum ping Exam ple
910
Lumping -.........................................................................................................................................................
Delumping: Overview
910
Lumping -.........................................................................................................................................................
Delumping: Step 1
912
Lumping -.........................................................................................................................................................
Delumping: Step 2
914
Lumping -.........................................................................................................................................................
Delumping: Step 3
918
Lumping -.........................................................................................................................................................
Delumping: Step 4
920
Lumping -.........................................................................................................................................................
Delumping: Step 5
922
Lumping -.........................................................................................................................................................
Delumping: Step 6
924
Lumping -.........................................................................................................................................................
Delumping: Step 7
926
Lumping -.........................................................................................................................................................
Delumping: Step 8
934
Lumping -.........................................................................................................................................................
Delumping: Step 9
937
Lumping -.........................................................................................................................................................
Delumping: Step 10
943
8 Example
...................................................................................................................................
Section 6: OpenServer Examples
945
Exam ple 6.1: ..........................................................................................................................................................
Drilling
945
Drilling : Overview
......................................................................................................................................................... 945
Drilling : Step
.........................................................................................................................................................
1
946
Drilling : Step
.........................................................................................................................................................
2
948
Drilling : Step
.........................................................................................................................................................
3
950
Drilling : Step
.........................................................................................................................................................
4
950
Exam ple 6.2: ..........................................................................................................................................................
Equipm ent
951
December 2010
Contents
Equipment.........................................................................................................................................................
: Overview
951
Equipment.........................................................................................................................................................
: Step 1
952
Equipment.........................................................................................................................................................
: Step 2
952
Exam ple 6.3: ..........................................................................................................................................................
Variable-Connection
953
Variable Connection
.........................................................................................................................................................
: Overview
953
Variable Connection
.........................................................................................................................................................
: Step 1
954
Variable Connection
.........................................................................................................................................................
: Step 2
954
Exam ple 6.4: ..........................................................................................................................................................
Com positional Mapping
954
Compositional
.........................................................................................................................................................
Mapping : Overview
954
Compositional
.........................................................................................................................................................
Mapping : Step 1
955
Compositional
.........................................................................................................................................................
Mapping : Step 2
955
9 Example
...................................................................................................................................
Section 7: Additional Examples
956
Exam ple
Exam ple
Exam ple
Exam ple
Exam ple
Exam ple
Exam ple
Exam ple
Exam ple
7.1: ..........................................................................................................................................................
Mixed ESP
956
7.2: ..........................................................................................................................................................
Process Model Scheduling
957
7.3: ..........................................................................................................................................................
Multiple Process Instances
958
7.4: ..........................................................................................................................................................
Gas Re-Injection
959
7.5: ..........................................................................................................................................................
Sm artWell
960
7.6: ..........................................................................................................................................................
RedoSolve - Scripting
961
7.7: ..........................................................................................................................................................
Voidage Replacem ent
962
7.8: ..........................................................................................................................................................
Water Re-Injection
962
7.9: ..........................................................................................................................................................
Optim iser Settings OpenServer
963
Chapter
Technical Overview
Technical Overview
1.1
RESOLVE: An Introduction
The IPM suite "core" set of tools (i.e. GAP / PROSPER / MBAL / PVTp) enables to establish a
fully integrated model of a field from the reservoir level up to the separator level.
This concept of integrating the different parts of a producing system is now a standard in the
industry, and enables to gain a detailed understanding of the interactions between reservoirs,
wells and surface network.
For instance, during the design phase of a project, such a model will enable to diagnose easily
where the bottlenecks are in the system: are the tubing sizes selected too small or too large, are
the surface facilities adapted to the reservoir and wells potential?
It enables as well, associated to a powerful non-linear optimisation engine, to optimise the way
the producing system is setup: what will be the optimum wells to choke down to respect a
production plateau, what choke settings will need to be selected, what will be the optimum gas
lift gas allocation...
Value can be added to this type of models by pushing the integration concept further including
both upstream (i.e. reservoir) and downstream (i.e. process / economics) aspects of the
producing system, as illustrated below.
Petroleum Experts Ltd.
RESOLVE
Some of the applications used at these upstream and downstream levels are not provided by
Petroleum Experts therefore requiring the possibility of dynamically linking engineering tools
from different providers.
This will enable the engineers to design "No Compromise" systems where the most appropriate
tools can be used to model each section of the system.
RESOLVE is the IPM tool that will allow dynamic coupling between different petroleum
engineering packages.
RESOLVE is a master controller which allows Petroleum Experts and third party software
applications to be connected and controlled centrally: while each application runs autonomously,
RESOLVE takes care of synchronisation, data transfer, reporting, data gathering, solving and
optimisation.
RESOLVE will then allow systems such as the ones described below to be setup:
Numerical Simulation Reservoir Model + Well and Surface Network Model:
Material Balance, Well and Surface Network Model + Process Model:
Material Balance, Well and Surface Network Model + Process Model + Economic
Spreadsheet:
Numerical Simulation Reservoir Model + Well and Surface Network Model +

Process Model + Economic Spreadsheet:
Re-cycling setups (e.g. passing fluid from a process model to gas-lift injection or produced
water re-injection models) can be handled as well.
Technical Overview
In addition to the connectivity capacity, RESOLVE will include additional modules enabling for
instance to setup optimisation problems across applications (i.e. the objective function can be
for instance located in Excel, constraints in the process model and the control parameters in the
surface network model) or event driven scheduling routines.
An example from such a setup can be found in the snapshot below.
This model consists of:
- 4 reservoir models: Eclipse100, Eclipse 300, REVEAL and MBAL
- 3 surface network models: GAP Production, water Injection and gas injection
- 2 Process models: UniSim Design
- 1 Economic Spreadsheet: Excel
1.2
RESOLVE
RESOLVE: How does it work?
RESOLVE is the IPM tool that allows dynamic coupling between different engineering packages,
such as economic spreadsheets, reservoir and process simulators.
1. The application drivers
In order to establish these connections, RESOLVE uses an "application driver" scheme: each
application "talks" to RESOLVE through its own driver.
This technique has the advantage of allowing users with specific connectivity requirements (i.e.
for instance wanting to connect to a self or company developed tool) to build their own
connections.
The "RESOLVE Architecture"and "Driver Registration"sections will include further information
regarding this topic.
These drivers enable to:
Transfer data from one application to the other, making the data formats
compatible.
This data transfer is performed for every RESOLVE timestep (i.e. see the
timestep description below for more details).
Synchronise each applications timestep during a prediction.
Two type of timesteps can be distinguished when referring to a RESOLVE model:
The RESOLVE timesteps are the times at which dynamic coupling between the
applications take place: at this point in time data is passed from one application
to another and results are written in RESOLVE.
The internal application timesteps are the timesteps required by certain
applications (i.e. for instance the reservoir simulators) for convergence
purposes.
These timesteps will be respected when running a model through RESOLVE,
however there will be a synchronisation performed to obtain an internal timestep
that is consistent with the RESOLVE timestep chosen.
For instance, if the RESOLVE timestep specified is one month, the numerical
simulator will take as many timesteps as needed during this one month period,
but will have to stop after running exactly for a one month period, to be
synchronised with the other applications, as illustrated below.
Technical Overview
2. What happens during a timestep: the RESOLVE dataflow

RESOLVE can be used to solve the field model at a specific point in time (i.e. equivalent to the
solve network capacity of GAP), or to run a prediction forecast over a pre-defined length of time.
If one consider a Reservoir Simulator - GAP - Process Simulation - Economic Spreadsheet
model, the RESOLVE procedure applied at every timestep of a prediction forecast will be the
following:
The reservoir models (i.e. this could be either material balance or numerical
simulation models) are initialised at the start date of the RESOLVE run.
For each well model, the fluid PVT description (i.e. black oil or compositional)
and the well inflow performance data (i.e. IPR) are passed to the network
models.
The production and injection systems are solved and optimised against the GAP
objective function.
The fluid rates and PVT descriptions (i.e. including the fluid composition if
available) at the separators are passed to the process model and the process
model is solved.
The well performance results are passed back to the simulation models as,
depending on the user choice, fixed rate, fixed bottom hole pressure or fixed
wellhead pressure.
If a global optimisation setup has been setup in the RESOLVE model, RESOLVE will iterate on
the third and fourth points in order to optimise the system against the overall objective function
before passing back any data to the simulation models.
The simulation models then take the required timesteps up to the next
synchronisation time of RESOLVE.
RESOLVE
The process is then repeated until the RESOLVE schedule is completed.

Events that occur in any model will be accounted for during the run and reports will be generated
dynamically.
This procedure is illustrated in more details in the drawing below.
It is possible to notice that this workflow makes the coupling procedure an explicit procedure.
1.3
RESOLVE: Summary of Capabilities
The table below will illustrate the RESOLVE capabilites, and link to the corresponding sections
of the user guide and worked examples.
Capability
Description
User Guide Section
Worked Examples
Section
Main Features
Hyper-threaded
Parallelisation of solver
Distributed
algorithm
Applications
Use of local and network
PxCluster
machine resources
Support link to PC and Unix OS
machines
Support link to cluster of
machines
N/A
Technical Overview
Capability
Description
Worked Examples
Section
User Guide Section
No fixed concept of upstream

Allows any
and downstream
topography of Possibility of bi-directional (i.e.
connected system looping) configuration between
modules
Possibility of developing user
specific connections
Application
as
a
whole
can
be
Open Architecture
controlled from an external
OpenServer
controller such as an Excel
concept
macro for instance
Possibility of integrating userdefined optimisers
Solve Network or Models can be run predictively
Forecast
or at a specific snapshot in time
Edit Loops
N/A
OpenServer
Example Section 6:
OpenServer
Creating a
RESOLVE optimiser Examples
in Excel
Options Section
Example Section 1 |
Getting Started
Reservoir
Coupling
REVEAL
Connections in
RESOLVE: Further
Schlumberger Eclipse 100 and
Details
300
Numerous
Connections
to
CMG IMEX and GEM
Reservoir
External
IFP PumaFlow
Connections
Applications
Proprietary Reservoir
Available
Specific
Elements
Connections (Shell MORES,
Saudi-Aramco POWERS,
ConocoPhilips PSIM, Chevron
CHEARS)
Specific Inflow Performance
Loading and Editing
Advanced
Calculations
a REVEAL case
Algorithms for
IPR
Generation
Improved Stability
Options
Adaptative Time- Enables to asses the optimal Timestep Control
Stepping
timestep lenght
Example Section 2 |
Connection
to
Reservoir Simulation
Tools
Example Section 2 |
Connection
to
Tools
N/A
Surface Network
Coupling
Take full advantage

of Petroleum
Experts GAP
software
capabilities
Non-Linear Optimisation
Connection to GAP Example Section 1 |
Connection to Material Balance - GAP driver details Getting Started
Example Section 5 |
(MBAL)
Advanced RESOLVE
Production and Injection
Examples
systems in a SINGLE license
Production and Gas Lift Injection
systems in a SINGLE license
RESOLVE
Capability
IPM-OS
(OPENSERVER)
coupling
Take full advantage
of Petroleum
Experts IPM
(PROSPER, GAP,
MBAL, PVTP,
RESOLVE,
REVEAL) software
capabilities
Description
User Guide Section
Link to any of the IPM tools

Possibility to input, perform
external calculations with any
IPM model and feedback the
results to RESOLVE or any
other application connected
Connection to IPMOS - IPM-OS driver

details
Worked Examples
Section
Thermodynamics
and PVT
PVT information passed from
Thermodynamic
one model to another
consistency
Black-Oil models can be mixed
between
with Fully Compositional Models
applications
Lumping /
Delumping
Facilities
PVT within
Example Section 3 |
RESOLVE:
Connection
to
Process
Modeling
Importance of PVT
Tools
Consistency
Connection Details:
Composition Tables
Enables to pass from a "simple" Lumping /
Example Section 5 |
compositional fluid description
Delumping Options Advanced RESOLVE
at reservoir level to a "detailed"
Examples | Example
compositional fluid description
5.2:
Lumping
at surface network / process
Delumping Example
level
Event / Well
Management
Conditional
Scheduling
Scenario
Management
Event driven scheduling options Event Management Example Section 2 |

available.
Connection
to
Possibility of publishing and
Tools | Example 2.3:
monitoring any variable from
GAP
REVEAL
any application to perform IF...
connection with event
THEN .. ACTION directives
driven scheduling
Possibility of ranking the actions
Possibility of re-solving the
system after the action has
been performed
Possibility of setting-up different Scenario Manager Example Section 2 |
scenarios and run them
Connection
to
automatically sequentially or in
Reservoir simulation
parallel through the use of a
cluster
GAP
REVEAL
Technical Overview
Capability
Description
User Guide Section
Worked Examples
Section
connection
Scenario
Management
Results of each scenario are

displayed in the same location,
enabling easy comparisons to
be performed
10
with
Optimisation
Two Levels of
Optimisation
Distribution of
Optimisation
Problems
Routing
Optimisation
User Optimiser
Non-Linear Optimisation in GAP Optimisation

Example Section 3 |
Section - Setting-up Connection
to
Successive linear optimisation
the RESOLVE
Process
Modeling
in RESOLVE
optimisation
GAP
Hysys
connection
with
Optimisation (1)
Example Section 3 |
Connection
to
Process
Modeling
GAP
Hysys
connection
with
Optimisation (2)
Optimisation problems can be Optimisation
Example Section 3 |
distributed over ALL applications Section - Setting-up Connection
to
in an integrated model: objective the
RESOLVE Process
Modeling
function, constraints and
optimisation
controls can be defined at any
GAP
Hysys
level in the model
connection
with
Optimisation (1)
Example Section 3 |
Connection
to
Process
Modeling
GAP
Hysys
connection
with
Optimisation (2)
Mixed Integer Optimisation
Optimisation
N/A
enables to perform routing
Section - Setting-up
optimisation, finding the
the
RESOLVE
optimum routing at each
optimisation
timestep
Open Architecture enables
User Optimisers
N/A
users to define their own
optimisers
Version Control
Tight Integration RESOLVE models can be
Refer to
N/A
11
RESOLVE
Capability
Description
with Petroleum
Experts
ModelCatalogue
checked IN and OUT, as well as

all associated models
User Guide Section
Worked Examples
Section
ModelCatalogue
Manual
Excel Link
Calculation
Connection to Excel
- Excel driver details
Reporting
Dynamic Link with
Compositional
stream
splitting
/
Excel
manipulation
Economics calculation
Internal in RESOLVE
OpenServer
External to RESOLVE using the

External or Internal OpenServer architecture: The
Link
RESOLVE model can be
controlled externally using a
VBA macro
Example Section 4:
Connection to Excel
Example Section 5 |
Advanced RESOLVE
Examples
|
OpenServer
Examples
Process Model
Links
Hysys
UniSim Design
Numerous Links
Available to
Process Models
Connection
to
Hysys - Hysys driver
details
Connection
to
UniSim Design UniSim
Design
driver details
GUI
Comprehensive Results appear dynamically
Analysing and
and Dynamic
during the run
Reporting the
Reporting
Results
Direct access to Debug
Logging, enabling to analyse
every single process happening
during the run, whatever
software is considered
Direct Export to different file
types: text, Excel spreadsheet
copy / paste format
Wizards available for common Wizards Section - IT
and Engineering
RESOLVE Wizards tasks such as voidage
replacement, IT configurations
Utilities
or drilling queue setup
Possibility of reporting all
Publish Application
Published Variables connected application results
Variables
Example Section 3 |
Connection
to
Process
Modeling
Tools
Example Section 1 |
Getting Started
N/A
Example Section 1 |
Getting Started
Technical Overview
Capability
Description
User Guide Section
12
Worked Examples
Section
directly in RESOLVE
1.4
What's New in RESOLVE?
IPM version 7.5

Changes to the link to Eclipse (100 and 300)
2009+ versions are now supported.
On Windows, Intel MPI, rather than Verari MPI is not used for versions of Eclipse from
2009. This allows the connection to 64-bit Eclipse running on Windows platforms (
RESOLVE continues to run under 32-bit emulation).
On Linux, Intel MPI can be used in addition to Scali (Platform) MPI.
A bug in the 2008.2 version, which caused Eclipse to crash if the .ECLEND file were
present at the start of the run, has been worked around.
The links to the CMG simulators and PSim on Linux are now 'cluster enabled'. LSF (or similar)
can be used to queue and load balance when these jobs are launched from RESOLVE.
An 'IPM-OS' driver has been added for generic interactions with the IPM tools (i.e. getting/
setting data or performing commands). Any IPM model can now be included in a RESOLVE
workflow, as required.
A new wizard has been added to take advantage of the above IPM-OS functionality. This
wizard will be used to perform generic batch OpenServer tasks. The functionality currently
extends to the batch generation of lift curves from a GAP model. The generation can be done
sequentially or over the nodes of a cluster.
Significant performance improvements have been made in the data transfer speed for large
models, and the generation of GAP variable lists.
Node lists in the reporting and plotting are now sorted alphabetically.
Ability to copy variables between 'optimisation' sets and general 'exported' sets (currently GAP
only).
Optimisation states can be saved. This means that the system state that is evaluated at a
particular iteration (or the optimal iteration) can be stored to be re-implemented at a later time.
The state can be restored as an action in the event driven scheduling, or from the Visual Basic
script.
13
RESOLVE
REVEAL Link
IPR models and control modes can now be set per well, rather than globally.
IMEX Link
Well layer data can now be accessed from the RESOLVE script to automate workovers/
recompletions.
Build 162 (IPM version 7.1)
Improved advanced scheduling screen to indicate immediately which sections have data in
them.
Improved archiving screen - multiple baggage files can now be added simultaneously from a
multiple-selection file selector.
Added reporting at all connections of average black oil rates.
Added the ability to export cumulative data (node or system level) from GAP into RESOLVE
(for plotting or scheduling, etc, purposes).
IPM version 7.0
Lumping and delumping:
RESOLVE takes advantage of the lumping / delumping scheme within GAP, if a GAP
model is present.
External lumping / delumping (i.e. in RESOLVE) is possible if GAP is not part of the
system.
Black oil models (e.g. Eclipse 100) can be delumped into a compositional model (e.g.
Hysys).
Compositions can be imported into PRP format from any application module
supported by Petroleum Experts.
Reporting and plotting facilities have been completely reviewed.
Multiple plots and results tables can be displayed within RESOLVE, either during or
after a forecast.
Improved structure for results reporting - additional module variable results are stored
separately to the connection results.
Reporting to clipboard and file has been improved.
Support of gas lift networks in GAP. The source of gas lift can be an external process or other
model (e.g. Excel). RESOLVE will automatically iterate across production and gas lift injection
systems to ensure that the casing pressure to inject the gas can be achieved.
Technical Overview
14
Implementation of a generic routing and integer optimisation algorithm (GIRO).

Improvements to compositional modeling across a RESOLVE system. IPRs based on mass
(rather than volumetric) rates can be passed which makes the results independent of any
simulator process/separator train.
Addition of an Excel optimisation plug-in. This allows users to code (i.e. using simple Excel
VBA) their own optimisation routines to solve RESOLVE optimisation problems. A sample
Excel spreadsheet is also supplied.
Addition of an interface to automate WAG processes (currently REVEAL and PSim only).
General performance improvements in external optimisation. The improvement compared to
IPM version 6 is about 60%.
Improvement to the logic implemented when a RESOLVE archive is opened: after the archive
is extracted it will open up the master file under the assumption that all the client files are
located in the directory to which the files have just been extracted.
The option has been implemented to cascade variables which are passed on to an Excel
instance (by way of a variable connection) horizontally or vertically during a forecast.
Improved interface to Petroleum Experts IFM tool.
REVEAL Link
Integration with WAG tool (see above).
Integration with compositional model.
Eclipse Link
Direct (one way) connections from Eclipse wells. In this case, Eclipse is allowed to
control the well(s) and sends only the operating data of the well to the downstream
module. Along with the compositional and black oil delumping capability, this means
that direct connections between Eclipse and Hysys are now possible.
SCHEDULE section data can now be sent directly from a RESOLVE script or external
macro to Eclipse.
Excel Link
Macros called from the Excel module can now be run at different points in the
RESOLVE timeline: Start of Run, End of Run, PreSolve, PostSolve, Start of Timestep,
End of Timestep.
The Excel spreadsheet can be hidden during the run to prevent accidental interaction
with the application while under the control of RESOLVE.
PSim Link (ConocoPhillips)
Ability to specify an injection composition during the well test phase for gas injectors.
Ability to perform all IPR pre-calculation well tests simultaneously.
15
RESOLVE
Ability to export well variables into RESOLVE (for event driven scheduling, etc).
Integration with WAG tool (see above).
Support for parallel Eclipse under the LSF version of the link to Linux; LSF is allowed to
choose the running nodes for the Eclipse job.
Support for Hysys in version 2006.5 and later versions.
Addition of PSim (ConocoPhillips) driver to distribution.
IPR pre-calculation (for the corrected IPR model) in IMEX/GEM improved so all tests are
performed simultaneously.
Added a flag to allow events to be ignored (DATE and TSTEP keywords) in Eclipse.
Improvements to the LSF link to Eclipse running on Linux:
a timeout can now be entered so that RESOLVE does not have to wait indefinitely for
the process to start
RESOLVE no longer hangs if the process fails after it has been started by LSF
Parallel Eclipse (running on a Linux cluster) is now supported.
Major improvements to the link to Eclipse from RESOLVE.
Linux-side daemons run as "root" user
Administrator can restrict or allow access to users, or change the accounts on which
Windows users run Linux processes
Different LSF queues can be set for different users or groups of user
Installer script to improve the ease of setup of the Linux side processes
Other miscellaneous improvements - see documentation
Technical Overview
16
Added facility to reload selected client modules at the start of the run of each scenario under
the scenario management. This affects sequential (rather than clustered) runs only. It may be
used if (for example) a model file is to be changed as part of the scenario.
Improved the reporting and handling of failures in the advanced ("scaling") IPR calculation of
the Eclipse link driver.
Added ability to retrieve the currently running scenario index from the internal script
Addition of client nodes to PxCluster
Addition of PxCluster and associated utilities
Allows multiple RESOLVE scenarios to be parallelised over the nodes of a cluster
Also added to GAP, REVEAL, and IMEX/GEM drivers to allow models to be distributed
to spare CPU capacity automatically.
Hysys / UniSim DesignDesign
Properties available from correlations under stream property view can now be reported
or exported into RESOLVE. "Standard" and "Gas" correlations are added by default;
others can be added as required.
[Bug Fix] Limit on number of GAP variables which can be saved in a RESOLVE model has
been removed
Addition of Petroleum Experts drivers for IMEX and GEM reservoir simulators
[Bug Fix] Problem in E300 of passing data for large numbers of components is fixed
Extensions to OpenServer interface to Eclipse
Dynamic group (e.g. OPRDLIM) data can now be set from a script or an external
OpenServer routine (provided the group wells are not connected to GAP)
17
RESOLVE
Extensions to OpenServer interface to Eclipse

Dynamic group (e.g. GOPT) and system (e.g. CPU information) can now be retrieved
from a script or an external OpenServer routine
Improvements to the interface that allows GAP OpenServer variables to be imported into
RESOLVE
The input separator pressures can now be brought into the screen automatically
The difference between output and input variables in this screen has been clarified
Implementation of "targets"
A target value in one application variable can now be met by adjustment of a single
variable in another application, without recourse to setting up an optimisation problem.
An example would be the adjustment of a separator pressure in GAP to meet an export
line pressure target in the process module
Steam injection can be carried out between GAP and REVEAL
Added more variables to Hysys and UniSim Design output lists. These are the variables which
are normally accessed from the property correlations in Hysys / UniSim Design, and which do
not appear automatically in the programming interfaces (type libraries) of these products.
For example, Wobbe Index (Gas property) and True Vapour Pressure (Standard
property) can now be queried
Additional property correlations can be added by the user as required
Improved OpenServer wrapper for Hysys and UniSim Design
Entire arrays (delimited with "|") can be returned and set with strings of the form:
Resolve.Module[{Hysys}].Equipment[{equip}].Variable[{ComponentMolarFraction}].
Value
Individual array elements can still be returned as before: Resolve.Module[{Hysys}].
Equipment[{equip}].Variable[{ComponentMolarFraction(Methane)}].Value
IPM version 6.0
RESOLVE
Improved event driven scheduling
More variables can be passed to RESOLVE from the client applications
Drilling queue wizard to automatically populate the event driven scheduling screen for the
Technical Overview
18
case of a drilling queue

Management of different scenarios
Separate storage of different model realisations
Separate storage of the results of different realisations
Models can be run sequentially, or in parallel (using a cluster)
Use of clusters
Integration with LSF to distribute multiple runs (scenarios) over the nodes of a cluster
Open interface for integration with other clustering tools
Automatic configuration of OpenServer for remote launching and running of all IPM tools
OpenServer improvements
A single, unified OpenServer interface can be used to access the data from all client
modules, e.g. GAP, Hysys, UniSim Design
Direct connections between applications
Any variable (which can be imported from a client application) can be passed to another
module in RESOLVE
Various GUI enhancements
Modules in RESOLVE can be enabled or disabled (i.e. removed temporarily from the
RESOLVE model)
IPR data being passed from reservoir simulation models can be logged and plotted from
RESOLVE
Auto-save facility
Improved scripting
Optimiser enhancements
Various implementations of 3rd party optimisation packages (e.g. AIMMS)
Not released but available on request for testing
GAP link driver
Regression can be performed on IPR data passed from reservoir simulation models
Can improve run stability in cases where simulator data is suspect
Extra variables can be exported from GAP to RESOLVE
Equipment bypass
Static MBAL variables, e.g. OOIP, porosity, etc
REVEAL link driver
New IPR model for improved drainage region calculations
Miscellaneous improvements to the performance of GAP - REVEAL coupled models
19
RESOLVE
Eclipse link driver

Additional IPR models for improved drainage region calculations (run stability)
Direct calculation of drainage region
Build-up calculation
Scaling (proprietary model)
New protocols for communication
Verari MPI for Windows-Windows (or local) connections
Scali MPI for Windows-Linux connections (32- or 64- bit Linux - Red Hat)
Integration with LSF under Linux
Integration with OpenServer
Internal Eclipse variables can be queried with OpenServer strings
Hysys link driver
UniSim Design link driver
Integration with OpenServer
No need to use the standard DCOM interface to Hysys or UniSim Design
Object browser lists all the OpenServer strings for all accessible variables
Access to the Hysys and UniSim Design optimisers
Optimisation models that have already been set up can be started from RESOLVE
Improved performance for data transfer
Excel link driver
Development of a driver that works under Windows Vista operating system
Ability to export variables (i.e. cells contents) to RESOLVE
1.5
Linux distribution
Certain parts of the RESOLVE functionality depend on executables that need to be installed on a
Linux system. These areas of functionality are those in which RESOLVE communicates with an
application which runs under Linux, i.e.
RESOLVE-controlled Eclipse runs on a Linux cluster
RESOLVE-controlled IMEX/GEM runs on a Linux cluster
RESOLVE-controlled PSim runs on a Linux cluster
The Linux executables, which are included in the standard IPM distribution, generally need to be
Technical Overview
20
installed with each major release of IPM (for example, IPM6 - IPM7, IPM7 - IPM7.5). If an
incompatible Linux executable is accessed from a RESOLVE session, an error message will be
displayed at runtime.
For the avoidance of doubt, this section contains a list of Linux-side functionality changes along
with the versions affected, starting from IPM7.
Eclipse
IPM7 - start
IPM7, build 136
1. A workaround was added, which removes the .ECLEND file from the Eclipse data directory
before the Eclipse run is performed. If this file is not removed, the 2008.2 version of Eclipse
crashes.
2. General tidying of Fortran scratch files which are written by Eclipse.
3. The Windows user running RESOLVE is mapped to a Linux user account through the .
ecl_resolve_users (or .ecl_resolve_users_lsf) file. The comparison of Windows user names
was made case-insensitive, to match the Windows standard.
IPM7.5
The Linux executables were made compatible with Eclipse 2009, which can use Intel MPI as the
information exchange protocol. This has necessitated a change to the argument list used when
running the mpirunfactory executable; this is detailed here.
IMEX/GEM/PSim
IPM7.5 - start
1.6
IT Requirements
Requirements for individual applications
RESOLVE (absolute minimum requirements)
Pentium II class PC (Windows XP or Vista)

1 GHz processor
500 Mb RAM
5 Gb hard disk space for temporary files
1280 x 1024 display size with 16bit colour
GAP / REVEAL
2 GHz processor
2 Gb RAM
21
RESOLVE
3rd party applications

See individual vendor requirements, except where noted below.
Requirements to link external applications into RESOLVE
GAP / REVEAL
Standard licences for each of the applications to be linked. One licence is required for each instance
of the application in the RESOLVE model.
An OpenServer licence for each instance of the application that is in the RESOLVE model. Note
that GAP production, water injection, and gas injection systems can run inside a single instance of
GAP, and so require only a single licence of GAP and OpenServer
Eclipse
A standard Eclipse licence which includes any options that are required to run the model in question.
One licence is required for each Eclipse model in the RESOLVE model.
An OpenEclipse licence. One licence is required for each Eclipse model in the RESOLVE model.
When linked into RESOLVE, Eclipse is supported on any Win32 platform as recommended by SIS.
When the Win32 version is linked, Verrari MPI is required. This comes with Eclipse on the
distribution CD.
Eclipse is also supported on Linux platforms with additional software supplied by Petroleum
Experts. The Petroleum Experts software must run on a rhel4 system; Eclipse will run on any
Linux platform supported by SIS (except for caveat in note vi).
Licences of Platform (formerly Scali) MPI will be required to control Eclipse on Linux. These licences
are provided by Platform per node.
LSF licences will be required if LSF is to be used to distribute jobs about the Linux cluster. If LSF is
to be used, then (currently) Eclipse must also run on rhel4 systems.
Hysys / UniSim Design
Standard Hysys / UniSim Design licences are required with no special features.
A single licence is required for multiple models linked into Petroleum Experts, where these
models run on a single computer.
IMEX / GEM
A standard licence is required plus a network coupling licence.
Excel
No special options are required for this.
Other software
These are generally proprietary and so advice should be sought separately if these are required.
Petroleum Experts Licensing

RESOLVE can be run using a single user (stand-alone) license or on a network. In either case, a
special security key is needed. The security key is called Bitlock for stand-alone licenses, and
HARDLOCK for network licenses. The security key is provided by Petroleum Experts.
Technical Overview
22
For a stand-alone license, the security key (Bitlock) must be attached to the USB port of the PC.
For a network installation, the security hey (HARDLOCK) can be attached to any PC communicating
with the network.
The installation procedure for a network HARDLOCK can be found in the manual provided with the
purchase of a HARDLOCK licence.
Chapter
User Guide
User Guide
2.1
What is in this guide?
24
This RESOLVE user guide will include a description of all the different options available in
RESOLVE.
The flowchart below outlines the basic procedure required to setup a RESOLVE model to carry
out full field modeling and optimisation by dynamically connecting several engineering
applications.
The "Further Technical Elements" section focuses on providing information on specific technical
aspect such as clustering, running applications distributed over a network, etc...
The organisation of the manual adheres to the RESOLVE processing and main menu logic and
is detailed below.
Introduction
Getting Started with RESOLVE
File Menu
Drivers menu
Wizards menu
Options menu
Edit System menu
Module Variables menu
Program Functions menu
Schedule menu
Optimisation menu
Scripting menu
Running the RESOLVE model
Analysing and Reporting the Results
Window menu
25
RESOLVE
View menu
Appendix
Examples Guide
The setup and usage of RESOLVE models is illustrated on case examples in the "Worked
Examples" section.
2.2
Contacting Petroleum Experts
Should a user have further questions or experience any issues when using RESOLVE,
Petroleum Experts technical support team can be contacted by using the following email
addresses:
C
on
ta
ct
us
Yo
u
ca
n
co
nta
ct
us
by
Em
ail,
User Guide
Ma
il ,
Ph
on
e
or
Fa
xor
on
the
we
b
at
htt
p://
ww
w.
pet
ex.
co
m
UUC
n nh
i i i
t tn
e ea
dd
KS
i t
na
gt
de
os
m
P PP
26
27
RESOLVE
eee
t t t
r r r
o oo
l l l
eee
u uu
mmm
E EE
xxx
p pp
eee
r r r
t t t
sss
LI J
i ni
mc a
i . n
t 7w
e5a
d7i
P NS
e oO
t r H
et O
x h,
HE#
ol 7
u dB
sr l
ei d
1 d.
0 gR
Lem
o P7
ga0
i r 3
ek3
Mw9
i aE
l ya
l Ss
Eut
User Guide
di ,
i t 3
ner
b5d
u1R
r 0i
g Hn
h og
, uR
Eso
Ht a
7 od
4 nC
HT h
GE a
S Xo
c Ay
o Sa
t 7n
l 7g
a0D
n7i
d9s
U Ut
KSr
Ai
c
t
B
e
i
j
i
n
g
1
0
0
0
0
4
C
H
I
28
29
RESOLVE
N
A
+44
+1+86
281
(0)10
131
531
5869
474
1121
0561
7030
+44
+1+86
281
(0)10
131
531
5869
474
0810
0563
7031
Technical
Support
Technical
Support
houston@petex.com
support@petex.com
support@petex.com
All Other
Queries
All Other
Queries
houston@petex.com
edinburgh@petex.com
beijing@petex.com
US based technical support: houston@petex.com

UK based technical support: edinburgh@petex.com
When contacting Petroleum Experts technical support team, the user should include the
following details in the request:
Include the keyword "RESOLVE" in the e-mail subject.
RESOLVE version and build number that are being used.
This information can be found in the Help | About section of the main RESOLVE menu.
Detailed description of the question or issue experienced.
A copy of the RESOLVE model, including a copy of all the models required to run this
particular RESOLVE model.
If this is too large to go through email, please do not hesitate to let us know and we will
provide details on how to access one of our ftp sites.
2.3
Introduction
This section will include recommendations regarding the different ways the User Guide can be
used, as well as describing the main symbols, conventions and definitions used.
A general introduction to the RESOLVE concept and a detailed description of its capabilities
can be found in the "Technical Overview" section.
2.3.1 How to Use This Guide?

Depending on the user needs and the amount of time the user wishes to spend becoming
familiar with the program, the User guide can be used in the following ways:
Beginning
to end
Selected
tasks
If the user is new to Windows applications, Petroleum Experts

recommends to read this document from beginning to end to become
familiar with the program features, menus, and options.
This is the slow approach, but will cover all a user needs to know about
the program
Use this approach only if the user is already familiar with the basic
functionality of the program
User Guide
Worked
examples
30
If the user has limited time and wants to sample the program features
quickly, the instructions provided with in the step by step examples can
be followed.
The examples can be found in the "Worked Examples" section of the
manual.
To get started with the tool for the first time, Petroleum Experts
recommend to use the "Getting Started" step by step guided example
2.3.2 RESOLVE Glossary of Terms

The section below will list and define some of the most often used terms in this manual:
Client Program /
Connected
Application
Data Provider /
Source
Both terms are used to define an application (i.e. provided by

Petroleum Experts or by another company) that can be used within a
RESOLVE model
This term is use to define a part of a model loaded in RESOLVE that
can be used to provide data to another model
For instance, if one considers a link between a surface network model
and a process model, the separator node of the surface network model
will be a data provider: it will provide the pressure, temperature, fluid
flow rates and compositions that are passed to the process model
Data Receiver / Sink This term is use to define a part of a model loaded in RESOLVE that
can be used to receive data from another model
For instance, if one considers a link between a surface network model
and a process model, the inlet stream of the process model will be a
data receiver: it will receive the pressure, temperature, fluid flow rates
and compositions that are passed by the surface network model
Published Variable This term is used to define a variable that has been imported from a
data provider or receiver directly into the RESOLVE model, enabling
this variable values to be monitored directly in RESOLVE.
For instance, if one considers a surface network model, it will be
possible to directly report the oil production rate at the separator in
RESOLVE: to do so, the oil production rate will have to be published
within RESOLVE before the start of the calculation
.
.
.
.
31
2.4
RESOLVE
Getting Started with RESOLVE
For first time users, this chapter covers the essential features of data management and setup
options of RESOLVE: in essence, everything that is required to get started on a RESOLVE
project.
2.4.1 Basic Model Setup - Guidelines

This section describes, in a general sense, the steps that are used to setup a RESOLVE model.
The "Getting Started"and "Worked Examples"sections give more specific information on how to
build coupled systems.
Step 1: Load and query application model
The first step is to create an "instance" of one of the models that the user wishes to connect
within RESOLVE.
To do so, the following procedure can be used:
Select File | New to create a blank graphical view.
Select Edit System | Add Client Program | <program name> and click in the
graphical view section.
This will create an icon representing the application model.
When a case of a client application is loaded, RESOLVE will create a slave instance of that
application and will load the case (which may be a single file) into the application.
RESOLVE will then query the case for the inputs and ouputs of the system, referred to as
sources and sinks.
In the case of GAP, for example, the sinks in the system are production wells and injection
manifolds, whereas the sources are injection wells and separators.
In simulators, wells can be sources or sinks depending on whether they are production or
injection wells.
The sources and sinks of the model will be displayed as icons underneath the main application
icon in the RESOLVE graphical view. These icons will be labeled with the same name as they
are given in the application model (i.e. icons corresponding to simulation wells will be labeled
with the well name).
As far as RESOLVE is concerned, the application is a black-box calculator that has inputs and
outputs according to the sources and sinks it exposes.
User Guide
32
Later, it will be seen how the functionality of the system can be enhanced by exposing
('publishing') variables from the client applications for use by RESOLVE. These variables can be
used for optimisation, event driven scheduling, reporting, and so on.
For details as to what sources and sinks are exposed by an application, see the section of the
user guide dedicated to the individual driver in question.
After the first instance has been created in RESOLVE, the user can continue to create as many
other instances in the interface as are required in the coupled system.
As a general rule, integrated modeling is improved by ensuring that the individual models
are working satisfactorily in their individual applications, prior to the model being built.
Step 2: Connect individual sources and sinks from client applications
Once the different instances are loaded into RESOLVE, equivalent sources and sinks can be
connected together graphically.
For example, wells in a REVEAL (reservoir simulator) model are the outputs of the REVEAL
model and therefore can be connected to their equivalent wells in GAP, that are the inputs of the
GAP model.
To make a connection, go to Edit System | Link and click and drag between the corresponding
icons on the main screen. Alternatively, the "Connection Wizard"can be used to connect large
numbers of items together automatically.
Connecting items together can result in loops being formed, where model A depends on the
data from model B and model B depends on the data from model A. RESOLVE will detect this
and additional data will be required to handle such loops.
See "Models and Loops"to see how loops are solved.
Step 3: Set the system options
Before running the system, the type of model considered needs to be specified.
To set the system up, go to Options | System Options to invoke the "System Options"screen.
On this screen one can select the forecast mode, enable the "Scripting" options or set various
flags.
Step 4: Create a schedule and / or set the solver options
If a forecast is being run then schedule data must be entered.
Go to the "Schedule Setup" screen by clicking Schedule | Forecast data on the RESOLVE
menu. The timesteps of the RESOLVE forecast are set on this screen; timesteps can either be
fixed in duration or adaptive (adapting to changes in the simulation properties).
33
RESOLVE
The RESOLVE timestep length does not determine the timestep length of the individual
applications, it just gives a date at which the individual applications should synchronise (See "
How does RESOLVE work ?" section for further details).
If the RESOLVE optimisation option has been selected, then the objective function, constraints,
and control information will need to be specified. This can be done from the "Optimisation Setup
" screen which can be accessed from Optimisation | Setup.
Step 5: Run the simulation
A forecast or solve calculation is performed by clicking on Run | Start from the main menu. If
there are errors in the data set (e.g. no connections are made) the run will immediately terminate
and the errors will be displayed.
Once the calculation is started, the following sequence of events will occur:
If specified on the "System Options"screen, all the client models will be reloaded from
scratch. This is to ensure that there is no historical data in the model (e.g. from a
previous run) that might affect the forecast.
Loops will be "collapsed" so that they can be treated as if they were a single model
which can be solved as a separate entity. The "models" in the diagram below can
equally represent loops of connected models. Go to the "Model and Loops"section for
more information.
Each model is "initialised". The meaning of this depends on the application: for a
reservoir simulator this implies that an equilibration will be performed or a restart file
loaded.
For a fully compositional model the "base composition" for the model will be obtained.
RESOLVE needs to know this so that it can map a component from one application (e.
g. which may be called "methane") with a component from another (e.g. which may be
called "C1"). Refer to the "Compositional tables" section for more information.
RESOLVE will then solving the system using a "bottom to top" technique.
The following case can be considered:
User Guide
34
Model E will be "solved", i.e. whatever data is present within E will be used to calculate
the data at the Model E outputs.
Data is obtained from the outputs of model E that are connected to model D inputs. The
dataset passed includes the pressure, temperature, phase rates, mass flow rates, and
compositional data. Other data can be passed as required by the model. Some items
(e.g. a separator in GAP) pass a single data point. Other items (e.g. a reservoir
simulator well) pass a table of points to represent a full response curve. When this
happens the receiving model is expected to calculate the operating point on this
response curve when it performs its solve.
Solver results are passed to the corresponding model D outputs.
All the data is present now for models B, C, and D. These models are solved using this
data. If they are on different machines (or can be put on separate processors) then the
solve processes will be performed in parallel.
Data is transferred to model A.
Model A is solved.
Some of the results of the calculations will be extracted (especially relating to the data
transferred between the models) to allow them to be displayed in RESOLVE.
Those models that passed a full response curve to the next model downstream will
receive the result of the upstream model calculation in the form of a point on the
response curve: for instance, a reservoir simulation model that passed an inflow
performance curve for one well to the surface network model will receive the result of
the surface network model under the form of a rate, bottom-hole or well-head pressure.
35
RESOLVE
If a single solve and / or optimisation is being performed, the run stops here. If a
forecast is being performed then a timestep command will be broadcasted to all the
models that have time dependency to run the forecast from t0 to t1. After the timestep,
all the models will all be synchronised at t1, and RESOLVE will return to the Model E
solve and perfom a similar workflow until the schedule data runs out.
Step 6: View the results
The results of the calculations can be viewed by going to Results | View Results. The data that
is passed between the models (i.e. pressures, temperatures, rates) are stored.
Internal module variables that have been published in RESOLVE can also be plotted in the
results.
2.4.2 The RESOLVE User Interface

2.4.2.1 User Interface
The main screen of RESOLVE has the following appearance:
User Guide
36
The user interface consists of five main sections, as indicated on the diagram above:
Main Menu
Toolbar
Shortcut Icons
Toolbar
Main Display
Window
HelpViewer
Window
System
Window
This is the menu used to issue commands to RESOLVE - The user guide
follows the structure of the main menu toolbar, allowing for a detailed
description of all the options available
This toolbar contains menu accelerators icons - They are described in
details in the "Shortcut Icons Toolbar" section
By default this window will include the graphical view, which describes the
network drawing. In some cases, for instance when the RESOLVE model
is run or when an optimisation is performed, other child windows will
appear in the main display window section. Further information regarding
this window can be found in the "Main Display Window" section
This window enables the user to access specific sections of the user
guide directly from RESOLVE. Further information regarding this window
can be found in the "HelpViewer Window" section
This window enables the user to view all the client modules included in the
model and their respective elements. Further information regarding this
37
RESOLVE
window can be found in the "System Window" section

The user can switch between the "HelpViewer" window or the "System" window by clicking on
the tab corresponding to the view to display, as illustrated below.
2.4.2.2 Shortcut Icons Toolbar

The shortcut icons toolbar is located below the main menu toolbar at the top of the RESOLVE
main window.
It consists of a row of icons (illustrated below) which acts as accelerators to common menu
functions.
The section below describes the options available as shortcuts on the RESOLVE icon bar.
File / Interface Functions
User Guide
Accelerator for File | New.

Clears the current system and initialises a new one.
A warning will be displayed if there are any unsaved changes in the old
system.
Accelerator for File | Open.
This will prompt the user for a new file name. If the file can be opened
successfully, the old file will be cleared and the new file opened in a new
window.
Accelerator for File | Save.
By default, this will override the currently saved version of the file considered.
Use File | Save As to save the file to a different location or with a different
name.
Help Functions
Accelerator for Help | About.
Enables to display the version of RESOLVE currently in used as well as
Petroleum Experts contact details.
Scripting Functions
Accelerator for Script | Edit.
Enables to access directly the RESOLVE internal script.
Model Set-up Functions
Accelerator for Edit System | Add Client Program.
When this is selected, a list of available client modules is displayed. The user
has to choose the client program required from that list and click on the
location where that client program is to be located on the graphical view.
The user will be prompted to label this client program immediately.
Accelerator for Edit System | Link.
Once this is selected, drag and drop the mouse cursor to establish a
connection between two elements in the graphical display window.
Accelerator for Edit System | Target.
Once this is selected, it will be possible to establish a connection between two
modules that will act as a target solver.
Accelerator for Edit System | Select.
After this is pressed, an item of the model may be selected by clicking on the
38
39
RESOLVE
item in the system window. A dark blue circle will be displayed around the item
selected. One can select any item on the window system for further actions:
move items, delete items, etc...
This will enable to automatically unselect all previously selected items.
Accelerator for Edit System | Move.
Move an item. After this is selected, an item may be moved by clicking on the
item in the system window and then, with the mouse button depressed,
dragging the item to the new position.
Accelerator for Edit System | Delete.
Delete an item. After this is selected, an item might be deleted by clicking on
the item in the system window. The icon automatically becomes unselected
following a deletion to prevent accidental deletion of further nodes.
Accelerator for Edit System | Mask and Edit System | UnMask.
When either of these is selected, clicking on an equipment item in the system
window with mask or unmask the item as directed.
The mask option will not modify the scheduling of the items: if an item is
masked but an scheduled event specifies to open it, it will automatically be
unmasked.
Accelerator for Edit System | Disable and Edit System | Enable.
When either of these is selected, clicking on an equipment item in the system
window with disable or enable the item as directed.
The disable option will modify the scheduling of the items: if an item is
disabled, then it will be kept inactive irrespective of its associated schedule.
This will enable to respectively Zoom In / Zoom Out the graphical display.
When "zoom in" is selected, a zoom can be achieved either by clicking the
mouse on the system window, which will zoom in a fixed amount and set the
centre of the view to the position clicked, or by sweeping an area with the
mouse which RESOLVE will then display.
The aspect ratio will be retained when an areal zoom is performed.
This will enable to automatically un-zoom all the way to the default view.
Scheduling Functions
Accelerator for Schedule | Event-Driven Scheduling.
This will enable to automatically access the event driven scheduling section,
which enables to setup conditional scheduling (IF this happens THEN perform
User Guide
this action).
Accelerator for Schedule | Scenario Manager.
This will enable to automatically access the scenario manager section, which
enables to setup different scenarios.
Forecasting Functions
Accelerator for Run | Start.
This will enable to launch a prediction forecast.
Accelerator for Run | Run Scenarios.
This will enable to launch the calculations of the scenarios specified in the
scenario manager section.
Accelerator for Run | Single Step.
This will enable to launch a single step of a prediction forecast.
The run will be paused after this single step has been performed.
Accelerator for Run | Pause.
This will enable to pause a forecast.
Accelerator for Run | Stop.
This will enable to stop a forecast.
Accelerator for Run | Single Iteration (Optimiser).
This icon is only active if the RESOLVE optimiser has been selected and will
enable to run a single optimiser iteration. The run will be paused after this.
Results Functions
Accelerator for Results | View Forecast Results (Table).
This enables to access directly the results of the latest (i.e. or even currently
running) forecast run as well as all the previously saved results under a tabular
format.
Accelerator for Results | View Forecast Plots.
This enables to access directly the results of the latest (i.e. or even currently
running) forecast run as well as all the previously saved results as plots.
40
41
RESOLVE
Accelerator for Results | View Forecast Plots (New Window).

This enables to open a new plotting section in which the results of the current
run as well as all the previously saved results can be viewed.
Accelerator for Results | View Scenario Results (Table).
This enables to access directly the results of the scenarios that have been run
under a tabular format.
Accelerator for Results | View Scenario Plots.
This enables to access directly the results of the scenarios that have been run
as plots.
Accelerator for Results | View Scenario Plots.
This enables to open a new plotting section in which the results of the
scenarios run can be viewed.
Accelerator for Results | View Optimisation Results.
This enables to access directly the optimisation results.
Accelerator for Results | View IPR Log Results.
This enables to access directly the inflow performance data coming from the
reservoir simulation models for every well at every timestep.
This is only active if the Run | IPR Logging option was previously selected.
2.4.2.3 Main Display Window
The main display window is the section of the interface where all the information required by the
user to know the status of the model and the current calculations is displayed.
When starting a RESOLVE model, the main display window will only contain one child window,
the graphical view window, which describes the connections between the different client
modules.
Several other child windows will be displayed at different stages of model building / running, as
described below:
Graphical
Window
An example of the graphical window is displayed below.
User Guide
42
This child window describes the connections between the different client
modules.
Working in this window, the user can modify the location of the different icons, as
well as mask / unmask; disable / enable or delete some connections.
New client modules can be created and connected to the already existing ones.
Double-clicking on any of the elements of that graphical window will enable to
access a screen summarising the setup of this element.
In this window, elements with an arrow coming IN the icon will be data receivers
and elements with an arrow coming OUT of the icon will be data providers, as
illustrated below.
43
RESOLVE
In this window, connections are displayed as diamond shapes.

The colour of the connection icon will describe the type of fluid flowing through
that connection: red for gas, green for oil and blue for water.
During a calculation, pointing the mouse cursor on these connection icons will
display a summary of the flowing conditions and fluid volumes through these
connections.
Calculation As soon as a calculation is launched, a calculation progress window will be

displayed, as illustrated below.
Progress
Window
User Guide
44
This window enables to provide information regarding the status of the run.
For each timestep, the following information will be displayed:
Date and length of run so far.
Order in which the required calculations are performed - The last calculation
displayed is the one that is currently being performed. As soon as this
calculation is finished, then the next calculation label will be printed.
Any modifications to the calculation performed by the user, such as stopping the
calculation as illustrated above, will appear in purple text.
Output
Log
Window
Any error messages coming from one of the applications used within the model
will appear in red text
As soon as a calculation is launched, an output log window will be displayed, as
illustrated below.
This window displays more detailed information regarding the status of the run,
both DURING and AFTER the calculations have been performed.
45
RESOLVE
The information included in this window is organised in tabs as follows:

will display the detailed timing breakdown of the run, including:
1. The exact run start and finish date / time.
2. The computing time consumed by each application - the
first duration displayed is the total computing time, the
second one (i.e. in between brackets) specifies the
computing time that could be parallelised.
3. The total computing time for all applications for both
calculations performed sequentially and in parallel.
Script
will display any messages that have been programmed in the
RESOLVE internal script
section
Clients
will display any messages such as warning or error messages
coming from non IPM modules used in the model. For
modules
instance, if an Eclipse model is used in the RESOLVE model,
section
then the Eclipse log messages will be displayed in this section
Timestepping records the evolution of the timesteps when using specific
timestepping options such as the adaptive timestepping
section
Events
records all the modifications from the original model that occur
during the run due to scheduling
section
User
is only active when a user defined optimisation routine is used
and will record messages coming from that routine
Optimiser
RESOLVE
section
User Guide
46
section
Optimisatio
n
Progress
Window
The optimisation results screen is displayed every time RESOLVE performs an

optimisation. It can also be invoked from the menu by clicking on Results |
View optimisation results. It contains information that can be useful for
debugging optimisation runs.
The body of the screen consists of four tabbed sections and a "Save Results"
section, as described below.
Table
For each iteration of the optimiser, this displays the linearised

equations for the objective function and all the constraint
equations with respect to the control variables. It also contains
the bounding values for the control variables for the current
iteration
This is only displayed while an optimisation is being perform

not displayed when optimisation results are invoked subseq
This is sometimes useful for debugging purposes to work out
why the optimiser has taken a specific action
Ctrl
(control)
This displays, for each iteration, the values that the control
variables have been set to
47
RESOLVE
Results
Fn
(function)
Results
This contains a list of the results for the objective function and
the constraint equations.
The first row represents the value of the objective function
obtained by RESOLVE following a pass through the system (i.
e. at each iteration of the optimiser). The second row contains
the value predicted for this equation by the optimiser. The third
and fourth rows contain the error term calculated from the first
two rows. This term is used to calculate new bounds for the
control variables at the next iteration.
Below this (the blue band) is the same information for each
constraint equation in turn.
Overall
Results
Save
Results
Stream
The value in green represents the current optimum found by

the optimiser. A value in red (for constraint equations)
represents a constraint violation. A value in pink is a constraint
violation that is within tolerance
At the end of the run, this will display the results for the
objective function, the constraint equations, and the controls.
More information is displayed in the panels below: the current
iteration, the convergence status, and the current optimised
solution
In the same way that forecasts results can be saved to a
separate screen, optimisation results can be too.
A screen is displayed prompting to select a label for the new
results screen.
Next time the optimisation results menu item will be prompted,
a screen similar to the following will be displayed:
User Guide
48
The left hand side contains a list of the currently saved

streams. These streams can be removed here (except for the
current results).
The right hand side contains a summary of the optimisation
run that was performed.
To display optimisation results, highlight the required results in
the left hand list and click on the display button
Additional Notes on the Display of Windows in RESOLVE

The child windows are generally displayed on top one another: clicking on one window will
automatically activate that window.
It is also possible to organise the different windows displayed by going to the "Window" section
of the main menu toolbar.
Two options are available:
Cascade
will organise all the windows one on top one another, for example:
49
RESOLVE
Tile
will re-arrange the size of the windows so that they all fit in the main
display window, for example:
User Guide
50
2.4.2.4 HelpViewer Window

The helpviewer window is located on the left-hand side of the RESOLVE main window.
It lists all the subjects that are described in the RESOLVE help sections and user guide and
enables the user to directly access one of these subjects by selecting it on the list and doubleclicking on it.
The corresponding help section will then be displayed in a new window.
2.4.2.5 System Window
The system window is located on the left-hand side of the RESOLVE main window.
By default, it is not displayed: the user will have to click on the "System" tag to display this
window.
It lists all the client modules and their corresponding data receivers and data providers.
By clicking on one of them, for instance here the "Well1" element of the "Reservoir1" client
module, a summary screen will appear describing the main characteristics of that element, as
illustrated below.
For instance, this element is labeled "Well1", it is a Well, it is a data provider and it is controlled
by system response.
51
2.5
RESOLVE
"File" Menu
2.5.1 "File" Section

The "File" section of the main menu performs the file management functions within RESOLVE.
The following options are available:
New
Open
Save
The current system is cleared and all connected clients are closed.
A new blank file is created
A RESOLVE case can be loaded from disk.
This will in turn load the client applications that this case refers to - there is no
need to have the client applications already open.
It will be required to have access to enough active licences for each application
used in the model to be opened
Saves the current RESOLVE model as a .RSL extension.
The connected applications references will be stored in the file to be reopened
when the case is reopened.
This only saves the RESOLVE file. It does NOT save the files from the application
connected through RESOLVE. For instance, if a RESOLVE model is used to link an
Eclipse deck and a GAP deck, using this option will only save the RESOLVE file, not
the GAP nor the Eclipse decks
As above, except that it enables the user to specify a new file name and / or file
location
This saves the current RESOLVE model as a .RSL extension, but it also
broadcasts a "Save Case" message to all the connected applications.
Save As
Broadcase
Save
User Guide
Close
52
For instance, if a RESOLVE model is used to link an Eclipse deck and a GAP
deck, using this Broadcase Save option will enable to automatically save the
RESOLVE file, the GAP file and the Eclipse decks under their respective names
and locations
Closes the current RESOLVE model.
The connected applications references will be closed as well
When using the PVM protocol to setup Eclipse connections, it will be
necessary to remember to close PVM using the "halt" command. If this is
not done, a file called "username.pvmd" will be saved in the C:\ecl\home
directory.
This file will need to be deleted before any further successful Eclipse
connections through RESOLVE can be established.
Please note that using the PVM protocol to establish a connection
between Eclipse and RESOLVE is not the procedure recommended by
Petroleum Experts, as PVM is not supported anymore.The
recommended protocol to establish a connection between RESOLVE and
Eclipse is the MPI protocol. Further information regarding these protocols
can be found in the "Eclipse Driver Configuration" section
This will open a case without opening the connected clients: the connections will
be displayed and the results of the run can be accessed, but a new run can not
be performed as the clients will not be active. This is useful as the opening of
client applications can be time consuming in cases where only the results are
required.
There are two options:
Allow client
If the model associated with one program instance in
RESOLVE is modified (e.g. change a GAP model from case1.
programs
gap to case2.gap) then RESOLVE will cause GAP to load
to reload if
case2.gap. It will then redisplay new icons on the screen for the
model
new model as required
changes
Never
In this case changes to the client program models will not be
reloaded by RESOLVE.
reload
If the model is modified and the file is saved, then the client
client
program models will potentially be inconsistent with the icons
programs
displayed on the RESOLVE screen. When the file is reloaded
entirely, warnings may be generated and connections lost.
Care should be used with this option
Open
(results
only)
Archive
Preferences
Print
commands
Exit
Refer to the "RESOLVE Archives"section

Refer to the "File Preferences" section
Commands for printing the system, configuring the printer driver, and previewing
the print job
Terminates the application. Any client applications will be simultaneously shut
down
53
RESOLVE
2.5.2 RESOLVE Archives

The archive options in RESOLVE allows to create an archive file of the entire RESOLVE project:
the resulting file will bear a .rsa extension and will contain both the RESOLVE file itself and all the
associated files from the different applications used in RESOLVE.
For instance, the archive file will contain the GAP, MBAL and PROSPER files when a GAP model
is used in the RESOLVE model.
When double-clicking on the .rsa file, all the files contained in the .rsa file will be extracted to the
current directory considered.
This option is extremely useful to back-up files or to send files through ftp or email.
The procedures to create a new archive and extract an existing archive are detailed below:
Archive
creation
When a model is loaded into RESOLVE, File | Archive | Create can be invoked.
This leads to a screen with the following appearance:
User Guide
54
The main list displays all the files in the model, arranged by module, with the
main RESOLVE file at the top.
The exception to this is if a model is being run remotely such that RESOLVE
cannot "see" the files in question (i.e. for instance an Eclipse model running on a
Linux machine). In this case, the files can not be added to the archive.
Additional files can be added to the archive (e.g. Word documents, Excel
spreadsheets) by clicking on Add baggage file. This invokes a multiple
selection file dialog - select the file or files that are to be added to the archive.
Click on Create archive to generate the archive. RESOLVE archives have an .
rsa extension.
Archive
extraction
For this list of files to be generated, code needs to be added to the "Application Driv
". Petroleum Experts guarantees that the Petroleum Experts developed drivers
have this functionality, and so it will always be possible to generate archives containi
the files for these applications. No such guarantees can however be made for drivers
developed by third party companies
To extract an existing archive, File | Archive | Extract should be invoked.
Alternatively, a .rsa file can be dragged onto the RESOLVE application window,
or double-clicked in Explorer.
The following screen is displayed when an archive is to be extracted.
55
RESOLVE
Files that could not be archived because they were stored remotely will be
displayed with a cross in the list of files contained in the archive.
The archive can be extracted by clicking on Extract archive.
This creates a directory browser (defaulted to the current directory). Once a
directory is selected, the files will be extracted into that directory.
Once the archive has been extracted, the option exists to immediately open the
RESOLVE file in question. By default, RESOLVE will open all the client application
files from the directory to which they were extracted
2.5.3 File Preferences

The "File Preferences" section in RESOLVE allows the user to set system-wide preferences:
these preferences will be respected for every file that is setup and used in RESOLVE.
User Guide
56
These file preferences can be opposed to model preferences that are only setup for one
specific model.
The following screen appears when selecting the File | Preferences section.
The following preferences can be setup in this screen:

Data
directory
Autosave
options
This is the directory in which RESOLVE will open the file browser when performing
a File | Open operation.
To use this option one must also check the next option: "Use data directory for
opening files"
Note that on Windows 2000 operating systems one is forced to use a data directory,
as a result of a known bug in the operating system
This option allows backup files to be made during RESOLVE runs in case of a
failure in the simulation (e.g. due to a network or license failure).
Write
thread
debug
file
When the model is next loaded, a screen will appear asking whether the backup
model or the original model should be loaded. It is also possible to change the
frequency of generation of the backup files
This option allows to generate a debug file including a detailed description of the
actions performed by RESOLVE.
This is can be useful to troubleshoot a problematic case, in which case the log file
should be sent to Petroleum Experts
57
2.6
RESOLVE
"Drivers" Menu
2.6.1 "Drivers" Section

The "Drivers" section of the main menu enables to setup the connections between RESOLVE
and the connected applications.
Two main options are available in this section of the main menu.
Register
drivers
AutoRegister
Latest
Drivers
This invokes a screen that allows to register, unregister and obtain a summary of
the driver properties for specific applications.
See the "RESOLVE Architecture"section for more information explaining the
drivers role.
See the "Driver Registration"section for more information regarding how to
register the drivers
This option enables to register the latest set of drivers that are supplied by
Petroleum Experts.
User developed drivers will not be registered with this function.
This is equivalent to going to the "Driver Registration"screen and clicking on
"Auto-register"
Drivers need to be registered every time a new major version (not build) of RESOLVE is
installed, so that the most recent drivers for each application can be loaded. The first
time RESOLVE is opened following the installation, the user will automatically be
prompted to register the drivers.
Once RESOLVE has been installed and the drivers registered, there will be no further
need to re-register the drivers unless a new version of RESOLVE is installed
2.6.2 RESOLVE Architecture

RESOLVE is built around an "application-driver" architecture as follows:
In the above picture only GAP, REVEAL, and Hysys are shown as an example.
There is a driver for every application that is linked to RESOLVE.
User Guide
58
The functionality of the program is split into two parts:

The
executable:
Resolve.exe
The drivers
This is responsible for providing an user interface and for collecting and
passing data between applications.
It also performs other basic tasks such as file input / output, data validation,
and reporting.
The scheduling is also part of the executable
Each driver, in the form of dynamic link libraries (i.e. DLLs), implements the
connection with a product by communicating with the application in question
and by passing on requests for data from RESOLVE. The form of
communication with the application is irrelevant to RESOLVE: in general,
Petroleum Experts programs will use OpenServer, other PC packages
(such as Hysys, above) will tend to use DCOM, while other programs may use
PVM or CORBA, for example.
Drivers must be registered in RESOLVE before they can be used: this can be
done from the RESOLVE front screen (see the "Driver Registration"section)
To illustrate further, consider the events that occur when an application case is loaded into
RESOLVE:
RESOLVE will tell the driver to create an instance of the required application (e.g. GAP)
and then tell the driver to load the case into the application.
RESOLVE will then ask the driver for the details of the sources and sinks exposed by
the case: this request will be passed on to the application and returned to RESOLVE to
display on the graphical window.
The structure of the drivers is "Open Source".
This means that users who would like to develop their own linkage can develop and build their
own drivers to load into RESOLVE.
For more information, please contact Petroleum Experts.
2.6.3 Driver Registration

A driver is a software component (dynamic-link library, or DLL) that is used by RESOLVE to
implement the link to a particular piece of software.
For example, there are currently drivers (that are distributed with RESOLVE) to control the links
to the Petroleum Experts products and several third party vendors products.
See the section on "RESOLVE Architecture"for more information.
In order for RESOLVE to use a driver it must be registered with the RESOLVE system.
59
RESOLVE
A new installation of RESOLVE will automatically detect and load new drivers (or more recent
drivers than the currently registered set); however, there are some circumstances in which one
may wish to register the drivers by hand, and the procedure to do so is described below.
To register RESOLVE drivers, go to Drivers | Register Drivers on the main screen.
The following screen is invoked:
Registered DLLs information

The column titles are as follows:
App. Module
DLL Path
Application
Type
Version
This is the name of the driver as it will appear in RESOLVE when an instance
is created. It is generally setup to be the name of the application considered
This is the path to the dynamic link library that implements the link between the
application considered and RESOLVE
This is an identifier given to RESOLVE, supplied by the driver, that determines
the nature of the application that is being linked. It is used by RESOLVE to
guess the "upstream" and "downstream" components of a system. This guess
can be overridden by the user before the system is executed so this identifier
is not crucial to the running of RESOLVE
The driver version number
Command buttons
The following functions can be performed through this screen:
Register
This can be used to register a new driver. When this is pressed, a screen will be
presented allowing to browse for the required driver. Once selected, RESOLVE
will check that the file has the correct format for a RESOLVE driver, and will then
add it to the above list
User Guide
Unregister
Configure
Properties
60
This function enables to unregister a driver that has been registered previously.
A driver needs to be selected in the driver list for that function to work
This button invokes a screen that allows application specific settings to be set
up. For example, the configuration screens for the GAP and Reveal drivers are
very similar, and include:
The path to the local executable of the application considered
The application startup timeout, which is the length of time RESOLVE will
wait for the application to start before calling an error. This has to be defined
for both normal and cluster startups (i.e. for instance when several
machines, organised as a cluster, are used to run different RESOLVE
scenarios for instance.)
A driver needs to be selected in the driver list for the function to work
This option invokes the screen below. It displays a summary of the driver
properties and supported features. A driver needs to be selected in the driver
list for the function to work.
The supported features can be described as follow:
61
RESOLVE
Compositional
only
This flag determines whether an application can only be run

fully compositionally (i.e. requires EOS data to run) or if it
supports black oil models as well.
For example, GAP will have this flag setup to No as it can
both run fully compositional and black oil
Can provide
This flag determines whether an application is able to
produce EOS data.
composition
For example, GAP is able to produce compositional data
through both the compositional tracking function and fully
composition runs, so this flag will be setup to Yes
Global
This flag determines whether the driver supports "Global
Optimisation" (i.e. whether constraints, controls, and an
optimisation
objective function can be retrieved into RESOLVE from a
system which is modelled with this application)
Voidage
This flag determines whether the driver supports the use of
the voidage replacement script
replacement
Variable export This flag determines whether the driver supports the export
of runtime variables within the RESOLVE results reporting
to RESOLVE
interface
Integration
This flag determines whether the driver supports the
ModelCatalogu integration with the ModelCatalogue tool
e
Cluster run
clusters (LSF/PxCluster/Other)
distribution
Allow WAG
WAG scheduling: using that type of scheduling requires the
Scheduling
application considered (i.e. generally reservoir simulation
or surface network modeling tool) to be able to dynamically
change the description of the wells from water to gas
injection..
User Guide
AutoRegister
2.7
62
This option enables to automatically register the standard set of drivers included
within RESOLVE
"Wizards" Menu
2.7.1 "Wizards" Section

The RESOLVE wizards section enables to access a certain number of utilities that assist the
user in performing common tasks.
Two main groups of wizards can be found:
IT setup
wizards
These wizards will assist the user to set up RESOLVE to perform IT type tasks
such as connection to remote applications.
63
RESOLVE
The following IT setup wizards are available:

DCOMUTIL.EXE Allows the configuration of remote connections for IPM
applications: Refer to the "DCOMUTIL.EXE" section for
further information
ECLCONFIG.
Allows the configuration of local and remote connections to
Eclipse: Refer to the "ECLCONFIG.EXE" section for
EXE
further information
LSF Configure
Allows the configuration of the LSF cluster: Refer to the "
Running Scenarios on a Cluster" section for further
information
PXCluster
Allows the configuration of the PX cluster: Refer to the "
PXCluster Overview" section for further information
Configure
PXCluster Test Allows the testing of the PX cluster: Refer to the "
PXCluster Test Utility" section for further information
Environment
Engineering These wizards will assist the RESOLVE user with some specific engineering
task, such as setting up a voidage replacement scheme for instance.
wizards
The following engineering wizards are available:
Voidage
replacement
Drilling queue
OpenServer
wizards
Perform GAP /
Eclipse
Validation
GIRO Optimiser
Performance
Execute
OpenServer
command
Allows the setup of a voidage replacement scheme within

the RESOLVE model: Refer to the "Voidage Replacement"
section for further information
Allows the setup of drilling queues based on the evolution
of user-chosen variables: Refer to the "Drilling Queue"
section for further information
This will be a repository of wizards that relate to the use of
the IPM-OS driver, which can be used to perform batch
OpenServer tasks. There is currently only one: the batch
generation of lift curves for a GAP model, either
sequentially or on a cluster
This option allows the running of the Eclipse schedule to
verify that the rates produced for each well can be handled
by the surface network model: Refer to the "Perform GAP /
Eclipse Validation" section for further information
Allows to evaluate the behaviour of the GIRO optimiser for
a particular problem as well as sensitising on the most
suitable GIRO optimiser settings: Refer to the "GIRO
Optimiser Performance" section for further information
Allows to perform one specific OpenServer command
and check its validity: Refer to the "Execute OpenServer
Statement" section for further information
User Guide
64
2.7.2 IT Setup Wizards

2.7.2.1 DCOMUTIL.EXE
This wizard invokes a utility program distributed with the IPM suite that allows the configuration
of remote connections (i.e. over a network) to IPM applications such as GAP and / or REVEAL.
These remote connections will enable to distribute the applications run for one specific
RESOLVE model on different PCs.
See the "Running IPM Instances on a Remote PC" section for more information.
2.7.2.2 ECLCONFIG.EXE
This invokes a utility program distributed with the IPM suite that allows the configuration of local
and remote connections to Eclipse 100 and Eclipse 300 on the Windows platform.
More information on this utility can be found under the section dealing with the configuration of
the Eclipse driver to connect to Eclipse instances.
2.7.3 Engineering Wizards

2.7.3.1 Voidage Replacement
2.7.3.1.1 Voidage replacement - Method
A common requirement is the ability to implement a voidage replacement scheme in one or
more reservoir simulation models.
To do this the RESOLVE system must consist of production and injection surface network
models, as well as the reservoir simulation model(s).
There are a couple of ways in which this can be done:
The simulator injection wells that are to inject the voidage volumes required can be left
unconnected in the RESOLVE system. They can then be controlled by the simulator
alone.
The voidage can be injected from an injection system modelled in GAP. To do this the
voidage requirement must first be calculated and then applied as a constraint on the
GAP injection model(s). This is normally carried out with a Visual Basic script. The
advantage of this approach is that the water injection system is physically
modeled: the user therefore has a way of checking that the injection rates
required to achieve the voidage replacement targets can physically be
achieved by the current injection system.
The voidage replacement wizard objective is to assist in setting up the second option.
The utility works by writing a visual basic script that controls the model by calculating the voidage
65
RESOLVE
volumes required and applying appropriate constraints on the injection system. For this to work
the reservoir simulator variables must be accessible from the script: this is currently only
possible in REVEAL and the Petroleum Experts implementation of the Eclipse link (i.e. the
standard driver that comes with the IPM installation).
In order to perform voidage replacement the following elements must be included in the system:
One or more reservoir simulation models connected to:
One or more production network systems, and
One or more injection network systems.
An example system, with a reservoir simulation model connected to a production and injection
system, is shown below:
The logic followed by the voidage replacement script at each timestep for such a system is as
follows:
The reservoir calculates the inflow performances for all the wells - producers and
injectors. These inflow performances are then passed to the production and injection
systems.
Before either network is solved the well data from the last simulator timestep is
analysed. The reservoir and surface volumes from the producing wells are calculated to
obtain an effective FVF for the producers. Similarly, the volumes for the injection wells
are used to find an effective FVF for the injectors.
At this time the total reservoir volume produced and the total reservoir volume injected
are obtained.
The production system is then solved. This enables to obtain the surface volumes
produced from the production system and the FVFs calculated earlier are used to
calculate a required injection rate to meet the voidage requirement.
The injection rate just calculated is optionally corrected with the difference in the
User Guide
66
cumulative reservoir volumes obtained in the third step. These differences arise
because the voidage is calculated explicitly, i.e. using FVF data from the previous
timestep.
The injection rate is now applied as a constraint on the injection system model and the
injection system is then solved. Note that as the injection is a constraint the network will
not necessarily inject all the required rate (i.e. the manifold pressure may not be high
enough). The script will output at each timestep the percentage of the voidage
replacement target that has been achieved.
2.7.3.1.2 Voidage replacement - Setup

The voidage replacement script can be setup from the Wizard | Voidage Replacement generate a VB script section.
Once this section is prompted, the following screen will appear:
67
RESOLVE
In order to setup a voidage replacement scheme using this wizard, the following procedure can
be used:
Step 1
Select the reservoir considered and its main producing phase in the left hand side
panel of the screen: this is a list of all the reservoirs in the system that support
scripted voidage replacement.
Note that it is not obligatory to set up voidage replacement for all the reservoirs: it
is possible to set it up for as many or as few as needed.
The reservoir phase will be used to determine whether to capture the gas or the
User Guide
68
liquid rates in the surface network production system.
Step 2
Step 3
Step 4
Step 5
Additionally, fallback FVFs can be chosen: these are the default FVFs that will be
used by the script as a starting point of the calculation
Add a well group using the Add button on the top right hand side of the screen.
This well group will include all the wells (i.e. producers and injectors) to consider
for one specific voidage replacement scheme.
To add wells to this well group, click on the grey square next to the well names. The
selected wells will be highlighted in red.
In the case considered here, production for Well1 and Well1_GL will be
compensated by injection from Water_Inj1, Water_Inj2, Water_Inj3 and Water_Inj4.
For the script to work it is essential that the production wells of each group are
coupled to a single production network and the injection wells of each group are
coupled to a single injection network. Production Network and Injection Network
fields display the name of the production and injection networks in question.
If the wells selected are coupled to different production or injection networks then
the corresponding field will be blank. The field will also be blank if no selection has
been made. If the field is blank when the script is generated an error will be
generated. Note that different voidage groups can be coupled to different
production and injection networks
Select the equipment to constrain in the network: this will specify which element of
the injection model is to have the voidage injection rate applied as a constraint.
It is necessary to choose a piece of equipment that will constrain all the injection
wells in the voidage group: in the example above all the injection wells are linked to
the same injection manifold, which connects to no other wells, and so the
constraint can safely be applied to this manifold. Other pieces of equipment that
could be used for this are injection manifolds, groups, or even single wells
Define the voidage fraction to be used: voidage fractions higher than 1 can be
entered, leading to the volume of fluid injected in the reservoir measured at
reservoir conditions being higher than the volume of fluid produced from the
reservoir measured at reservoir conditions.
Select the voidage method used: the normal method is to calculate a required
injection rate to replace the volume that has been produced. It is also possible to
calculate a production that will balance an injection rate. In this case, the logic of
the script will be reversed
Define the period of time over which the voidage scheme has to be applied
Once the voidage scheme has been setup, the following additional options are available:
Include correction
on voidage
injected / produced
based on
cumulative voidage
This option enable to keep track of the voidage volume required

through time.
If this option is selected, a correction to the voidage injection will be
performed that is based on the total reservoir volumes that have been
injected and produced up to this point. The reason why this might be
69
RESOLVE
Replace
current script
Include
logging
statements
in the script
code
Log warning if
injection system
does not achieve
voidage amount
Enable error
handling in script
Edit script on exit
necessary is because the FVF calculations are performed explicitly, i.e.

using the data from the previous timestep. This means that small
deviations can build up between the total voidages produced and
injected, which this option attempts to correct
This option enables to specify whether the Visual Basic script created
will replace any existing script or whether the existing script will just be
appended with the additional voidage related sections
This option enables to specify whether script logging statements will be
displayed.
These logging statements provide information regarding the voidage
fraction achieved at each timestep for instance
This option enables to specify whether warning statements have to be
displayed when the voidage fraction requested is not achieved
This option enables to generate an log message if a script error occurs

during the run
If this option is selected, the voidage script created will be displayed
when the voidage setup screen is closed
A detailed description of the script structure can be found in the "Voidage Replacement - Script
"section.
2.7.3.1.3 Voidage replacement - Script
In this section the script written by the voidage replacement wizard is described and analysed.
An understanding of the details of the script is not essential although it could be useful in
debugging or to tailor the script to specific needs.
Please see the "Scripting"section for more information on how the Visual Basic script is called
from RESOLVE.
Consider the following GAP - Eclipse model.
User Guide
70
The following voidage strategy is to be implemented: the entire production through wells PROD1
and PROD2 has to be replaced by water injection in wells W-INJ and G-INJ.
The voidage wizard will write a script in the following sections:
Declarations
PreSolve
PostSolve
StartOfTimestep
Declares global variables required by the other functions

Calculates the reservoir FVFs before the production system is solved
and applies a constraint to the injection system after the production
system is solved and the voidage requirement has been calculated
Checks that the voidage injection rate is the same as that calculated,
and outputs a warning if there is a discrepancy
Stores the current RESOLVE time
2.7.3.1.4 Voidage replacement script - Declarations

The first section written by the voidage wizard is the "Declarations" section.
For the sample model is has the following appearance:
71
RESOLVE
These are the variables that will be used by the voidage script calculation:
Tlast
MMCFtoBBL
This variable stores the current RESOLVE timestep

This variable defines a constant specifying the conversion between
MMcf (for gas rates) and BBL (for liquid rates). All the downhole
volumes are expressed in barrels and FVFs are dimensionless, and
so
surface gas rates in MMscf/day need to be converted to
downhole barrels
The next variables are repeated for each voidage group.

A voidage group is a set of related production and injection wells, where the injection wells are
required to inject a given fraction of the production voidage.
FVFProdx
FVFInjx
FVFRatiox
VoidProdx
VoidInjx
Formation volume factor for production wells, group x

Formation volume factor for injection wells, group x
Ratio of above formation volume factors
Cumulative voidage from the production wells, group x
Cumulative voidage replaced by the injection wells, group x
See also the following sections: PreSolve, PostSolve, StartOfTimestep

2.7.3.1.5 Voidage replacement script - PreSolve
This is where the main voidage parameters are calculated.
For the given example it would have the following appearance:
User Guide
72
Each section of the script is described in details below:

1. This sets up an "error handler" for the script routine. If an error occurs then execution will not
stop but a warning message will be logged at the end of the routine (part 11).
73
RESOLVE
2. The first part of the routine (parts 3 - 6) needs to be run before the production system is
solved. This "if" statement will only be "true" if this routine is being called before the
production system is solved (i.e.If ModuleList contains the string "produce", which is the
label of the production system).
3. This sets up "fallback" values for the formation volume factors. The FVFs are calculated
using data from the previous simulator timestep: if this is the first timestep the simulator
may have to rely on these default, user input, values.
4. These lines calculate the total downhole production from the group of wells and the total
surface production, and hence calculates an effective production FVF. In this case the
reservoir fluids are oil and water, although FVFs with respect to gas production can be
calculated also.
5. This is performing the same function for the injection wells. Here the injection fluid is water
although gas is also allowed. An effective injection FVF is calculated and, for convenience,
the ratio between the production and injection FVFs.
6. This calculates the cumulative downhole production and injection, which can be used to
adjust the injection in the next timestep (part 9).
7. The next part of the routine is called after the production system is calculated and before the
injection system is called. This line ensures that parts 8 - 11 are only called after the
production system is solved.
User Guide
74
8. This calculates the surface rate from the production wells as calculated by the GAP
production system to be applied to the simulator for the next timestep. It then uses the FVFs
calculated above to determine the correct surface total injection rate for the injection wells.
9. This adjusts the injection calculated in part 8 to account for the current error between the
voidage produced and the voidage injected (the error arises from the fact that the FVFs are
being calculated on data from the previous timestep). Note that the dT here is the previous
timestep length and so this scheme may not work well in adaptive timestepping models.
Note also that this is optional, and is governed by the setting in part (7) of the "Voidage
Replacement Wizard"screen.
10. This takes the required surface injection rate calculated in parts 8 and 9 and applies it as a
constraint on the GAP injection model. The piece of equipment specified in the
OpenServer tag string must represent an item that can constrain all the injection wells in
the voidage group together. In this case "J3" is a manifold that is common to all the wells: it
could equally be an injection manifold, a group, or even a single well if there is only a single
injection well in the voidage group.
11. The error handler set in part 1 will set an error number and description if an error occurs in
the script code. At this part any error is recorded to the RESOLVE log window.
See also the following sections: Declarations, PostSolve, StartOfTimestep
2.7.3.1.6 Voidage replacement script - PostSolve

This is called after the entire system has been solved and is used to check that the required
amount of voidage has actually been injected by the model.
If the injection manifold pressure is not high enough, or there are some other constraints in the
injection model, it is possible that the surface network, modelled in GAP, will not be able to inject
all that it needs to to maintain voidage.
75
RESOLVE
The script is fairly self-explanatory: the initial "if" statement ensures that this code is only called
after the injection system is solved. Following this, both the injection rate that was applied as a
constraint and the rate actually injected are obtained and then compared.
Any discrepancy is logged to the calculation screen.
See also the following sections: Declarations, PreSolve, StartOfTimestep
2.7.3.1.7 Voidage replacement script - StartOfTimestep

This is a simple function that is called after the system has completed all the solves and before a
new timestep is taken.
It is used simply to record the date at this timestep to allow RESOLVE to calculate the timestep
length at the end of the timestep.
User Guide
76
See also the following sections: Declarations, PreSolve, PostSolve.
2.7.3.2 Drilling Queue

The drilling queue wizard enables to setup drilling schedules in the system based on the values
of certain user-specified variables.
For instance, one can specify that a certain well has to be opened when the total system
production falls below the plateau rate.
This wizard does not edit a Visual Basic script as per the voidage replacement script, but will
automatically edit the event driven scheduling section of RESOLVE.
The procedure to setup this wizard will be demonstrated using the following example:
The RESOLVE archive file for this example can be found at the following location:
C:\Program Files\Petroleum Experts\IPM 7.5\Samples\Resolve\Drilling_Queue and is
saved as Drilling_Queue.rsa
77
RESOLVE
The plateau rate for this field is 28,000 STB/d.

The Well1_GL is initially closed, and we want to know when will it need to come online to keep
the plateau production as long as possible.
The wizard setup can be used as follow to achieve this:
Step 1
The drilling queue script can be setup from the Wizard | Drilling Queue populate event driven schedule section.
The following screen will then be prompted:
User Guide
Step 2
78
This screen enables to define a drilling queue label, and the GAP module to which it
is related
Select the system node that is going to be used as the constrained node: a variable
of this node will be monitored and the value of this variable could be used to trigger
one specific action.
In the case considered, this node will be the separator: the production at separator
has to be monitored and trigger the opening of Well1_GL when this falls below a
certain level.
Select the system nodes that are going to be used as control nodes: the status of
these nodes during the forecast will be changed based on the value of the variable
monitored.
In the case considered, these nodes are the wells Well1 and Well1_GL.
79
Step 3
RESOLVE
Select the type and value of the target variable considered: in this case, it is the
liquid rate at the separator level. It needs to be maintained at 29,000 STB/d.
A tolerance of 15 STB/d has been set to avoid the well being put online if the solver
comes back with a separator production of 28,999 STB/d for instance, which might
just be due to the solver tolerances in GAP and will not be representative of a lower
system potential.
Select the nodes that are initially active in the model, here for instance the well
Well1, as well as the number of nodes to be activated each time the target rate is
violated.
User Guide
Step 4
80
Once these steps have been fulfilled, the drilling queue will be setup and the event
driven scheduling section will be modified to accommodate the drilling queue setup
The model can then be run and the following results observed:
81
RESOLVE
As soon as the initial system setup (i.e. Well1_GL closed) can not produce the
target rate of 29,000 STB/d, the Well1_GL well will be open.
It is possible to notice in the Events section of the RESOLVE output log that:
The Well1_GL is masked at the start of the prediction.
The Well1_GL is opened on the 01/04/2006, first date at which the
production is lower than the prediction target rate.
User Guide
82
2.7.3.3 OpenServer wizards

This is to be a repository for wizards that relate to the user of the IPM-OS driver, for automating
batch OpenServer tasks.
There is currently only one wizard. This is for the batch generation of lift curves from a GAP
model.
83
RESOLVE
The GAP model in question should be loaded into the field at the top of the screen.
Note: if the need is to generate lift curves in parallel, across the nodes of a cluster, then
it is essential that the GAP model is on a network drive that can be seen from all nodes
(with the same path structure), and that the PROSPER files referred to in the GAP model
are similarly visible.
The wizard takes the user through three steps:
Step 1
Step 2
Step 3
A new RESOLVE case is created. The GAP model is loaded into RESOLVE (as a
module in the main screen) and the underlying PROSPER models are extracted
The PROSPER models are used to generate scenarios under the RESOLVE
scenario manager. Each scenario represents the generation of a different
PROSPER lift curve
The scenarios are run and the resulting TPD files are imported into GAP (which is
again loaded into RESOLVE). The scenarios may be run sequentially, although this
User Guide
84
is not doing anything that could not be done equally easily from the GAP application
itself
2.7.3.4 Perform GAP - Eclipse Validation
The "Perform GAP-Eclipse Validation" option allows a connection between a reservoir
simulation model in Eclipse and a surface network model in GAP to be tested. In this case, the
wells are controlled from the normal Eclipse production strategies (rather than the GAP solver/
optimisation), and RESOLVE is merely used to test that the given rate is able to flow through the
network.
The main objective of this calculation will be to check that the production rates
specified in the schedule section of the reservoir model can physically be produced
through the surface network in use.
This validation can be launched by using the "Play" button at the bottom left hand corner of the
screen, as illustrated below.
First of all, the Eclipse data file path can be used to point the RESOLVE model to use a different
data deck to the one specified in the model setup. This may be necessary as Eclipse decks are
often modified to remove the group controls that are to be tested with this tool.
85
RESOLVE
During the calculation, RESOLVE will run the reservoir model based on the schedule defined in
the reservoir model itself: the Eclipse model will be run based on the SCHEDULE defined in the
Eclipse data deck.
At each timestep, the production rates produced from the reservoir based on the reservoir
model schedule will be passed directly to the surface network model in GAP. In addition, any
artificial lift quantities (ALQs) will be passed; the type of ALQ should be specified for each
Eclipse module in the table at the top of the screen. GAP will perform a solve network calculation
with no optimisation. The bottom-hole flowing pressure and tubing head pressure calculated by
GAP for each well will be stored in RESOLVE for each well at every timestep. These pressures
can then be compared with the equivalent pressures (WBHP and WTHP, where present) in the
Eclipse model.
In many cases, a comparison of tubing head pressures is most useful. The THP calculated by
GAP will be a function only of the network downstream of the well heads, and so will be
independent of the well lift curves. This comparison thus gives an immediate indication of a well
rate can be produced.
If there are no lift curves in the Eclipse model then a comparison of BHP's can be made. The
GAP-calculated BHP obviously depends on the downstream network and the well lift curves.
If the THP/BHP calculated by the GAP surface network model is lower than the THP/BHP
calculated by the reservoir model, then the production rates specified in the reservoir model can
be successfully produced through the surface network in use. In other words it would be
possible, in principle, to choke the well back in order to match the THP/BHP recorded by
Eclipse. Nothing is then reported in the above screen.
If the THP/BHP calculated by the surface network GAP model is higher than the THP/BHP
calculated by the reservoir model, then the drawdown required to produce the production rate
calculated by the reservoir model can not be achieved through the surface network, and
therefore will not be representative of the behaviour of the real system.
For each well, the dates at which this situation will be encountered will be reported in the
"Flagged wells" section of the "GAP - Eclipse validation wizard". Wells can be flagged on the
basis of THP, or BHP, or both.
For instance, in the model illustrated above, the well prod2(PROD2) has a GAP BHP higher than
the Eclipse BHP on several dates in 2000. The THP is also reported, although the figure
calculated (-14.696) is indicative of an Eclipse model without lift curves. This will indicate to the
user that at these specific dates, the production schedule specified in the reservoir model for
that particular well is INCONSISTENT with the capacity / performance of the surface network
model.
All the results for Eclipse flowing pressures, GAP flowing pressures, and the differences
between the pressures, are stored in the main RESOLVE reporting data under a separate folder
User Guide
86
(GAP-Ecl validation):
2.7.3.5 GIRO Optimiser Performance

If the GIRO optimiser is being used for routing or integer problems, then this wizard can be used
to analyse its performance and understand the sensitivity of the model to the various input
parameters. This is a useful, one-off, first step that can be used prior to the carrying out of an
optimisation study. More information on the GIRO optimiser can be found here.
Typically, it will take some time for the wizard to run and accumulate all the required data. This is
normally something that can be run overnight, or in some idle period.
The wizard has the following appearance:
87
RESOLVE
The screen is divided into several different sections:

Sensitivity
variables
These are the inputs that parameterise the model, and are typically the 'levers'
which can be used potentially to tune the performance of the optimisation. The
values shown in the screen above are good defaults for most studies.
When the wizard is executed, RESOLVE will make runs with all combinations of
these values. In the above case, this equates to 2x1x1=2 separate runs.
User Guide
88

Number of
Each of the above combinations can be run multiple times
evaluations per to reduce any distortion as a result of a rogue run. A value
of '20' evaluations per combination means that the wizard
combination
will run 2x20=40 separate runs
Do baseline
This provides a baseline which is generated on the basis of
a pure-random set of configurations. The aim is to give a
calculation
clear idea of the benefit of using GIRO compared to the
random approach.
If this is selected, the optimiser will be forced to make 3
different evaluations with a given number of random
iterations. The number of random iterations is chosen from
the range of iterations used when GIRO was run 'nonrandomly'.
Reset/Clear
OK
Cancel
Start arrow
Stop arrow
Results
A total of 5 different values for the iteration number are used

to form the baseline. This equates to 5x3=15 random runs,
meaning a total of 40+15=55 separate runs set up from the
wizard as displayed above
These buttons reset the settings to the 'factory defaults', or
alternatively clear the data
This saves any data which has been accumulated so that it
may be displayed next time the wizard is invoked
This exits the wizard without saving any data
This starts the sequence of runs. A warning message is
displayed initially to warn of the number of runs that will be
executed
This interrupts the execution prematurely
This section of the screen displays a scatter plot of the results of the individual
optimisations. The optimiser objective function is displayed in the left hand axis;
the number of iterations to obtain that result is displayed across the horizontal
axis.
If the mouse is held over a data point, a panel is displayed which gives the input
(sensitivity) parameters for the run in question along with the corresponding
value of the objective function.
To give an idea of the clustering of the points with respect to the different
sensitivity values, the points can be coloured according to the different values of
the sensitivity variables. This is achieved by changing the setting in the drop
down list at the bottom of the screen. All points with the same value of the
selected sensitivity variable will be drawn in the same colour.
89
RESOLVE

Filter
Statistics
Reporting
This allows points to be removed or added to the plot for

clarity. A grid is presented with the sensitivity variable
values used in the run: these may be selected or
deselected. RESOLVE will then only display those points
which are in the combined set of the selected variables
This displays statistics relating to the run which has been
performed and is which is plotted in the wizard
This allows the data to be reported/exported as required
2.7.3.6 Execute OpenServer Statement

The "Execute OpenServer Statement" wizard allows the user to test the impact or syntax of one
specific OpenServer variable / command.
An OpenServer command or variable can be entered in the string section. This string must
correspond to a DoGet, a DoSet, or a DoCommand: this should be selected above.
Selecting the Evaluate button will run the OpenServer command considered.
The left hand side of the screen includes a list of the OpenServer commands available in
RESOLVE along with their arguments.
An "=" sign represents a default argument: if the argument is not set explicitly in the command,
the value shown will be used.
User Guide
2.8
90
"Options" Menu
The RESOLVE options section allows the setup of the global options of the RESOLVE model.
The menu is divided into the following input fields:
System
Options
Lumping /
Delumping
Units
Colours
This is the section that defines the type of model and run to perform, as well as the
options of visualisation (see System Options topic)
This is the section that enables to pass from a black oil to a compositional model
or from a simple compositional model (i.e. for instance only using 5 pseudocomponents to describe the fluid, as required by reservoir simulation models) to a
complex compositional model (i.e. with a higher number of components, as
required by process models) without losing any accuracy on the fluid description
and properties.
This is an essential capability as it keeps the fluid PVT description consistent from
one application to another while respecting the ideal PVT requirements of each
module used (see Lumping/Delumping topic)
RESOLVE uses the same procedure as all the other IPM tools to describe the
units used.
Different default sets of units can be selected by the user (the IPM default being
oilfield units), and the user can create his own set of units.
Input and output units are independent for all variables and validation ranges are
set to prevent the use of non-sensible values for certain variables.
If the value entered for a variable is out of range, RESOLVE will display a
validation error.
Please refer to the PROSPER User Guide to obtain additional information
regarding the use of the Units section
Two choices of colours are available for the connections icon:
Standard
By Fluid
Bitmaps
This set of colours uses a single colour for all the connections
This set of colours allows the colour of the connection to match
the type of fluid passed through the connection: for instance an
oil will be green, but the more the WC increases, the more blue
will be mixed with the initial green colour of the connection
This section enables to import a bitmap file and replace any of the icons from the
different modules used by a user selected picture
2.8.1 System Options

This screen allows certain properties of the system display and runtime mode to be changed
When Options | System options is selected from the main menu, the following screen is
invoked.
91
RESOLVE
The model properties that can be modified from this screen are separated in two sections:
Run Properties
System View
will affect the way the calculations are being run in the RESOLVE model
will affect the way the model is displayed
The "" section that and the "" section that .

Detailed descriptions of the options available for both these sections can be found below.
Run Properties
Forecast
Three different running models are available:
User Guide
92
mode
Full Forecast This enables to run a prediction forecast. This is the default
setting
Full Forecast
with Global
Optimisation
Single Solve /
Optimisation
Visual Basic
scripting
Run
initialisation
This enables to run a prediction forecast with the RESOLVE

optimiser being activated at each timestep
This enables to solve the system at one specific point in
time. The RESOLVE optimiser is activated. This can be
particularly useful when studying the behaviour of a system
where a GAP model is linked to a process model for
instance
This will enable or disable the "Visual Basic Script" in RESOLVE. If it is

disabled, the script subroutines will not be called during the run
This option enables to specify whether the client modules included in the
RESOLVE model are reloaded at the start of the run.
Reloading the client modules at the start of a run is generally recommended:
this will for instance ensure that if the models are modified (i.e. by a schedule
entry for instance) at the beginning of the forecast, they will be correctly
initialised.
However, in some cases where the client modules do not need to be reinitialised, the reload procedure is just time-consuming and can be skipped,
therefore selecting the "Do not reload clients modules" option can be
recommended. If this option is used, the status of the models used at the start
of the prediction will be exactly the same as the status of the models currently
open on the machine
Parallelisation This option enables the user to select whether the RESOLVE calculations are
run sequentially or in parallel.
It is generally recommended to perform calculations in parallel wherever
possible as this will cut down the model run time.
For example, if two reservoir simulators were connected to a surface network,
it would be desirable to run the simulation timesteps in parallel.
Validation
The default setup is to run the calculation in parallel whenever possible,

however the user can decide to modify that setting to run all the calculations
sequentially
This option enables the user to choose whether the non-fatal validation errors
are displayed prior to launching a calculation.
By default, these warnings will be ignored.
If the user chooses not to ignore non-fatal validation errors, RESOLVE will
present a screen at run-time that will display any non-fatal validation errors in
93
RESOLVE
Debug
logging
Reporting
Optimiser/
target solver
failure
the system.
Such errors would be for instance a node that is not connected to another
node: this is not going to stop the system from running, but could be a
reminder that the system is incomplete
This option can be activated to create a log file with the data that is passed
between applications.
This is essentially used for debugging purposes
From IPM #7 onwards, a new reporting structure is used that enable to store
the results of the variables selected by the user in each module separately to
the connection results.
Should the user wish to return to the old reporting system, this can be done by
changing this option to "Use old reporting system"
If the solver calculation in any of the connected applications fails for some
reason, this option allows to either carry on running the calculations or to stop
the forecast
System View
Title
Label fonts
Background
bitmap
This controls the display of a system title on the main screen.

To give the system a title, enter the title in the text box supplied and select the
"Display Title" tick box. The font for the title can be changed by pressing the
Title Font button. The system title information is saved with the RESOLVE file
Press the Label Font button to change the font that is used to label the icons
on the main RESOLVE screen
A bitmap can be displayed on the back of the graphical view. Click on the
Background Bitmap button to browse for a bitmap to display.
The Clear button can be used to remove a bitmap
2.8.2 Lumping / Delumping

Lumping / delumping options enable passing from a black oil to a compositional model or from
a simple compositional model (i.e. for instance only using 5 pseudo-components to describe the
fluid, as required by reservoir simulation models) to a complex compositional model (i.e. with a
higher number of components, as required by process models) without losing any accuracy on
the fluid description and properties.
This is an essential capability as it keeps the fluid PVT description consistent from one
application to another while respecting the ideal PVT requirements of each module used.
RESOLVE can use the lumping / delumping procedure from GAP itself if a GAP model is part of
the RESOLVE project. If there is no GAP model within the RESOLVE project, then it will be
possible to use the same lumping / delumping procedure that is available in GAP directly within
RESOLVE itself.
User Guide
94
Further information on the different options available for the lumping / delumping procedure can
be found in the "Lumping / Delumping" section as well as in the "Example 5.2: Lumping /
Delumping Example".
2.8.2.1 PVT Within RESOLVE: Importance of PVT Consistency in Full-Field Models
One of the most important elements to consider when an integrated model is setup is the
consistency of the PVT models used in the different connected applications.
Effectively, the fluid flowing through the system from the reservoir to the plant is the same.
However, when considering the modeling aspects, each module will have its own PVT
requirements: for instance, reservoir models are essentially focusing on volumetric aspects,
hence a black oil PVT model will therefore be suitable, whereas process models are focusing
on thermodynamic properties and will require a full compositional description of the fluid.
The main challenge is to be able to make these different PVT descriptions consistent
within the full-field model.
The techniques used to do so are described below, along with different examples.
For an integrated model linking for instance reservoir, surface network and process simulator
models, it will be important to consider the following elements when defining the way the fluid
PVT is going to be described:
Consistency
Mixing
Accuracy
The PVT description of one fluid needs to be consistent from one

model to the other: the fluid description in the reservoir simulator has to
be the same than the fluid description in the well models for instance: this
will ensure the PVT properties used to calculate the VLP curves for the
well are identical to the PVT properties used to calculate pressure drops
in the reservoir / surface network for instance
If several fluids are to be mixed, the PVT description of these fluids,
specifically when using fully compositional description should
allow them to be mixed. Recommendations on how PVT
characterisations can be handled when considering a full-field model can
be found in the 'Recommendation for PVT characterisations' section
In addition to these two elements, the PVT models used in each
application should provide the user with the best compromise
between PVT accuracy, model requirements with regards to PVT
and runtime
Effectively, if a reservoir / surface / process full-field model is setup, each of these three
applications will have different requirements when it comes to PVT modelling and the usage it
makes of it.
The text below illustrates the needs of each type of model with regards to PVT.
95
RESOLVE
RESERVOIR LEVEL
PVT model
requirement
At the reservoir level, the PVT parameters having the most impact are the
parameters describing fluid expansion: oil, gas and water FVF.
For this reason, the main objective of a reservoir PVT model will be to
provide an accurate description of these parameters at different pressure
and temperatures
Possible types of Based on the elements above, both a black oil or a fully compositional
PVT description model can be used in the reservoir model
Limitations
If a black oil model is used, then the fluid compositions within the reservoir
are not monitored.
If a fully compositional model is used, then the number of components that
can be used in the PVT description are limited: too large compositional
descriptions will lead to very large running times. Moreover, an extremely
detailed compositional description is not required to achieve the
objectives of the reservoir PVT model.
Most of the time, a compositional description that is used in a reservoir
model will only include 5 or 6 groups of components. This type of
composition will be referred to below as a "lumped composition"
SURFACE NETWORK LEVEL
PVT model
requirement
At the well / surface network level, the PVT parameters having the most
impact are the fluid densities, due to their large impact on pressure losses
along the wellbores / in the pipeline
For this reason, the main objective of a well / surface PVT model will be to
provide an accurate description of these parameters at different pressure
and temperatures
Possible types of Based on the elements above, both a black oil or a fully compositional
PVT description model can be used in the well / surface model.
GAP also allows for a third option, the compositional tracking option,
where all the calculations are based on the black oil PVT model, but the
evolution of the fluid composition is also calculated along the surface
network. This can obtain the best of both worlds: speed and accuracy of
the black oil and fluid composition from the compositional model
Limitations
There are no limitations as such, however it is important to note that is a
compositional model is used, then both a "reservoir" type description or a
more detailed description of the composition can be used, as the impact
of the number of components on the runtime is less important than in a
reservoir model
PROCESS LEVEL
PVT model
requirement
At the process level, a detailed description of the fluid composition at

every point of the system is required
User Guide
96
Possible types of Fully compositional model is used in the process model

PVT description
Limitations
The description of the fluid composition has to be detailed for most of the
process models to be producing physically meaningful results
The diagram below summarise the different possible PVT model combinations that can be used
when setting-up a reservoir / surface network / process full-field model.
In order to make sure the PVT is consistent, different techniques can be used to connect these
different PVT models.
Three techniques are available in RESOLVE:
Data Passing
Black Oil
Delumping
This exchanges PVT data between two applications using the same type
of PVT description: for instance, passing PVT data from a reservoir model
using a black oil PVT description to a surface network model using black
oil PVT description
This allows the exchange of PVT data between two applications, one
using a black oil and one using a compositional description (whether the
compositional model uses a lumped or detailed composition is irrelevant).
For instance, this could be used to pass PVT data from a surface network
97
RESOLVE
Lumping /
Delumping
model using a black oil PVT description to a reservoir model using a

compositional description
This allows the exchange of PVT data between two applications using
different types of compositional description: for instance, this could be
used to pass PVT data from a reservoir model using a lumped
compositional description to a surface network model using a detailed
compositional description.
Insights on the technical aspects of this technique can be found in the "
Lumping / Delumping Technical Overview" section
It is important to note that all these techniques will ensure that the PVT properties of the fluid are
the same, whatever PVT description is used: there is NO loss of accuracy when the data
exchange is performed.
In one single model, these techniques are very often combined to be able to maintain PVT
consistency throughout the model.
For instance, a RESOLVE model using a reservoir model with a black oil PVT description, a
surface network model with a black oil PVT description and a process model using a detailed
compositional description will use both the data passing and the black oil delumping techniques,
as illustrated below.
User Guide
98
Another example could be a RESOLVE model using a reservoir model with a lumped
compositional description, linked to a surface network model using a lumped compositional
description and a process model using a detailed compositional description. The model will
then use both the data passing and the lumping / delumping techniques to ensure PVT
consistency across the applications.
99
RESOLVE
All the possible combinations and the different techniques used to ensure PVT consistency are
described in the diagram below:
User Guide
100
2.8.2.2 Recommendations for PVT Characterisations

When setting up a full-field RESOLVE model, the following considerations have to be taken into
account when the PVT models to be used are being defined.
Pure component properties cannot be used as match parameters.
Surface simulators, in general, do not allow these components to be altered.
Additionally, if two fluids are to be mixed in the surface network, and the properties
defined for C1 (for instance) are different in the two fluids, mixing the two fluids will lead to
erroneous PVT properties for the resulting fluid being calculated.
All pure components isomers e.g. nC4 and iC4 should be kept separate to
allow identification and separation in the surface simulator.
More pseudo components are used for all fluids. This gives more flexibility when
characterising the equation of state for the fluid. The surface simulation may also
101
RESOLVE
require more heavy ends to model the separation processes effectively.

This has to be considered carefully for the following reasons: a fully compositional
reservoir model will require a relatively small number of pseudo-components to be
specified in order to obtain the correct PVT variables for its calculations to be performed.
So does a surface network model. However, a process model will require a more
detailed description of the components present in the fluid to perform accurate
calculations.
It is therefore possible to see that the format of the EOS model used for one specific fluid
will need to be different for different applications.
One could use a detailed description of the fluid (i.e. suitable for the process model) in
the entire system, however, the larger the number of components, the slower the run will
be.
This is the reason why the lumping / delumping process has been developed: to be able
for instance to use a "simple" EOS model for the reservoir / surface network model and
make this description more detailed when passing the fluid composition from the surface
network to the process model.
This delumping process is able to keep the fluid properties constant between the two
fluid descriptions.
Since some of the process simulators do not at this time support Volume Shift, it is
common practice within surface facility modeling to use the Costald method of oil
density estimation as an alternative. This is available within PVTp as a direct
comparison to the calculated Equation of State value.
The lack of a blending function within the surface simulator may require the build
up of a composition which contains all the pseudos within the gathering network.
2.8.2.3 Lumping / Delumping Technical Overview
The idea behind compositional lumping / de-lumping is to have a methodology that is able to
pass from an extended composition (i.e. referred as de-lumped or "full" in the following text) to a
reduced one (i.e referred as lumped or grouped in the following text) and vice-versa consistently,
that is to say, preserving the quality of the characterisation.
This means that at any point in time the full and the lumped compositions will be equivalent and
representative of the real fluid. In general when creating two characterisations of the same fluid,
by definition they will not give the same answers.
However, lumping / de-lumping has to make sure that the important properties are consistent, so
that calculation speed and accuracy are both satisfactory.
In IPM this is achieved by means of the so-called "Lumping Rule", which is a piece of logic that
defines the mechanisms to pass from the full to the lumped composition.
User Guide
102
The "Lumping Rule" is created at the stage of building the EOS model using Petroleum
Experts PVT package PVTp.
PVTp has all the facilities to create and quality check the couple full / lumped compositions and
to create the "Lumping Rule".
An example of a possible "Lumping Rule" is reported below:
In RESOLVE it is possible to import a "Lumping Rule", which is then used to generate the
lumped (or the full) composition when desired. It is then possible to decide whether to run the
calculations with the full or with the lumped composition.
The lumping / delumping options available in RESOLVE are detailed in the "Lumping /
Delumping Options" section, and worked examples using the lumping / delumping capacities
can be found in the "Worked Examples" section.
2.8.2.4 Compositional PVT Models Description

This section defines the major options used to handle equation of state (EOS) PVT modeling
within a RESOLVE model.
The following screen will be displayed:
103
RESOLVE
A description of the options available to define the EOS model can be found below:
General
These options enable to define the type of EOS used in the model:
EOS Model
Optimisation
Mode
Peng Robinson (i.e. PR) or Soave Redlich Kwong (i.e.

SRK)
None, Low or Medium
Over the past few years, Petroleum Experts PVT
experts have been working on ways to speed up the
calculation of properties from an EOS model. Speed
User Guide
Optimise
Repeat
Calculations
Reference Data
for Standard
Conditions
Volume Shift
Lumping
104
is one of the main issues with fully compositional

models and the options in this field will define the
speed of calculations.
The objective of this option is to speed up the
calculations without penalising the accuracy the
results. The medium optimisation mode enables to
obtain the fastest EOS calculation possible when
using the IPM suite
When repetitive calculations are performed, this option
can be selected to reduce the number of
compositional calculations performed (increase of
speed by up to 40 times). This option is particularly
useful when running with Black Oil Compositional
Lumping/Delumping: the determination of the
equivalent black oil model is done only when the
composition changes. If the composition does not
change, that means that the black oil properties
remain indeed the same, hence it is not required to
use the EOS to re-calculate the black oil properties
This section defines the temperature and pressure at which the results are
referenced
This section enables to enable or disable the use of volume shift in the
EOS model, for both the full and lumped compositions
This option allows to activate the fully compositional Lumping / Delumping
capabilities.
Allow Lumping
RESOLVE uses EOS calculations only in the context of

lumping and delumping, and so Yes is selected
automatically. This means that each fluid in the system
can be characterised by two equivalent EOS
compositions, a full (i.e. high number of components)
105
RESOLVE
and a lumped (i.e. reduced number of components)

and the user can decide which one to use for the
calculations and to pass from one to the other
consistently: see the "Lumping / Delumping Technical
Overview" section for further details
Mode
Master Rule
More Lumping
Blending
This option is not relevant to RESOLVE, and so is

greyed out
This field allows to select the Master Rule used to
perform Lumping / Delumping. The Master Rule can
be created or imported from PVTP and contains the
logic followed to pass from an extended compositon to
a lumped one (lumping) and viceversa (delumping)
This section defines the Lumping Rule used in the
RESOLVE model. See the "More Lumping" section for
further details
This is not currently relevant to RESOLVE, but is included here as it is a

useful discussion on how blending occurs in the network software (GAP).
Component pairs can be taken as selected for blending based on their
NAMES only or on a combination of their NAMES and PROPERTIES. The
property principally considered is the Molecular Weight of the individual
components.
Traditionally when using GAP / RESOLVE in compositional mode, it was
required that all the fluids have the same number of components. The
blending of the streams was then done sequentially through the
components.
It is now possible to model a situation where there are unequal number of
components in the fluids. The blending of the components would then be
performed based on the option selected in the "Match Components By"
section.
The "Use Number of Components as Key" option is used in a situation
when the fluids each have the same number of components, but the
properties of these fluids are different. This requires that each of the
components be treated separately in the combined fluid. In this case, the
"Use Number of Components as Key" must be switched to "NO".
This can be further explained with the following example:
A system is considered where three wells producing into the separator.
The wells have the following compositions:
Well1
A1
Well2
A4
Well3
A7
User Guide
A2
A3
Phase Check
Path to Surface
and Recycle
A5
A6
106
A8
A9
If the "Use Number of Components as Key" is set to "YES" the blended

stream will have only three components.
If this option is set to "NO" then the blended stream will have nine
components
As a quick measure of phase the average molecular weight of a fluid is
calculated and compared a test value. If the molecular weight is less than
the test the fluid is assumed to be a gas. The test value can be entered on
a file by file basis using the edit box provided
This option dictates the path taken be the oil and/or gas to surface.
It therefore sets the calculation method for all path sensitive variables such
as:
GOR
CGR
Oil FVF
Oil API
Separator Gas Gravity
Accumulated Gas Composition
Stock tank oil API
The user can select either a straight flash to stock tank or to send the fluid
through a train of up to 10 separators.
The final option is to replace the separator train with a set of overall or
stage K Values
2.8.2.5 More Lumping

The More Lumping button allows to access the Lump Option Dialog, where Lumping Rules and
associated settings can be edited.
107
RESOLVE
The Lump Options available are:

Lump
Rules
Lumping
Rules
This section allows to select the Master Rule used throughout the
RESOLVE model
This contains a table with the list of lumping Rules imported in the
RESOLVE model.
By selecting 'Select', the Lumping Rule may be imported/exported, viewed
or edited:
User Guide
108
In the Lumping Rules Summary Dialog section the lumps are described
(for example, in the figure above the first lump is N2C1, which is given by
the sum of N2 and C1), giving the correspondence between the lumped
and the full composition.
At the top right of the screen a BIC Multiplier is reported, This is a multiplier
to the Bi coefficients of the lumped composition, which is a methodology
available to make sure that the lumped composition reproduces the same
saturation pressure as the full composition.
The Setup button allows to define the logic behind each lump, for example:
109
RESOLVE
General
This section allow to select the options for Lumping / Delumping.

Allow Lumping and Mode are the same as reported in the main EOS
Setup section: "Compositional PVT Models Description".
The other options are defined below:
Seps
Use Full
Composition
for Enthalpies
DeLumping
It is possible to perform Lumping/Delumping using

gas and oil obtained by flashing the fluid straight to
Stock Tank or through separator stages
One of the main reasons why surface and process
models need to have a large number of components
is that thermal calculations (i.e. heat capacities,
enthalpies) require a very detailed composition in
order to be accurate.
This option forces the program to use the full
composition every time enthalpies need to be
calculated, and should always be selected
This section allows to define the techniques used to Delump a lumped

composition, as described below:
DeLump
Method
This option defines the method used to determine a full

composition from a lumped one.
Three main options are available:
Use DeLump
Rule
and Target
GOR
This option uses the Lumping Rule to delump the

composition, along with the Target GOR method
sure to reproduce the lumped composition's GO
option is default and also recommended
User Guide
Use
Target GOR
Only
Use DeLump
Rule Only
110
This option makes sure that the full composition

matched the GOR of the lumped composition
Only the Lumping Rule is applied
Hold C1
This option makes sure that the C1 amount is preserved
when passing from the de-lumped to the lumped
Group in
DeLumping composition. This is useful to quality check
Lumping
This section allows to define the techniques used to Lump a full

composition.
Lump
Method
This option defines the method to determine the lumped

composition from the full.
The options are the same as in the DeLump Method
options
2.8.2.6 Lumping / Delumping Module Fluid Characterisations

If the lumping / delumping capabilities of RESOLVE have to be used, this section will enable the
user to specify the fully compositional PVT descriptions available for each model.
This section can be accessed through the Options | Lumping / Delumping | Module Fluid
Characterisations and leads to the following screen being displayed:
For each module included in the RESOLVE model, a specific tab will be created.
111
RESOLVE
The following options are therefore available for each module:

Setup
This section allows the import of the fully compositional PVT description of
the fluid as defined in the module considered.
The format in which the fluid PVT description has to be imported is the
PVTp .prp format.
Once the PVT description has been imported, the Setup screen will be as
follows:
User Guide
112
In this particular case, the .prp file includes two compositions for the
reservoir fluid: a lumped and a full composition.
Import
Clear
Component
name
mapping
for
lumping /
delumping
This enables to directly import the PVT description

from the module considered
This enables to clear the current PVT description
If the lump rule for a fluid includes lumps defined by component name, then it
may be necessary to identify fluid names in the module in question.
For example, a lump rule may specify that N2 and C1 form a lump called
'N2C1'. A Hysys module (for example) will refer to these components as
'Nitrogen' and 'Methane', and so prior to performing the lump procedure the
long (Hysys) names will have to be substituted by the short names.
The screen below allows these correspondences to be made.
113
RESOLVE
2.8.3 Process Independence in Resolve models

2.8.3.1 Introduction
The coupling between reservoir simulators and surface network applications (typically GAP), as
explained above, has typically worked through the exchange of surface volumetric rates. In other
words, the surface rate as calculated by GAP is then passed to the simulator to act as a control
mode for the simulator wells over the coming timestep.
The advantage of this method is that it is simple to implement for the user: the volume rates are
standard outputs of any simulator and so coupled models should run without any modifications to
the data decks.
A drawback, however, is that volumetric rates are calculated with reference to an internal model
process or separator train. This can lead to discrepancies between what the network 'sees' as a
unit volume and what the simulator 'sees'.
User Guide
114
A solution to this is to pass masses between the applications, as has always been the case
when passing data to process models. The unit of mass is clearly independent of any process:
115
RESOLVE
2.8.3.2 Setup of Process Independent Models

As explained, a model is made process independent by forcing the relevant applications to
exchange mass, rather than surface volumetric, data.
There are two tasks:
1. Re-generation of PROSPER lift curves.
PROSPER lift curves, which were previously set up with volumetric sensitivity variables, need to
be regenerated with equivalent mass-based sensitivity variables. The table below lists the
volumetric variables with their corresponding mass variables:
User Guide
116
For more information, please review the PROSPER manual.

2. Formation of a mass-based inflow performance relation (IPR)
It is necessary to tell GAP that it will receive mass, rather than volumetric, IPR data. This is
achieved through the 'composition' tab of the data entry screen.
All the compositional simulator drivers that Petroleum Experts provide can supply mass
based inflow data. In all cases other than Eclipse this is done automatically with no intervention
required by the user.
In the case of Eclipse, it is not possible to calculate mass rates directly from the OpenEclipse
interface. Mole rates are available, so the EOS description is required to turn these mole rates,
through the molecular weights, into mass rates.
The EOS description is entered, as normal, in the form of a PVT include file into the Eclipse
data entry screen. In normal (i.e. volumetric) use, this is not an obligatory input. If it is not present,
then the downstream (network) composition will not receive compositional data and the
composition will be fixed by that which is already resident in the GAP model.
If it is present then the EOS data will be passed downstream. If there is a substantial number of
wells, this can slow the connection down. If the EOS data needs to be supplied to provide
molecular weight data for the calculation of mass rates, then there are two possibilities:
1. Provide a cut-down PVT file which only contains the molecular weight data, or
2. Right-click on the Eclipse icon, and select the option to not pass EOS data.
2.8.3.3 Further considerations

As discussed, a process-independent model passes mass, rather than surface volumetric, rates
between applications.
When the mass rate for a well is passed to the simulator, the simulator needs to convert the
117
RESOLVE
mass rate into a rate which can then be used to control the well for the duration of the
forthcoming timestep, as usual.
Generally, it is not possible to control simulator wells by mass rate: for individual well control,
volumetric rates are needed. These are obtained by extracting the equivalent volume rate from
the original well IPR for the mass rate which was returned from GAP.
It is assumed that the mass rates computed in the IPR are hydrocarbon mass rates only. The
mass rate that will come back from GAP is always hydrocarbon only. This means that if the
simulator IPR computes a mass rate which includes water, then mass-balance discrepancies
will occur.
All reservoir simulators that Petroleum Experts support, with the exception of Eclipse, will
always generate hydrocarbon only mass rates. Eclipse is different because the mass rates are
calculated by multiplying the component mole rates by their molecular weights. If the EOS
description of the simulator includes water, then this will be implicitly included in the mass
calculation.
This means that it is important not to include water as part of the Eclipse EOS description if a
process-independent model is to be set up.
2.9
"Edit System" Menu
2.9.1 "Edit System" Menu

The commands available from the "Edit System" menu are used to create and manipulate
User Guide
118
icons on the main screen.

Most of these commands are also available when Right-Clicking anywhere in the graphical view
window.
The following commands are available through this system menu
Add Client
Program
Link
Target
Select
Move
Delete
Mask
Unmask
Disable
This will invoke a menu with a list of the application models available to
add into RESOLVE.
The list is taken from the list of "Registered Drivers".
To create an instance, click on the application to load and click in the
graphical view window at the location where the icon is to be displayed
Enters "Link" mode for linking corresponding sources and sinks
together.
Once in link mode, point the mouse cursor on the first element to
connect, click on the left mouse button and drag the mouse cursor to the
second element to connect. Release the left mouse button - A connection
should have been established between the two elements considered. It
will be displayed as a dashed line
Enters "Target" mode.
Once in this mode, it will be possible to establish a direct connection
between two modules that will act as a target solver.
Further information on that type of connection can be found in the "Target
Connections" section
Enters "Selection" mode for selecting icons for later manipulation (e.g.
moving).
Selection can be done per icon (i.e. by clicking into the icon) or by
dragging over a rectangle which will toggle the selection state of all the
icons within the rectangle. Selected icons are marked with a dark blue
circle
Enters "Move" mode for moving icons. Icons can be moved individually
by clicking into the icons and dragging with the mouse, or collectively by
clicking near a group of selected icons and dragging to the new location
Enters "Delete" mode for deleting client modules. Source and sink icons
can not be deleted individually as these are properties of the client
application cases. The client modules can be deleted in this mode by
clicking onto the main icons. Connections between sources and sinks
can also be deleted in this mode
Enters "Mask" mode for masking connections. When a connection is
masked, it is grayed out on the screen and zero rates will be passed
when the model is run
Enters "Unmask" mode for unmasking connections (see above)
Enters "Disable" mode for disabling connections or modules.
When applied to a connection, this has the same effect as masking
except that it can not be changed or scheduled once a run has started.
When applied to a module, all connections to and from the module are
automatically disabled. In addition, the module itself will not be controlled
119
RESOLVE
Enable
Select /
Unselect all
items
Show / Hide all
sources / sinks
Connection
Wizard
Icon Sizes
Set system
state
in any way - no initialisation or timestepping in the module will be

performed. This means that runs can be performed where modules are
switched in and out of the system, with excluded modules being disabled
Enters "Enable" mode for enabling connections or modules. See above
Enters "Select" or "Unselect" mode. Once items have been selected
they can be moved in block
For clarity in complex systems it may be desirable to hide all the sources
and sinks of a client application - when they are hidden a small plus (+)
sign appears in the bottom corner of the case icon.
These menu options toggle the states of all the client applications
Invokes the "Connection Wizard".
Further information on RESOLVE connections can be found in the
Connection Rules, Models and Loops, Connection Wizard and
Composition Tables sections
Allows the user to change the icon sizes on the screen. This may be
useful if a system is fairly complex and is looking cluttered
This allows a previously saved system state to be recalled and applied to
the underlying applications. An example would be a routing configuration
that was previously evaluated by the GIRO optimiser
2.9.1.1 Connection Wizard

The Connection Wizard may be used to generate connections between nodes in the
RESOLVE system.
This can also be achieved graphically, but this can be quite arduous when generating
connections over a large system.
When invoked, the following screen is produced:
User Guide
120
The following options are available within the connection wizard screen:
Module
lists
The drop down list boxes at the top of the screen contain all the client
modules defined in the RESOLVE system.
Select the two modules for which connections have to be made from the
lists on the left and right of the screen.
The sources / sinks that correspond to the module selected are then
listed in the list boxes below
121
RESOLVE
Sorting
options
Filter - Display
Add
Individual
Connection
Add
connections
by name
The lists of nodes can be manipulated in various ways. Options to

modify the ordering of the nodes can be found below the list box.
The following actions can be performed to modify the organisation of the
list of nodes:
Nodes can be selected in the lists and removed by clicking the Remove
Selected button.
The Reset button will display all nodes sorted alphabetically - This is the
defaults sorting process.
The sorting can be reversed by clicking <Reverse Sort>
The checkboxes available in this section enable to specify which items
appear in the list of nodes.
By default, data providers and data acceptors (i.e. all items) are listed.
Click on the relevant checkboxes to apply a filter to the list, and then
click Apply
Connections can then be made by highlighting the individual sources
and sinks in the list and clicking on Add Individual Connection. If the
lists have been sorted and filtered to align the nodes that are to be
connected, then Add Connection by List can be used to form
automatic connections between the node lists. The resulting connections
are displayed in the list box at the bottom of the screen
This will automatically connect like-named items from the models
displayed on either side of the screen.
The match criterion can be case sensitive or insensitive
2.9.1.2 Target Connections

It is possible in RESOLVE to establish a direct connection between modules that acts as a
target solver.
This target solver will enable to modify the system using a control variable specified by the user
so that the target variable specified by the user becomes equal to a certain fixed value or
expression.
For instance, a target connection can be established between a GAP and a Hysys model so that
the GAP separator pressure is adjusted to be consistent with the Hysys inlet pressure.
This link can be setup as per the procedure below:
Step 1
Publish Target and Control variables

Use the Edit System | Import Application Variables section to publish both
target and control variables.
Click on the "Edit Variables" section to access the screen enabling to select the
variables required. Further information on this screen can be found in the "
Publish Applications Variables Section".
In the case considered, the control variable is the GAP separator pressure and
the target variable is the Hysys pressure, as illustrated below.
User Guide
122
123
Step2
RESOLVE
Establish the link between the modules considered

Select the target link icon in the main icon menu bar as illustrated below.
Once this has been done, establish a direct link between GAP and HYSYS
modules as illustrated below.
User Guide
Step 3
124
A "Target" icon will appear between the two modules

Setup the Target Link
Double clicking on this target icon enables to setup the target link, as described
below:
125
RESOLVE
Target Section
The target section enables to specify a label for the target connection.
Control Variable Section
The control variable section enables to define the control variable to be used for
this target connection.
The control variable section enables to specify which variable is the control
variable: a list of all the writable variables that have been published will appear,
from which the user chooses one.
Lower and
these options enable to specify a minimum and maximum
Upper bound value for this control variable
Minimum Step is an optional parameter. It enables to define the minimum
User Guide
Size
Initial Bound
126
variation of the control variable that is allowed by the user

is an optional parameter. It enables to define the initial value of
the control variable to be considered
Target Variable Section

The target variable section enables to define the target variable.
Target
Variable
enables to specify which variable is the target variable: a list

of all the variables that have been previously published will
appear, from which the user chooses one
Target
enables to specify a fixed value or a mathematical
expression that defines the target variable.
Variable
The expression used in this section can be a function of
Expression
another published variable: use the drop-down box above
and the Variables button to select a published variable and
integrate it in the target variable expression
Tolerance
enables to specify how tight the user wishes the convergence
of the target variable to be
Maximum
enables to specify the maximum number of iterations allowed
for the target variable value to be met
iterations
Stop if target
If the option is selected, then the calculation will stop if the
variable is not internal calculation of one of the client modules fails during
the target calculation
calculated
2.9.1.3 Set System State

This screen allows a system state, which was previously (for example) saved from the
optimisation results screen, to be recalled and applied to the underlying models. Note that this
can also be performed dynamically (i.e. during a run) from the visual basic script or the event
driven scheduling.
In the example below, there are two saved states labelled 'iter_4' and 'iter_6'.
127
RESOLVE
A summary of the state to be recalled is given in the grid for the state selected in the drop down
list box. When the 'OK' button is pressed the variables indicated will be applied to the underlying
applications.
Note that certain variables may be optimisation variables for a child application. An example
would be a wellhead choke in a GAP model. There is no guarantee that the value of such a
variable will be retained by the child application in question: depending on other RESOLVE
settings (for example, whether it is allowing the underlying applications to optimise), GAP may
simply overwrite the choke setting with a calculated value as soon as the model is run.
2.9.2 Setting up RESOLVE Model - Specific Elements for external

applications
This section will describe in detail how to setup each of the clients modules available to use
within RESOLVE as well as describing all the options that are available for each client module.
As each client module is connected with RESOLVE through a driver, this section also doubles as
a description of the features supported by each driver.
The following sections are available:
Connection to GAP - GAP driver Details
Connection to REVEAL - REVEAL driver Details
User Guide
128
Connection to IPM-OS - IPM-OS driver Details

Connection to Eclipse - Eclipse driver Details
Connection to IMEX / GEM - IMEX / GEM driver Details
Connection to PSim - PSim driver Details
Connection to Hysys - Hysys driver Details
Connection to UniSim Design - UniSim Design driver Details
Connection to Excel - Excel driver Details
2.9.2.1 Connection to GAP - GAP driver Details
2.9.2.1.1 GAP Driver Configuration
Before the driver can be used effectively, it must be configured for use with GAP.
The configuration screen can be accessed from the RESOLVE driver registration screen (Select
Drivers | Register Drivers on the main menu).
Click on the GAP driver in the list and press the "Configure" button.
The configuration options are:

129
RESOLVE
GAP
In this field the user should enter the directory in which the GAP executable is
executable installed. If this is left blank, RESOLVE will attempt to start GAP in the same
path
directory as the OpenServer executable (i.e. PXServer.exe) is running.
For safety it is recommended to enter the directory from which the GAP
executable has to be started
Application In case of difficulties, RESOLVE will wait a certain period when attempting to start
timeout
up GAP.
If it is not able to do so then RESOLVE will call an error after the timeout period
defined.
For most cases a timeout of 30 seconds should be appropriate. If a fairly slow
machine is used then the user may want to make this value larger to avoid
RESOLVE "timing out" unnecessarily.
Two different timeout duration can be specified, depending whether the model is
run on a single machine or over a cluster setup
2.9.2.1.2 Loading and Editing a GAP Case
2.9.2.1.2.1 Loading and Editing a GAP Case : Overview
Once a GAP module has been created, it is possible to edit the case (i.e. specify which GAP
model should be loaded and setup the calculation preferences for the case considered) by
double-clicking on the GAP icon in RESOLVE.
The following GAP data entry screen is displayed.
This screen is split into four tabbed sections, as illustrated below:
User Guide
130
Input fields
General
Source/Sinks
Wells / Inflows
IPR
Compositional
The settings under this tab relate to the GAP model settings.
More information regarding these settings can be found under the GAP
Driver : General section
This tab allows to add extra sources and sinks to those displayed in
RESOLVE by default.
Driver : Sources and Sinks Section
This section enables to specify the way IPRs are generated / handled
before being sent to the GAP model.
Driver : Wells / Inflows IPR Section
This section enables to specify which composition (i.e. list of
131
RESOLVE
components) is taken as a default list in GAP.

Driver : Compositional Section
2.9.2.1.2.2 GAP Driver : General Section
Once the GAP module icon has been located in the graphical view, it will be required to
associate this module icon to a specific GAP model as well as to setup the options that are
going to be used to integrate the GAP model to the overall RESOLVE model.
This can be done through the "Edit Case Details" screen that can be obtained by doubleclicking on the GAP module icon.
The screen of that specific section is as follow:
User Guide
132
Input fields
The following options are available on this screen:
GAP
Filename
System
Machine
Name
This is where the location of the GAP case (i.e. extension *.gap) considered
has to be specified
As well as the main system, GAP cases can optionally contain associated
water and gas injection systems.
This control can be used to select one of these systems rather than the main
production system. This is useful to connect separately to a GAP case and its
associated injection system.
This can be done by using the following procedure:
Create one GAP instance for the production system. Open the "Edit the
GAP case" screen and specify which GAP file this GAP instance relates
to. Keep the "System" option to "Main System".
Create another GAP instance for the water OR gas injection system OR
gas lift injection system. Open the "Edit the GAP case" screen and
specify which GAP file this GAP instance relates to - THIS SHOULD BE
THE MAIN GAP FILE, NOT THE INJECTION FILE. Change the
"System" option to "Associated Water Injection" OR "Associated Gas
Injection" OR "Associated Gas Lift Injection".
Using that method will allow to use only one GAP license to run the production
and associated injection models
GAP cases run from RESOLVE can be distributed over a network.
Enter in this field the name of the machine on the network on which the GAP
case should run. The machine name can be given as an IP address or a name
in the DNS register (e.g. "dave-8200").
Leave the space blank to run GAP on the local machine.
Use
specified
computer /
use cluster
When entering file (case) names for remote machines, the file name entered
should be relative to that machine and not the local machine
The machine name (above) is not used if the "use cluster" option is specified.
In this case, RESOLVE will start the GAP model on some node of a cluster
configured either with PxCluster or LSF.
For more information on PxCluster (i.e. the Petroleum Experts cluster
software), refer to the "Further Technical Elements | PX Cluster" section.
If a cluster is used, the following should be kept in mind:
The filename should be visible to all the specified nodes of the cluster
(which, by default, is all the nodes). This means that the file name should
normally be a UNC name.
A subset of cluster nodes and the software executables can be selected
by clicking on "setup cluster". By default, the software is assumed to be
located on the remote nodes in the same path as the local machine, but
this can be overridden from this screen.
133
RESOLVE
Whether LSF or PxCluster is used, RESOLVE will have to locate a node which
is not busy before starting GAP. If there are no free nodes, the startup of GAP
will eventually timeout. The timeout period can be set in the "Configuration
screen"
Predictive
GAP can be used as a standalone calculator or in predictive mode.
Mode
By default, GAP is run in the same mode as is set up in the GAP model, which
may be predictive if there are MBAL or decline curve reservoir models
present.
The prediction mode can be overridden here to always use GAP as a
standalone calculator: by setting the option to "Always Non-Predictive (GAP
performs instantaneous solve)", the GAP model will be set to run only for an
instantaneous Solve Network.
This means that the IPR information for the wells is kept constant and
is not updated from the reservoir model
Snapshot
Through this setting, RESOLVE can force GAP to save or not to save
Mode
prediction snapshots, independently of the value of the corresponding setting
in GAP prediction settings
Action to take This setting is useful when several types of reservoir models are available for
if MBAL wells one reservoir: for instance, a MBAL model and a numerical simulation model
connected to are both available for the reservoir considered.
In this case, it will be possible for the GAP model to be connected within GAP
simulator
to a MBAL model for "Reservoir 1" and to be also linked through RESOLVE to
a numerical simulation model for "Reservoir 1".
In that case, that option enable the user to automatically decide which one of
the two is used for the run.
By default, the numerical simulation model will be used over the MBAL model
Model
GAP can be setup to calculate the system potential at each timestep or not.
The system potential can be added to the "Variable reporting set" in the usual
way or, if GAP is running predictively, the system potentials will be stored in
the GAP forecast results. It takes a little longer for GAP to calculate potentials
at each timestep and so for this reason the default setting is "do not calculate
system potential"
Stop
If this setting is selected and a convergence error is experienced in GAP, then
execution if
the entire prediction will be stopped.
If not, a message will be logged on the calculation progress window of
solver /
RESOLVE to illustrate the convergence error
optimiser
fails
(or just log)
2.9.2.1.2.3 GAP Driver : Sources and Sinks Section
When loading a GAP model, the nodes that appear by default are all the separator (i.e. data
provider) and the wells (i.e. data receiver) nodes.
This section enables to setup additional nodes in the RESOLVE model.
User Guide
134
Additional nodes such as the "Total System Lift Gas" could be used for instance to feed a GAP
model with the amount of gas lift available at each timestep from a process model in Hysys or
UniSim Design.
Input fields
Total system
lift gas
If this is checked then an icon representing the total lift gas available for the
GAP system will be displayed in RESOLVE.
This can then be connected to a source from another application.
For example, the gas lift supplied to a GAP system can come from a plant
(Hysys) model or it can be calculated from a spreadsheet macro.
GAP will then use this total amount of gas lift gas available as part of its gas lift
gas allocation optimisation calculation
135
RESOLVE
Pass gas
properties
This option is only available if the "total system lift gas" option
is checked: this determines whether or not the PVT properties
(i.e. including EOS properties if present) are applied to the
gaslift stream.
If it is not checked then only the quantity (i.e. phase rate) of the
lift gas will be passed, not its PVT properties
Lift gas for

individual
gas lifted
wells
If this is checked then an icon representing the lift gas for each gas lifted well
will be displayed (i.e. in addition to the usual icon representing the well itself).
The icon will have the label "<wellname>-gaslift".
The lift gas passed to this node from a different model can be applied in two
ways depending on the well model:
Gas lifted
well with
fixed
injection
rate
Gas lifted
well with
variable
injection
rate
Pass gas
properties
Inline
injection
elements
Unused
lift gas
In this case the lift gas quantity passed from the source model
will be applied as a fixed gas lift injection rate in the well
In this case GAP is to optimise the amount of gas lift gas

injected into the well to optimise on the required objective
function at the separator level. The lift gas quantity passed
from the source model will therefore be set as a maximum
injection rate constraint for that well on the optimiser
As for the total system lift gas, this determines whether the
PVT properties of the gas lift stream will be passed to the well
If this is checked then inline injection elements will be displayed as additional

icons on the RESOLVE screen.
These can then be connected to sources of lift gas in other models. The same
rules as for gas lifted wells apply: if the injection is fixed then the amount of gas
passed will be applied as a fixed injection rate, if the injection is controllable
then the amount passed will be set as a maximum constraint
This will create a "source" icon in RESOLVE that allows the unused quantity of
lift gas to be passed from GAP into another model.
This feature should be used with care. The amount of unused lift gas is
calculated simply from the GAP solve results (i.e. gas lift gas available minus
gas lift gas used). The properties of the gas are derived from the gas lift gas
passed into the model at the "total system lift gas" icon.
If this is not connected or not present then dummy properties will be passed.
Even if the total system gas lift is connected there is still the possibility that the
lift gas could come from various internal sources in the GAP model and so it is
not possible to predict the exact properties of the unused lift gas
User Guide
Individual
separation
streams for
oil, gas,
water, and lift
gas
Add extra
nodes
136
If this is checked then each separator icon will have a "child" icon representing
the separated streams of each phase. Note that this is for black oil cases only
This invokes the following screen to allow adding internal joints from the GAP
system as new sources on the RESOLVE screen.
The screen has the following appearance:
The list on the left contains the names of all the joints in the GAP system. To
add a joint to the output sources, highlight the required joint and click Add. The
joint will appear in the list on the right. Remove and Clear can be used to
delete entries in the right hand list
2.9.2.1.2.4 GAP Driver : Wells / Inflows IPR Section
This section enables to specify the potential modifications to be done on the IPR curves coming
from the numerical simulator before they are passed to GAP.
137
RESOLVE
The main objective of this screen is to select whether the driver will perform a regression on the
inflow performance data received from the reservoir model or not.
It is important to note that accounting for the progress done in the area of inflow
performance exchange between reservoir and surface network model with the scaling
methods (i.e. see "Connection to REVEAL - REVEAL driver details" section), this method
has been superseded and is not recommended any more.
The regression process will enable to match the BHP vs. rate points received from the simulator
(i.e. inflow lookup tables) using a specific IPR model such as Straight Line PI for an oil producer
or Forcheimer for a gas / retrograde condensate producer.
The main screen will enable to apply this modification to all or non of the wells.
Using the advanced button, it will be possible to select this regression on a well to well basis as
illustrated below:
User Guide
138
The following IPR regression options are available:

Use rate gradients
to calculate phase
fractions in IPR
Populate IPR
tables even
when performing
regression
(slower - debug)
This option, if selected, will use the rates from the two previous timesteps
and extrapolate to the current timestep to obtain the phase fractions
This option will ensure that the IPR tables are populated in GAP even if
the regression calculation is performed
2.9.2.1.2.5 GAP Driver : Compositional Section
This section is used only for compositional or compositional tracking GAP models.
139
RESOLVE
This section enables to select which item from the surface network will be used to provide a
standard list of components names for the entire GAP model.
If this is left by default, that component names list will be taken from the connected items.
Input fields
Select item from
which to extract
composition
Rate Model
Perform 'Target
This network element will provide the names of the components for the
entire GAP model.
The Rate Model option at the bottom of the screen enables to choose
between an IPR data passed to GAP based on volumes or on mass. A
mass-based transfer is necessary if process-independence is required
from the model
When a compositional reservoir simulation model is connected to a
User Guide
GOR' on full
composition
140
compositional GAP model, there will be a GOR as well as a composition

that is passed across by the simulator to the GAP model. If this option is
selected, then RESOLVE will perform a 'target GOR' operation on the fluid
composition that is received to the GOR that is passed to obtain a new
composition.
If this option is not selected, then RESOLVE will simply pass on the
composition received from the simulation model to GAP.
Generally speaking, if the simulation model passes a GOR which is
consistent with the fluid composition also passed by the simulation, then
the 'Target GOR' option should return a composition that is identical to (or
close enough) to the composition passed by the simulation. If the
composition passed by the simulation model is different from the
composition obtained from the 'target GOR' method, then it indicates
some inconsistency between the GOR and composition passed by
simulator (for ex. EOS setup)
2.9.2.1.3 Publishing GAP variables

This section allows variables to be published from GAP into RESOLVE.
These variables can then be used for "Event driven scheduling", or for building up different "
Scenarios", for example.
This screen can be obtained in two ways:
By going to Edit System | Import Application Variables
By going to Schedule | Import Application Variables
The following screen will then be displayed:
141
RESOLVE
By clicking on "Edit Variables", the following screen appears, enabling to select which GAP
variables have to be published in RESOLVE:
User Guide
142
This screen is split into several sub-sections.

Working from the left to right , these are:
OpenServer
variables
This screen is used to copy OpenServer strings from the GAP interface into
RESOLVE.
There are two ways of using it:
Go to the GAP interface, do <ctrl> and <RightClick> on the required
variable, copy the OpenServer string to the clipboard, and paste it into the
grid displayed here. When the grid cell loses focus the "writable" status
and the unit will be displayed. This can be used to export any OpenServer
variable from GAP into RESOLVE.
As a convenience, the GAP solver variables and equipment constraints are
displayed in the lists on the left hand side of the screen.The user can select
between the solver variables and the equipment constraints list by clicking
on the respective tabs. To add a variable to the list of published variables
used in the event driven scheduling section, highlight the variable in
question and click on the Add button.
Further information on solver variables and constraints can be found below:
Solver
These variables are the GAP solver (output) variables only:

143
RESOLVE
Variables
Constraints
they will always be assigned a "non-writable" status. The

drop-down lists below the equipment list can be used to
add a variable for each piece of equipment of a given type.
In the left hand side on the screen, it is possible to notice
than one can switch from "Solver Variables" to "Constraints
Variables": if this is done, then a list of GAP equipment will
be displayed and the constraints available for each
equipment listed. They can then be added in the list of
published variables. These variables will be input variables
and therefore they will all have a "writable" status.
Also, it is possible to add automatically the separator pressures against

which the GAP system is solved. These are input variables: they will always
be assigned a "writable" status. To add the separator pressures, click on
the "Add separator pressures as input variables" at the top of the screen.
When an entry is made, the OpenServer tag, the unit, and the writable status
will be set up automatically, along with a suggestion for a variable name.
In the above example, the oil rate from the solver results for each of the GAP
equipment items has been set up, along with the separator pressure against
which the system is to be solved.
Equipment
masking
This section allows the mask status of pieces of equipment to be published

as variables.
To do this, highlight the required piece of equipment from the list on the left
hand side and click on the Add button.
The variable has the value "1" when the element is masked in the
system, and "0" when it is not masked.
User Guide
144
In the above example, the mask status of a GAP well has been set up
Equipment
bypassing
Group
Membership
MBAL tank
variables
This follows the same logic as the equipment masking, except that it assist in
publishing the bypassing status of the elements in the system rather than the
masking status
This section enables to monitor group memberships: it enables the user to
know whether one specific element / node of the GAP model is part of a
specific group.
Variables of the type equipment "A" is a member of group "G"" can be set
up in this section.
The equipment can be selected from a drop down list in the "equipment"
column. Similarly, the group can be selected from a drop down list in the
"group" column. A variable name for this will be suggested automatically, but
this can be changed. The variables have the value of "1" if "A" is in group
"G", and "0" if it is not
These are variables that relate to the tank models which are internal to the
GAP model considered.
145
RESOLVE
The list of tanks that are in the GAP model is displayed on the left hand side.
The most convenient way to use this screen is to first create an instance of
the MBAL application.
This can be done in two ways:
If MBAL is already open on the desktop, then click on the "Connect to
existing MBAL instance" button. This will open up an OpenServer
connection to MBAL
If MBAL is not open, click on "Connect to new MBAL instance". This will
open MBAL, and also set up an OpenServer communication with it. It is
important to note that this process will require some time and the screen
will be disabled during this time.
Once an MBAL connection is made,the equipment of interest should be
selected from the list on the left hand side and the red arrow should be
clicked.
RESOLVE will automatically open the MBAL model that is associated with
this tank - The name of this MBAL tank will appear in the Equipment column.
An OpenServer variable can then be taken from the MBAL model (using
<Ctrl> <RClick> in the usual way) and pasted into this table.
The unit of the variable will automatically be written into the "Unit" column. A
variable name should be given to the variable, as shown.
User Guide
146
If the unit of the variable does not appear, this means that the
variable has not been found. This can be due to the fact that
the red arrow was not clicked after the MBAL file was loaded,
leading to no reservoir name being specified in the Equipment
column.
If this happens, click on Clear and start the process again
Note that the values of these variables can not be changed dynamically (i.e.
during the run). They are changed at the start of the run, before the prediction
in GAP is started. They would normally be used for uncertainty analysis, for
example, to determine the affect of OOIP or OGIP on the length of a plateau.
Cumulative
rate
variables
When the screen is exited (by pressing "OK" or "Cancel"), MBAL will also
be exited provided the instance of the MBAL application was created from
this screen.
The cumulative black oil rates can be exported, either at the node level or the
system level.
The required variables are selected from the list on the left hand side of the
screen. All the variables pertaining to a particular piece of equipment can be
exported in one click by highlighting the equipment itself.
A single variable type (e.g. Cum Oil) can be exported for all pieces of
equipment by using the drop down lists at the bottom of the screen
147
RESOLVE
2.9.2.1.4 Optimisation
RESOLVE allows a global optimisation over an entire system to be performed.
This means that control variables, constraints, and an objective function can be set up that span
several applications.
For example, well controls can be set up in GAP to optimise an objective function in a separate
application (a plant model for instance) while obeying constraints which can be in GAP or in
another model.
The screens described here are used to set up control variables, constraints, and an objective
function as required in the GAP model.
They are accessed by right-clicking on the GAP icon on the RESOLVE screen or by going to the
Optimisation | Setup section.
The following screens will then be displayed:
Optimiser Objective Function and Constraints
This allows both objective functions and constraints to be setup in the GAP model.
User Guide
Objective
Function
148
The top section of the screen enables to setup the objective function.
This is not mandatory - the objective function might be located in another
application.
Label
This is the label for the objective function that will be used
when reports are generated by the RESOLVE optimiser
OpenServer This is the GAP output variable (in the form of an
variable
OpenServer string) that represents the objective function.
The OpenServer string can be directly obtained from the
GAP interface by using <Ctrl> and <RClick> when the mouse
is over the output variable display, or obtained by selecting
the equipment and variable to consider in the appropriate
dropdown boxes.
Selecting Set after this will enable to setup the OpenServer
string directly
Maximise/
One can choose to maximise or minimise the variable
149
RESOLVE
Minimise
Constraints
selected above
The following inputs can be entered:

OpenServer This is the GAP output variable (in the form of an
variable
OpenServer string) that represents the objective function.
The OpenServer string can be directly obtained from the
GAP interface by using <Ctrl> and <RClick> when the mouse
is over the output variable display, or obtained by selecting
the equipment and variable to consider in the appropriate
dropdown boxes.
Selecting Set after this will enable to setup the OpenServer
string directly
Relation
The constraint can be "less than", "greater than", or "equal to"
the value specified in the value section
Value
The constraint value
Unit
The unit of the variable in question. The constraint value is in
these units
Optimiser control variables

This allows controls / control parameters to be set up in GAP. Controls are variables that can be
adjusted in order to maximise an objective function while observing constraints. For example, in
GAP (when run by itself) wellhead chokes can be modified automatically by the GAP optimiser
to optimise oil production or revenue. In RESOLVE, wellhead chokes can be set to optimise an
objective function which is not a variable in GAP, but that is defined in another model: for
instance in an Excel spreadsheet.
When invoked, the following screen is displayed:
User Guide
150
From left to right, the grid columns are:

Report name
OpenServer
variable
This is the label that will be used in the reports that RESOLVE generates when
the optimiser is run
The RESOLVE optimiser accesses the control variables through the GAP
OpenServer interface. This column contains the OpenServer tag string for
the control variable. These strings can be obtained from the GAP interface
itself: in common with all the IPM applications, pressing <Ctrl> and <RClick>
when the mouse is over a variable input field will yield a screen which gives
the OpenServer variable.
To get the current set of control variables from GAP automatically, use the "
Add GAP controls" button.
To allow the GAP separator pressure to be a control parameter, use the "
151
RESOLVE
Vary separator pressure" button. In systems where a GAP model is linked

to a process model, this enables for instance to avoid choking back wells
heavily with a low separator pressure to respect a rate constraint at
separator, and enables to have instead a higher separator pressure, passing
therefore more energy to the process.
Unit
Bounds
It is important, of course, to supply the tag strings of input variables which can
be adjusted to optimise the objective function
Once the OpenServer variable has been supplied this column contains the
current GAP unit for the quantity in question. This is the unit that will be used
when entering the allowed variable range (below)
Enter here the minimum and maximum value for the control.
Again this can come directly from GAP for the current set of control variables.
It is not necessary to enter either maximum or minimum values, but this should
be done if there is a physical limit on the variable (e.g. for instance, pressure
drops or injected gas quantities cannot be negative)
Integer Controls
This section allows to setup mixed integer optimisation cases such as routing optimisation
cases: from different routing possibilities, which one is the most appropriate to be used.
The screen that enables to setup that optimisation is as follows:
User Guide
152
Please refer to the Optimisation Help topic for further details.
2.9.2.1.5 Other functions

The following assorted functions are available in the GAP driver: these functions can be
accessed for instance by right-clicking on the GAP module icon in the graphical view or by going
to Program Functions and select the GAP module considered.
Toggle Select
(This Item / All
Children)
Select All
This enables to select the item considered or all its "children" items
This enables to select / unselect the module considered and all its children
153
RESOLVE
Children /
Unselect All
Children
Save Case
Reload Case
Display
Child Icons /
Do Not
Display
Child Icons /
Display
Only
Connected
Child Icons
items
Saves the GAP case to the current file name

Reloads the case from file: this can be useful if the file considered has been
edited.
It is important to note that RESOLVE will always reload the file before a
simulation run, unless told otherwise in the simulation options
This enables to select whether to display only the module icon OR the module
icon and all children icons OR the module icon and only the connected icons.
This is particularly useful when large models with numerous sources / sinks
are used: displaying all the items in these cases can alter the clarity of the
graphical view of the RESOLVE model.
By default, RESOLVE will display the module icon and the child icons. If the
number of child icons is too large, then RESOLVE will only display the module
icon. A red cross will then be displayed on the module icon to specify that it
has child icons associated but that they have not been displayed
Change Label / This enables to change the label or alias associated with the module
considered
Alias
Do not send / This is only available when models with compositional data are considered.
These options enable to block the flow of compositional data from or to the
receive EOS
property data module specified
Optimiser
These relate to the RESOLVE optimisation function. Further information on
Setup
this function can be found in the "RESOLVE Optimisation" section
Test
This simply tests whether PXServer.exe is registered with the operating
system and returns the full path of the registered application
PXServer
Output
This allows additional variables from the GAP run to be added to the main
Variables
RESOLVE reporting facilities.
A screen similar to the following is presented:
User Guide
154
To add a variable, the equipment and variable considered can be selected in

the left hand side list, and passed using the "Add from list" button in the right
hand side list. It is possible as well to use the dropdown boxes to select the
equipment type and variable considered and click on "Add".
All the variables in the right hand side list will be displayed in the RESOLVE
results alongside the default RESOLVE results.
2.9.2.1.6 Setting up the GAP Case : Additional Information
2.9.2.1.6.1 Setting up a case in GAP
There are a few points which should be kept in mind when setting up the GAP case to use within
a RESOLVE model:
Well Models
Optimisation
Setup
The wells should be modelled with a VLP / IPR intersection within the GAP
model- this is set from the main summary screen of the well data entry screen
in GAP
To make use of GAP optimisation capability, there should be appropriate
controls available in the GAP model.
155
RESOLVE
System
Pressures
Quality
Checking
Link to a
Reservoir
Simulation
Model
In other words, gas lifted wells should have the lift gas calculation set to
"calculated", naturally flowing wells should be controllable (i.e. the dP control
should be set to "calculated"), and so on
The separator and / or injection manifold pressures that the model is to run
with should be set in the GAP model
As with all calculations, quality checking of the model before the simulation is
run is extremely important.
It will be recommended to check for errors at an early stage, generally by
running the GAP model stand-alone, before adding extra complexity by
connecting it to other models in RESOLVE
If the GAP model is to be linked to a reservoir simulation model, it will be
advised to allow the prediction snapshots to be saved during the prediction
forecast. This will allow for straightforward troubleshooting of the quality of the
inflow data passed from the simulator to the GAP model
2.9.2.1.6.2 Source/Sink items in GAP
The following GAP items are considered as source or sink items in RESOLVE.
Wells
Inflows
Separators
Injection
manifolds
Sources
These are data acceptors, i.e. they accept tabular inflow data from the item
to which they are connected. They also implement a bi-directional link, i.e.
they return solution values to the connected module that lie on the original
curve that was passed
These have the same functionality and manipulate the same data as GAP
wells as far as RESOLVE is concerned
These are data providers, i.e. they pass data to a connected object. Only a
single point is passed and so no data can be returned, that is, they
implement a uni-directional link
These are data acceptors and receive data from a connected object. In
general, RESOLVE attempts to maintain a continuous pressure profile over
the system and so the injection manifold pressure is set to the pressure of the
connected node. The rate that is injected will depend on the injectivity of the
system: thus the rate from the connected node is set only as a constraint on
the injection: if the injection system is physically able to inject that amount,
then it will be injected, but if the injection system is not physically able to inject
that amount, then the rate injected will be equal to the maximum rate the
injection system can inject
These are data acceptors and behave similarly to injection manifolds. The
main difference is that GAP sources do not have a pressure variable: the
pressure is allowed to float to inject the rate that they are set to (in this sense
they have the opposite behaviour to injection manifolds). The accept a single
data point, i.e. the link is uni-directional.
Note that sources do not appear as separate items in RESOLVE when they
are used as targets for inline separators to separate fluid streams in GAP.
User Guide
Sinks
156
They only appear if they are used "standalone"

These are data providers. As far as RESOLVE is concerned, they have the
same functionality as separators
Additional Information
Setting up
GAP sources
and injection
manifolds
Also note
When these items are setup in GAP, they refer to a labelled fluid definition
that consists of a description of the fluid in question.
For example, a gas injection manifold may refer to a fluid description called
"gas01" with appropriate associated properties (gas gravity, etc). An oil
source may refer to a fluid description called "oil01" with associated
properties GOR, water cut, oil gravity, gas gravity, and so on. These fluid
descriptions are set up on the "fluid" tab of the GAP data input screen for
the item in question.
When a source or injection manifold is connected to another item through
RESOLVE, the fluid properties will be passed into the fluid description
properties. A unique fluid description will be created for each stream from a
source model that is passed into GAP. These "new fluids" may be observed
in the GAP model after a GAP file that has been run with RESOLVE has
been saved
Other sources and sinks can be added to the RESOLVE interface optionally.
These are detailed under the Sources / Sinks tab of the main data entry
screen, which is described in more details in the "Source / Sink in GAP"
section
2.9.2.2 Connection to REVEAL - REVEAL driver Details

2.9.2.2.1 REVEAL Driver Configuration
Before the driver can be used effectively, it must be configured for use with REVEAL.
The configuration screen can be accessed from the RESOLVE driver registration screen:
Drivers | Register Drivers on the main menu.
Click on the REVEAL driver in the list and press the "Configure" button. The following screen
will be displayed.
157
RESOLVE

REVEAL
executable
path
Application
timeouts
In this field the directory in which the REVEAL executable is installed should
be entered.
If this is left blank, RESOLVE will attempt to start REVEAL in the same
directory as the OpenServer executable (PXServer.exe) is running.
For safety it is recommended to enter the directory from which the REVEAL
In case of difficulties, RESOLVE will wait a certain period when attempting to
start up REVEAL.
If it is not able to do so then RESOLVE will call an error after the timeout
period. For most cases a timeout of 30 seconds should be appropriate.
If a fairly slow machine is used then the user may want to make this value
larger to avoid RESOLVE "timing out" unnecessarily.
Two different timeout duration can be specified, depending whether the
model is run on a single machine or over a cluster setup
2.9.2.2.2 Loading and editing a REVEAL case

Once the REVEAL module icon has been located in the graphical view, it will be required to
associate this module icon to a specific REVEAL model as well as to setup the options that are
going to be used to integrate the REVEAL model to the overall RESOLVE model.
This can be done through the "Edit Case Details" screen that can be obtained by double-
User Guide
158
clicking on the module icon.

Two sub-sections are available:

Case Details
Filename
Machine
Name
Use
specified
computer /
This is the REVEAL case name (extension *.rvl)

REVEAL cases run from RESOLVE can be distributed over a network.
Enter in this field the name of the machine on the network on which the
REVEAL case is to be run. The machine name can be given as an IP address
or a name in the DNS register (e.g. "dave-8200").
Leave the space blank to run REVEAL on the local machine.
should be relative to that machine and not the local machine
The machine name (above) is not used if "use cluster" is specified. In this
case, RESOLVE will start the REVEAL model on some node of a cluster
configured either with PxCluster or LSF. For more information on PxCluster
159
RESOLVE
use cluster
(the Petroleum Experts cluster software), refer to the "PXCluster Overview"

section.
If a cluster is used, the following elements should be kept in mind:
The filename should be visible to all the specified nodes of the cluster
(which, by default, is all the nodes). This means that the file name should
normally be a UNC name.
A subset of cluster nodes and the software executables can be selected
by clicking on "setup". By default, the IPM software is assumed to be
located on the remote nodes in the same path as the local machine, but
this can be overridden from this screen.
IPR
Model
Whether LSF or PxCluster is used, RESOLVE will have to locate a node which
is not busy before starting REVEAL. If there are no free nodes, the startup of
REVEAL will eventually time out. The timeout period can be set in the "
Configuration screen"
This enables to select which type of calculation is used in the simulator to
provide each well inflow performance to the surface network model.
Three main options to calculate this inflow are available:
"Block" option Calculate the inflow performance of the well assuming the
well "reservoir pressure" is equivalent to the pressure of the
block in which the well is perforated.
This option is rarely used as it will lead to an underestimation of the real reservoir pressure for producers
and an over-estimation of the real reservoir pressure
for injectors, therefore leading to erroneous
evaluations of the well performance
"Drainage
Calculate the inflow performance of the well assuming that
the well "reservoir pressure" is equivalent to the pressure at
Region"
the external boundary of the well drainage area. This is the
options
default and more realistic option.
This corresponds to the Drainage Region (Linear) or
Drainage Region (Non Linear) option
"Drainage
A Petroleum Experts proprietary method has been
Region
developed to calculate the well inflow performance: the
(Advanced)" Drainage Region (Advanced) method.
This method has been found to provide more stable
option
and realistic inflow performance curves than the two
previous options, and is the recommended method.
It is important to notice that if this method is to be used, a
setup calculation has to be performed prior to the model
being run.
User Guide
160
This calculation can be launched by clicking on the "Setup"

button that appears when the Drainage Region (Advanced)
option is selected.
The following screen will appear - click on Calculate and the
calculation will be performed.
The Tuning section enables to modify some of the
parameters for this calculation: these parameters are set to
standard values that will handle most of the cases and should
not be modified except under direct recommendation of
Petroleum Experts.
Once the calculation will have been performed, then the "
Setup" button will become green as displayed below.
161
RESOLVE
This calculation only has to be done the first time the

REVEAL model is loaded UNLESS changes to the REVEAL
model have been made since the last calculation was
performed
Load all
The option enables to load different input streams for each completion defined
in REVEAL
completion
data for wells
Associated Data
The following screen will be displayed when selecting this tab:
User Guide
Well
Control
162
When REVEAL is connected through RESOLVE, the connected wells can be

controlled by:
Fixed rate (total liquid rate, or gas rate for gas reservoirs),
Fixed bottom hole pressure
Fixed manifold pressure
System response
The third option is available only when REVEAL is connected to GAP, and is
generally to be preferred to the two previous ones as the lift curve will describe
some of the system response of the surface network and so will reduce the
explicitness of the system. If fixed manifold pressure is selected, it is essential to
include the same lift curves that are in the GAP model in the REVEAL model.
The system response option enables to automatically select which of the three
previous options will be the most suitable to control the well in order to reduce the
impact of the system explicitness.
Once the type of well control has been selected, it is possible to define the
behavior of the wells in case they are shut-in.
163
RESOLVE
This can be done by using the "Edit well shut-in behavior" option.
When this section is selected, the following screen will be displayed:
This screen enable the user to select two different ways of closing a well:
If the well is SHUT, it is assumed that the well is closed at the perforation
level and that there is therefore no crossflow potential at reservoir level.
If the well is STOP, it is assumed that the well is closed at the wellhead level
and that there is therefore crossflow potential at reservoir level.
Using this screen, the user can define, depending on the reason for which the well
does not produce, whether the well has to be SHUT or STOP.
The "Set Global Flags" section enables to do so for ALL wells, whereas the
table at the top lists all the wells and enables to make that choice on a well by well
User Guide
Run
REVEAL
from
164
basis
By default, REVEAL simulations are started from t = 0. If a restart file has been
saved in the simulation case, then this control can be used to start from the restart
date chosen.
The "Load / Refresh" button enables to reload the REVEAL case, which can be
quite useful if the reservoir model has been modified. Please note that RESOLVE
will automatically reload all the clients modules prior to starting a run UNLESS the
contrary has been specified by the user in the general RESOLVE options
2.9.2.2.3 Publishing Reveal variables

This screen allows variables to be published from REVEAL into RESOLVE.
165
RESOLVE
Select the Reservoir section to access the REVEAL variables and click on Edit Variables.
User Guide
166
REVEAL allows variables associated with wells AND with completions to be published in
RESOLVE.
The "Well Data" section enables to automatically publish the well results.
The following procedure can be used to do so:
Step 1
Step 2
Step 3
Step 4
In the well list on the left hand side of the screen, select the well to consider
Click on the "+" sign: the list will expand and all the variables that can be
published for this specific well will be displayed
Select the variables to import in RESOLVE and click on the red arrow: this will
add them in the right hand side list, which summarises the variables that have
been published into RESOLVE
If one wants to publish in RESOLVE a specific variable for ALL the wells in the
REVEAL model, then it will be possible to select the variable in the "All Wells"
drop-down box and click the red arrow next to it. This will update the right hand
side list, which summarises the variables that have been published into
RESOLVE
The "Well Completions" section enable to publish completion results within RESOLVE.
The following procedure can be used to do so:
Step 1
In the Variable Name section, enter the name of the variable to import - This
167
RESOLVE
Step 2
Step 3
Step 4
Step 5
name is user-defined
In the Well section, a drop-down box will allow to select which well the variable
to publish is associated to
In the Completion section, a drop-down box will allow to select which
completion the variable to publish is associated to
In the Variable section, a drop-down box enables to select the variable to be
reported
The variable Unit will then be automatically reported
In the example below, the oil rate of completion 1 of the Horizontal well defined in REVEAL will
be published in RESOLVE.

The following assorted functions are available in the REVEAL driver. These functions can be
accessed for instance by right-clicking on the REVEAL module icon in the graphical view.
Toggle Select
(This Item / All
Children)
Select All
Children /
Unselect All
Children
items
User Guide
Save Case
Reload Case
Display
Child Icons /
Do Not
Display
Child Icons /
Display
Only
Connected
Child Icons
168

edited.
considered
Alias
receive EOS
Tabular well
This option allows the display and editing of all the individual well data in a
single table.
data
169
RESOLVE
The control mode and IPR model can be changed from this table on a perwell basis. It is sometimes appropriate to set different wells to use different
control modes or IPR models, but generally the global defaults are to be
preferred.
Test
PXServer
The drop down boxes at the bottom of the screen may be used to change the
settings of all the wells simultaneously
2.9.2.2.5 Setting up a case in Reveal : Additional Information

In general terms, there are no special requirements that a REVEAL model has to fulfill in order to
be used by RESOLVE, but the following elements can nevertheless be considered:
Well
Scheduling
RESOLVE controls the schedule of the combined run. This means that
scheduling of wells that are connected in RESOLVE will be handled by the top
level schedule in RESOLVE. Wells that are not connected in RESOLVE will
have their REVEAL schedules honoured
User Guide
Start Dates
Lift Curves
Well Type
Setup
Fluid ReInjection
170
The RESOLVE start date and REVEAL start date may be different. If they are
the same RESOLVE will start REVEAL at the start of its run.
If the RESOLVE start is before the REVEAL start, then RESOLVE will shut the
reservoir in until it reaches the REVEAL start date. RESOLVE will
automatically put in a timestep to coincide with the start of the reservoir
schedule.
If the RESOLVE start is after the REVEAL start, then REVEAL will run a
simulation/history until the RESOLVE start date before RESOLVE takes
control
Lift curves in REVEAL will be ignored unless the wells are controlled with a
fixed manifold pressure
Wells will be set to production or injection wells depending on the item that
they are connected to.
For example, if a REVEAL well is connected to a water injector in GAP, then
it will become a water injector in REVEAL
Fluids that are injected into REVEAL may not be at the same temperature as
the reservoir.
It is important in these cases to have a fully thermal PVT model defined in
REVEAL for these fluids
2.9.2.3 Connection to IPM-OS - IPM-OS driver details
2.9.2.3.1 IPM-OS driver configuration

Before the driver can be used effectively, it must be configured for use with IPM-OS. Note that
the IPM-OS driven has the objective to connect RESOLVE to any of the IPM tools (GAP,
PROSPER, MBAL, PVTP, REVEAL, RESOLVE).
The configuration screen can be accessed from the RESOLVE driver registration screen:
Drivers | Register Drivers on the main menu.
Click on the IPM-OS driver in the list and press the "Configure" button. The following screen will
be displayed.
171
RESOLVE

Application
executable
path
Application
timeouts
In this field the directory in which the IPM executables are installed should be
entered.
If this is left blank, RESOLVE will attempt to start the application in the same
directory as the OpenServer executable (PXServer.exe) is registered.
For safety it is recommended to enter the directory from which the IPM
In case of difficulties, RESOLVE will wait a certain period when attempting to
start up the application.
If it is not able to do so then RESOLVE will call an error after the timeout
period. For most cases a timeout of 30 seconds should be appropriate.
If a fairly slow machine is used then the user may want to make this value
larger to avoid RESOLVE "timing out" unnecessarily.
Two different timeout duration can be specified, depending whether the
model is run on a single machine or over a cluster setup
User Guide
172
2.9.2.3.2 Loading and editing an IPM-OS case

The first step is to place an IPM-OS instance in RESOLVE by selecting the button
or the
menu Edit System / Add client Program / IPM-OS and then clicking anywhere in the main screen.
This will create a module icon.
Note that the first time the module icon is created, it will have the aspect of a PROSPER icon:
Later, after the IPM application has been defined, the icon will change depending on the
application selected. For example, if the application selected in GAP, the icon will turn to the one
of GAP:
Once the IPM-OS module icon has been located in the graphical view, it will be required to
associate this module icon to a specific IPM model as well as to setup the options that are
going to be used to integrate the new module to the overall RESOLVE model.
This can be done through the "Edit Case Details" screen that can be obtained by doubleclicking on the module icon.
173
RESOLVE
Three sub-sections are available:

IPM
application
IPM
model
In this section it is possible to select the IPM tool to connect (GAP, PROSPER,
MBAL, PVTP, RESOLVE, REVEAL)
In this section details concerning the IPM model to run need to be entered:
File
name
Name and full path of the model to run
Machine
Name
IPM cases run from RESOLVE can be distributed over a

network.
Enter in this field the name of the machine on the network on
which the IPM case is to be run. The machine name can be
given as an IP address or a name in the DNS register (e.g.
User Guide
174
"dave-8200").
Leave the space blank to run the application on the local
machine.
When entering file (case) names for remote machines, the file
name entered should be relative to that machine and not the
local machine
Use
The machine name (above) is not used if "use cluster" is
specified. In this case, RESOLVE will start the IPM model on
specified
some node of a cluster configured either with PxCluster or LSF
machine /
use cluster (Platform). For more information on PxCluster (the Petroleum
Experts cluster software), refer to the "PXCluster Overview"
section.
If a cluster is used, the following elements should be kept in
mind:
The filename should be visible to all the specified nodes of
the cluster (which, by default, is all the nodes). This means
that the file name should normally be a UNC name.
A subset of cluster nodes and the software executables can
be selected by clicking on "setup". By default, the IPM
software is assumed to be located on the remote nodes in
the same path as the local machine, but this can be
overridden from this screen.
Whether LSF or PxCluster is used, RESOLVE will have to locate
a node which is not busy before starting the IPM application. If
there are no free nodes, the startup of the application will
eventually time out. The timeout period can be set in the "
Configuration screen"
Actions
to take
In this section the user can define the actions the connected IPM application
needs to carry out, like for example entering data in the model or running
calculations.
Type
Defines the action to take. These are two possible choices:

DoCmd (run a calculation or perform a command like masking
wells in a GAP model), DoSet (enter an inout in the model)
OS
OpenServer variable associated to the command to perform or
Statement the input to enter in the model
Arg "i" field This contains arguments of the OS Statement variable.
For example:
GAP.SOLVENETWORK(1) is the variable to perform Solve
Network calculations in GAP with optimisation mode. In this case
the OS Statement is GAP.SOLVENETWORK, whilst the
argument is "1"
175
RESOLVE
2.9.2.3.3 Publishing IPM-OS variables

This screen allows variables to be published from any of the IPM tools (here named IPM-OS
application) into RESOLVE.
Select the IPM-OS section to enter the corresponding variables and click on Edit Variables.
User Guide
176
RESOLVE has access to virtually all the parameters input and output by the connected
applications. In order to import a variable, paste the corresponding OpenServer string in the
table, along with a user-defined variable name and reporting name.
Variable
name
Reporting
node
OpenServer
string
Writable
Name associated to the variable to input/output. This is chosen by the user

and is used for reporting purpose
Name used to identify the model itself. This could be for example the name
of a well or of a field. The name is chosen by the user and is used for
reporting purpose
OpenServer string corresponding to the variable to import/export.
For input/output parameters usually the string can be directly obtained from
the program GUI by pointing the value itself and using the combination
CTRL + mouse right click. Alternatively, the OpenServer strings can be
obtained from the OpenServer User Guide
Highlights if the variable is read-only or can be changed by the user
177
Unit
Delete
RESOLVE
Units corresponding to the imported variable

Table entries can be erased by clicking on the button under the Delete
column
Example
In the following example the IPM-OS instance is a PROSPER well model. The variable imported
is the liquid rate from the System calculation:
Note that the variable is called Liquid_rate and the Reporting node is called well1.
After running a calculation, in the results it is possible to see the role of the variable name and
reporting node:

The following assorted functions are available in the IPM-OS driver. These functions can be
accessed for instance by right-clicking on the IPM-OS module icon in the graphical view.
User Guide
Toggle Select
(This Item / All
Children)
Select All
Children /
Unselect All
Children
Save Case
Reload Case
Display
Child Icons /
Do Not
Display
Child Icons /
Display
Only
Connected
Child Icons
178
items

edited.
considered
Alias
receive EOS
Test
PXServer
2.9.2.3.5 Setting up a case with IPM-OS: Additional Information
In general terms, there are no special requirements that an IPM-OS model has to fulfill in order to
be used by RESOLVE, but the following elements can nevertheless be considered:
Models
validity
As with all calculations, quality checking of the model before the simulation
is run is extremely important.
It is recommended to quality check each model connected running it
standalone and making sure it yields consistent results before linking it
within RESOLVE
179
RESOLVE
2.9.2.4 Connection to Eclipse - Eclipse driver Details

2.9.2.4.1 Eclipse pre-requisites
The following list summarises the resource requirements for Eclipse to run under RESOLVE.
1.
2.
3.
4.
5.
Eclipse licences are required as they would be if Eclipse was running standalone. For
example, an E300 model would need access to a compositional licence. Other models
may require parallel licences, multisegmented wells licences, and so on
Each Eclipse model under RESOLVE will require its own set of licences. In other words, 2
Eclipse models in a RESOLVE model will require 2 Eclipse licences
For RESOLVE, each Eclipse model will also lock an OpenEclipse licence. These are
available from Schlumberger. To avoid any doubt, it is the runtime licence, rather than the
development licence, that is required
Appropriate hardware must be available to run Eclipse. Windows 2000, XP, and Vista
operating systems are supported for RESOLVE. Eclipse can also run under these
operating systems and, from the 2009 version, 64-bit Windows is supported (XP or 2003
Server). Eclipse can also be run under Linux while connected to RESOLVE: the supported
architectures are ia32 and x86_64
The protocol used for communication between RESOLVE and Eclipse is MPI. Various
flavours of MPI can be used, as explained below. However, an appropriate installation of
MPI must be configured on the machine(s) in question in order for the connection to work.
Most, but not all, supported MPI flavours come free with the Eclipse software
When RESOLVE executes Eclipse, it does so by directly calling the Eclipse executable, and not
by calling the usual Eclipse macros. This means that the licence information for Eclipse may be
missing, leading to a licence error.
It may therefore be necessary to set up the environment variable LM_LICENSE_FILE to point to
an Eclipse licence before using the RESOLVE-Eclipse link. This can be done through Control
Panel | System | Advanced | Environment variables.
2.9.2.4.2 The use of MPI to connect to Eclipse

The connection between RESOLVE and Eclipse is through a mechanism known as
'MPI' (message passing interface). By this method, commands and data are transferred
between RESOLVE (or more specifically, the Eclipse driver) and the Eclipse application.
MPI superseded PVM as the data passing mechanism in the 2007 versions of Eclipse. Notes
on the use of PVM can be found here, although its use is not recommended or, indeed,
supported.
The situation regarding the versions of MPI which work with Eclipse have changed over the
various Eclipse releases. The situation from the 2009 version is summarised in the tables
User Guide
180
below:
Windows
Eclipse version
Pre-2009
2009+
MPI flavour
Verari MPI
Intel MPI
Notes
32-bit only, incompatible with Windows
Vista, free
32- or 64-bit(*) and Vista compatible.
Free.
* RESOLVE always runs as a 32-bit application, even on a 64-bit operating system. However,
certain components have a 64-bit version which allow the connection to 64-bit Eclipse.
Note that the Windows versions of MPI do not allow cross-platform connections: they connect to
Eclipse running on the same machine as RESOLVE, or to another Windows machine on the
network. To connect to Eclipse running on Linux, use the mechanisms below.
Linux (Red Hat 4 or 5)
Eclipse version Processor
MPI flavour
Notes
Pre-2009
ia32
mpich or Platform MPI(*) mpich is free, Platform MPI is
licensed by Platform(**)
Pre-2009
x86_64
Platform MPI
2009+
ia32
mpich or Platform MPI
2009+
x86_64
Platform or Intel MPI
Intel MPI is free
* Platform MPI was formerly known as Scali MPI, or Scali Connect (SMC).
** Platform MPI is recommended for this application, as it is considerably more robust.
When connecting to Linux, RESOLVE still runs as a Win32 application.
2.9.2.4.3 Setting up MPI

Once it has been decided which flavour of MPI is required, or which mode of operation (Eclipse
on Windows or Linux) is to be used, it will be necessary to install and configure the appropriate
software.
Setting up Verari MPI (Windows, pre-2009 Eclipse versions)
Setting up Intel MPI (Windows, 2009+ Eclipse versions)
Setting up the Linux software (all Eclipse versions)
Once the MPI software has been set up, RESOLVE (or specifically, the Eclipse-RESOLVE
181
RESOLVE
driver) needs to be configured for local Windows connections to point to the correct version of
the Eclipse software, and to set up a couple of other settings.
See also the section dealing with connections to Eclipse when running under Citrix.
2.9.2.4.3.1 Setting up Verari MPI
Verari MPI works only with Eclipse versions older than the 2009 version.
Step 1
Step 2
MPI needs to be installed on the local PC.

Installation instructions and files are available on the Eclipse CD provided by
Schlumberger. Once MPI has been installed, the computer needs to be re-booted
and the user password needs to be registered with MPI. This is done through
the 'password registration' utility that should have been set up in the MPIPro
program group. An encrypted password file will be stored in the home directory
The Eclipse 'configuration utility' needs to be run to test the use of MPI through
RESOLVE.
This can be done by going to Wizard | RUNECLCONFIG.EXE
In the first screen of the configuration wizard, select Configure and Test Verari
MPI.
User Guide
182
The following screen will help to know whether the relevant MPI service is running or
not.
183
RESOLVE
If the service is not installed, as is the case here, one needs to start the MPI service
manually.
To do so, go to:
Control Panel | Administrative Tools | Services
Look for the MPI Pro Startup Service and Launch the service manually.
User Guide
184
The MPI_HOME environment variable, below, would normally be set up by the MPI
installer.
The next screen enables the testing of whether Eclipse can be run or not. There is
no need to have an Eclipse license available on the computer to do so.
185
RESOLVE
The path to the Eclipse executable has to be given, as well as the type of
communication used: Windows Messages or TCP / IP. The TCP/IP method, which
came later, is to be preferred as it does not depend on the transmission of
Windows messages (which some systems block).
When doing the tests for the first time, it is useful to select the 'View Output of
MPIRun Command (notepad)' option, as this will ease the diagnosis should
Eclipse fail to start.
Click on 'Test Eclipse startup' and this will test whether Eclipse can be started
from RESOLVE.
If this is the case, the following message will be displayed:
User Guide
186
If a windows firewall is setup on the machine that is used, it is possible that a firewall
message will be displayed, asking whether the start up of the Eclipse software has to be
blocked or not. The user has to confirm that the Eclipse software can be launched by
selecting the 'Unblock' option
When this setup is ended, clicking on 'Next' will bring the user to a screen similar to the
previous one, but specifically designed to configure remote connections with Eclipse (i.
e. Eclipse running on one PC and RESOLVE on another PC). The same procedure than
described above can be used to do so, with MPI being installed on both machines
considered
2.9.2.4.3.2 Setting up Intel MPI
Intel MPI works only with Eclipse versions starting from 2009.
Step 1
MPI needs to be installed on the local PC.

Installation instructions and files are available on the Eclipse CD provided by
Schlumberger (in fact, MPI can be installed from the Eclipse installer interface).
Once MPI has been installed, the computer needs to be re-booted and the user
187
RESOLVE
password needs to be registered with MPI. This is done through the 'password
registration' utility (wmpiregister) that should have been set up in the Intel MPI
program group. An encrypted password file will be stored in the home directory.
Step 2
Note: during the installation, the option is presented to allow the setup of the
I_MPI_ROOT environment variable. This should be set up
Additional configuration tasks - IMPORTANT:

The version of Intel MPI that ships with Eclipse 2009.1 does not set up the path
environment variable correctly. For example, something similar to this might be set
up:
PATH=C:\Program Files\Intel\MPI-RT\3.2.0.011\bin;...
This path does not exist, it should read:
PATH=C:\Program Files\Intel\MPI-RT\3.2.0.011\ia32\bin;...
or for 64-bit systems:
PATH=C:\Program Files\Intel\MPI-RT\3.2.0.011\em64t\bin;...
This must be corrected, otherwise the mpiexec call which RESOLVE makes will fail.
It must be corrected for all Windows machines on which RESOLVE will connect to
Eclipse.
Step 3
This can be done from the Control Panel | System | Advanced | Environment
Variables
The Eclipse 'configuration utility' needs to be run to test the use of MPI through
RESOLVE.
This can be done by going to Wizard | RUNECLCONFIG.EXE
In the first screen of the configuration wizard, select Configure and Test Intel MPI.
User Guide
188
The following screen will help to know whether the relevant MPI service (spmd.exe)
is running or not.
189
RESOLVE
The panel at the bottom indicates whether the correction in step 2 has been made
correctly.
If the service is not installed, as is the case here, one needs to start the MPI service
manually (see the instructions for Verari MPI).
The next screen enables the testing of whether Eclipse can be run or not. There is
no need to have an Eclipse license available on the computer to do so.
User Guide
190
The path to the Eclipse executable has to be given. In contrast to Verari MPI, there
is no need to specify Windows messages as opposed to TCP/IP for the
transmission protocol; it will always use TCP/IP.
When doing the tests for the first time, it is useful to select the 'View Output of
MPIExec Command (notepad)' option, as this will ease the diagnosis should
Eclipse fail to start.
Click on 'Test Eclipse startup' and this will test whether Eclipse can be started
from RESOLVE.
If this is the case, the following message will be displayed:
191
RESOLVE
If a windows firewall is setup on the machine that is used, it is possible that a firewall
message will be displayed, asking whether the start up of the Eclipse software has to be
blocked or not. The user has to confirm that the Eclipse software can be launched by
selecting the 'Unblock' option
When this setup is ended, clicking on 'Next' will bring the user to a screen similar to the
previous one, but specifically designed to configure remote connections with Eclipse (i.
e. Eclipse running on one PC and RESOLVE on another PC). The same procedure than
described above can be used to do so, with MPI being installed on both machines
considered
2.9.2.4.3.3 Setting up the Linux MPI software
As RESOLVE always runs on Windows, a connection to Eclipse running on Linux is, by

definition, a remote connection. See the section on remote controlled Eclipse runs on Linux.
2.9.2.4.4 Driver Configuration
Before the driver can be used, it must be configured for use with Eclipse. Separate settings are
held for Eclipse, E300, and DeadOil Eclipse.
User Guide
192
This screen can be accessed from the RESOLVE driver registration screen (Drivers | Register
Drivers on the main menu) and allows the setup of various global options related to the Eclipse
link(s).
Input fields
Eclipse
license
The Eclipse100 and Eclipse300 drivers can both be configured to loop

while waiting for a license.
Essentially, RESOLVE will try and obtain an Eclipse license and, if it fails,
will continue trying for a certain number of attempts with a fixed time delay
between each attempt.
In this part of the screen enter the maximum number of retries before
193
RESOLVE
RESOLVE gives up and the time delay between each retry. Note that
there is no way of aborting the process and so one should be careful
about entering large values for the maximum number of retries.
Note also that the default behaviour of Eclipse is to check the license
after the grid file has been read. This can cause the loop to run rather
slowly. In addition, one should be careful about entering too short a time
delay between retries as Eclipse will flag an error if the log file is not
unlocked before the next attempt is made.
Communication
These options should not be used unless there is a very good reason to
do so
Here the mode of communication between RESOLVE and Eclipse can be
specified. These settings are only relevant to the use of Eclipse
when it is local to the machine running RESOLVE, or when
connecting to another Windows machine.
There are three options: PVM, Verari MPI, and Intel MPI. See the 'Use of
MPI' section for further information.
It is important to note that support for PVM has been discontinued by
Schlumberger: The 'PVM Setup' section provides legacy notes regarding
this communication protocol. Therefore it is recommended to use the
appropriate MPI communication channel
If 'Verari MPI' or 'Intel MPI' is chosen, then the following options become available:
Local program
executable path
Show MPI server
interface (Verari
only)
Process start
timeout
Communication
with local
controller (Verari
only - Intel always
If the path to eclipse_mpi.exe is in the $PATH environment variable then

this version will be executed. If it is not in the path, then the path to
eclipse_mpi.exe/eclipse_ilmpi.exe (or e300_mpi.exe for E300 runs) must
be entered here
The communication between RESOLVE and Eclipse_mpi is through a
third program called MpiServer.exe. Normally this program is hidden, but
here there is the option to show this interface during the run. Having the
interface open will slow down the runs but it can be a useful debugging
tool
The timeout for the process start is supplied here. It applies to both
Windows systems and Linux systems, and refers to the time taken after
the command to start Eclipse is executed until the first communication
with Eclipse can be made. The default (20 seconds) is normally
reasonable, although there have been cases on Linux clusters where it
has been necessary to increase the timeout significantly (3-4 minutes)
This enables to specify whether communications will go through Windows
messages or TCP/IP channel
User Guide
194
uses TCP/IP)
Local
This option can be used to force the LM_LICENSE_FILE environment
LM_LICENSE_FIL variable to an appropriate value which may point to an Eclipse licence
server or servers. RESOLVE is not able to change this setting at the
E override
system level; the change is only made for the current RESOLVE session.
Nevertheless, the setting made here is retained for all future RESOLVE
sessions. If no value is entered, the LM_LICENSE_FILE value is taken
from the system environment
Debugging
The option Log timings at end of end of run generates a large amount
of performance data for the run which can be helpful if benchmarking is
being performed
2.9.2.4.4.1 Running Eclipse on Citrix
The following elements should be kept in mind when running Eclipse through RESOLVE under
Citrix.
Typically, RESOLVE will be an application that is published under the Citrix framework. Eclipse
does NOT need to be published under the Citrix framework to be used by RESOLVE.
There are three possible configurations:
Eclipse running on the
Citrix server (but not
published)
This is equivalent to a standard local installation, where RESOLVE

and Eclipse run on the same machine. When RESOLVE is run,
Citrix effectively "logs on" to the server under the user account of
the person running RESOLVE, and so any log on environment
settings will take effect in the Citrix session.
It will be necessary to ensure that the LM_LICENSE_FILE
environment variable is set up in the RESOLVE session. This can
be done for all users by setting the variable on the server, or can be
set up as part of the user's log on environment (as explained
above).
As is normal with MPI, the password must be registered before MPI
will start Eclipse. If the user's home directory (which is where the
encrypted password file is stored) is a network driver which is
mapped from the Citrix server, then it will be sufficient for the user
to run the password registration on the local machine.
If the user's home directory is not set up in this way, it will be
necessary to perform the password registration on the Citrix server.
This can be done by publishing the registration program
(MPIpasswd.exe under the MPIPro\bin directory) to allow users to
run it under the Citrix environment.
Alternatively, the password registration can be run from a command
195
RESOLVE
Eclipse running on the

local desktop or some
other Windows
machine
Eclipse running on a
Linux machine
prompt which is published under Citrix

This is equivalent to a remote run of Eclipse: even if the local
machine is used for Eclipse, as far as RESOLVE (which is running
on the Citrix server) is concerned it is communicating with a remote
computer.
The notes on "Configuring Eclipse to run remotely" should be
followed
As long as the Linux machine is visible from the Citrix server (and
can be pinged by DNS name) there is no problem with this
configuration and no additional setup is required.
The notes on "Configuring Eclipse to run remotely" should be
followed
2.9.2.4.5 Loading and Editing an Eclipse case : Overview

To create an instance of Eclipse in the RESOLVE system, click on Edit System | Add Client
Program | Eclipse OR Eclipse300 OR DeadOil Eclipse from the RESOLVE main menu.
If the Eclipse entries does not exist in the menu, then the drivers need to be registered with the
RESOLVE application.
See the "Driver Registration" section to do so.
In order to open and / or run an Eclipse case, the Eclipse connection needs to be
configured. Refer to the "ECLCONFIG.EXE ", "Setting up MPI" and "Running an Eclipse
instance on a remote computer" sections for further information on how to setup an
Eclipse connection on both local and remote machines.
Once the icon is created on the RESOLVE interface, double-click on the icon to enter the load/
edit case screen.
The following screen displayed and is split into three tabbed sections:
Case Details
Control Data
Miscellaneous
This tab has information on the Eclipse data file and the machine on which
the Eclipse runs.
More information regarding these settings can be found in the "Eclipse
Driver : Case Details Section"
This tab contains information on how wells are controlled and whether or not
Eclipse group controls are to be respected.
Driver : Control Data Section"
This section contains information on other items, such as whether the well
management should be taken from the Eclipse schedule or the connected
application (i.e. normally GAP).
User Guide
196
Driver : Miscellaneous Section"

The Advanced section at the bottom of the screen contains some options that have been
introduced to cope with exceptional circumstances in the model. Normally they should not be
changed. More information regarding these settings can be found in the " Eclipse Driver :
Advanced Options Section".
The Start button will start the Eclipse simulation (e.g. or stop it if it is already running). It will be
necessary to start Eclipse in order to generate the well icons in RESOLVE, although the startup
may take some time. Once the wells have been created in RESOLVE, it will not be necessary to
start Eclipse unless a run is being performed.
The OK button will save the settings that have been made without running Eclipse. Care should
be taken if the data file contents have been changed compared to the well representation on the
RESOLVE screen. If changes have been made, or the data file itself has been changed, Start
should be used to refresh the RESOLVE screen.
197
RESOLVE
2.9.2.4.6 Eclipse Driver: Case Details Section: Overview
The following settings can be specified through this screen:

File Name
This is the data file name. It should be an Eclipse100 or 300 case

depending on the driver being run.
User Guide
198
Note that no syntax errors have to be present in the data file as that will
cause Eclipse to terminate prematurely.
As a general rule, it will be necessary to check that the model runs
independently (i.e. standalone) before including it in a RESOLVE model
It is important to note that OpenEclipse only allows file names of 72
or less characters. If the file considered has a file name of more than
72 characters, it will be required to relocate this file into another
location before the connection can be established
Windows
shared
path to
data file
This is optional. If it is supplied then it should be a Windows path to the data

file given above, in the case that the path given is not visible from the
machine running RESOLVE (notably if the model is running on Linux). It is
used in the following ways:
Parallel run
1. To allow the IFM model catalogue to locate and store Eclipse models
located on other systems or architectures than the local system.
2. To allow the viewing of the data, log, and prt files from the local
workstation
Parallel Eclipse is supported for Linux runs. If this button is checked then the
"Parallel options" button will be displayed, and all controls on the screen
which are not required for the Linux setup will be greyed out
This is the name of the host on which Eclipse100 or Eclipse300 or DeadOil
Eclipse is to be run.
Machine
The file name specified should be the file as seen by the remote computer
(i.e. relative to the root of the remote computer file system).
This is a
remote
Linux Run
Send data
file to client
Remote
working
folder
Grid
A remote Windows machine must be "visible" to the MPI protocol (i.e. the
MPIStartupServer or similar Intel MPI service must be running on the remote
machine). A remote Linux machine does not have to be visible to MPI, but it
will be necessary to fill in the port number and location of the run factory
(controller) machine. See the "Running an Eclipse instance on a remote
computer" section for further information
If a remote Linux machine is used, this tick-box should be selected, and the
machine port number and controller machine name should be specified
This may be used if the file specified under "File Name" is not visible to the
remote computer. This option is not recommended. The data file will be
sent to the remote instance of Eclipse by the driver. For most models this
can be quite slow to initialise (although the actual forecasting time is
unaffected)
If sending the data to the client (above), this allows the working folder on the
remote machine to be specified. All Eclipse output files will be written to this
directory. The path must exist on the remote machine, otherwise the Eclipse
initialisation will fail
These options allow the grid topography to be imported into RESOLVE for
199
RESOLVE
topography
options
Read "best
practice"
document
PVT File
visualisation or drainage pressure calculation purposes.

See "Loading the Grid Topography" section for more information on these
options
This enables to display the best practice document that describes the best
way to setup an Eclipse model in order to link it with a GAP model through
RESOLVE.
See the "Best Practice" section for further details
Eclipse300 only
OpenEclipse does not allow the EOS properties to be read dynamically,
and so this data is parsed from the data deck.
In this edit field the name of the file in which the EOS properties are held
should be entered, which may be the same as the file entered under "File
Name".
Note that INCLUDE files are not read. Note also that, if no properties are
read (e.g. if no file is supplied), black oil properties will still be passed from
the simulator to the receiving model
2.9.2.4.7 Eclipse Driver: Case Details Section: Parallel options

If Eclipse is run on a Linux system, then parallel Eclipse may be used.
To do this, the "Parallel run" check box should be clicked on the main "case details" screen.
The "Parallel options" button should then appear, which when pressed invokes this screen.
User Guide
200
Two options are available for machine allocation purposes:

Manual
Machine
Allocation
In this case, the machines on which the Eclipse models are run are selected
by the user.
The "LSF will be used to allocates suitable nodes" option is not selected.
The number of processors to be used in the parallel run along with the
machines in the cluster should be entered here.
Note that the number of processors MUST be the same as that set up in the
Eclipse model (using the "PARALLEL" keyword, for example), otherwise
the run will fail.
Also, the parallel run will use the Scali (SMC) version of eclipse
(eclipse_scampi.exe or e300_scampi.exe) and so it will be necessary to
ensure that the SMC options have been set up appropriately, with the
correct interconnect (e.g. infiniband) etc.
201
RESOLVE
LSF
Machine
Allocation
In this case, the machines on which the Eclipse models are run are selected
by the LSF cluster.
The "LSF will be used to allocates suitable nodes" option is selected
2.9.2.4.8 Eclipse Driver: Case Details Section: Loading Grid Topography - Overview
The grid topography can be loaded into RESOLVE.
This enables for instance the grid visualisation as displayed below.
The following sections will illustrate the method used to load the grid topography within
RESOLVE.
Go to the "Step 1" section to see this explanation.
User Guide
202
2.9.2.4.9 Eclipse Driver: Case Details Section: Loading Grid Topography - Step 1
The first step is to check the options defined for the Eclipse model considered on the "Case
Details" tab and select the "Import grid topography" option.
A button should be displayed: it will appear red when no grid is currently loaded (as shown).
The path to a graphics file should be added: the visualisation data will be written to this file.
If the file does not exist, RESOLVE will create it.
203
RESOLVE
To start loading the grid, press the red button.

Go to "Step 2".
The "Grid" button on the case details tab enables to access the following screen.
The grid topography is read into RESOLVE from the output files of the Eclipse run (i.e. the grid /
egrid files, the init files, and the rst / unrst files).
A run must therefore have been done previously to generate these files with the Eclipse data
decks set up correctly to generate them.
The restart files are required as this is where the well data is read from. For this reason it is
necessary that the restart files contain all the wells that are in the coupled run, otherwise errors
will occur when the RESOLVE run is performed.
If there are several restart records in the restart file, the last one in the list is imported.
User Guide
204
The first step will be to specify the Eclipse data directory, the Eclipse root name (i.e. name of the
Eclipse case) and whether the restart file available is unified or not.
For convenience, the eclipse data directory and root name fields are filled in automatically with
data from that entered in the "Case details" screen. This can as well been edited.
When the data in these fields has been entered, click on the Load button and move to "Step 3
".
205
RESOLVE
If the grid is loaded successfully into RESOLVE, the screen will have the following appearance.
Parts of the data that were read in are displayed, e.g. the number of wells and their names, the
grid dimensions, and whether the PVT data could be read.
It is not essential that the PVT data is read from the Eclipse data. Indeed, it is not possible
currently to read models with the VAPOIL keyword or E300 EOS data. RESOLVE uses the PVT
data to dynamically calculate PVT properties such as phase density. If the PVT tables can not
User Guide
206
be read these properties will be added to the data includd in the SUMMARY section INCLUDE
file.
The next step is to generate the cells whose data (pressure, saturations, etc) will be passed to
RESOLVE. The cells are selected by considering the diffusivity of the fluids around the wellbore,
as described in the next step.
In the above screenshot, no cells have been selected and the button is red. Click on the button to
select the cells in "Step 4".
When the cells are to be selected for the first time, the screen has the following appearance.
207
RESOLVE
The following dataset has to be entered:

Diffusivity
time
Reference
pressure /
Reference
temperature
Wells
This is the diffusivity time of the fluids to each wellbore in the model. Cells
that lie within this diffusivity time of the wellbores will be selected
These data are used in PVT calculations to estimate fluid mobilities for the
diffusivity calculation. They will not usually affect the selected region greatly
and so should be set to "ballpark" figures for the model
This grid contains information on the wells that have been imported from the
Eclipse data (i.e. a single well in the above example).
User Guide
208
It allows the cell selection to be configured on a well by well basis, based on

the following parameters:
Perforations
Select
Number of blocks
Shared blocks
Set diff time
Diff time (days)
This contains the number of perforated layers for the

well in question
This allows to select which wells to consider when
importing grid cells. This option enables for instance
to load cells related to a well that is not connected in
the RESOLVE model, or to select additional cells to
be reported
This is the total number of cells selected for this
particular well
This is the number of cells selected for this particular
well which are also shared with other wells. This
gives an idea of how much interference an individual
well can expect from other wells
This allows to set an individual diffusivity time for this
well which will override the global diffusivity time set
at the top of the screen
If an individual diffusivity time is required (as set
above) then this should be entered here
To select cells, set the data in the fields as required and click on the Update button.
The screen will then have the following appearance:
209
RESOLVE
In this case a total of 77 cells have been selected into the diffusivity region about the single well,
P16.
The default diffusivity time of 1 day is normally reasonable. An upper limit of about 25000 30000 cells should be considered.
To reduce the number of cells the global diffusivity time can be reduced, or the diffusivity time for
selected wells, or wells can be unselected from the list.
After this has been done, clear the screen by clicking OK.
The cells have now to be written to the SUMMARY section of the Eclipse model. This is done in "
User Guide
210
Step 5".
Having selected the cells, it will be necessary to come back to the main grid topography screen.
The cell generation button should be displayed in green and the number of cells selected should
be displayed, as shown.
The cell property data has now to be written to the SUMMARY section.
There are two possibilities:
Automatically
Automatically write the data to the summary section of a data file. This can
Update the DATA obviously only be done if the Eclipse model is not remote on a network
computer. By default, the name of the current .data file is loaded into the
File
screen field (as shown), although one can browse to another data file if
needed. Selecting the Update button the data will be written; if Eclipse is
running it will have to be stopped and restarted and this can take some
time.
If this option is selected, the data file will be adjusted in two places:
Under RUNSPEC a SMRYDIMS keyword will normally be added to tell
Eclipse to expect a certain number of summary section keywords.
Under the SUMMARY section itself an INCLUDE will be added to
include the new summary keywords. It will be tagged to indicate that this
has been added by RESOLVE.
211
RESOLVE
Manually Update An include file can be generated which can then be entered manually into
the data file. This will be necessary for remote runs. Selecting Update
the DATA file
there will be some instructions on how to add the generated file to the data
file.
All the data entry screens can then be confirmed to return to the main
RESOLVE screen. The grid topology that has been imported and the
settings (e.g. diffusivity) used will be saved with the RESOLVE file
The model can then be run.
Refer to the "Step 6" section to finalise the grid topography import method.
User Guide
212
Running the model and viewing the data
When the coupled model is run, the date and time of the grid import will be displayed in the
calculation screen.
This will help to ensure that the imported grid and the grid used in the coupled run remain
synchronised. The grid dimensions of the model that is run are also checked against those of
the grid that is imported.
During, or at the end of the run, the visualisation tool can be accessed to look at the properties
of the selected grid cells. This can be done by right-clicking on the Eclipse icon on the
RESOLVE main screen:
When this is done, a visualisation window will appear.

Below is a brief list of the actions that can be performed:
Rotation about an
axis in the plane of
the visualisation
Rotation about an
axis normal to the
plane of the
visualisation
Zoom in
Zoom out
Left-click on the window and drag
<Shift> and right-click on the window. The speed of rotation is related

to the distance of the mouse from the centre of the window
<Ctrl> and drag, or highlight the magnifier(+) icon and drag, or highlight
the icon and click once in on the window for a fixed zoom, or use the
mouse wheel
Highlight the magnifier(-) icon and click once, or use the mouse wheel
213
RESOLVE
Reset zoom
Change property
to view
Click the reset toolbar button, next to the zoom buttons

Right-click on the window and select the new property from the View
sub-menu
Other functions are available from the toolbar buttons, such as the ability to take cutting planes,
remove objects, and so on.
In addition, a drainage pressure calculator will appear.
At the top of the screen is a list of the timesteps that have been saved in the grid file (i.e. which
were specified in the case details tab of the data entry screen).
In the above example only a single timestep has been saved.
As one toggles to different timesteps the date of the timestep viewed changes. At the same
time, the property data in the main visualisation window is updated (new pressures, saturations,
and so on) and the calculated drainage region pressure is updated.
In addition, it is possible to choose whether to view the data in SI or oilfield units.
User Guide
214
2.9.2.4.15 Eclipse Driver: Control Data Section

This tab contains the data that relates to the control of wells in the Eclipse run.
The entry screen will be as follow:
The following elements can be setup :

Control
level
Choose from Explicit (start of timestep consistency) (default) and Newton

(end of timestep consistency)
Explicit The explicit control is the RESOLVE standard: inflows are
215
RESOLVE
Control generated for each simulation module based on the reservoir

conditions at each RESOLVE synchronisation timestep. These
are then passed to the receiving module (e.g. GAP) which
performs its solve / optimisation and then passes the results
back to the simulation models. The inflow operating points (i.e.
bottom hole pressures, flow rates, or tubing head pressures) are
then held constant over the next RESOLVE timestep such that
there will be a divergence between the reservoir conditions and
the surface network response by the end of the timestep
Newton In a Newton control system an iteration loop is entered between
a single Eclipse model and a single GAP model such that the
Control conditions at the end of each timestep are consistent between
the simulation model and the surface network. In this case the
timestep length is set by the simulation model and the timestep
size entered in the RESOLVE schedule simply serves as an
upper limit on the simulator timestep size (in addition to any
such limits in the Eclipse deck)
Aside from the above limitation, there are other reasons why
Newton level control may not be advisable:
The run will be much slower than the equivalent explicit run.
Petroleum Experts experiments indicate that the deviation
between fully implicit and explicit results are minimal provided
a suitable control method is chosen for the wells. In addition,
the adaptive timestepping in RESOLVE can be used to
speed up the forecasts.
GAP is capable of genuine (i.e. physically realistic) non-linear
behaviour which may make convergence with a Newton
method very slow or impossible. This is particularly true when
GAP has many degenerate solutions.
The Newton level control should not be used unless only a sin
Eclipse model is to be connected to a single GAP model which
run predictively. This is because the timesteps in this case are
the Eclipse model - the Eclipse model becomes the "master" o
system
When Eclipse is controlled at the Newton level the workflow is as

follows.
The first Newton iteration is entered by RESOLVE and inflows
are generated for all the connected wells.
These IPRs are used by the connected program (i.e. generally
GAP) to calculate operating points on the inflow performances
(rates, bottom hole pressures, tubing head pressures).
The operating points are applied to the Eclipse model and a
Newton solve is performed with these well controls.
User Guide
216
The Newton iteration results in new inflows being generated

for GAP. GAP uses these inflows to calculate new operating
points on the inflow performance relations.
A further Newton solve is carried out and again new IPRs are
calculated. The process continues until IPRs of successive
iterations converge in all phases. The tolerance for this
convergence is given below (RMS tolerance field).
Once convergence has been achieved Eclipse may perform
other iterations for its own internal convergence criteria. For
this reason it is possible that
there will be a divergence
between the points on the IPRs calculated by GAP and the
eventual solution used by Eclipse (e.g. if fixed rate is the
control, the BHP calculated by Eclipse may diverge from that
calculated by GAP). It is therefore important to set a
reasonably tight tolerance on the convergence.
Maximum
iterations /
RMS tolerance
Control
production
wells / Control
injection wells
Auto-switch
between
gas and liquid
control
Fluid
temperature
These settings govern the performance of the Newton level control.

The default values will be suitable for most cases and these values should
normally not be modified
Inflow Performance Type
The IPR generation is a very important consideration when
setting up coupled models. More details can be found in the "
IPR Generation Options" section
This is a global setting for all production / injection wells determining how
the wells will be controlled. Individual well controls can be set by pressing
the Set individual well controls button.
Care should be taken when setting the control mode in an explicitly
controlled system. For example, very productive wells operating under a
small drawdown should not be controlled with a fixed bottom hole pressure
as the rate can then vary enormously over the length of the RESOLVE
timestep.
The default setup, which is to control the wells by their main phase rate, is
the most reliable way to control the wells for a wide range of circumstances
In some cases wells which are predominantly producing oil may, at some
stage in later life, start to produce large amounts of gas (or vice versa). A
fixed oil or liquid rate may not be appropriate for the well over its entire
lifetime. This option allows to switch automatically between a fixed liquid,
oil, or water rate to a fixed gas rate (or the reverse) in such circumstances.
RESOLVE will use a GLR threshold to determine the stage at which a well
can be considered to have switched between phases. This threshold is
15,000 scf/STB by default, but it can be changed on the "Advanced options
" screen
RESOLVE always passes temperature data between applications. When
Eclipse is isothermal this data does not exist and so must be entered
217
RESOLVE
manually in this field. Note that the data is only required for production wells.
Group
controls
Show
production
groups in
Interface
Eclipse300 only: In thermal cases the reservoir temperature is read

from the data deck where available
Generally group controls should be removed from the Eclipse model to
allow the wells to be controlled by RESOLVE.
If RESOLVE attempts to control wells that are also under group control
conflicts can occur.
The "Group control edit" screen allows to enable or disable any or all of the
group controls in the simulation run.
This button will only be available after an Eclipse run has been opened as
RESOLVE needs to be able to interrogate the model for the group names.
This button will enable to have additional nodes added to the RESOLVE
model, each of them reproducing a production group defined in the Eclipse
datadeck. These nodes (i.e. data providers) can then be linked to data
receivers node to pass the group control data to Excel for instance
2.9.2.4.16 Eclipse Driver: Control Data Section: IPR Generation Options

The IPR generation options can be accessed from the "Control" tab of the data entry screen.
IPR that are passed from the reservoir model to the surface network model can be generated
from the reservoir model in different ways, as described below. Some of these techniques
provide realistic inflow performance definitions, whereas other techniques provide unrealistic
inflow performance definitions, often leading to instabilities in the full-field model results.
The choice of the IPR generation option used is crucial to the behavior and accuracy of the
model, and IPR generation techniques are a subject of constant development and testing.
Even so all the different IPR generation options are detailed below, it is important to note that the
most advanced, and recommended option is the Calculated PI (Based on Drainage) |
Scaling option.
Before detailing the different IPR generation options that are available in RESOLVE, the
following describe the important elements when generating IPRs for dynamic coupling:
The true rate-pressure response of the well over a timestep (i.e. which is what should be passed
to the GAP model) is given by the green line in the diagram below, which is simply the line
connecting three different solution points at (Q1,P1), (Q2,P2), and (Q3,P3). The red lines
represent typical block-calculated IPRs for each of these points.
One way of effectively obtaining the true (green) response is to iterate between Eclipse and
GAP. This is what the "Newton level" coupling is trying to achieve. However, this is not an
efficient coupling as it is computationally expensive and is normally limited to the coupling of a
single Eclipse model to a GAP model.
Alternatively, if a zero flow pressure P0 is calculated then it will be possible to generate an IPR
User Guide
218
by connecting the current solution to the pressure P0. This zero flow pressure is the drainage
region pressure for the well in question.
This describes why IPR generation methods based on drainage region reservoir pressure are
preferred to the ones based on block reservoir pressure.
There are three IPR generation options:

Use PI reported
by Eclipse
Calculated PI
(block)
This option does not perform any calculation of PI but just uses the PI
reported from Eclipse.
This should not be used and is retained for backwards compatibility
only
In this case an IPR is calculated by performing well calculations for a set of
different bottom hole pressures for each well at the first Newton iteration of
the Eclipse solver. This will build an IPR that is a representation of the well
performance at one specific point in time. The "reservoir pressure" used to
calculate this IPR is derived from the pressure of the block in which the
wells are perforated. It will include non-Darcy effects (i.e. especially
important, therefore, for gas wells) and any potential cross-flow. However,
the entire reservoir is not solved for each bottom hole pressure so effects
such as coning will not be included in the resulting IPR description.
219
RESOLVE
This option is rarely used as it will lead to an under-estimation of the real

reservoir pressure for producers and an over-estimation of the real
reservoir pressure for injectors, therefore leading to erroneous evaluations
of the well performance
In this case an IPR is calculated by considering the drainage region
pressure as the zero flow pressure. As discussed below, this is an
improvement on the block IPR model
Calculated PI
(drainage)
The drainage PI calculation section has three sub-models:

Diffusivity
The drainage pressure is calculated directly from the grid cell pressures.
Clearly, the grid cell pressures have to be referred to the well reference depth.
This ties in with the grid visualisation facility and requires that the Eclipse
model grid is loaded into RESOLVE as described
Advantages
Gives a direct and fairly quick calculation of drainage

pressure about a well
Disadvantage Requires the grid topography to be loaded into RESOLVE
s
with changes necessary to the Eclipse data file
(SUMMARY section).
The imported grid must be kept synchronised with the
actual model grid run in RESOLVE
The output files (e.g. RSM and SMRY) can become very
large and there may be upper limits imposed by Eclipse.
This imposes limits on the number of cells that should be
included in the drainage region (25000 - 30000 cells is an
empirically observed limit).
Initial load times of the model are increased.
COMPLUMP can not be used in the well description in the
Eclipse model
Setup
In this case the grid topography must be loaded into
RESOLVE and must be kept synchronised with the model
that is being run. Details on how to load the grid topography
can be found in the "Loading the Grid Topography" section
Build-Up
(E100 only)
In this model the wells are closed for a fixed (i.e. though configurable) time and
the pressure transient is observed. The drainage pressure is then calculated.
Advantages
By contrast to the diffusivity model, this does not require

any changes to the Eclipse model and does not generate
any problems with COMPLUMP.
This technique can be used in models with large drainage
zones (high permeability) which may require too many cells
to be selected in the SUMMARY section for the diffusivity
calculation
Disadvantages This technique can be slow for large models, as the
User Guide
Setup
220
simulation state has to be dumped to disk and reloaded at

each RESOLVE timestep.
This model is not suitable for tight (i.e. low permeability)
models with long transients: for these the diffusivity
calculation will be much more appropriate.
Does not work with E300 due to a bug in OpenEclipse or
E300
If this option is selected, an Options button appears on the
data entry screen. This allows to select a relaxation time for
the reservoir. It is also possible to choose to sub-divide the
relaxation into several timesteps and perform a curve-fit to
the subsequent pressure data to determine the drainage
pressure. Most of the time in this model is spent dumping
and restoring the reservoir state, so the impact of a long
relaxation time is not major.
Scaling
Both of these options will lead to a degradation of the overall model

performance, specially when using large models and have been superseded
by the "Scaling" option described below
This is a proprietary model which improves the IPR generation without the
degradation of performance with larger models that is experienced with the
previous two options.
This is the IPR Generation calculation that is recommended
Advantages
Works with E100 or E300

Does not induce a degradation of performance as the
Eclipse models become larger
Disadvantages The initial calculation of the drainage parameters can be
time consuming, although this a a single, one-off
calculation which does not need to be repeated unless
the grid topography changes. The results of the
calculation are stored in the RESOLVE file
Setup
A pre-run calculation is required to use this option. This
calculation can be performed by going to the "Options"
section. A calculation screen is then displayed, as
illustrated below. At the top of this screen a message is
displayed which indicates whether the calculation has
already been carried out.
221
RESOLVE
If the calculation has not been performed previously, the

following procedure can be followed:
Define the Wells for which the calculation has to be
performed
This can be done by selecting the "Wells" button.
By default, the calculation will be done on all the wells of
the model.
Perform
the Calculation
This can be done by selecting the "Continue" button.

The calculation may take some time - progress is indicated
on the two progress bars at the bottom of the screen.
Once the calculation is finished, the screen will be cleared
and the results of the calculation will be stored. At the end
of the calculation a screen is displayed with information on
the status of the calculations (success or failure).
There is no need to repeat this calculation once the
User Guide
222
RESOLVE file has been saved, unless the grid

topography changes.
Notes on Diffusivity Calculations
The few elements below can be considered if issues are experienced with the diffusivity
calculations: it is important to note that the first element to be consider when experiencing
diffusivity calculation issues is the way the Eclipse deck is setup. It is recommended to follow the
"Best Practice" notes when setting up an Eclipse model to be used with RESOLVE.
In addition to this, the following elements can be considered:
If a calculation fails because of a failure to generate an IPR, then this would normally
because RESOLVE is not able to bring the well in question online.
If the model is running from a restart, it is important to ensure that the well is "on" at the
point where the restart is generated: (which can be specified by using a WCONPROD
or WCONINJE keyword.)
Another frequently observed reason for the failure of the scaling calculations is the use
of the Well Economic Limit (WECON) keyword in the Eclipse deck. During the Scaling
calculation, it is possible that this minimum rate limit be triggered and the wells will be
shut off and hence not allow RESOLVE to control the well/s. It is recommended that the
WECON keyword be completely removed from the data deck, since in the presence of
a Network Model, this is not required as the fluid production rate is a function of the
wellhead pressures. Should the wellhead pressures are high enough, the wells will stop
production.
If Eclipse is sitting at a time before history data is applied - when RESOLVE performs
the well calculations it will not be able to override history production or injection settings
(WCONHIST, etc).
If Eclipse prevents RESOLVE from controlling the wells, then superfluous control
keywords should be removed.
One way to ensure that the scaling will be run is to remove ALL the Scheduling
keywords from the Eclipse deck and simply place the WCONPROD keyword for each
well with the status set to open at a certain rate. (The rate itself will be insignificant as it
will be overwritten by RESOLVE)
2.9.2.4.17 Eclipse Driver: Control Data Section: Group Controls

If an Eclipse model contains group controls (i.e. GCONPROD or GCONINJE) then these can
interfere with the individual wells controls set by RESOLVE. However, sometimes it might be
necessary to allow wells that are not connected to equivalent wells in RESOLVE to be controlled
by Eclipse. An example of this might be the case where injection wells have to be controlled by
voidage while the production wells are controlled by a full surface network.
If RESOLVE tries to generate IPR data for connected wells which are under
group control, an error will be reported and the run will terminate
223
RESOLVE
This screen allows to respect or clear any or all of the group controls in the Eclipse run, with the
caveat that if RESOLVE wells are allowed to be under Eclipse group control then this will cause
problems in the run.
The screen displays all the groups that are present in the Eclipse model. Each group can be
checked or unchecked each group to tell RESOLVE whether any controls on that group are to be
respected. If a group is left unchecked then this group will effectively be deleted from the Eclipse
run.
The action buttons can be used to check or uncheck all the groups. Note that the top level
"FIELD" group is always unchecked as it makes no sense to allow field production constraints in
Eclipse when any part of the model is controlled by RESOLVE.
Note on the use of GPMAINT keyword in Eclipse

As well as GCONPROD and GCONINJ, the Eclipse user has the option to define
pressure maintenance for groups. It is not possible for RESOLVE to override
GPMAINT control.
For this reason GPMAINT should be avoided for wells which are connected to GAP
through RESOLVE
User Guide
224
2.9.2.4.18 Eclipse Driver: Miscellaneous Section

This tab sets up some miscellaneous data that may be used in the Eclipse run, and uses the
following screen:
The following elements can be considered:

Well Scheduling
The well schedule can be controlled by Eclipse itself or by the connected application (i.e.
typically GAP). This refers to the way that wells can be scheduled to be brought online or shut in.
225
RESOLVE
We strongly recommend that this is option is set to "GAP" and that all scheduling is
removed from the Eclipse model, as discussed in the "Best practice" document.
The options available for the well scheduling are as follow:
Eclipse
Connected
application
(GAP)
In this case, the well management scheduling will be carried out entirely by
the Eclipse schedule deck. Wells can be brought on line with WCONPROD
or WCONINJE keywords or shut in with a WELOPEN keyword, for example.
Alternatively, economic limits can be set with WECON. In essence the well
state (on or off) will be determined entirely by Eclipse.
If GAP shuts a well (for optimisation purposes or because it is unable to
flow) the rate for that well will be set to zero for the timestep, but the well will
not be closed unless this violates some limit in the Eclipse input data. The
well efficiencies set by Eclipse with the WEFAC keyword will be honoured.
Note that in this mode RESOLVE will put in extra timesteps to synchronise
with the Eclipse events. In fact, RESOLVE will synchronise with all Eclipse
report times: in other words, if TSTEP is used in the Eclipse schedule
RESOLVE will put in extra timesteps to synchronise with the times in the
TSTEP keyword
In this case, the well state is determined by GAP alone and the Eclipse
schedule is effectively overwritten. If GAP closes a well, that well is closed
for the timestep but is potentially allowed to flow at the next timestep if this
is possible (unless abandonment has been specified as indicated below).
Well efficiencies will be derived from the well downtime set in the GAP (or
connected) model.
If this option is chosen, the following choices are available:
Stopped
Shut
This is equivalent to the STOP keyword in Eclipse - the

well rate will be cut to zero but cross-flow will be allowed
This is equivalent to the SHUT keyword in Eclipse. The
well rate will be zero and no cross flow will occur
and this means that wells that have been closed will be
/ abandoned with no possibility of their being brought back
and on later
Stop
abandon
shut
abandon
Follow GAP
If this option is selected, a "Edit" button appears on the

interface. This interface will allow the user to choose,
either on a overall model basis or on a well by well basis,
how the wells are closed. It is then possible to define a
different way (i.e. Stop or Shut as described above) of
closing the well as a function of the reason for the well
closure, as illustrated below
User Guide
226
Note on constraint handling

The above discussion applies only to the case of well scheduling, i.e. the possibility of
wells being closed or opened. The scheduling of constraints in GAP will be honoured
regardless of the above setting. In addition, a GAP well can still be masked (i.e. either
from the GAP schedule or from the RESOLVE scheduling) even if the well management
is under Eclipse control; this will be passed on to Eclipse as a zero rate for the well in
question but the well will not be physically closed unless this violates a limit in the
Eclipse schedule data
Additional Output and Simulation Debugging

Write a well
If this button is selected a well management debug file will be written
scheduling debug which gives the status of all the wells (including those not controlled by
RESOLVE) at the start of each timestep. It will also highlight when a well
file
has changed state (i.e. been closed having been open, etc), and will
indicate if a well has been prevented from flowing by the connected
application (i.e. GAP).
The location of the debug file can also be specified. By default, RESOLVE
will attempt to write the file at the same location as the Eclipse input file. If
the model is running remotely then this might not be possible so a new
output file should be selected. This should point to a local directory and be
a fully qualified filename (e.g. c:\eclipse-data\dbg.txt)
227
RESOLVE
Additional output Variable keywords that appear in the SUMMARY section of the Eclipse
model can be added to the results that appear in the RESOLVE reporting.
variables
The box should be checked to activate this feature.
Simulation
debugging
Note that the RPTONLY keyword in Eclipse will suppress the passing of
this data to RESOLVE and so should not be used if this feature is to be
used
From the drop down list select the level of reporting that is needed on the
RESOLVE calculation windows.
It is possible choose which RESOLVE windows to send the messages to
in the check boxes below this
2.9.2.4.19 Eclipse Driver: Advanced Options Section

This screen contains some options that have been introduced to cope with exceptional
circumstances in the model.
Normally they should not be changed.
User Guide
228
Each one of these options is described below:

Start
date
This section enables to specify an initialisation date for Eclipse.

If this is specified, when the Eclipse file is loaded, Eclipse will run its
schedule (i.e. history and/or forecast) up to the given initialisation date. This
then becomes the point at which RESOLVE queries Eclipse for the well
numbers and types.
If the entry is left blank, Eclipse will be started at its own internal start date (i.
e. with reference to its input file). This can be the start date of the history or
the date of a restart file.
229
RESOLVE
If the RESOLVE start date is later than the Eclipse start date, Eclipse will run
its history (i.e. and/or forecast) up to the start date of RESOLVE. For this
reason there is no need to enter anything here if Eclipse has to run to the
RESOLVE start date as this will be done automatically for the user.
Ignore
Eclipse
events
GLR
Threshold
IPR
Generation
If the date entered here is earlier than the date at which Eclipse starts (i.e.
the start of the history or restart) then it has no effect
This should be used with care.
By default, RESOLVE will synchronise at every Eclipse DATE or TSTEP
entry (i.e. in addition to its own synchronisation times) to ensure that any
control keywords at these times are overwritten by the control data from the
network. There is a small overhead associated with this, as the Eclipse
timestep is cut after a synchronisation. However, if the keywords are only for
reporting or for generating restart steps this flag can be set to force
RESOLVE to ignore these events
This is the threshold above which RESOLVE considers a producer to be a
gas producer and hence a candidate for a fixed gas rate control through the
auto-switch option. If a well is controlled with a fixed liquid or oil rate and the
GLR exceeds this value, the well will automatically change to fixed gas rate
control if the auto-switch option is on (alternatively, a single warning
message will be generated).
Similarly, a well controlled with a fixed gas rate can revert automatically to a
fixed liquid rate control when the GLR falls below this threshold value
These are options introduced in IPM #5 to help with a particular set of
problems which concerned OpenEclipse.
The options to consider in that section are described below:
Generation
timestep
When an IPR is calculated, different BHPs and rate points

are set in Eclipse and well calculations are performed to
generate the points on the IPR. This is only possible when
at the Newton level of the Eclipse solver. Unfortunately,
there is no way to close or stop a well from OpenEclipse
while at the Newton level, and so a fixed surface rate of
zero has to be applied. This allows cross-flow to occur
which can be false and can also slow the simulation down
considerably.
For this reason, the timestep length at which the IPR is
calculated is set to a small value (by default, 1 days). The
time over which cross-flow occurs is therefore limited:
when the simulator completes the small timestep the well
is SHUT or STOP appropriately, according to the setting
in the "Miscellaneous" tab.
This value should normally not be modified. It can be
User Guide
230
made smaller, but convergence problems can occur if the

value is too small (i.e. the "critical value" depends on the
model; the default of 1 has been determined by
observation of many Eclipse models in operation). If
convergence problems are observed in the wells that are
connected to GAP it will be necessary to consider making
the value larger. In any case, the value should not be made
equal, or even comparable, to the timestep size (or
minimum timestep size if the adaptive timestepping
option is used)
This option allows some "pre-convergence" of the
simulator before the IPR is generated.
Perform
Newton
solves before
In normal use the IPRs are calculated at the "0th" Newton
generating
iteration of the solver: OpenEclipse is used to move the
IPR
simulator from the start of timestep loop to the Newton
level loop where the IPRs are calculated with a series of
well calculations. It has been noted in some cases (see
below) that the IPR sent to GAP differs from the one used
by Eclipse at the end of the timestep. This manifests itself
as a (potentially) large discrepancy between the BHPs of
the wells recorded in GAP and Eclipse when the Eclipse
wells are controlled with a fixed rate.
To date the cases in which this has been a problem use
the "GPP" well model for gas-condensate wells and are
controlled at relatively high rates.
The option here allows a few Newton iterations of the

Eclipse solver to be performed before the IPR is
generated. In general the IPR generated will move closer
to that used by Eclipse at the end of the timestep. It is not
normally required; there is no point using this model
unless there is an obvious discrepancy in the BHP data
between GAP and Eclipse as it will slow down the
simulation
Convergence Eclipse will take Newton iterations until the convergence is
less than this value multiplied by the tolerance specified
tolerance
under the TUNING keyword. The IPR will then be
generated for the surface network
Material
(E100 only) Eclipse will take Newton iterations until the
material balance error is less than this value multiplied by
balance
the tolerance specified under the TUNING keyword. The
tolerance
IPR will then be generated for the surface network
Minimum
These options force a certain number of Newton iterations
before the IPR is generated
iterations /
231
RESOLVE
Maximum
iterations
IPR point
grouping
It is very unlikely that this option will have to be changed. It

may be useful for cases where there is a BHP
discrepancy between GAP and Eclipse that can be traced
back to interpolation errors in the IPR table (which can be
most apparent in cases with large non-Darcy factors)
These options only affect runs in which the IPR generation

mode is set to "calculated (block)" WHICH IS NOT THE
RECOMMENDED IPR GENERATION OPTION. See the "IPR
generation" page for more information
2.9.2.4.20 Publishing Eclipse variables

This screen allows variables to be published from Eclipse into RESOLVE.
User Guide
232
Select the Eclipse section to access the Eclipse variables and click on Edit Variables.
The following screen will be displayed, in which three section are available: Groups, Wells and
Completions.
233
RESOLVE
Groups
Section
Wells
Section
Completion
Section
This section enables to publish variables from the group control sections of
the Eclipse model
This section enables to publish variables from the wells sections of the
Eclipse model.
To select the variables to publish in these two sections, select in the left
hand screen the group and the variable of that group that is to be published
and click on the red arrow button. The variable to be published will be
displayed in the right hand side of the window
Eclipse allows variables associated to each of the well completions to be
published in RESOLVE.
In order to do so, the following procedure can be used:
In the Variable Name section, enter the name of the variable to import This name is user-defined.
In the Well section, a drop-down box will allow to select which well the
variable to publish is associated to.
In the Completion section, a drop-down box will allow to select which
completion the variable to publish is associated to.
In the Variable section, a drop-down box enables to select the variable
to be reported.
User Guide
234
The variable Unit will then be automatically reported.

In the example below, the oil rate of completion 1 of the LU1 well defined in
Eclipse will be published in RESOLVE.

The additional functions menu of the Eclipse link can be invoked by right-clicking on the Eclipse
icon in the RESOLVE graphical view.
235
RESOLVE
The commands at the bottom (outlined) are those that are specific to the Eclipse link.
Description of the other functions can be found in the "Other functions" section of the GAP driver
description.
These specific functions perform the following tasks:
Well control
table
View data file
This enables to access a table that summarise the well control options used
for the different wells of the model
Provided the data file is local to the machine on which RESOLVE is running,
this will allow to view the main Eclipse .data file
View log file
this will allow to view the .log file generated by Eclipse during the forecast
View prt file
this will allow to view the .prt file generated by Eclipse during the forecast
View well status If the "Write a well management debug file" option has been selected (i.e.
on the "Miscellaneous" tab of the data entry screen) this will allow to view
file
this file.
It can be viewed during the forecast, although it will not be updated
dynamically. To get updates the screen must be closed and re-opened
User Guide
View grid data
236
If the grid topography has been loaded on the case details tab of the data
entry screen then this will invoke the " Visualisation"
2.9.2.4.22 'Best practice' for Eclipse coupling

This document provides recommendations on how Eclipse models should be set up to achieve
good results when coupling to GAP models through RESOLVE.
Rationale
In any RESOLVE model consisting of several elements (e.g. reservoir,

surface network, process), RESOLVE is the master controller. As
RESOLVE can "see" the entire system it is appropriate that all the
scheduling of events should be at the RESOLVE level. This could be done
through the Visual Basic scripting or the "Event driven scheduling"
capability of RESOLVE, which allows sophisticated logic to be set up to
control the models based on events that occur in the system.
The converse of this is that it is strongly advised that the
scheduling should be removed from the client applications.
Setting up an
Eclipse deck
In the case of Eclipse, there is another reason for this advise. RESOLVE
must control the wells based on the rates and pressures which are being
calculated by the surface network. Control keywords (such as
GCONPROD) in the Eclipse model can interfere with the control of wells
by RESOLVE. Although RESOLVE attempts to remove any superfluous
control by Eclipse, it is not possible to guarantee that there will never be
interference as it is not possible to test all possible combinations of
keywords against the OpenEclipse interface that RESOLVE uses
The advised changes all affect the SCHEDULE section.
Ideally, the predictive (as opposed to history) part of a schedule section for
an Eclipse model to be coupled to GAP should consist of only the following:
Any engineering, reporting or restart options that are required, e.g.
RPTSCHED, DRSDT.
Well definitions through WELSPECS and COMPDAT
WCONPROD and WCONINJE keywords to open a well with some rate.
The rate that is specified in the Eclipse deck will be overwritten by
RESOLVE. Since the WCONPROD and WCONINJE keywords are
replaced, if the well is defined as closed in the Eclipse deck, it will be
opened by RESOLVE.
A single DATE to define the end of the forecast, followed by the END
keyword.
The date defined should be such that the simulation period (in the
Eclipse Deck) is greater than 60 days. For example, if the Eclipse start
date (defined in the Eclipse data deck) is specified as "01 JAN 2012",
then the end date defined must be about "01 APR 2012" or higher. This
237
RESOLVE
is a prerequisite for performing the scaling operation.

The keyword NOSIM should not be included in the datadeck. (The
NOSIM keyword would tell Eclipse that there is no simulation that needs
to be performed and would terminate the Eclipse run)
Opening and closing of wells, or changing of constraints, should be done
through the RESOLVE scheduling. Any wells which are to be controlled by
RESOLVE should never be under group control; however, groups can be
set up for the wells for reporting purposes.
In addition, it is advised that lift curves be removed from the Eclipse model
if the connection is to be made at the sandface. This is because Eclipse
will continue to calculate a THP for whatever rate is calculated by the
network, and Eclipse will not allow this pressure to become negative or
violate some upper limit (for an injector). Clearly, this should not happen if
the network and the Eclipse lift curves are consistent. Nevertheless, there
remains the possibility that an Eclipse model which does not have
consistent lift curves with the network will violate the limit and apply an
unwanted THP control to the well(s) in question.
An example of an "ideal" schedule section of a data deck is shown below:
-------------------------------------------------------------------------SCHEDUL E
-------------------------------------------------------------------------TUNI NG
/
/
1* 1* 50/
DRSDT
0 /
RPTRST
" BASI C=4 " " NORST" /
RPTSCHED
" RESTART=2 " " WEL L S=2 " " WEL SPECS" " CPU=2 " /
I NCL UDE
" l i f t 1. ec l "
/
I NCL UDE
" l i f t 2. ec l "
/
I NCL UDE
" l i f t 3. ec l "
/
I NCL UDE
" l i f t 4. ec l "
/
I NCL UDE
" l i f t 5. ec l "
/
WEL SPECS
- - we l l n a me
P1
g r o u p n a me
GO1
I
14
J
64
r e f . BHP
1830
pr ef er ed phas e
" OI L "
/
User Guide
P2
P3
P4
I1
I2
GO1
GO2
GO2
GOI NJ
GOI NJ
26
32
28
11
32
69
23
38
90
48
1788
1755
1755
1*
1*
"
"
"
"
"
OI L "
OI L "
OI L "
WATER"
WATER"
238
/
/
/
/
/
/
COMPORD
P4 I NPUT/
/
COMPDAT
" P1 "
14
64 5
5 " OPEN" 1 *
0. 624 0. 124
27. 542
" P1 "
14
64 6
6 " OPEN" 1 *
21. 921 0. 124 1826. 370
" P1 "
14
65 6
6 " OPEN" 1 *
2. 001 0. 124 173. 384
" P1 "
14
65 7
7 " OPEN" 1 *
20. 639 0. 124 1365. 221
-------------------------------------------------" P2 "
34
2 1 1 2 1 2 " OPEN" 1 *
0. 157 0. 124
27. 136
" P2 "
35
1 9 1 6 1 6 " OPEN" 1 *
13. 458 0. 124 2520. 052
" P2 "
36
1 9 1 6 1 6 " OPEN" 1 *
7. 603 0. 124 1411. 776
" P2 "
36
1 9 1 7 1 7 " OPEN" 1 *
21. 706 0. 124 4053. 938
" P2 "
36
1 9 1 8 1 8 " OPEN" 1 *
3. 970 0. 124 741. 744
---------------------------------------------------" P3 "
28
38 2
2 " OPEN" 1 *
4. 317 0. 124 687. 251
" P3 "
29
37 5
5 " OPEN" 1 *
0. 001 0. 124
0. 222
" P3 "
29
37 6
6 " OPEN" 1 *
9. 501 0. 124 1706. 844
" P3 "
29
37 7
7 " OPEN" 1 *
268. 140 0. 12448033. 410
" P3 "
30
36 7
7 " OPEN" 1 *
2. 358 0. 124 416. 195
" P3 "
30
36 8
8 " OPEN" 1 *
235. 539 0. 12442575. 227
" P3 "
32
3 5 1 2 1 2 " OPEN" 1 *
0. 139 0. 124
25. 960
" P3 "
33
3 5 1 2 1 2 " OPEN" 1 *
0. 833 0. 124 122. 008
" P3 "
33
3 5 1 4 1 4 " OPEN" 1 *
6. 852 0. 124 1204. 486
" P3 "
34
3 5 1 4 1 4 " OPEN" 1 *
0. 175 0. 124
32. 524
---------------------------------------------------" P4 "
26
69 3
3 " OPEN" 1 *
0. 188 0. 124
35. 430
" P4 "
27
68 8
8 " OPEN" 1 *
9. 168 0. 124 1691. 233
" P4 "
28
68 8
8 " OPEN" 1 *
1. 146 0. 124 212. 869
" P4 "
29
68 8
8 " OPEN" 1 *
0. 988 0. 124 170. 147
" P4 "
29
67 8
8 " OPEN" 1 *
1. 130 0. 124 180. 188
/
WCONPROD
" P1 " " OPEN"
" P2 " " OPEN"
" P3 " " OPEN"
" P4 " " OPEN"
/
WCONI NJ E
" I 1"
" I 2"
/
"
"
"
"
ORAT"
ORAT"
ORAT"
ORAT"
" WAT"
" WAT"
4*
4*
4*
4*
" OPEN"
" OPEN"
1*
1*
1*
1*
1*
1*
1*
1*
" RATE"
" RATE"
1*
1*
1*
1*
2
4
6
8
100000
100000
100000
100000
3975 1*
3975 1*
2*
2*
2*
2*
"
"
"
"
Y"
Y"
Y"
Y"
0.
5.
6.
2.
659
383
440
145
/
/
/
/
2*
2*
2*
2*
2*
"
"
"
"
"
X"
X"
X"
X"
X"
4.
9.
8.
9.
9.
288
507
735
262
306
/
/
/
/
/
2*
2*
2*
2*
2*
2*
2*
2*
2*
2*
"
"
"
"
"
"
"
"
"
"
Y"
X"
X"
X"
X"
X"
X"
X"
X"
X"
2.
7.
6.
6.
5.
6.
9.
1.
5.
8.
114
818
323
153
354
711
019
068
141
836
/
/
/
/
/
/
/
/
/
/
2*
2*
2*
2*
2*
"
"
"
"
"
X"
X"
X"
X"
X"
9.
8.
8.
4.
2.
905
186
769
238
146
/
/
/
/
/
/
/
/
/
420.
400.
/
/
DATES
1 " J AN" 2 0 3 8 /
/
END
Exceptions
Scheduling of events in Eclipse which can not be set by RESOLVE is

allowed. Examples of these are those events which affect the reservoir
239
RESOLVE
model, e.g. WDFAC. RESOLVE will synchronise its timesteps with any
event in the Eclipse schedule.
As explained in the Control Data section, it is possible for wells which are
not controlled by RESOLVE to be under control by Eclipse (group or well
control). In this case the scheduling of events for these wells would have to
be entered into the SCHEDULE section, as normal
2.9.2.4.23 Further Technical Elements on the Eclipse - RESOLVE link
About OpenEclipse
RESOLVE communicates with Eclipse using OpenEclipse. This is the open architecture for
Eclipse, allowing an external application to control and interrupt Eclipse runs.
When an Eclipse instance is loaded into RESOLVE, OpenEclipse initialises the Eclipse run
according to the information in the data deck (i.e. it either equilibrates the reservoir or loads a
pre-saved restart file) and runs it to the start of the first timestep. The instance of Eclipse is then
queried by RESOLVE for the sources and sinks - these will be the wells in the simulation that
exist at this time. For this reason, it is important that the wells that are to be present in the
coupled run are declared at the start of the run (as discussed below).
If the Eclipse data deck is quite large, it may therefore take some time for the case to be loaded
as Eclipse is actually running the first part of the simulation.
Once the case has run to the end (or the user has terminated the run with the "stop" button from
RESOLVE) Eclipse will terminate. Note that this is a different behaviour to GAP, REVEAL, and
for example Hysys as these applications stay in memory until RESOLVE is exited. When the user
starts a new run Eclipse will again have to perform the initialisation described above; thus
repeated runs may take longer to initialise than the original run.
About the coupling with a surface network model (e.g. GAP)
The following elements should be kept in mind when coupling Eclipse to a surface network (e.g.
GAP).
Well
Control
Constraints in the schedule data should be avoided as these can interfere

with the control by RESOLVE. Note that if Eclipse is attached to GAP, it is
best to put any constraints in the GAP file where they can be "seen" by the
optimiser.
If there are well constraints these will be removed automatically be the
Eclipse driver.
Wells that are not controlled by RESOLVE (i.e. they are not connected to
data acceptors in the RESOLVE system) will be controlled purely by the
Eclipse schedule data (i.e. this allows, for example, voidage injection wells
User Guide
THP Control
240
to be set up). In addition, group controls can be overwritten by RESOLVE

from the interface
THP control of wells is available from the Eclipse drivers. In this case, the
pressure at the "top" of the lift curve is passed between the applications.
For consistency, it would be required that the GAP system and the Eclipse
system have the same lift curves - note that GAP is able to import Eclipse
lift curve formats.
An artificially lifted well can not be controlled by tubing head pressure (BHP
and rate controls are still available).
IPR Generation
Drawdown
constraints
Scheduling
See also the notes below regarding IPR generation and scheduling
Note also that the IPR generated by Eclipse is generated at the reference
depth for the well in question. The well reference depth is set with the
WELSPEC keyword. It is important that the lift curve used by GAP,
regardless of the well control mode in Eclipse, is generated to this
reference depth to ensure the continuity of the model
As with point (1), drawdown constraints should be placed in the GAP model
where they can be seen by the optimiser.
Drawdown constraints in the Eclipse deck (i.e. entered using the
WELDRAW keyword) can interfere with the control of E300 runs from GAP.
This should not be a problem with E100 where the constraints can be
overridden programmatically from RESOLVE
The Eclipse link attempts to honour the schedule in the Eclipse deck for the
wells.
The caveat here is that all wells must be "declared" at the start of the run
using the WELSPEC keyword in Eclipse.They must also be declared as
producers or injectors with the WCONPROD and/or WCONINJE
keywords. They do not need to be open from the start - it is acceptable for
the wells to be initially SHUT or STOPped before being opened up at a
later time.
If a well is closed by the connected program (e.g. GAP) then there are two
possibilities. The first is that the well will be opened at the start of each
RESOLVE timestep to generate the inflows for GAP and then started or
stopped again based on the GAP calculation: in other words, RESOLVE
will keep trying to restart the well. Alternatively, the well will be abandoned
and either shut or stopped in the simulation. This is set on the "
Miscellaneous" tab of the "Edit case" screen.
Finally, if a well is controlled with a THP and it dies during a RESOLVE
timestep, Eclipse can attempt to bring the well back on at a later time
based on the setting of the WTEST keyword. Note that a well controlled
with rate or BHP does not "die" in the same way but may change control
mode (e.g. if BHP -> zero, BHP will become the control mode at zero psig).
This should not happen in a well controlled system, but if it should the
241
RESOLVE
Eclipse deck
errors
control mode will be reset at the start of the following timestep

In some circumstances errors that occur in the Eclipse deck can cause the
Eclipse run to fail and terminate prematurely without notifying RESOLVE.
This may cause RESOLVE to hang (this problem has now been fixed and
this should no longer happen). Before connecting an Eclipse run to
RESOLVE one should ensure that the simulation will run by itself without
error. If RESOLVE is appearing to hang at any point, go to the PVM prompt
and type ps. The Eclipse process reported can then be seen. If it is not,
then it will be necessary to kill the RESOLVE run by hand (e.g. from
Windows Task Manager)
2.9.2.4.24 PVM legacy notes
The use of PVM as a communication protocol between RESOLVE and Eclipse is NOT
recommended as PVM is not supported by Schlumberger anymore. The notes below are
therefore legacy notes. It is highly recommended to now use MPI as the communication
protocole between Eclipse and RESOLVE.
Details of the local configuration and testing of PVM can be found under the corresponding
section of the "Eclipse Configuration" wizard.
The following considers the configuration of PVM to run Eclipse on a remote machine separated
from the one running RESOLVE.
Step 1
One needs to make sure that it is possible to execute a remote shell from one
computer to another one: one needs to make sure that it is possible to launch a
command from one computer that is performed by another computer.
To Do So, run the following command in the Start | Run | Cmd Prompt DOS
window:
rsh <Remote Computer Name> dir (PC), or
rsh <Remote Computer Name> ls (Unix/Linux)
User Guide
242
Where: Remote Computer Name can be accessed from a cmd prompt /

hostname
dir is the command to execute
If the command succeeds, it is possible to go directly to the Step 2.
If the command fails, then configuration of the remote host is required. On a PC a
remote shell daemon (rshd) may need to be installed and configured on the
remote PC to allow the master computer permissions to run processes on the
remote computer.
The remote shell daemon normally exists on a Unix or Linux computer, but these
need to be configured (normally by altering the .rhosts file). Please refer to the
PVM documentation for more information on this.
For the PC case, a remote shell daemon can be downloaded off the internet
(Ataman, for example). Alternatively, contact Petroleum Experts. Note that MPI
is the preferred protocol for local PC or PC-PC connections, and this does not
require a remote shell daemon.
Step 2
The usual reason for this failing (apart from simple network problems: host not
found) is the lack of permissions for the rsh service on the remote computer.
Permissions can be set from the .rhosts file which is stored in the userr Linux
home directory. the user should add a line to this giving the IP address of the
<master-machine>, e.g.:
192.168.1.65
There are other options available to refine how permissions are granted; refer to
standard Linux documentation for these
Once the remote shell is working, the user can proceed with the PVM
configuration. Environment variables need to be set up as follows in the (for the
243
RESOLVE
case of bash) /etc/profile file:

PVM_ROOT
/ecl/2006.1/pvm3
PVM_ARCH
LINUX
PVM_TMP
/tmp
PVM_RSH
/usr/bin/rsh (or wherever rsh is installed)
This assumes that the Eclipse distribution was installed in /ecl, and is the version
2006.1. Having made these changes the user should check that they are not
overwritten at login time, e.g. in the /etc/bashrc file.
The PC equivalents will be set up in the case of Windows.
the user should now be able to add <linux-machine> to the PVM group on the
<master-machine>. From the PC master, start a PVM session from the Eclipse
launcher, and type:
add host <linux-machine>
With luck a success message will be written and the machine will be added.
Type conf to verify that the machine has indeed been added.
Step 3
There are various reasons why this command could fail. Apart from the most
basic reason (there is no network connection) the most command is that the
<master-machine> could not find the remote PVM daemon (pvmd). To test this,
type the following command at a command prompt:
rsh <linux-machine> $PVM_ROOT/lib/pvmd
If this fails then the command-line response can be helpful. the user may find, for
example, that the <master-machine> is attempting to run /lib/pvmd, which tells us
that the environment variable $PVM_ROOT is not set correctly, even though it
was set in the profile. If the user are using ksh or bash then the environment is not
set when a rsh is executed and so $PVM_ROOT is not assigned in the above
command. In this case the user have to tell PVM on the master machine the path
to the pvmd daemon on the remote computer. Do this by editing the PVM host
file (found under c:\ecl\home\pvmhost.xxxx) with a line of the form:
<linux-machine> dx=/ecl/2006.1/pvm3/lib/pvmd
and restarting PVM
Before going to RESOLVE, we need to make sure that we can spawn an Eclipse
run on the remote computer from PVM.
From the PVM prompt, we can use the spawn command to test this.
Type: spawn (<remotecomputer>) eclipse
PVM should tell the user if the spawn has been successful. Afterwards, the user
can check if the process is running by typing ps at the PVM prompt.
If the spawn has not been successful, then it is possible that PVM cannot find the
executable on the remote computer. In this case the user may need to supply a
path to the executable. This can be done within the above command line, or
alternatively the user can edit the PVM configuration file (by adding a line
beginning ep=) before running PVM. This is explained more completely in the
User Guide
Step 4
244
PVM documentation
In RESOLVE, specify the remote machine name in the Host section of the
simulation setup screen.
If PVM does not know the path to the Eclipse executable, then the user might
need to add the full path on the remote computer in the Executable field.
245
RESOLVE
2.9.2.5 Connection to IMEX/GEM - IMEX/GEM driver Details

2.9.2.5.1 IMEX/GEM Overview
This help section documents the links to two reservoir simulators: IMEX and GEM.
These applications are developed by Computer Modeling Group (CMG).
IMEX
GEM
is a three-phase, black-oil reservoir simulation model

is a fully compositional, thermal, reservoir simulation model
The links are essentially the same in operation (aside from the compositional differences) and
have the following properties:
Simulation models can be run locally or on a remote machine
A remote machine can be of any architecture supported by the reservoir simulator, e.g.
Linux or Unix.
Execution of the simulators on the nodes of a cluster is supported. This uses either LSF
(developed by Platform Inc.) or PxCluster (developed by Petroleum Experts). The
original LSF connection assumed that the RESOLVE computer (running Windows) and
the target computer (potentially running Linux) were part of a single LSF cluster. A third
method, termed 'Head Node Daemon', is now supported which allows submission of
the IMEX/GEM job to a Linux cluster in which the task distribution is handled by the
head node of the cluster.
Integrated models that include IMEX or GEM can be
ModelCatalogue, so that integration with IFM is assured.
checked
into
the
Full OpenServer access is available to all the input parameters of the IMEX/GEM case
(e.g. dataset, IPR model, remote execution, etc). This allows full automation of the
setting up of an integrated model from a third-party application or web-service.
Initial versions of the driver were developed by CMG to work with the 2005.10 (and later)
versions of the simulators. The first version of the driver developed by Petroleum Experts, and
built upon the CMG code, has been designed to work with the 2007.10 version of the simulators.
2.9.2.5.2 IMEX/GEM case setup guidelines
The following sections concern the setup of IMEX and GEM cases to work with GAP and
RESOLVE. There are certain recommendations that ideally should be followed, although the
coupling should work with minimal or no changes to the data deck. In the following descriptions,
IMEX and GEM are interchangeable unless mentioned explicitly.
Preparation
of the
There are no specific keywords required for IMEX to couple with GAP. The
only requirement is that the reservoir temperature must be passed in the link.
User Guide
IMEX
Data Set
Recurrent
Data
ON-TIME
Fraction
246
This is ensured by putting the reservoir temperature (*TRES) into the IMEX
Component Properties section.
Some restrictions and differences in how well recurrent data is interpreted are
imposed. The following well data restrictions are applicable for wells that are
linked between GAP and IMEX / GEM and are not applicable for wells that are
not linked
In recurrent data, for linked wells, any operation that changes the value of a well
rate constraint is ignored. Rates are exclusively determined by GAP
For linked wells, at each RESOLVE date, the GAP down-time percentage is
passed to IMEX as an on-time fraction. IMEX uses the received on-time
fraction as if the same value was input through the IMEX recurrent data.
Essentially the definition / handling of on-time fraction for coupled wells is
moved to the GAP network.
For unlinked wells, on-time fraction should be given in IMEX recurrent data as
usual.
Opening /
Closing
Wells
IMEX passes back on-time fraction for all wells to RESOLVE, so that it is
accessible via a RESOLVE script and readable in the RESOLVE reporting
window
IMEX passes open / shut-in status for linked wells to RESOLVE at each
RESOLVE date. After receiving this well status information from IMEX, GAP
honours those wells IMEX shuts in and may add other shut-in wells based on
its schedule or optimisation procedure.
RESOLVE then runs a new timestep and passes the updated well status back
to IMEX. IMEX keeps the received well status for the IMEX timesteps required
to reach the new RESOLVE date.
IMEX can attempt to open a well (i.e. using a monitor or well control in a
trigger), but if the GAP schedule or the GAP network optimisation overrides
this, the well remains shut-in until the next RESOLVE date, where it will be
checked again by GAP, and if the network schedule or optimisation allows the
well to open, it will open. This check will occur at every RESOLVE date.
Monitors
and Triggers
All this means that either IMEX or GAP can shut-in a well, but both IMEX and
GAP must agree that a well should be open before it actually opens
Generally, scheduling of events that affect the wells should be placed in GAP
or, preferably, RESOLVE (via the "Event driven scheduling"). In the current
version of this link there is no access from RESOLVE to well layer information,
so events which affect layer productivity (e.g. workovers) must be scheduled in
IMEX in the usual way.
IMEX well monitors, group monitors and triggers are allowed to operate on
wells or well layers only. Details are described below. The allowed operations
247
RESOLVE
are restricted to those which open or shut-in wells or well layers, or that modify
productivity / injectivity indices of the wells or well layers.
IMEX and GAP ONLY exchange information at each RESOLVE date, so it is
critical that the well and well layer status is not changed between RESOLVE
dates. There are two options that have been modified for IMEX-GAP coupled
runs which ensure information exchange only at RESOLVE dates. This is done
by only checking Monitor (*MONITOR) violations (for linked wells) and all
trigger actions (*TRIGGER) at RESOLVE dates
MONITOR For linked wells, monitors (*MONITOR) are checked at RESOLVE
dates ONLY. For unlinked wells, monitors are checked at each
IMEX timestep.
For well groups defined in IMEX, if a group includes linked wells,
the applicable group monitor option is limited to the group
monitor (*GCONM) and the group monitor will only be checked at
RESOLVE dates. On the other hand, if a group does not include
linked wells, group monitors can be applied as usual
TRIGGER Triggers (*TRIGGER) are the means by which the user can
ensure that well controls are only applied when IMEX and GAP
are synchronized. The user must place all well control keywords
within triggers as in linked runs triggers are only checked at
RESOLVE dates.
Keywords that directly change the well status or that modify
productivity for linked wells (i.e. not in triggers) must be avoided.
For example, well 2 is a linked well and the date 2000 1 1 is not
a RESOLVE date. The inputs,
*DATE 2000 01 01
*SHUTIN 2
will shut-in well 2 between two RESOLVE dates, and therefore
cause a rate mismatch between IMEX and GAP. By rate
mismatch we refer to the situation where the network model (GAP
) and reservoir model (IMEX) are assuming different rates or well
indices for the same well. This may include having a well open in
one model and shut-in in another.
This inconsistency must be avoided by using triggers (as shown
in the example below). In this example, we redefine the layers for
well no. 2, then multiply its original productivity index by five times
at the first RESOLVE DATE after 2000 1 1
* DATE
2000
User Guide
248
* TRI GGER
" t r g_wel l 2"
* ON_ELAPSED
" TI ME"
t r el t d > 0. 0
* GEOMETRY
*K
0. 07
0. 37
1. 0
0. 0
* PERFV
* GEO
2
* * KF
FF
2: 3
1. 0
* SETPI * MULTO 2
5. 0
* END_TRI GGER
The use of this elapsed time trigger ensures that the keywords
within the trigger will be read at the first possible RESOLVE date
following 2000 1 1.
The use of the *ON_ELAPSED TIME treltd > 0.0 trigger would
normally force the trigger to fire immediately, but as this is a
linked model, the trigger is checked at the next RESOLVE date.
Keywords *OPEN and *SHUTIN for wells should be included in
triggers. For example,
* DATE 2000 1 1
* TRI GGER
" shut 2"
* ON_ELAPSED
" TI ME"
t r el t d > 0. 0
* SHUTI N
" PRODUCER- 2"
* END_TRI GGER
The use of this trigger above will shut-in "PRODUCER-2 at the
first RESOLVE date following 2000 1 1.
Of course triggers can still be used to control when a well is shutin based on a real criteria, such as in the example below, where a
well is shut-in when its well bottom-hole pressure is less than
1000.00 psia.
* TRI GGER
" t r g_bhp2"
* ON_WELL
" PRODUCER- 2"
BHP < 1000. 0
* SHUTI N
" PRODUCER- 2"
* END_TRI GGER
The trigger above will be fired at the RESOLVE date when the
bottom-hole pressure of PRODUCER-2 is lower than 1000 psia
Well
Constraint
Definitions/
Use/
Restrictions
For coupled producers, a non-zero surface rate constraint should be given just
to define the target stream phase for IMEX to use with the coupled well.
For example,
*OPERATE *MAX *STO 500
249
RESOLVE
indicates the target stream of the producer is oil: the rate itself is ignored.
The target stream phase is used to determine the IMEX constraint from the
three phase rates received from GAP. Within the recurrent data, the keyword
*TARGET with non zero rate can be used to shift the target stream phase from
one phase to another. *TARGET for linked wells should also be placed within a
trigger.
Similarly, non-zero STG and STW can be used to indicate a gas and a water
producer (if applicable) respectively. If more than one of the STO, STG and
STW constraints are defined, the first will be used.
For injectors, the injection stream to be used is given by keyword *INCOMP.
Bottom-hole pressure constraints, if applicable, should be defined in GAP. A
BHP constraint given in IMEX is ignored for rate calculation purposes.
However, for injectors, if the keyword:
OPERATE *MAX *BHP
1000
is given, the value of *BHP (1000) will be used to define as the upper limit for
pressure in that wells IPR table which IMEX passes to GAP through RESOLVE.
It will not be used as an operating constraint.
The violation action *SHUTIN within the *OPERATE keyword should be
avoided.
For example,
*OPERATE *MIN *BHP 1000
*SHUTIN
for a producer may act at any IMEX timestep and cause a rate mismatch
between IMEX and GAP. Such conditional operations may be performed
instead by the monitor keyword or within a trigger.
DATE and
TIME
Injectors must be of the default mobility weighted type

DATE and TIME keywords can normally be used within the IMEX data set.
These can be used to obtain IMEX output when the WPRN / WSRF DATE
output options are used.
The start date of IMEX cannot be earlier than the start date of the RESOLVE
date schedule. The IMEX start date can be an IMEX Restart start date.
The stop date in the IMEX data set should be later than or equal to the stop
date specified in the RESOLVE schedule
2.9.2.5.3 Loading and Editing an IMEX/GEM case

The following screen is used to enter the input data required to run IMEX or GEM on a given
data set.
User Guide
250

Use specified
computer /
Use cluster
Select "Use specified computer" to execute the simulation on a given

computer, which may be the local computer. Select "Use cluster" to execute
the simulation on a node of a cluster (see below)
Computer If the option is set to "Use specified computer" this allows the
selection of the computer on which the simulation should run.
The drop-down list contains a list of recently selected
computers as well as an entry "More", which invokes a
computer selector, as described below.
251
RESOLVE
Cluster
IMEX/GEM
executable
If a remote computer is selected, then "Windows" or "Unix"

must be selected to inform the link of the architecture of the
remote machine. For more information, see "Running IMEX/
GEM on a remote computer"
If the option is set to "Use cluster" then this allows the
selection of the cluster nodes (if necessary). The user can
choose between using PxCluster (the Petroleum Experts
clustering tool) or LSF (from Platform Inc)
The executable used for the run can be entered in this field.
For local runs, If it is left blank, then the default entered in the "Configuration
screen" for the computer considered will be used.
For remote runs, the remote executable will have to form part of the SSH
command which is entered in this screen
Dataset
This is the IMEX or GEM dataset for the run.
This may be specified with a full UNC definition: indeed, a cluster run in which
the target node is not known would have to have the dataset defined in this
way so that the same path is "seen" from all nodes. A remote run should have
a dataset defined for the remote (target) computer; again, it may be
convenient to use a UNC path which can be browsed to from the button to the
right
SSH command These are only active when a remote computer is selected.
(update) /
Local path to The SSH command button is used to display/update the ssh command,
User Guide
work folder
IPR model
Advanced
simulator
options
252
based upon the information supplied in the boxes above. The displayed SSH
command is also editable, for example if the user has a different login name
on the client and server computers. (In this case it would be necessary to alter
ssh to ssh l username_on_server).
"Local path to work folder" is the local path that points to the folder/directory
where the IMEX dataset exists. Clearly, the path should be visible from both
local and remote machines, and should have a UNC path definition. The
exception to this would be when the work-folder is on a local disk, and the
target CPU is a Windows machine. In this case, a mapped drive for the entry
(e.g. D:\CMG\Dataset\) can be specified. However, a UNC path is
recommended as it should always work, even if the mapping has not been
set up
Choose from "Block" or "Corrected".
If "corrected" is chosen, a preliminary calculation must be performed before
the run. See the "IPR models" section for more information
These options allow greater control over the simulation job and its output,
such as creating a simulation log file or running the simulations on multiprocessor mode
2.9.2.5.3.1 IPR models
The IMEX / GEM links to GAP use two models for the generation of the IPR which is passed on
to GAP.
from the reservoir model in different ways: the IMEX / GEM links to GAP use two models for the
generation of the IPR which is passed on to GAP, as described below. Some of these
techniques provide realistic inflow performance definitions, whereas other techniques provide
unrealistic inflow performance definitions, often leading to instabilities in the full-field model
results.
Even so further details on IPR generation are provided in the "IPR Generation" section, it is
important to note that the most advanced, and recommended option is the Corrected option.
The IPR generation options available when connecting IMEX / GEM to GAP are the following:
Block
This is the original model in which the IPR is the inflow referred to the well
block pressure.
The block IPR is that generated by the simulator based on the block pressure
of the well and the mobility of the phases. It is the same IPR as would be
"seen" by the simulator at one iteration of its solver; a reservoir simulator
253
RESOLVE
Corrected
would then iterate on the inflow when it solves its timestep. Use of the block
IPR, therefore, leads to a fully explicit formulation which can be unstable
This is an improved model which is proprietary to Petroleum Experts.
The corrected IPR attempts to reduce the explicitness of the system by
calculating an IPR which is more representative of the performance of the well
over the timestep. To use this model, preliminary well test calculations need
to be performed.
When this option is selected on the main data entry screen, a button appears
which indicates whether the pre-calculation has been performed.
When the button is clicked, the following calculation screen is displayed:
The "Calculate" button will perform the calculation for all wells. To choose a
subset of the wells (for example, if many of the wells are not connected) then
the "Wells" button invokes a screen in which wells can be selected:
User Guide
254
The wells to be included in the calculation should be selected in the left hand
pane, and the arrow button will add the selected wells to the calculation set.
The "Tuning" button displays some parameters which can be used to tune
the calculations. These parameters should only be changed on the advice of
Petroleum Experts.
Normally, the system will be equilibrated by setting all well rates to zero for a
fixed period. This can clearly take some time. If the system is already
equilibrated at startup, then this step can be skipped by using the check
button at the top of the screen
2.9.2.5.4 IMEX/GEM driver configuration
The driver configuration screen can be invoked from the Drivers | Register drivers RESOLVE
menu item, by double-clicking on the IMEX or GEM entry or selecting the entry and clicking "
Configure".
255
RESOLVE
The following screen is presented:
The default executable path for this machine (or this user on this machine depending on user
permissions) can be set here. This means that the "executable" entry on the main data entry
screen can be left blank.
As the executable on the data entry screen is saved with the RESOLVE file then a file which is
transferred between different machines can fail to run because the executable is not correct for
the new machine. If the executable fields are all left blank and default executables are set with
this system, then this problem is overcome.
2.9.2.6 Connection to PSim - PSim driver Details
2.9.2.6.1 PSim Overview
PSim is the proprietary reservoir simulator of Conoco-Phillips (COP). The following pages are
therefore of interest only to COP users and third parties licensed by COP
PSim can run in black-oil or fully compositional modes. In addition, it has an EXTEND capability
so that the simulation can run with a smaller subset of components to that passed to GAP.
The communication mechanism between PSim and RESOLVE is through mpich, which is the
MPI implementation of the Argonne National Laboratory. Details on its setup can be found under
the "Setup and Configuration of mpich" section.
The PSim driver was originally developed by COP, but is now developed by Petroleum
Experts in collaboration with the PSim development team. Support requests should come
initially to Petroleum Experts, who will forward the information and request assistance from
COP as it is required.
The PSim driver is included (with permission from COP) in the IPM distribution, and as such
should be registered by RESOLVE by default.
User Guide
256
If it is not, then the Drivers | Register drivers menu item can be used to register the DLL. The
DLL name will be PSimLinkxx.dll, where "xx" is the current IPM version number.
2.9.2.6.2 PSim case setup guidelines

2.9.2.6.2.1 Introduction
The target of the current coupling between PSim and RESOLVE is the use of GAP as an surface
network optimisation model as well as an additional well management tool for PSim. The
assumption underlying this work is that users embarking on this endeavour wish to use GAP as
the sole well management tool and will specify any well management instruction in GAP. Hence,
it is assumed that all well management instructions are only communicated to PSim rather than
being placed in the simulation input deck directly. Although the above is not enforced and
deviations are possible, the documentation provided in this section needs to be read from this
perspective.
It needs to be emphasized that the coupling of PSim to other tools through RESOLVE is fully
explicit in nature, i.e. at synchronization time the decision on flow rates for the coming time
period, which may be larger than the next PSim timestep, is purely based on an IPR which is
exclusively constructed from data available at the end of the previous time period. Therefore,
changes in the reservoir behavior occurring between two synchronization times will not be
reflected in the IPR until the next update. The implications of this assumption need to be well
understood, as they may have several effects which can easily be misinterpreted as bugs or
errors made by any one of the tools involved.
Explicit coupling and therefore its limitations - are at the very center of the assumptions
underlying the overall IPM approach and is not limited to PSim but applicable to any reservoir
simulator.
2.9.2.6.2.2 Preparing a PSim simulation deck
The overall logic outlined below aims at minimizing the effort required to adjust or modify
existing PSim simulation decks. The only non-standard keyword requirement is the presence of
the NETWORK keyword.
Psim simulation decks must be prepared / modified before they are loaded into RESOLVE and
the RESOLVE project is started.
PSim Well Management Keywords and Control through GAP / RESOLVE
Any single well can only be either under control by PSim or GAP / RESOLVE, i.e., these tools are
mutually exclusive at the level of wells. Hence, well management related keywords defined for
wells placed under control through GAP / RESOLVE will be ignored.
257
RESOLVE
Depending on the type of the keyword the following logic holds:

Keywords in Table 1 will be ignored or overridden by the operating point data received
from GAP. It is assumed that limits (e.g. QGLMAX) which can be specified through
these keywords will be set in GAP by the user. If no limits for bottom hole pressure and
tubing head pressure are received from GAP PSim will default these values to 14.6 psi
for producers and 20.000 psi for injectors, respectively regardless of previous
definitions in the PSim deck.
BHP
HISTORY
QGLMAX
DRAWDOWN
INJECTVOL
RATE
DRILL
LIMITFIELD
THP
FIELDHGOR
LIMITWELL
WAGTBL
FIELDHWCUT
OPENWELL
WELLONTIME
Table 1: Keywords overridden by GAP / RESOLVE
Wells under GAP / RESOLVE control will automatically be detached from platforms
defined in PSim decks. In consequence, these wells will be unaffected by keywords
specified in Table 2. Note that wells which are not controlled by GAP / RESOLVE will
still be under platform control. The detachment logic does not change the limits
specified through platform related keywords. However, detaching wells will reduce the
number of wells producing against these limits. Note that the automatic detachment of
wells also applies to cosmetic platforms.
FIELDLIMIT
LIMITPLAT
PLATHWCUT
FTARG
MULTIPLATFRM PTARG
HIGHGOR
ONTIME
ITARG
OPTPLAT
SUBSTREAMS
LIMITGLG
PLATHGOR
Table 2: Platform related keywords
Keywords in Table 3 specify global limits of different fluid rates for production and
injection. Global control is disabled selectively. E.g., if any of the wells under GAP /
RESOLVE control is a producer all global limit(s) affecting production will be
deactivated. A similar logic holds for gas and water injection separately.
FIELDLM
Table 3: Keywords selectively deactivated
A very limited number of keywords (Table 4) cannot be used in runs coupled to GAP /
User Guide
258
RESOLVE.
PLATPRS
Table 4: Non-permissible keywords
Other keywords which do not directly interfere with control through GAP / RESOLVE
such as SHUTGLR, SHUTGOR or SHUTWC are unaffected by the coupling. Still, they
should be used with care and optimally all of them should be transferred into the GAP
equivalent control.
Combining PSim Well Management Keywords and Control through GAP / RESOLVE
In general this is not a recommended practice.
However, in certain cases it may be desirable to allow control of certain wells by PSim and other
wells by GAP / RESOLVE, e.g., cases where water injection is handled by PSim while
production wells are controlled by GAP / RESOLVE.
Any attempt to combine PSim and GAP well management in one model needs to be developed
considering the keyword disabling logic outlined in section PSim Well Management Keywords
and Control through GAP / RESOLVE above.
Special care needs to be taken with respect to keywords presented in Table 2.
Well Control Section in a PSim Deck
The deck below is an example showing the mandatory NETWORK keyword required for runs
coupled with GAP / RESOLVE and the complete input data required for wells in an IPM run.
Specifically, the minimum data requirements are
well name and perforation location in the grid
well type definition
THP table number for each well (if applicable)
The THP limits provided with the THP card will be overridden by the operating point data sent by
GAP / RESOLVE. The presence of RATE cards is not required.
New decks prepared specifically for IPM runs should not contain additional keywords. As
outlined above, all additional well control keywords for coupled wells will be ignored.
Static Data
ENDINIT
NETWORK 180 NOEXTEND
C --------------------------------------------------------C WELL CONTROL
259
RESOLVE
C --------------------------------------------------------WELL
I J K PI
PROD1
10 10 3 10.614
PROD2
10 1 1 10.614
10 1 2 10.614
10 1 3 10.614
PROD3
1 10 3 10.614
PROD4
3 3 3 10.614
GINJ1
1 1 1 10.614
GINJ2
6 7 1 10.614
WELLTYPE
PROD1
STBOIL
PROD2
STBOIL
PROD3
STBOIL
PROD4
STBOIL
GINJ1
MCFINJ
GINJ2
MCFINJ
THP
PROD1 250 1
PROD2 250 1
PROD3 250 1
PROD4 250 1
Other recurrent data
Compositional Simulation
Coupling between PSim and RESOLVE is not limited to black oil cases. If the number of
components specified in the PSim deck does not match the number of components in GAP
model the EXTEND keyword can be used to lump / delump production and injection streams.
Please refer to the NETWORK and EXTEND keywords in the PSim manual.
Restart Runs
The same guidelines including the use of the NETWORK keyword - presented in the General
Guidelines section still hold for runs starting from a restart. Note that if extended compositions
are to be used the EXTEND keyword must already be present in the initial run used to generate
the restart.
User Guide
260
2.9.2.6.2.3 Driver configuration
This screen governs global settings which affect how all PSim - RESOLVE models run.
It is invoked from the "Register drivers" screen, either by double-clicking on the driver entry in the
list, or highlighting the entry and clicking on Configure.
The following options are available in this driver registration section:

Local
executable /
Run
executable
Default PSim
version
These are settings that are applicable to either Windows or Linux runs.
The "Load executable" is the location of the submodel shell script.
The "Run executable" is the location of the subrun shell script
This is the default version of PSim that will be run if no version number is
entered in the "Data entry screen"
261
RESOLVE
MPI debug
modes
By default these should both be switched off, as if activated they will

compromise the performance of the run.
The "MPI server" is an application that sits between RESOLVE and PSim,
and acts as a conduit for the MPI messages passed between the two.
Normally, it is hidden but it can be displayed, along with the contents of the
messages which are passed, by clicking on the "Show MPI server window"
option.
In addition, the messages that are passed can be dumped to a log file, the
path of which must be supplied in the field at the bottom of the screen
2.9.2.6.2.4 Setup and configuration of mpich
The following procedure describes how to successfully install MPICH2.

The mpich software can be obtained directly from Petroleum Experts or COP upon request.
1. WINDOWS installation/configuration
STEP 1
MPICH2 Installation
The installation of MPICH2 (version 1.0.5p2) on PCs is facilitated by an msi
installer.
The file required for the installation of MPICH2 is distributed with the PSim
installation files.
The following steps need to be followed:
STEP 2
1. Launch the installer by double-clicking the mpich2-1.0.5p2-win32-ia32.

msi file.
2. Click Next on the welcome screen.
3. Click Next on the MPICH2 information screen.
4. Select I agree on the license agreement screen and click Next.
5. Do not change the proposed passphrase behappy! Click Next.
6. On the select installation folder screen:
Leave the installation folder at the proposed default.
Select Everyone.
Click Next.
7. On the confirm installation screen click Next.
8. On the installation complete screen click Close
MPICH2 Registration
1. Launch Start->Programs->MPICH2->wmpiregister.exe.
2. Fill out the fields in the pop up window:
In the Account field enter the userr user name and the domain name, e.g.,
conoco\mlacnm.
User Guide
262
Enter the userr current PC password in the password field.

Click the Register button.
Click OK.
STEP 3
Update Environment Variables

1. Right click the "My Computer" icon on the user desktop.
2. Choose the advanced tab and click on the "Environment Variables"
button.
3. Scroll down in the "System variables" field until the user find a variable
called "PATH" (or "Path" or "path"). If the user do not find a variable called
"PATH" go to step 6. Else continue with step 4.
4. Highlight the "PATH" line and click "Edit".
5. In the "Variable value" line add the path to the bin folder in the MPICH2
directory. For a typical MPICH2 installation this should be "C:\Program
Files\MPICH2\bin". Make sure to separate the new entry from previous
entries by a semi-colon ";". Go to step 7.
6. If "PATH" is not part of the user system variables click "New". In the "
Variable name" field enter "PATH", in the "Variable value" field enter the
path to the bin folder in the MPICH2 directory. For a typical installation this
should be "C:\Program Files\MPICH2\bin".
7. Click OK.
8. Click OK
Restart the user Computer
STEP 4
2. Linux installation/configuration
263
STEP 1
RESOLVE
Set environment to compile the mpich software

The .cshrc file must have the paths set properly to identify the gcc compiler,
e.g.
setenv CC gcc
setenv CFLAGS "-m32"
STEP 2
... with equivalents if ksh or bash are being used

Unpack and build the software
Refer to the MPICH2 Installers guide Section 2.2
STEP 3
1. Perform the tar, gunzip, mkdir as described on Section 2.2 on the mpich21.0.5p4.tar.gz.
2. When running the configure command from the manual, run the following
command below (this configures the smpd process manager)
configure -prefix=/home/usr/mpich2_4-install_32 --with-pm=smpd --withpmi=smpd
3. Run the make command
make
4. Run the 'Make Install' command
make install
5. Set the path environment variable, for example:
setenv PATH /home/sudanhh/mpich2_4-install_32/bin:$PATH
start the process manager
This will complete the installation. To start the process manager on the node,
the following commands can be used.
smpd -phrase behappy
smpd -start
smpd -status
smpd shutdown (This will shutdown the process.)
2.9.2.6.3 PSim model setup

Before it is possible to set up a PSim model in RESOLVE, it will be necessary to have the driver
"Registered" with the application. This should normally have been carried out automatically.
To set up a PSim model in RESOLVE, the Edit System | Add Client program | PSim and click
somewhere on the RESOLVE screen. A PSim icon should appear, which can be given an
appropriate label for the field in question.
Double-clicking on this icon yields the main data entry screen:
User Guide
264
The following options are available when setting-up a PSim model.

Global Well
Control
Mode
PSim case
details
IPR model
Choose from "block" or "corrected".

If "corrected" is chosen, a preliminary calculation must be
performed before the run.
See the "IPR models" section for more information
Production These are the default modes of control for production / injection
well control / wells between RESOLVE synchronisations.
Injection well Individual well controls can be overridden from the "Well
controls" button
control
These settings enable to specify the model that is to be run under RESOLVE.
File name
Host method
This is the PSim model to be run

This can be set to 'specified computer', in which case the
machine name (below) will have to be specified, or 'cluster
head node' to allow the link to connect to a head node
daemon running on a Linux cluster
More information on these options can be found here
265
RESOLVE
Head node/
port
Machine
Directory
name /
Automatically
generate
directory
names
Local path
to directory
name
PSim version
If 'cluster head node' is specified above, then these fields

should contain the name of the Linux head node (running the
lxresolve daemon) and the port on which the daemon is
waiting
If 'specified computer' is set under 'host method', then this is
the machine on which PSim is to run. If the machine is Linux,
then the "Linux node" box should be checked
When PSim runs it writes temporary and post-processing files
to a sub-directory of the run directory.
There are two options to define this sub-directory:
- The sub-directory name can be declared here explicitly. If
"myruns" were entered into the "directory name" field in the
above example, PSim would write files to the "c:
\projects\examples\PSim\gaslift\myruns" directory. The
directory is created automatically at the start of the run if it
does not already exist.
- In the above case, every run that is made will write the output
data to the same location, and existing data will be
overridden. If this is not appropriate, it is possible to force
RESOLVE to automatically generate a new directory for each
run that is performed. In this case, the directory will have a
name of the form "<reservoir-label>_<date>_<time>"
If the path to the data file is set for a remote machine (e.g. a
Linux cluster), then this can be used (optionally) to map the
remote path to the corresponding Windows path which is
visible from the local workstation. This allows the model to be
checked in and integrated with the IFM tool and the model
catalogue
The version number of PSim must be entered here. This is the
postfix of the PSim executable name (e.g.
model_2006.00.01.14.exe for the 2006.00.01.14 version).
The version number can be entered globally for all runs in the "
Configuration screen". If something has been entered here, it
will be displayed next to the version field
Restart
This is the name of the restart file, if required. It is not obligatory to enter anything
Information here for a non-restarted run
Action
Well controls Invokes the "Well controls" screen
buttons
Advanced
Invokes the screen for "Advanced options"
Executable
This section invokes a screen that enables the user to specify
the paths to the PSim executable. Executable paths defined
Paths
in this section will overwrite those set in the "Configuration
screen"
User Guide
266
2.9.2.6.3.1 IPR models
The PSim links to GAP use two models for the generation of the IPR which is passed on to GAP
.
from the reservoir model in different ways: the PSim links to GAP use two models for the
generation of the IPR which is passed on to GAP, as described below. Some of these
techniques provide realistic inflow performance definitions, whereas other techniques provide
unrealistic inflow performance definitions, often leading to instabilities in the full-field model
results.
Even so further details on IPR generation are provided in the "IPR Generation" section, it is
important to note that the most advanced, and recommended option is the Corrected option.
The IPR generation options available when connecting PSim to GAP are the following:
Block
Corrected
This is the original model in which the IPR is the inflow referred to the well
block pressure.
The block IPR is that generated by the simulator based on the block pressure
of the well and the mobility of the phases. It is the same IPR as would be
"seen" by the simulator at one iteration of its solver; a reservoir simulator
would then iterate on the inflow when it solves its timestep. Use of the block
IPR, therefore, leads to a fully explicit formulation which can be unstable
This is an improved model which is proprietary to Petroleum Experts.
The corrected IPR attempts to reduce the explicitness of the system by
calculating an IPR which is more representative of the performance of the well
over the timestep. To use this model, preliminary well test calculations need to
be performed.
When this option is selected on the main data entry screen, a button appears
which indicates whether the pre-calculation has been performed.
When the button is clicked, the following calculation screen is displayed:
267
RESOLVE
The "Calculate" button will perform the calculation for all wells. To choose a
subset of the wells (for example, if many of the wells are not connected) then
the "Wells" button invokes a screen in which wells can be selected:
User Guide
268
The wells to be included in the calculation should be selected in the left hand
pane, and the arrow button will add the selected wells to the calculation set.
The "Tuning" button displays some parameters which can be used to tune
the calculations. These parameters should only be changed on the advice of
Petroleum Experts.
Normally, the system will be equilibrated by setting all well rates to zero for a
fixed period. This can clearly take some time. If the system is already
equilibrated at startup, then this step can be skipped by using the check
button at the top of the screen
2.9.2.6.3.2 Well controls
This screen allows the user to change the control modes of individual wells from the global
setting of the "Main data entry screen".
It consists of a list of the wells (i.e. which can be filtered to select only those wells that are
269
RESOLVE
connected in RESOLVE).
To change a well's (i.e. or group of wells) control mode, it / they should be selected from the list.
A selection can then be made from the drop-down list at the top of the screen, and the "Select"
button will change the control modes of the requested wells.
2.9.2.6.3.3 Advanced options
This screen can be used to make advanced settings to influence how PSim is run.
User Guide
270
The following option is available:

Add small
timestep...
This forces PSim to make a small timestep immediately after rate data has
been sent to the simulator (i.e. immediately after GAP has solved /
optimised). This forces a synchronisation between the results of PSim and
GAP, i.e. the pressures and rates will be consistent regardless of the
explicitness of the coupling. This can have an adverse effect on the
performance of the model, as PSim has to build its timestep again from the
small value sent from RESOLVE after every synchronisation

Other functions for the PSim link can be accessed by right-clicking on the PSim icon, or by
navigating to the "Program functions" item of the main menu.
There are two functions which are specific to PSim:
View data
file
View log
file
This will display the PSim data file (.dek file) in its own window. The file can
be searched by pressing <Ctrl-F> to invoke a search panel. Clearly, the data
file can only be displayed if it is "visible" to the local machine, i.e. if the run is
local or the data file is mounted on a shared drive
Similarly, the log file generated as a result of the run can be displayed and
searched. Once again, this is only possible if the log file is visible to the
RESOLVE machine
2.9.2.6.5 Further Techical Elements regarding the PSim / GAP connection

THP
Control
This section concerns PSim wells set to THP control in RESOLVE.

Although THP control may seem to be the most realistic coupling method,
several sources of errors need to be carefully considered. THP control in a
reservoir simulator involves several additional assumptions and
computational steps in comparison to rate or bottom hole pressure control.
271
RESOLVE
The following factors need to be considered:

Consistency between the vlp curves used in GAP and PSim is
paramount to this type of control. To ensure consistency it is
recommended to export curves from GAP, preferably in the VFPPROD
(Eclipse style) format.
GAP places the extraction point at the top of the top perforation while
PSim places it at the middle of the first perforation (where first refers to
the sequence in which perforations have been defined). This difference
can be corrected through the WELLHEADZ keyword.
There is no guarantee that the algorithm for computing the operating
point used in PSim is exactly the same as in GAP. Differences may arise
from different implementations of the VLP-IPR intersection algorithm.
Shut-in
of Wells
Additional
Output
to the *.out
File
PSim does not allow instable IPR-VLP intersections while GAP by

default does. PSim will always try to find the stable intersection and will
shut in the well if only an instable intersection can be found. It is
recommended to exclude the unstable intersection from the computations
in GAP when considering the link with PSim. If the unstable intersection is
required it is recommended to control wells through the rate control
mechanism
Shut-ins are controlled by GAP / RESOLVE.
The following logic applies:
Coupled wells set as disabled in GAP are shut in without recirculation
(no crossflow allowed).
Wells assigned a zero rate as constraint in GAP will be shut in with
recirculation in PSim (crossflow is allowed).
If the GAP optimiser shuts in a well it is shut in with recirculation in PSim
In runs coupled to RESOLVE two additional output tables are automatically
reported for each synchronization time between PSim and RESOLVE. The
first table (labeled OPERATING POINT DATA TABLE) reports the
complete operating point received from RESOLVE for each well. The second
table (labeled VOLUME BALANCE ERROR TABLE) reports the
cumulative volume errors incurred by PSim wells not being able to honor the
operating points commanded by RESOLVE between synchronization points.
The volume errors at each synchronization time are computed by integrating
over the differences between the operating point set by RESOLVE and the
actual operating point used by PSim.
The error reported here is a consequence of the explicit nature of the coupling
between PSim and other tools controlled through RESOLVE. Typically, it is
smallest for the rate under which a well is actually controlled. The error tends
to increase as PSim moves further away from the last synchronization time.
User Guide
Postprocessing
of IPM
Results
Multi-PC
Runs
LINUX
Runs
272
For each timestep a reservoir simulator takes it uses a new IPR to generate
results. Reservoir simulation timesteps typically occur at a much higher
frequency than the synchronization (update) of data with RESOLVE.
RESOLVE passes updated IPRs to GAP only at synchronization times and
GAP bases its decision on flow rates for the coming time period on this
snapshot data. As the IPR in the reservoir simulator is repeatedly changed
with every timestep the wells in the reservoir simulator will not be able to
produce at exactly the operating point prescribed by GAP / RESOLVE, i.e.,
they will not be able to honor oil, gas and water flow rates or bottom hole
pressures simultaneously over the period between synchronization times. E.
g., if gas breaks through between synchronization times GAP / RESOLVE will
remain unaware of the event until the next synchronization. Although the
reservoir simulator now produces gas, the fact that gas is now being
produced will not be accounted for in any downstream application, e.g.
HYSYS until the next update. This behavior leads to a loss of volumes, i.e.,
the reservoir simulator produces volumes (which are correctly reported in its
output) but these volumes are never communicated to the tools sitting
downstream in the workflow.
The main purpose of this error table is to help users manage the error from
explicit coupling to help making better decisions about the required frequency
of synchronization, and to support the decision process for whether the
advanced, welltest based IPR calculation implemented in RESOLVE should
be used and for which wells
Results from the current RESOLVE project can be imported into CView and
compared to actual PSim results reported in the *.pltdat file. All CView tools
of the line plot functionality (e.g. VCM) can be used for imported IPM data
RESOLVE projects containing multiple PSim models can be run distributed
over several PCs in the same network.
The following requirements need to be satisfied:
The user launching the IPM run needs to have administrator or power
user privileges on each machine designated for running a PSim module.
MPICH2 needs to be installed and running on each PC designated for
running a PSim module.
PSim needs to be installed on each PC designated for running a PSim
module.
The directory containing the PSim data needs to be located on the
remote PC and mapped as a drive on the master PC (PC running
RESOLVE). After the run finishes the result data will reside on the remote
PC
PSim models in a RESOLVE project can be run on Linux clusters.
The only requirement that needs to be satisfied is that the MPICH2 daemon
must be running on each node (i.e. smpd -start must have been run). The
connection can either be made directly (using mpich2 to go across the
Windows-Linux platforms) or by connecting to a daemon on the head node of
273
RESOLVE
the cluster, which can then distribute the job using LSF or some other load
balancing software.
Tips
To save time in finding errors in the simulation deck it is

recommended to run any deck prepared for IPM simulations
in standalone mode before loading into RESOLVE. Note that
the NETWORK keyword needs to be removed from the deck
for standalone runs.
It is recommended to explicitly shut in all wells at the end of
the very first TIME / DATE card to avoid conflicts with
previous rate target definitions. This may be particularly
useful for runs starting from a restart where rate definitions
from pre-restart times may still linger and wells assumed to
be shut in and unconnected to GAP / RESOLVE may keep
producing.
If the forecast logic contained in a PSim forecast dek needs
to be transferred to GAP several related PSim keywords
and their values can be exported from the simulation dek to
a text file in a schedule format via the PRINTKW keyword.
Simple VBA scripts can use this output and assign it to the
right entities in the corresponding GAP model
Direct coupling of HYSYS and PSim is currently not supported
Limitations
Support
Unless an obvious PSim problem has been identified or a

question directly related to PSim arises all support requests
regarding IPM should be directed to Petroleum Experts
technical support at edinburgh@petex.com. Petroleum
Experts will immediately inform COP and a solution will be
worked out between the development groups at Petroleum
Experts and COP where necessary
2.9.2.7 Connection to Hysys - Hysys driver Details

2.9.2.7.1 Use of the Hysys driver
The Hysys driver allows instances of Hysys to be opened and controlled from RESOLVE.
How to use HysysLink?
The driver first needs to be registered with RESOLVE. The "Configuring the Hysys Driver"
section illustrates how to do so.
Once the driver is registered, it will be possible to create instances of Hysys in RESOLVE, as
per the workflow described below.
Create an instance of Hysys from the "Create Instance" menu on the RESOLVE main
User Guide
274
screen. Click on the RESOLVE main display screen to create a Hysys icon.
Load a pre-modeled case of Hysys by double-clicking on the created icon and then
browsing to the case in question. Note that it is possible to run Hysys on a remote
computer over a network. To do this, DCOM security must be set up on the registered
Hysys component on the remote computer.
Click on the OK button. An instance of Hysys will be created in the background that will
load the required case.
The driver will now determine the "sources" and "sinks" of the Hysys model for display
on the RESOLVE screen.
These correspond to the input streams and output streams of the model.
The Hysys streams can now be connected in RESOLVE to other sources and sinks
from other applications.
Note that the streams in Hysys are "uni-directional". This means that a single point is
passed by the program that supplies the data to Hysys and Hysys returns no data back.
The streams can only be connected to other uni-directional sources/sinks.
RESOLVE only extracts the basic black-oil results from each connection.
If it is necessary to set up additional variables from Hysys to monitor in the RESOLVE
results, right click on the Hysys icon in RESOLVE, and click on "Output variables".
As many cases of Hysys as the user wish can be loaded into RESOLVE at one time.
What does the driver do?
When RESOLVE is run, it will query the individual cases for the compositional data that they are
to run with - RESOLVE requires a common set of components to be present across the entire
system. These components do not necessarily have to have the same names (e.g. pseudocomponents may be named differently in GAP compared with Hysys, say) but it must be
possible to map the different component sets together. This has to be kept in mind when setting
up the Hysys model, i.e. the fluid package that is created must contain all the components that
are to be expected from the connected package. Pseudo-component properties do not have to
be known as these will be set by RESOLVE as part of the data transfer.
When the case is run in RESOLVE, data will be passed to the connected input stream(s) in
Hysys. This data will consist of a single point of pressure, temperature, mass flow rates, and
black oil and compositional data. This data will be set at the input stream.
The compositional data is set in Hysys by poking the data into the fluid package. This means
that all streams that access the same fluid package will be affected. If more than one input
stream is connected through RESOLVE, and these share a fluid package, then the
compositional data of that fluid package will effectively be written twice, once for each stream.
This is only a problem if the input streams arise from different sources with different properties. It
is possible to set up different fluid packages for different streams in Hysys, but then a stream
275
RESOLVE
cutter (or some mechanism for mapping components between fluids) will be necessary in the
Hysys model.
Once the data has been passed, Hysys is allowed to solve the system. Data for the monitored
variables are extracted. Also, the data for any output streams that are connected in RESOLVE
are generated. Black oil data (that may be required for connection to black oil applications) is
obtained from a series of flash calculations.
2.9.2.7.2 Configuring the Hysys driver
The Hysys driver can be configured to run a particular instance of Hysys if more than one
installation of Hysys is present on the user machine.
To reach the configuration screen, first invoke Drivers | Register Drivers from the main
RESOLVE menu. It is then possible to highlight the entry for Hysys in the driver list and click on
the configure button.
The version of Hysys (pre- or post- 2004) must be selected. This is because the programming
interface to Hysys was changed between these versions.
If there is more than one installation of one of these versions, then the directory in which the
required Hysys.exe resides can be entered into the appropriate field. Alternatively, the entry field
User Guide
276
can be left blank: in this case, the version of Hysys that will run is that which is currently entered in
the Windows registry (which is generally the last version that was installed).
2.9.2.7.3 Loading and editing a Hysys case
To access this double-click on the Hysys icon in RESOLVE.
The following screen will be presented:

Hysys
This is the Hysys case name (extension *.hsc)
Filename
Machine Name Hysys cases run from RESOLVE can be distributed over a network.
Enter in this field the name of the machine on the network on which the user
would like the Hysys case to run. The machine name can be given as an IP
address or a name in the DNS register (e.g. "dave-8200").
Leave the space blank to run Hysys on the local machine.
should be relative to the local machine
277
RESOLVE
Start date
By default data will be passed to or from Hysys as soon as the RESOLVE

forecast starts. This option can be used to schedule a plant model coming on
line at a point in time midway through a RESOLVE prediction. If the field is left
blank then the plant model will start at the same time as the RESOLVE
forecast
Transfer
This defines the way PVT data is passed to Hysys by the connected
compositional application (i.e. generally GAP).
data
Three options are available:
Transfer
upstream
compositio
n to Hysys
feed stream
This will ensure that the individual compositions are passed

from the upstream feed (e.g. a separator in GAP, if
compositional tracking in GAP is enabled). In this case, the
mole fractions and composition EOS properties will be
passed along with the standard stream properties (P, T,
mass flow)
Compositio In this case the composition (i.e mole fractions and EOS
n is set by property data) will be fixed in the Hysys model prior to it being
connected in RESOLVE. These properties will not be
Hysys Pass only overwritten when the RESOLVE run is performed - only the
pressure, temperature, and mass flow rates calculated from
B.O
properties the black oil properties will be passed.
(hydrocarb Only the hydrocarbon data will be passed; the water
component will be ignored
ons only)
Compositio This is the same as above except that water is also included
n is set by in the mass flow
Hysys Pass only
B.O
properties
(hydrocarb
ons +
water)
Advanced
Options
When RESOLVE is run, a screen is presented that allows to

map component names from one package to component
names of another. If option 2 or 3 is selected, then this screen
can be ignored: just press OK to clear the screen
If this section is selected, the following will be displayed, allowing access to

the following settings:
User Guide
278
If Hysys
RESOLVE uses the following scheme to detect whether the
solver fails Hysys model solver has converged successfully:
At the start of the run, a list of all the Hysys streams is built
from the upstream links down.
After each solve, RESOLVE will detect any stream in the list
that is in an "unsolved" state. Only the main flowsheet is
considered, and streams that are not connected in any way
to the process network that is connected through RESOLVE
will not be included.
If a solve fails, then the following options are available:
Ignore it and
continue
Log to output
window and
The failure will not be logged to any output and the run
continue silently. This is probably appropriate if a long
is being performed, in order to avoid to interrupt it with
single solver failure
This is equivalent to the previous option, except for the
an output message containing a list of the unsolved str
generated
279
RESOLVE
continue
Halt execution
with error
Force
solver
timeout
Leave
interface
open
during
solves
Debug
Logging
Add Output
Streams
If a Hysys solve fails, then a list of unsolved streams wi

logged to the output window and the run will terminate.
may be more appropriate to an optimisation run where
failure will lead to the optimiser being sent the "wrong w
On the other hand, if the optimiser bounds are too large
that a situation arises where Hysys does fail it may be
just allow the optimiser to retake the step with smaller b
rather than stopping the run altogether
In some cases Hysys may fail to solve and can enter a loop
from which it never returns. In these cases RESOLVE never
regains control of the application and so the only way to finish
the run is to kill the processes from the Windows task
manager.
If this is a possibility then it might be reasonable to enter a
"timeout" time in this field to force Hysys to return after a
certain time interval
This enables to keep the interface open during the solves
This enables to create a debug logging file that enables to

troubleshoot the run if issues arise
This invokes a screen that enables to add additional output (source) icons to
the RESOLVE interface that represent internal plant streams. This can be
useful to export results from internal streams to an Excel spreadsheet for
reporting or other purposes. This button is disabled until a model has been
loaded into RESOLVE
2.9.2.7.4 Publishing Hysys variables

RESOLVE is able to build a list of input and output variables for every operation, stream, subflowsheet, and column in a Hysys model. This list is used in several different ways:
To specify an "Objective function, constraints, or control variables".
To export variables into RESOLVE for "Event driven scheduling" and / or "Scenario
management".
For output of additional variables from Hysys in the RESOLVE "Reporting" section.
The RESOLVE "OpenServer" uses the list to allow access to Hysys variables from a
third-party application (e.g. an Excel spreadsheet)
User Guide

Select the Hysys section to access the Hysys variables and click on Edit Variables.
280
281
RESOLVE
The list down the left hand side is common to several screens in the Hysys link. It consists of a
list of the streams and operations (and sub-flowsheets and column flowsheets, if present).
When one of these items is expanded, it displays a list of the variables that are supported by the
item in question.
The list of variables is obtained from two sources:

User Guide
282
Directly from the programming interface of Hysys. As items are added to this interface
by Aspentech they will automatically appear when this list is generated; no changes are
necessary to the RESOLVE software.
Some variables do not appear directly in the Hysys programming interface.
Specifically, these are process stream property correlations, e.g. Wobbe Index, which
appears under the "Gas" correlations. A default set of these properties have been
included in RESOLVE (comprising most of the "Standard" and "Gas" correlations) but
this set can be appended to - See the "Object Browser" section to do so.
In order to publish one of these variables, select the variable to consider in the left hand list and
click on the red arrow. The variable will automatically be passed into the list of published
variables on the right hand side of the screen, as displayed above.

The following assorted functions are available in the Hysys driver.
These are accessible by right-clicking on the Hysys icon in the RESOLVE graphical view, or
using the "Program Functions" item of the main menu.
283
RESOLVE
Most of these functions are described in the "GAP other functions" section.
The following options are specific to Hysys:
Optimiser Setup
Output Variables
Edit Plant
Schedule
Show Case
OpenServer /
Object Browser
Add Hysys
Allows the RESOLVE optimisation problem to be set up

Allows variables from the Hysys model to be added to the RESOLVE "
Reporting" section
Hysys in steady state mode has no scheduling capabilities.
A schedule can, however, be set up in the RESOLVE driver to perform
events, change plant parameters, or disable / enable equipment
This simply makes the case visible to the user.
It is important that Hysys is not exited while RESOLVE is controlling it, as
the connection can not be remade once it is lost without re-opening the
RESOLVE file. Note that, to save Hysys licenses, RESOLVE will only open
a single Hysys application for all the Hysys models in the RESOLVE
system. This means that it is not possible to view all the Hysys models at
once; they can only be switched between using this function
Allows RESOLVE OpenServer strings for Hysys variables to be obtained
See the "Object Browser" section for further information
User Guide
correlation
property
Rebuild
variable list
284
This option enables to reload the list of variables that can be exported
from the Hysys model within RESOLVE. This will enable for instance to
publish one variable that has just been added in Hysys within the
RESOLVE model without having to re-open the entire RESOLVE model
2.9.2.7.5.1 Optimisation
The link to Hysys supports the optimisation functionality implemented in RESOLVE. These
screens illustrate how to set up an objective function, control variables, and constraint equations
in the Hysys model.
An example of this usage would be if the user had a GAP (surface network) model connected to
a Hysys model. It is possible to have control variables and constraints in the GAP model (i.e.
these could be well choke settings or lift gas injection quantities) and constraints and an
objective function in the Hysys model (i.e. compressor duty and maximisation of molar flow at a
stream). The RESOLVE optimiser allows these to be distributed between different models.
The screens to set up controls variables, constraints, and an objective function, can all be
accessed by clicking the right mouse button over the Hysys icon in RESOLVE. and selecting the
"Optimiser Setup" section.
The Optimiser Setup screen is divided in three different section:
Objective
Function
This section enables to set an objective function:
285
RESOLVE
It is not obligatory to set an objective function in Hysys, although obviously there

should be an objective function somewhere in the coupled system.
To set an objective function, check the box at the top of the screen. A list of
variables will be displayed for each stream and equipment item for each
flowsheet in the model (as for the control variable setup). The variable to
optimise on can be selected in this section. When a variable is selected, the
display panel below the list will display the name of the variable and the Hysys
unit of that variable.
At the bottom of the screen it is possible to specify whether this variable should
be maximised or minimised
Constraints
User Guide
286
In a similar way, constraints on plant variables can be set with the second tab.
Again the variable list can be browsed for the variable to select as a constraint.
The variable label and unit will be displayed in the panel below the variable list.
Select whether the constraint should be a "less than", "greater than", or "equal
to" constraint (bearing in mind whether such a constraint is physically realistic).
Then enter the constraint value in the unit provided and click the Add button. The
constraint information will be written to the list at the bottom.
Controls
Constraints that have been previously added can be deleted by highlighting the
entry in the list and pressing the Delete button. Alternatively all the constraints
can be removed with the Clear button. To edit an existing constraint, highlight
the entry in the list and click on the Edit button. This will display another screen
allowing to change the information for that variable
This screen allows to setup control variables in the Hysys model.
When invoked for the first time the Hysys will build a list of all the plant variables
from the contents of the model.
287
RESOLVE
The list on the left hand side is a hierarchical list of all the spreadsheets,
streams, and equipment in the model. If an item is expanded (e.g. Feed1 in the
above screenshot) a list of all the variables that can be changed for that
particular item will be displayed.
To use this screen, browse to the variable that is to be implemented as a control
variable. Then click the Add button and the variable will be added to the list on
the right.
It is then possible to impose maximum and minimum bounds on the variable (i.
e. the optimiser will not let the value of the variable go out of this range). The
maximum and minimum quantities are not obligatory, although it is often a good
idea to bind the optimiser to a physically realistic region of solution space.
In the above example, a single optimiser control variable has been selected.
This is the pressure of a stream ("To reboiler") which flows into a fractionating
column in the plant model. The units (kPa) have been picked up automatically
from Hysys. The user has imposed a range on the variable of 1000 kPa to 2000
kPa.
To delete a variable from the list, click the delete button on the right hand side of
the grid next to the variable in question
User Guide
288
2.9.2.7.5.2 Output variables
This screen is invoked by right-clicking on the Hysys icon and selecting "Output variables".
Variables can be selected from the list on the left hand side. Once selected, they can be added
to the list of additional (reported) variables by clicking on the "Add" button.
Items can be deleted from the reported list by highlighting them and clicking the "Remove"
button.
If a parent item is deleted, then all children of that item will also be deleted.
The reported variable list can be cleared completely by clicking the "Clear" button.
2.9.2.7.5.3 Scheduling
This functionality is redundant now that the "Event driven scheduling" has been implemented in
the RESOLVE application itself. This is retained for backwards compatibility only.
289
RESOLVE
The hierarchical list at the top of the screen contains the variables that can be changed for each
input material stream, energy stream, and piece of equipment.
To schedule
a variable
change
To schedule a variable change, browse to the variable that has to change in

the schedule.
In the above example, the variable "PercentVapourValveOpening" of the
User Guide
To schedule
an enabling/
disabling of
equipment
Other
functions
290
equipment "V-101" has been selected.

The equipment name, variable name, and unit for this variable ("%") are
automatically displayed.
It is now possible to enter the date at which the variable has to be changed
and the value that the user would like it changed to. Click Add to add the
variable change to the schedule. It will appear in the list at the bottom of the
screen, as shown
Click on a piece of equipment in the list at the top of the screen. T
he screen will present a checkbox to allow disabling or enabling the
equipment.
Enter the date at which the enabling/disabling has to take place.
Click Add to add the event to the schedule. It will appear in the list at the
bottom of the screen, as shown
Delete
This removes any highlighted events in the list at the
bottom of the screen
Edit entry
Allows any existing schedule entries in the list at the
bottom of the screen to be altered.
A new "Edit schedule entry" screen will be presented
Sort by date
This just sorts the schedule event list from the earliest
event to the latest
2.9.2.7.5.4 Object browser
This screen can be invoked by right-clicking on the Hysys icon and selecting "OpenServer /
Object browser".
It has two functions:
It can be used to obtain the RESOLVE "OpenServer" string for any variable in the Hysys
model.
It can also be used as a simple interface to browse the Hysys model and to query the
values of different variables.
291
RESOLVE
The list on the left is a hierarchical list of all the items in the Hysys model with all their supported
variables. By expanding an item and selecting a variable, the corresponding OpenServer
strings for the variable's value and unit can be viewed. As a convenience, the current value of
that variable and its read / write status are also displayed.
Directly from the programming interface of Hysys. As items are added to this interface
by Aspentech they will automatically appear when this list is generated; no changes are
necessary to the RESOLVE software.
Some variables do not appear directly in the Hysys programming interface.
this set can be appended to.
To add additional property correlations, right-click on the Hysys icon and select "Add Hysys
Correlation Property".
The following screen is displayed:
User Guide
292
Those properties that are highlighted in blue are fixed and can not be removed. Additional
properties can be added, as shown. These changes are stored in the Windows registry, so
when RESOLVE is opened subsequently it should not be necessary to add the properties again.
If properties are added to the list, then any variable list that has already been built in the model
will have to be rebuilt if the new variables(s) are to be seen. This can be done by right-clicking on
the icon and going to "Rebuild variable list".
Note that properties are not checked for validity as they are added. If a property that is not valid
is detected when the variable list is built, the property will simply be ignored. In this case, it is
important to check that the wording / spelling of the property is exactly the same as appears on
the Hysys interface. If there are any doubts, contact Petroleum Experts.
293
RESOLVE
2.9.2.7.6 Setting up a case in Hysys : Additional Information

Here are some other points that should be considered when creating the Hysys model.
The driver has been developed for use with steady state (non-dynamic) Hysys.
Dynamic (time-dependent) behaviour is assumed to come from the connected models.
When the model is created, the fluid package should contain all the components that
are expected from the connected model (e.g. GAP). The components can be pure or
pseudo (hypo). They do not have to have the same names as in the GAP model as
RESOLVE will map GAP components to Hysys components as part of the initialisation
process. If the set of components is different between the connected modules then the
compositions will be re-normalised by RESOLVE when the data is passed across to
exclude the components that do not map.
When the compositional properties (critical temperature, pressure, etc) are passed,
only pseudo-component properties can be changed in Hysys. Pure component
properties are left unchanged. If the user would like to pass the critical properties for a
pure component, then this would have to be set up as a hypothetical component in
Hysys. This would, however, mean that Hysys does not have any knowledge of the pure
component that it is supposed to represent (for the purposes of enthalpy calculations,
etc).
When compositional properties are set in Hysys, they are applied to the fluid package
that is accessed by a stream. If the fluid package is shared across several input
streams all streams will be affected by the changes. This may also affect cases where
more than one input stream is connected in RESOLVE. If the streams access the same
fluid package, then the fluid package will be updated twice, potentially with different
fluid properties. It is possible in Hysys for the input streams to access different fluid
packages, but then a stream cutter or some other mapping will be required to map the
different packages together in the Hysys model.
Data will be passed by RESOLVE to the input feed of Hysys as indicated on the
RESOLVE graphical view. This input feed will therefore be the source of user entered (i.
e. fixed) variables to the Hysys model. On some occasions Hysys models are built
which are based on different fixed variables: if these models are linked with no changes
consistency errors may occur.
Consider, for example, the following system. A Hysys model consists of a separator
followed by a compressor. The user who built the model requires a fixed pressure at the
output stream which he has entered directly in this screen. Hysys is then allowed to
calculate the inlet pressure to the system. If this model is connected to GAP it is the inlet
condition that will be fixed. If the model is connected with no modification a consistency
error on the output stream pressure will be flagged by Hysys.
If, in a system such as this, a constraint on discharge pressure is to be met then it is
necessary to iterate on the inlet pressure to the system.
This can be done through the GAP optimiser.
User Guide
294
2.9.2.8 Connection to UniSim - UniSim driver Details

2.9.2.8.1 Use of the UniSim driver
The UniSim Design driver allows instances of UniSim Design to be opened and controlled from
RESOLVE.
How to use UniSimDesignLink?
The driver first needs to be registered with RESOLVE. The "Configuring the UniSim Design
Driver" section illustrates how to do so.
Once the driver is registered, it will be possible to create instances of UniSim Design in
RESOLVE, as per the workflow described below.
Create an instance of UniSim Design from the "Create Instance" menu on the
RESOLVE main screen. Click on the RESOLVE main display screen to create a UniSim
Design icon.
Load a pre-modeled case of UniSim Design by double-clicking on the created icon
and then browsing to the case in question. Note that it is possible to run UniSim Design
on a remote computer over a network. To do this, DCOM security must be set up on the
registered UniSim Design component on the remote computer.
Click on the OK button. An instance of UniSim Design will be created in the
background that will load the required case.
The driver will now determine the "sources" and "sinks" of the UniSim Design model for
display on the RESOLVE screen.
These correspond to the input streams and output streams of the model.
The UniSim Design streams can now be connected in RESOLVE to other sources and
sinks from other applications.
Note that the streams in UniSim Design are "uni-directional". This means that a single
point is passed by the program that supplies the data to UniSim Design and UniSim
Design returns no data back. The streams can only be connected to other uni-directional
sources/sinks.
RESOLVE only extracts the basic black-oil results from each connection.
If it is necessary to set up additional variables from UniSim Design to monitor in the
RESOLVE results, right click on the UniSim Design icon in RESOLVE, and click on
"Output variables".
As many cases of UniSim Design as the user wish can be loaded into RESOLVE at
one time.
What does the driver do?
When RESOLVE is run, it will query the individual cases for the compositional data that they are
295
RESOLVE
to run with - RESOLVE requires a common set of components to be present across the entire
system. These components do not necessarily have to have the same names (e.g. pseudocomponents may be named differently in GAP compared with UniSim Design, say) but it must
be possible to map the different component sets together. This has to be kept in mind when
setting up the UniSim Design model, i.e. the fluid package that is created must contain all the
components that are to be expected from the connected package. Pseudo-component
properties do not have to be known as these will be set by RESOLVE as part of the data
transfer.
When the case is run in RESOLVE, data will be passed to the connected input stream(s) in
UniSim Design. This data will consist of a single point of pressure, temperature, mass flow
rates, and black oil and compositional data. This data will be set at the input stream.
The compositional data is set in UniSim Design by poking the data into the fluid package. This
means that all streams that access the same fluid package will be affected. If more than one
input stream is connected through RESOLVE, and these share a fluid package, then the
compositional data of that fluid package will effectively be written twice, once for each stream.
This is only a problem if the input streams arise from different sources with different properties. It
is possible to set up different fluid packages for different streams in UniSim Design, but then a
stream cutter (or some mechanism for mapping components between fluids) will be necessary
in the UniSim Design model.
Once the data has been passed, UniSim Design is allowed to solve the system. Data for the
monitored variables are extracted. Also, the data for any output streams that are connected in
RESOLVE are generated. Black oil data (that may be required for connection to black oil
applications) is obtained from a series of flash calculations.
2.9.2.8.2 Configuring the UniSim driver
The UniSim Design driver can be configured to run a particular instance of UniSim Design if
more than one installation of UniSim Design is present on the user machine.
To reach the configuration screen, first invoke Drivers | Register Drivers from the main
RESOLVE menu. It is then possible to highlight the entry for UniSim Design in the driver list and
click on the configure button.
User Guide
296
Enter (or browse to) the directory in which UniSim Design.exe resides.
As the message indicates, the entry field can be left blank. In this case, the version of UniSim
Design that will run is that which is currently entered in the registry.
This happens to be the version that was last executed on the local computer.
2.9.2.8.3 Loading and editing a UniSim case
To access this double-click on the UniSim Design icon in RESOLVE.
The following screen will be presented:
297
RESOLVE

UniSim Design This is the UniSim Design case name (extension *.usc)
Filename
Machine Name UniSim Design cases run from RESOLVE can be distributed over a network.
Enter in this field the name of the machine on the network on which the user
would like the UniSim Design case to run. The machine name can be given
as an IP address or a name in the DNS register (e.g. "dave-8200").
Leave the space blank to run UniSim Design on the local machine.
should be relative to the local machine
Start date
By default data will be passed to or from UniSim Design as soon as the
RESOLVE forecast starts. This option can be used to schedule a plant model
coming on line at a point in time midway through a RESOLVE prediction. If
the field is left blank then the plant model will start at the same time as the
RESOLVE forecast
Transfer
This defines the way PVT data is passed to UniSim Design by the connected
compositional application (i.e. generally GAP).
data
Three options are available:
User Guide
Transfer
upstream
composition
to UniSim
Design feed
stream
Composition
is set by
UniSim
Design - Pass
only B.O
properties
(hydrocarbon
s only)
Composition
is set by
UniSim
Design - Pass
only B.O
properties
(hydrocarbon
s + water)
Advanced
Options
298
This will ensure that the individual compositions are

passed from the upstream feed (e.g. a separator in GAP, if
compositional tracking in GAP is enabled). In this case, the
mole fractions and composition EOS properties will be
passed along with the standard stream properties (P, T,
mass flow)
In this case the composition (i.e mole fractions and EOS
property data) will be fixed in the UniSim Design model
prior to it being connected in RESOLVE. These properties
will not be overwritten when the RESOLVE run is performed
- only the pressure, temperature, and mass flow rates
calculated from the black oil properties will be passed.
Only the hydrocarbon data will be passed; the water
component will be ignored
This is the same as above except that water is also
included in the mass flow
When RESOLVE is run, a screen is presented that allows to

map component names from one package to component
names of another. If option 2 or 3 is selected, then this screen
can be ignored: just press OK to clear the screen
If this section is selected, the following will be displayed, allowing access to

the following settings:
299
RESOLVE
If UniSim
Design
solver fails
RESOLVE uses the following scheme to detect whether the

UniSim Design model solver has converged successfully:
At the start of the run, a list of all the UniSim Design
streams is built from the upstream links down.
After each solve, RESOLVE will detect any stream in the
list that is in an "unsolved" state. Only the main flowsheet
is considered, and streams that are not connected in any
way to the process network that is connected through
RESOLVE will not be included.
If a solve fails, then the following options are available:
Ignore it and
continue
Log to output
window and
The failure will not be logged to any output and the ru

continue silently. This is probably appropriate if a lon
is being performed, in order to avoid to interrupt it w
single solver failure
This is equivalent to the previous option, except for th
an output message containing a list of the unsolved s
generated
User Guide
continue
Halt execution
with error
300
If a UniSim Design solve fails, then a list of unsolved

will be logged to the output window and the run will te
This may be more appropriate to an optimisation run
solve failure will lead to the optimiser being sent the "
way".
On the other hand, if the optimiser bounds are too lar
that a situation arises where UniSim Design does fai
better to just allow the optimiser to retake the step wi
bounds rather than stopping the run altogether
Force solver In some cases UniSim Design may fail to solve and can
enter a loop from which it never returns. In these cases
timeout
RESOLVE never regains control of the application and so
the only way to finish the run is to kill the processes from the
Windows task manager.
If this is a possibility then it might be reasonable to enter a
"timeout" time in this field to force UniSim Design to return
after a certain time interval
Leave
This enables to keep the interface open during the solves
interface
open during
solves
Debug
This enables to create a debug logging file that enables to
troubleshoot the run if issues arise
Logging
Add Output
Streams
This invokes a screen that enables to add additional output (source) icons to
the RESOLVE interface that represent internal plant streams. This can be
useful to export results from internal streams to an Excel spreadsheet for
reporting or other purposes. This button is disabled until a model has been
loaded into RESOLVE
2.9.2.8.4 Publishing UniSim variables

RESOLVE is able to build a list of input and output variables for every operation, stream, subflowsheet, and column in a Hysys model. This list is used in several different ways:
To specify an "Objective function, constraints, or control variables".
To export variables into RESOLVE for "Event driven scheduling" and / or "Scenario
management".
For output of additional variables from Hysys in the RESOLVE "Reporting" section.
The RESOLVE "OpenServer" uses the list to allow access to Hysys variables from a
third-party application (e.g. an Excel spreadsheet)
301
RESOLVE

Select the UniSim Design section to access the UniSim Design variables and click on Edit
Variables.
User Guide
302
The list down the left hand side is common to several screens in the UniSim Design link. It
consists of a list of the streams and operations (and sub-flowsheets and column flowsheets, if
present).
When one of these items is expanded, it displays a list of the variables that are supported by the
item in question.
303
RESOLVE

Directly from the programming interface of UniSim Design. As items are added to this
interface by Aspentech they will automatically appear when this list is generated; no
changes are necessary to the RESOLVE software.
Some variables do not appear directly in the UniSim Design programming interface.
this set can be appended to - See the "Object Browser" section to do so.
In order to publish one of these variables, select the variable to consider in the left hand list and
click on the red arrow. The variable will automatically be passed into the list of published
variables on the right hand side of the screen, as displayed above.

The following assorted functions are available in the UniSim Design driver.
These are accessible by right-clicking on the UniSim Design icon in the RESOLVE graphical
view, or using the "Program Functions" item of the main menu.
User Guide
304
Most of these functions are described in the "GAP other functions" section.
The following options are specific to UniSim Design:
Optimiser Setup
Allows the RESOLVE optimisation problem to be set up.
Output Variables
Allows variables from the UniSim Design model to be added to the RESOLVE "Reporting
" section.
Edit Plant Schedule
UniSim Design in steady state mode has no scheduling capabilities.
A schedule can, however, be set up in the RESOLVE driver to perform events, change
plant parameters, or disable / enable equipment.
Show Case
This simply makes the case visible to the user.
It is important that UniSim Design is not exited while RESOLVE is controlling it, as the
connection can not be remade once it is lost without re-opening the RESOLVE file. Note
that, to save UniSim Design licenses, RESOLVE will only open a single UniSim Design
application for all the UniSim Design models in the RESOLVE system. This means that it
305
RESOLVE
is not possible to view all the UniSim Design models at once; they can only be switched
between using this function.
OpenServer / Object Browser
Allows RESOLVE OpenServer strings for UniSim Design variables to be obtained.
Add UniSim Design correlation property
See the "Object Browser" section for further information.
Rebuild variable list
This option enables to reload the list of variables that can be exported from the UniSim
Design model within RESOLVE. This will enable for instance to publish one variable that
has just been added in UniSim Design within the RESOLVE model without having to reopen the entire RESOLVE model.
2.9.2.8.5.1 Optimisation
The link to UniSim Design supports the optimisation functionality implemented in RESOLVE.
These screens illustrate how to set up an objective function, control variables, and constraint
equations in the UniSim Design model.
An example of this usage would be if the user had a GAP (surface network) model connected to
a UniSim Design model. It is possible to have control variables and constraints in the GAP
model (i.e. these could be well choke settings or lift gas injection quantities) and constraints and
an objective function in the UniSim Design model (i.e. compressor duty and maximisation of
molar flow at a stream). The RESOLVE optimiser allows these to be distributed between
different models.
The screens to set up controls variables, constraints, and an objective function, can all be
accessed by clicking the right mouse button over the UniSim Design icon in RESOLVE. and
selecting the "Optimiser Setup" section.
The Optimiser Setup screen is divided in three different section:
Objective
Function
This section enables to set an objective function:
User Guide
306
It is not obligatory to set an objective function in UniSim Design, although

obviously there should be an objective function somewhere in the coupled
system.
To set an objective function, check the box at the top of the screen. A list of
variables will be displayed for each stream and equipment item for each
flowsheet in the model (as for the control variable setup). The variable to
optimise on can be selected in this section. When a variable is selected, the
display panel below the list will display the name of the variable and the UniSim
Design unit of that variable.
At the bottom of the screen it is possible to specify whether this variable should
be maximised or minimised
Constraints
307
RESOLVE
In a similar way, constraints on plant variables can be set with the second tab.
Again the variable list can be browsed for the variable to select as a constraint.
The variable label and unit will be displayed in the panel below the variable list.
Select whether the constraint should be a "less than", "greater than", or "equal
to" constraint (bearing in mind whether such a constraint is physically realistic).
Then enter the constraint value in the unit provided and click the Add button.
The constraint information will be written to the list at the bottom.
Controls
Constraints that have been previously added can be deleted by highlighting the
entry in the list and pressing the Delete button. Alternatively all the constraints
can be removed with the Clear button. To edit an existing constraint, highlight
the entry in the list and click on the Edit button. This will display another screen
allowing to change the information for that variable
This screen allows to setup control variables in the UniSim Design model.
When invoked for the first time the UniSim Design will build a list of all the plant
variables from the contents of the model.
User Guide
308
The list on the left hand side is a hierarchical list of all the spreadsheets,
streams, and equipment in the model. If an item is expanded (e.g. Feed1 in the
above screenshot) a list of all the variables that can be changed for that
particular item will be displayed.
To use this screen, browse to the variable that is to be implemented as a
control variable. Then click the Add button and the variable will be added to the
list on the right.
It is then possible to impose maximum and minimum bounds on the variable (i.
e. the optimiser will not let the value of the variable go out of this range). The
maximum and minimum quantities are not obligatory, although it is often a good
idea to bind the optimiser to a physically realistic region of solution space.
In the above example, a single optimiser control variable has been selected.
This is the pressure of a stream ("To reboiler") which flows into a fractionating
column in the plant model. The units (kPa) have been picked up automatically
from UniSim Design. The user has imposed a range on the variable of 1000
kPa to 2000 kPa.
To delete a variable from the list, click the delete button on the right hand side
of the grid next to the variable in question
309
RESOLVE
2.9.2.8.5.2 Output variables
This screen is invoked by right-clicking on the UniSim Design icon and selecting "Output
variables".
Variables can be selected from the list on the left hand side. Once selected, they can be added
to the list of additional (reported) variables by clicking on the "Add" button.
Items can be deleted from the reported list by highlighting them and clicking the "Remove"
button.
If a parent item is deleted, then all children of that item will also be deleted.
The reported variable list can be cleared completely by clicking the "Clear" button.
2.9.2.8.5.3 Scheduling
This functionality is redundant now that the "Event driven scheduling" has been implemented in
User Guide
310
the RESOLVE application itself. This is retained for backwards compatibility only.
The hierarchical list at the top of the screen contains the variables that can be changed for each
input material stream, energy stream, and piece of equipment.
To schedule
a variable
To schedule a variable change, browse to the variable that has to change in

the schedule.
311
RESOLVE
change
To schedule
an enabling/
disabling of
equipment
Other
functions
In the above example, the variable "PercentVapourValveOpening" of the

equipment "V-101" has been selected.
The equipment name, variable name, and unit for this variable ("%") are
automatically displayed.
It is now possible to enter the date at which the variable has to be changed
and the value that the user would like it changed to. Click Add to add the
variable change to the schedule. It will appear in the list at the bottom of the
screen, as shown
Click on a piece of equipment in the list at the top of the screen. T
he screen will present a checkbox to allow disabling or enabling the
equipment.
Enter the date at which the enabling/disabling has to take place.
Click Add to add the event to the schedule. It will appear in the list at the
bottom of the screen, as shown
Delete
This removes any highlighted events in the list at the
bottom of the screen
Edit entry
Allows any existing schedule entries in the list at the
bottom of the screen to be altered.
A new "Edit schedule entry" screen will be presented
Sort by date
This just sorts the schedule event list from the earliest
event to the latest
2.9.2.8.5.4 Object browser
This screen can be invoked by right-clicking on the Hysys icon and selecting "OpenServer /
Object browser".
It has two functions:
It can be used to obtain the RESOLVE "OpenServer" string for any variable in the
UniSim Design model.
It can also be used as a simple interface to browse the UniSim Design model and to
query the values of different variables.
User Guide
312
The list on the left is a hierarchical list of all the items in the UniSim Design model with all their
supported variables. By expanding an item and selecting a variable, the corresponding
OpenServer strings for the variable's value and unit can be viewed. As a convenience, the
current value of that variable and its read / write status are also displayed.
Directly from the programming interface of UniSim Design. As items are added to this
interface by Aspentech they will automatically appear when this list is generated; no
changes are necessary to the RESOLVE software.
Some variables do not appear directly in the UniSim Design programming interface.
this set can be appended to.
To add additional property correlations, right-click on the UniSim Design icon and select "Add
UniSim Design Correlation Property".
313
RESOLVE
Those properties that are highlighted in blue are fixed and can not be removed. Additional
properties can be added, as shown. These changes are stored in the Windows registry, so
when RESOLVE is opened subsequently it should not be necessary to add the properties again.
If properties are added to the list, then any variable list that has already been built in the model
will have to be rebuilt if the new variables(s) are to be seen. This can be done by right-clicking on
the icon and going to "Rebuild variable list".
Note that properties are not checked for validity as they are added. If a property that is not valid
is detected when the variable list is built, the property will simply be ignored. In this case, it is
important to check that the wording / spelling of the property is exactly the same as appears on
the UniSim Design interface. If there are any doubts, contact Petroleum Experts.
User Guide
314
2.9.2.8.6 Setting up a case in UniSim : Additional Information

Here are some other points that should be considered when creating the UniSim Design model.
The driver has been developed for use with steady state (non-dynamic) UniSim Design.
Dynamic (time-dependent) behaviour is assumed to come from the connected models.
When the model is created, the fluid package should contain all the components that
are expected from the connected model (e.g. GAP). The components can be pure or
pseudo (hypo). They do not have to have the same names as in the GAP model as
RESOLVE will map GAP components to UniSim Design components as part of the
initialisation process. If the set of components is different between the connected
modules then the compositions will be re-normalised by RESOLVE when the data is
passed across to exclude the components that do not map.
When the compositional properties (critical temperature, pressure, etc) are passed,
only pseudo-component properties can be changed in UniSim Design. Pure
component properties are left unchanged. If the user would like to pass the critical
properties for a pure component, then this would have to be set up as a hypothetical
component in UniSim Design. This would, however, mean that UniSim Design does not
have any knowledge of the pure component that it is supposed to represent (for the
purposes of enthalpy calculations, etc).
When compositional properties are set in UniSim Design, they are applied to the fluid
package that is accessed by a stream. If the fluid package is shared across several
input streams all streams will be affected by the changes. This may also affect cases
where more than one input stream is connected in RESOLVE. If the streams access the
same fluid package, then the fluid package will be updated twice, potentially with
different fluid properties. It is possible in UniSim Design for the input streams to access
different fluid packages, but then a stream cutter or some other mapping will be
required to map the different packages together in the UniSim Design model.
Data will be passed by RESOLVE to the input feed of UniSim Design as indicated on
the RESOLVE graphical view. This input feed will therefore be the source of user
entered (i.e. fixed) variables to the UniSim Design model. On some occasions UniSim
Design models are built which are based on different fixed variables: if these models
are linked with no changes consistency errors may occur.
Consider, for example, the following system. A UniSim Design model consists of a
separator followed by a compressor. The user who built the model requires a fixed
pressure at the output stream which he has entered directly in this screen. UniSim
Design is then allowed to calculate the inlet pressure to the system. If this model is
connected to GAP it is the inlet condition that will be fixed. If the model is connected
with no modification a consistency error on the output stream pressure will be flagged
by UniSim Design.
If, in a system such as this, a constraint on discharge pressure is to be met then it is
necessary to iterate on the inlet pressure to the system.
315
RESOLVE
This can be done through the GAP optimiser.

2.9.2.9 Connection to Excel - Excel driver Details
2.9.2.9.1 Excel Driver : Overview
The Excel driver is a generic link to the functionality provided by Excel. Data can be passed to,
or from, an Excel spreadsheet.
The user just has to tell RESOLVE which worksheets and cells provide the source or destination
for the data.
There are a number of potential applications for this link:
Reporting
Data sources
Arithmetic
operations
(splitting,
mixing, tees,
etc)
Data
manipulation
In the simplest case, Excel can be used just to provide a repository for the
data that comes from a forecast. The spreadsheet can be tailored to format
the data that comes into Excel, plotting the results or performing calculations
Excel can be used to provide a source of data into a RESOLVE system. For
example, lift gas to a GAP model can be calculated by a spreadsheet and
entered as a source into GAP
Excel can be used, for example, to copy a stream. A single input stream can
be copied to several output streams which can then be fed into different
modules in parallel
An Excel spreadsheet can be set up to perform calculations on input data

and provide resulting output data. An example of this would be if the user had
a plant model in Excel
There is no limit to the number of input or output streams that the link can support. In addition to
writing input data to the worksheet and extracting output data from the worksheet, Visual Basic
macros can be run to perform calculations at each timestep. There is also no limit to the number
of Excel instances that can be added to a RESOLVE system.
2.9.2.9.2 Loading and Editing a Case
2.9.2.9.2.1 Loading and Editing an Excel case : Overview
The Excel driver edit screen is divided into four different sections.
User Guide
Excel Details
Input Data
Output Data
Macros
316
This includes the number of input and output streams to set up and the Excel
file name
Specifies the destination cells for incoming data (optional)
Specifies the source cells for outgoing data (optional)
Allows the user to enter a VBA macro to run at each timestep (optional)
2.9.2.9.2.2 Excel Driver : Excel Details
The Excel details screen enables to enter the general properties of the Excel module.
317
RESOLVE
The data shall be entered as follow:

Excel
spreadsheet
file
Number of
inputs /
Number of
outputs
EOS data
This is the name of an Excel file (.xls) that will be loaded when the OK button
is pressed.
This is optional: if no file is entered then a blank spreadsheet will be used
These numbers give the number of inputs and outputs to the Excel module.
When OK is pressed icons will be generated for each input and output
stream.
There is no limit to the numbers of inputs and outputs
Pass
This has to be check to enable the passing of
compositional compositional data to Excel
data
Setup
This enable to setup the component names which will be
Compositions passed to or from this module.
User Guide
318
This invokes the composition screen illustrated below.

Multiple compositions can be setup, so in principle the
spreadsheet can be used for lumping or delumping
applications.
This screen allows to setup all the composition
descriptions (i.e. the set of component names) that will be
used in the link.
The "description" column contains a list of the component

names for all the defined compositions. Click on the "
Delete" button to remove a composition.
To create a composition or edit an existing composition
click on the "Edit" button next to the item in question.
The following screen is invoked:
319
RESOLVE
Component
names
The names of the components must be supplied in the

"component names" table.
These will be the names that are mapped in the
compositional map table displayed by RESOLVE when a
compositional forecast is run for the first time.
After "OK" is pressed the component names set up here
will be passed back to the "description" column of the
parent screen
Hide Interface This option hides the Excel interface when a RESOLVE calculation is
when
performed. It prevents accidental interference from the user, who may click
inside Excel while the calculation is being performed
RESOLVE is
calculating
2.9.2.9.2.3 Excel Driver : Input Data
This screen enables to specify the destination Excel cells for each input stream.
User Guide
320
Input fields
Input
Sheet name
Data needs to be entered for each input stream.

The input streams are displayed in the drop down list.
For each input stream it will be needed to specify the destination (target) cells
for the properties that are to be passed
For the input in question this allows to input the target worksheet.
If this is left blank a new worksheet will be created. The "Query" button can
be usedto automatically populate the drop down list with the worksheet
names.
The rest of the screen is split between Solver and Forecast sections.
The cells specified in the "solver" part will be overwritten at each RESOLVE
timestep.
The cells in the "forecast" part will represent the cells written to at the first
321
Solver
Forecast
RESOLVE
timestep; subsequent timesteps will be arranged vertically below or

horizontally to the right of these cells
Display
Check this to tell RESOLVE to enable the display of input
solver data
Property table For each property that is to enter into the spreadsheet
enter the target cell number (e.g. gas rate will be entered
into cell B5 in the example above).
This data can be generated automatically by clicking on
the "Auto generate" button.
Note that the unit in which the property will be displayed
can be changed
Composition
Click on this button to invoke the composition screen to
tell RESOLVE where to place EOS data on the worksheet.
See the "Excel Driver : Output Data" section for further
details
The data required here is equivalent to the data required in the "solver"
section, the difference being that the data is arranged either vertically below
these cells or horizontally to the right of these cells: this section enables
therefore to keep track of the data through time in the Excel spreadsheet,
whereas the data passed using the solver data section will be overwritten at
each timestep
2.9.2.9.2.4 Excel Driver : Output Data
This screen enables to specify the destination Excel cells for each output stream.
User Guide
322
Input fields
Output
Copy from
input
Composition
The data for each output stream should be entered as required. The names
of the output streams are listed in the drop down list here
It is possible to simply copy the input data from one of the input streams to
the output stream.
To do this, select the target input stream from the drop down list and then
click the "Copy" button.
The other options are equivalent to those described on the "Input data" tab
This screen is invoked from either the "Input data"tab screen or the "Output
data" tab screen. Obviously the data entered here will be either input data or
output data depending on where the screen was invoked from.
Compositional data will only be passed if the check box has been checked in
the "Main data entry screen".
323
RESOLVE
Composition
Composition
data cell
Binary
interaction
coefficients
EOS model
Mass rate cell
From this drop down list box it will be needed to select a

composition that has previously been set up in the
composition setup screen
The compositional data will be extracted from or written to
a rectangular block of cells in Excel. In this cell the top left
hand corner cell of this block needs to be entered
In a similar manner, enter here the top left hand corner of
the block of cells that will contains the binary interaction
coefficients
The Excel cell reference to report the EOS calculator i.e.,
PR or SRK. NOTE: The EOS calculator cell reference
must be specified if the composition is to be passed on
from the Excel input to an Excel output for instance
The mass rate of the stream will be written or extracted
from this cell. The units of the quantity can be changed
from the drop down list next to this field
User Guide
Units
324
For those properties that have units it is possible to

change the unit in this table. All the units can be changed
to a different system by changing the drop down list at the
top of the table (in the example above he unit system is
set to "Oilfield")
2.9.2.9.2.5 Excel Driver : Macros
This screen allows to run an Excel macro (VBA) at each timestep in RESOLVE.
This allows, for example, to generate data that can be input into another module (e.g. GAP
gaslift data).
The table consists of a list of potential points in the calculation timeline from which a macro can
325
RESOLVE
be called. Macro names can be entered in the table alongside the required entry point to
simulate the required functionality.
In addition, there are two possibilities regarding how the Excel macro is called from RESOLVE.
If "Pass current
timestep date as
argument to
macro" is NOT
checked
then the macro will be called with just the timestep count as an argument.
In this case, the subroutine in VBA must be declared as follows:
Sub AMacro (timestep As Integer)
Call MsgBox("AMacro called at timestep " + cstr(timestep))
" do something else
...
End Sub
If "Pass current
timestep date as
argument to
macro" is
checked
Note that the timestep count starts from zero for the first timestep
then the date will also be passed.
It will be passed as a string, so in this case the subroutine must be
declared as follows:
Sub AMacro (timestep As Integer, dt As String)
Call MsgBox("Macro is called on date " + dt + " timestep " + cstr(ts))
End Sub
In all cases, the macro name supplied must be fully qualified with the location of the
macro, e.g. "sheet1.amacro" or "ThisWorkbook.amacro".
2.9.2.9.3 Publishing Excel variables

This screen allows variables to be published from Excel into RESOLVE.
User Guide
326

By clicking on "Edit Variables", the following screen appears, enabling to select which Excel
variables have to be published in RESOLVE:
327
RESOLVE
The following elements need to be specified for each variable:

Name
Unit
Worksheet
Cell
Cascade
DoSet in
forecast from
In this section, the user specifies the name of the variable to publish
In this section, the user specifies the name of the variable to publish
In this section, the user specifies the Excel worksheet where the variable to
publish is located
In this section, the user specifies the Excel cell where the variable to
publish is located
If the variable considered is set to a specific value during the forecast, this
will allow the user to keep track of that variable value by automatically
feeding a column or row in Excel.
The starting cell for the column / row in which the variable value will be
displayed has to be specified.
The Cascade Direction option enables to specify whether the variabel
populates a row (i.e. horizontal cascade) or a column (i.e. vertical
cascade)
User Guide
328
2.9.2.9.4 Optimisation
The link to Excel supports the optimisation functionality implemented in RESOLVE.
This screen the user to setup an objective function, constraint equations, and control variables in
the Excel model.
An example of how this could be used would be if Excel were calculating a quantity that could be
seen as an objective function for the system, for example a calculation of revenue. This is
illustrated in the second of the GAP-Hysys-Optimisation step-by-step examples.
The screen to setup the optimisation components can be accessed by clicking the right mouse
button over the Excel icon in RESOLVE. Alternatively, this can be accessed from the
Optimisation | Setup screen from the main menu of RESOLVE.
329
RESOLVE
User Guide
330
The optimisation setup screen is split into two tabbed sections:

Optimiser
Objective
Function
Constraints
The top part of the first screen allows an objective function to be set up. It is
not obligatory to set an objective function in Excel, although obviously there
should be an objective function somewhere in the coupled system.
To set an objective function, check the box at the top of the screen. The
data fields below this can be entered as shown. In the example above we
are choosing to maximise the value of cell D3 (worksheet Sheet1). The
objective function is "tagged" with a name and a unit for reporting purposes
only
In a similar way, constraints on Excel cell values can be set in the table
below the objective function fields. Up to 100 constraints can be set.
331
RESOLVE
Controls
In the above example, a quantity that represents a water penalty in cell D2

(worksheet "Sheet1") is being constrained to less than 1000.
The name and unit are only for reporting purposes
The second tab allows to setup control variables in Excel, which might be
useful if the spreadsheet is upstream of another module and is feeding that
module with data. In the example above two cells which represent gas rates
are being added to the RESOLVE optimiser. The optimiser will not be
allowed to exceed the range for the control variable set up here: in this case
the range is 0 < Qgas < 5000 (scf/d)
2.9.3 Connections in RESOLVE: Further Details

2.9.3.1 Connection Rules
RESOLVE is an interface allowing disparate applications to be connected together. This
requires a set of rules (or "rule base") to be set down to determine which nodes in the RESOLVE
system can be connected to which other nodes. The rules are very straightforward and logical
and are explained below.
RESOLVE node When a model is loaded into RESOLVE, RESOLVE considers the model
as a black box calculation engine which exposes inputs and outputs (i.e.
descriptions
also referred to as sources and sinks) to the outside world. These sources
and sinks are called "nodes". There are various types of nodes, as
described below, and these types determine the connections that are
possible from one node to another.
Source /
Sink node
- source)
- sink)
Nodes are described as sources or sinks depending on the

direction of fluid flow from upstream to downstream.
For example, a well in GAP can be a sink for a production
well or a source for an injection well.
Some nodes might not be defined as sources of sinks
straightaway: their definition will depend on the nodes they
are connected to.
For instance, a well in a simulator becomes an injector if
connected to an injector in GAP.
Data
A connection between two nodes is denoted by the

icon
In addition to items being described as sources and sinks,
User Guide
providers /
Data
acceptors
332
items can be data providers or data acceptors. This

determines the data flow in a RESOLVE system as
opposed to the fluid flow.
For example, a simulation well will generally be a data
provider, as it generates inflow data that is passed to a
corresponding data acceptor (a GAP well, for example). A
data provider is indicated in the interface by a small dot
above the icon, as illustrated below.
In this case, the well PROD1 will be a source and it will

provide data to the model located downstream this well (i.e.
in this case, the well provides an inflow performance curve
to a surface network model for instance)
Uni-directional / When the RESOLVE system is run, a node is allowed to generate a table of
Bi-Directional
inflow data or a single point of inflow data.
links
In the former case, the data acceptor will calculate an operating point on
the table (i.e. which may or may not be optimised, see the "Schedule
"screen) and that operating point will be returned to the data provider. This
is a bi-directional link.
Nodes that generate tables of data are indicated with a red bar
over the icon
In the latter case, the data transfer is entirely one way from data provider to
data acceptor
Compositional / Each driver that is registered with RESOLVE indicates whether it is able to
Nongenerate EOS data, and also whether it requires EOS data to perform its
Compositional calculations.
For example, a process simulator may require EOS data, whereas GAP
nodes
will be able to provide EOS data while still using black oil calculations
internally. Refer to the "Driver Registration" section for further information
on this subject
In summary, the connection rules are as follows:
The source / sink type must be different between connected nodes: it is not possible to
connect two sources or two sinks together.
Data providers must be linked to data acceptors.
333
RESOLVE
Nodes producing tables of data must be connected to nodes accepting tables of data
(bi-directional).
Nodes producing a single data point must be connected to nodes accepting a single
data point (uni-directional).
Data acceptors that require compositional data for their calculations must be
connected to data providers that can supply compositional data.
2.9.3.2 Models and Loops
This section discuss the particularities or running RESOLVE models containing loops.
In this discussion, a model represents an instance of a system modelled in one specific
application.
An example would be a surface network modelled in GAP.
A loop represents several models that are connected in such a way that there is a circular
dependency.
Consider the following system (the arrows represent the direction of data flow):
Models B, C, and D form a loop where each depends on the other.

When RESOLVE is run it will detect this loop and the system will be effectively reduced to:
User Guide
334
The loop will be treated by RESOLVE as if it were any other model.

When a solve is requested for model A, model A will perform its internal solver calculation.
When a solve is requested for the loop, RESOLVE will iterate around the loop (i.e. starting from a
model that can be selected by the user) solving models B, C, and D in turn until convergence is
achieved on a target variable, which can also be selected by the user.
Loops can be setup from the Run | Edit Loops menu, and the procedure to do so will be
highlighted in the "Loop Edit" screen for more information.
At the end of the loop solve, data will be passed from the loop (models D and C) to the receiving
models E and F.
There is no limit on the number of loops in the RESOLVE system, although nested loops are not
currently supported.
2.9.3.3 Composition Tables
If a RESOLVE system is built which consists of applications which require or generate EOS
compositional data, it is necessary that there is a continuity in the compositional data throughout
the system.
This means that, for example, the composition passed to RESOLVE by one application should
map to the composition required by the connected application: although the component names
can differ, it is very desirable that there should be a one-to-one correspondence between each
component passed between each application.
This is achieved by using a composition table.
335
RESOLVE
When a compositional case is run for the first time, RESOLVE queries all the connected nodes
for their base composition.
It then generates the following screen:

Node
connection
list
RESOLVE
Lumping /
Delumping
This is a list of all the nodes in the RESOLVE system that are connected
together, grouped according to the applications that are connected (e.g. in
the above case, all the connections between REVEAL and GAP are
grouped together).
There is a key at the bottom describing what the symbols mean: the red
cross indicates that no mapping has been made, the green blob indicates
that some components are mapped, whereas a tick indicates that the
mapping is complete. If a model is run while the mapping is not complete,
those components that are not mapped to something will have their mole
fractions set to zero and the composition will be re-normalised as required
Enables the user to specify if the lumping / delumping facility of RESOLVE
is being used.
The options available are:
None
External
The composition is passed from one application to another

without any modification
RESOLVE will lump the composition, that is to say, it will
User Guide
336
Lumping
generate a grouped composition (small number of

components, or lumped composition) from an original one
(large number of components, or delumped composition)
and will pass this lumped composition downstream
External
RESOLVE will delump the composition, that is to say, it will
Delumping generate an extended composition from a grouped one
and will pass this extended composition downstream
Component lists The component lists on the right hand side of the screen list the base
compositions for the two nodes that are highlighted in the node connection
list
Add Individual
To map a component from one list to a component of the other, highlight
the components in the two lists and click this button.
Connection
When the button is pressed the connection appears in the composition
connection list between the component lists
Add All
If the compositions displayed in the two lists already lined-up, then this
button will automatically generate the links between the components
Remove Link
To remove an existing component mapping, highlight the entry in the list
and press this button
Copy to All
If all the connections have the same mapping, it will be possible to copy
one of the mapping that has been done to all the connections using that
button
Once this mapping has been setup it will be saved with the RESOLVE (.rsl) file. This means that
this screen will not be displayed on subsequent runs. If it is needed to edit this mapping before a
run, go to Run | Edit Composition Tables from the main menu.
When the run is carried out, RESOLVE will cross-check the current base compositions of the
client modules against the compositions saved with the file, and will re-display this screen if
necessary.
2.9.3.4 Direct Connections between instances
It is possible in RESOLVE to establish a direct connection between two instances, in order to
automatically pass the value of a specific variable from one application to another: for instance,
this can be useful to pass any variable from GAP to Excel for further calculations in a
spreadsheet.
The example below will illustrate how this option can be used: the oil rate obtained for well34 is
to be passed directly to the cell B3 of the worksheet "Sheet2" in Excel.
The first step will be to publish the variables to be considered by going to Edit System | Import
Application Variables.
The following screen will be displayed, where it is possible to select the variables to publish from
GAP and Excel, as illustrated in the snapshots below:
337
RESOLVE
User Guide
338
The "Edit Variables" button enables to publish specific variables, such as illustrated below for
the Excel variable - Further Information regarding how to publish variables can be found in the "
Publish Application Variables" section.
339
RESOLVE
Once the variables are defined, the two applications can be linked directly using the Edit
System | Link option.
User Guide
340
It is possible to specify which variable is passed from one instance to another by double-clicking
on the arrow icon.
The following screen will be displayed. The setup illustrates how to specify the well 34 oil rate to
be passed from the GAP variable to the Excel one.
It is possible to see that the variable could be modified by using a multiplier and a shift.
By default, the multiplier will be set to 1 and the shift to 0, which will lead to the variable not being
modified.
341
RESOLVE
2.10 "Module Variables" Menu
User Guide
342
2.10.1 "Module Variables" Menu

This section contains menu options that relate to the exporting of variables from the child
applications to RESOLVE. These variables can then be used in the event driven scheduling or
the scenario management, for example.
Import
Application
Variables
Transfer
optimisation/
imported
variables
Allows the user to select specific application variables to be reported in

the RESOLVE results section.
A step by step procedure illustrating how to do so can be found in the "
Publish Application Variables"section
This allows the user to copy variables between optimisation and imported
variable sets. For example, a GAP model may have a control variable, such
as separator pressure, set up which the user would like to use as a simple
reporting (plotting) variable. More information can be found in the "variable
transfer" section
2.10.1.1Import Application Variables

Several RESOLVE options such as specific connections between modules (i.e. Target
Connections, Direct Connections between Instances) or advanced scheduling (i.e. Event Driven
Scheduling, Scenario Management) require some of the variables of the applications connected
to the RESOLVE model to be published in RESOLVE.
This will enable RESOLVE to have access to these variables, either to be able to monitor the
value associated to them or change the value of the variable itself.
In order to publish connected application variables, the following procedure can be followed:
Go to Edit | System | Import Application Variables: The following screen will be displayed.
343
RESOLVE
The screen has a tabbed sub-section for every application in the system that supports the
"publishing" of its variables.
In this case, the GAP production and injection system both allow the exporting of their internal
variables. So does the Excel spreadsheet and reservoir model.
Any variables that are exported from an application will appear in the grid below the tab section.
The following elements can be found in this screen:
Name
Writable?
This is the name of the variable that will be used to refer to the variable in
subsequent operations. This is normally set up by the user when the
variable from the application is published
Variables can be read-only or writable.
An example of a read-only variable might be the result of a calculation in an
application.
A writable variable would normally be an input to an application (e.g. a pipe
User Guide
Unit
Add to Plot
Edit Variables
344
diameter)
This is the unit for the variable, if it has one. Once the variable is set up, the
unit can not be changed
This enables to monitor the variable throughout the production forecast and
add it to the results as a variable that can be plotted
The variables are not actually set up in the above screen but in the screen
that is invoked from this button. The screen displayed is implemented in the
driver and thus depends on the application in question
The screens are documented in the respective sections:
"Publish Application Variables: REVEAL"

"Publish Application Variables: GAP"
"Publish Application Variables: IPM-OS"
"Publish Application Variables: Excel"
"Publish Application Variables: Hysys"
"Publish Application Variables: UniSim Design"
"Publish Application Variables: Eclipse"
When the OK button of this screen is pressed, these variables will be copied into RESOLVE.
The variable publishing screen will then have an appearance similar to the following and will list
for each application all the variables that have been published.
345
RESOLVE
2.10.1.2Transfer optimisation/imported variables

This screen allows variables to be copied between optimisation sets and exported sets.
Optimisation variables are those which are defined under the Optimisation | Setup screen, and
may represent an objective function, a constraint, or a continuous control variable (integer control
variables are not covered in this functionality).
'Exported' variables are set up from the Edit System | Import application variables screen and
are used in the control of the RESOLVE model (through the event driven scheduling or scenario
management) or for reporting.
In some circumstances it may be useful to be able to copy from one set to another. This is
carried out in this screen.
User Guide
346
The module under consideration should be selected from the top of the screen. Only those
modules which support this functionality are displayed. After this, the screen is in two parts:
Exported to
optimisation
Allows the copying of exported variables to the optimised set.

To make a copy, highlight a variable or variables in the list on the left hand
347
RESOLVE
side and select whether they are to be made constraints or control

variables. To make an objective function, only one entry should be selected
as there can be only one objective function defined in each module.
Optimisation to
exported
Note that some variables can not be made into optimisation variables, e.g.
non-continuous variables such as equipment mask states
Allows the copying of optimisation variables into the general exported set.
For the module in question, the set of objective function, constraints, and
control variables is displayed in the left hand list. The required variable
should be highlighted and the arrow pressed to make the copy. Multiple
variables can be copied by selecting the parent item
:.
:.
2.11 "Program Functions" Menu

2.11.1 "Program Functions" Menu
This section enables to access the setup section of every loaded client application, as well as
obtaining a summary of the file paths to which every module refers.
The following sub-sections are available in this menu:
"Module"
Menu
This menu is generated dynamically and shows a list of the loaded clients
applications.
For each client, the following menu options are available:
Change
Label
Edit
Case
This section enables to modify the label of the module considered

This is equivalent to double clicking on the module icon and invokes
the Edit Case scree.
This allows the user to change the case being considered or the
running options associated with the case.
Further information regarding these screens can be found in the
following sections:
Eclipse: "Loading and Editing an Eclipse Case"
GAP: "Loading and Editing a GAP Case"
REVEAL: "Loading and Editing a REVEAL Case"
IPM-OS: "Loading and Editing an IPM-OS Case"
Excel: "Loading and Editing an Excel Case"
Hysys: "Loading and Editing a Hysys Case"
User Guide
Reload
Save
348
UniSim Design: "Loading and Editing an UniSim Design Case"

Broadcasts a message to the client application to reload the case
from scratch into the application
Broadcasts a "save" message to the client application to save the
case.
For drivers that support the RESOLVE optimisation, the following
additional option is available:
Optimiser setup This option brings the user back to the optimisation setup scr
each module.
Please refer to the "Global Optimisation" section for further
information
For drivers that support the use of EOS PVT data, the following
additional option is available:
Do not send /
receive EOS
property data
This is only available when models with compositional data a

considered. These options enable to block the flow of compo
data from or to the module specified
There may be other options available for some drivers - these

depend on the application considered and more details can be
found under the help for that specific application driver - Go to the "
Connection to External Applications - Specific Elements Section" to
access more details on these options
Change
Paths
Show
Project
Paths
This section enables to alter all the paths of all the client applications to one
specific folder
This section enables to display all the paths for all the clients applications
included in the RESOLVE model and their associated files.
It enables as well to select some / all of these files and create an archive file with
them
2.12 "Schedule" Menu

2.12.1 "Schedule" Menu
The schedule section enables the user to specify the run characteristics such as starting date,
end date, timestep length and any other aspects of the scheduling such as conditional
scheduling for instance.
This menu is only available if the "Run Forecast" or "Run Forecast with Global Optimisation"
options have been selected from the "Options" section.
349
RESOLVE
A workflow specifying how to setup a schedule in RESOLVE can be found in the "Schedule
Setup Workflow"section.
These are the commands that can be accessed from the "Schedule" menu:
Forecast
Data
WAG
Event
Driven
Scheduling
section
Enable
Event
Driven
Scheduling
Scenario
Manager
This section enables to access the timestep control screen.

Further information can be found in the "Timestep control"section
This section enables to access the water alternating gas injection scheduling
options.
Further information can be found in the "WAG" section
This section is divided in three sub-sections (i.e. Publish application variables,
Event driven scheduling and Enable event driven scheduling) and enables to
access the event management facility of RESOLVE.
This event management enables to trigger certain events such as opening /
closing a pipeline, re-routing a well to a lower pressure separator train or
masking a well based on the evolution of user-defined variables.
This can be used to design drilling schedules for instance.
Further information regarding the use of this event management facility can be
found in the "Event driven scheduling" section
This enables the application of Event Driven Scheduling at the beginning of the
run (Start), at the beginning of each step (Pre-Solve) and at the end of each step
(Post-Solve)
This section enables to access the scenario manager facility of RESOLVE.
This scenario management facility enables to setup different scenarios /
appraisal runs and to select which ones to run, compare the results, etc...
Further information regarding the use of this scenario manager facility can be
found in the "Scenario manager" section
2.12.2 Schedule Setup Workflow

RESOLVE can be set up to run in a standalone "single-solve" mode or in "forecast" mode as
described in the "Options" section.
In the forecast mode, time dependent data is passed between time dependent modules (e.g.
reservoir simulators, MBAL models, etc...) and timestepping is performed.
In cases such as these it is very common to require scheduling of the run to be performed.
This scheduling can vary considerably in its complexity, from simply requiring a simulator well to
be opened at a certain date to the implementation of drilling queues and conditional actions.
User Guide
350
The workflow for setting up a schedule in RESOLVE is as follows:

Step 1
Step 2
The basic schedule is entered from the Schedule | Forecast Data menu item.
Here the start and end date of the run are entered as well as the timestepping
model; this could be a simple timestepping or an adaptive mode. Refer to the "
Timestep Control Setup" section for further information.
If the start date entered is before the start date of any of the client applications,
these applications will be started during the run as part of the RESOLVE
schedule.
For example, if the RESOLVE forecast starts on 01/01/2000 and a reservoir
simulator is not due to start until 01/01/2001, then RESOLVE will automatically
close all the simulator wells for the first year of the forecast
The schedule control type has to be selected: three possibilities to control the
schedule are offered:
Schedule
The scheduling can be left up to the individual applications
specified in the and have no scheduling at all in RESOLVE.
clients modules - In this case, RESOLVE will attempt to honour any
No schedule in scheduling in the client applications, for example by
synchronising a timestep at the date at which an event
RESOLVE
occurs. However, this has the disadvantage that it can be
quite hard to follow what is going on as the run proceeds;
to get information on events one would normally have to go
into the applications in question. Also the question arises
as to what happens if two applications have perhaps
contradictory events occurring at the same time - who
controls the forecast?
In general, this approach is NOT RECOMMENDED unless
the scheduling is very simple, and ideally any schedules
that are in the applications should be removed when
connecting to RESOLVE
No Schedule in One can use RESOLVE"s built in event management
the clients
system. The advantage of this is that RESOLVE "sees" the
modules entire system and so can make decisions on global data
Schedule setup rather than single-application data. RESOLVE allows
variables to be queried from any of the applications in the
in RESOLVE
system: conditions upon which a modification will be
performed in one model can be specified using these
published variables.
For example, one can choose to perform an action based
on the current value of a well GOR.
No Schedule in
The different options related to this type of setup are

described in the "Event Driven Scheduling" section
For situations where the user would like to implement a
351
RESOLVE
the clients
modules - No
Schedule in
RESOLVE Schedule setup
through user
defined SCRIPT
very complex logic that falls outside of the capabilities

of the first two options, it is possible to write a "Script".
To use this facility, a basic knowledge of Visual Basic
and programming will be required. The "Example 2.2"
illustrates for instance the usage of a script in RESOLVE
2.12.3 Timestep Control

2.12.3.1Timestep Control Setup
In a RESOLVE system, RESOLVE is the master controller and all the attached client modules are
slaves of the RESOLVE process.
As such, RESOLVE coordinates the timesteps of the time-dependent applications and ensures
that the applications are appropriately synchronised.
Refer to the "How does RESOLVE works" section for more information.
The RESOLVE timestep lengths (i.e. the times between synchronisation of the modules) are set
from the following screen:
User Guide
352
The following sections can be found in that screen:

Global
Options
This section enables to enter a start date for the RESOLVE run.
This start date can be selected from the client modules (i.e. if they are time
dependent) by clicking the Select from client modules button. This brings up
a list of client modules with their respective start dates, as illustrated below.
353
RESOLVE
Schedules
Timestep
setup
There is also the option to offset an entire schedule list by clicking the Offset
schedule list button and entering a new start date: all the schedule records in
the list will then be offset appropriately
On the left hand side is a list of schedules that run concurrently when a
prediction is performed.
The buttons at the bottom of the list allow schedule records to be added,
removed and inserted, or the entire list can be cleared.
When a schedule in the list is highlighted, that schedule timing and duration is
displayed on the right hand side of the screen
This section enables to select the type of timestep used during the prediction
run, with the following options being available:
Timestep
mode
Schedule
end date
Timestep
This can be fixed, in which case the timesteps are of fixed

size and do not change with the prediction, or adaptive, in
which case timesteps will vary depending on the
performance of the system.
The adaptive timestep option is described in details in the "
Adaptive timestep" section
This is the date of the end of the schedule record
considered, and the start date of the record that follows.
RESOLVE will ensure that the client modules are
synchronised at this date, and will put in extra timesteps if
necessary
For the fixed timestep mode, this is the length of the uniform
User Guide
Length /
Initial
timestep
Individual
Application"s
Optimisations
Debug
Information
354
timestep.
For the adaptive timestep mode, this is the length of the
initial timestep. This should be set to a fairly small value to
allow RESOLVE to increase the timestep length if it is
appropriate to do so
For bi-directional links (e.g. the links between simulators and GAP where GAP
is returning operating data to the simulator) the option exists to make GAP
optimise at every timestep, or at a fixed interval, or not at all
If an adaptive timestep mode is selected, then debug messages will be written
to the log window during a prediction run. These messages will display how the
timesteps have been calculated (see the "Adaptive timestep section" for
additional information)
2.12.3.2Adaptive Timestep
The dynamic link between client applications established through RESOLVE is an explicit link: it
basically calculates the performance of the system at one specific point in time, and then
assumes that this system performance will remain constant over the length of the RESOLVE
timestep. This is achieved for instance for a reservoir simulation / surface network link by fixing
either the production rate, wellhead pressure (i.e. WHP) or bottom hole flowing pressure (i.e.
BHP) of the wells during the length of the prediction timestep.
This explicitness can lead to potential errors in the understanding and modelling of the system: if
for instance large changes in GOR occur between two RESOLVE timesteps, the influence of
these variations can only be captured at the end of the next fixed RESOLVE timestep.
The adaptive timestep option enables to monitor for each connected pair of client modules the
change in an user-defined variable between timesteps.
The RMS (i.e. Root Mean Square) variation over all the connections is then calculated.
A timestep multiplier is then calculated using the following relationship:
multiplier = RMS(target) / RMS(calc)
The multiplier is constrained within the limits set on the screen below.
The resulting timestep is obtained by multiplying the previous timestep with:
the multiplier IF the multiplier calculated is higher than 1 - The timestep length is then
increased.
the square-root of the multiplier IF the multiplier calculated is lower than 1 - The
timestep length is then decreased.
The timestep length is also constrained within the limits on the screen below.
355
RESOLVE
This therefore enables to increase the length of the timestep if the system is stable and
decrease the length of the timestep if the system is rapidly evolving, enabling to reduce
the potential explicitness error.
A couple of additional elements need to be considered:
If RESOLVE is forced to synchronise with an event which occurs in a client module or by
the end of a schedule record, the adaptive timestep data will be cleared and the
timestep sizes will start again from the initial timestep.
If there is more than one module connection, the smallest multiplier over all connections
will be used.
If the adaptive timestep mode is chosen within the "Timestep control setup screen", the adaptive
timestep options button will be available, and will lead to the following screen:
The following sections can be found in this screen:

Maximum and
Minimum
Timesteps
Timestep
Growth
Multipliers
The adaptive timestep scheme will not allow the timestep to vary outside
these limits
The adaptive timestep scheme calculates a multiplier on the previous
timestep when it calculates a new timestep.
These options forces the multiplier to be set within the limits specified.
The closed connection penalty enables to apply a penalty to the timestep
multiplier for wells that are closed (i.e. no THP is available in those case for
instance).
User Guide
Per-Module
Data
356
A value of 0 will ensure that no penalty is applied, whereas a value of 1 will

apply a relatively large penalty
The variable that is to be monitored by the adaptive scheme and its target
RMS value are set for each module link in the table on the right.
Note that the flowing wellhead pressure (i.e. THP) option is only available if
making a connection to GAP
2.12.4 WAG
RESOLVE includes an option enabling to setup Water Alternating Gas injection schemes.
This option will only be available with clients modules that allow the modification of a well type (i.
e. from water to gas injector and vice-versa) during the prediction run. In order to know whether a
client module allows this type of scheduling, refer to the "Driver Registration" section.
The WAG option enables to define injection sub-cycles within the overall RESOLVE schedule.
In order to set these, the following screen can be used:
357
RESOLVE
The WAG schedule screen includes the following options:

WAG Groups When defining a WAG schedule, the first step to take will be to define a WAG
group.
This can be done by clicking on "Add" in the WAG schedule screen. Once this
is done, dialog box will appear enabling the user to specify a label for the WAG
group.
User Guide
358
The user can define as many WAG groups as required: each WAG group will
have its own scheduling.
WAG
Connections
Once a WAG group has been created, it will be possible to define the injection
schedule for this specific group. This can be done in the WAG connections
section described below
Once a WAG group has been defined, the following screen will be displayed.
359
RESOLVE
The options available on this screen are as follows:

Possible
This section list the potential connections that are available for
WAG scheduling.
WAG
Connections In the case considered, the connection between the
Reservoir1 and the Water Injection surface network model is
available for WAG scheduling.
The user has to choose which connection has to be included
in the WAG group considered
Cycle List
Once the connection to which the WAG group refers to has
been specified, it will be possible to define injection cycles (i.
User Guide
360
e. injection schedules) for this group. All the injection cycles

defined will be listed in the "Cycle List" section.
The user can add or delete a specific cycle by using the "Add"
and "Delete" buttons at the bottom of the screen.
For each of these injection cycles, the user can define the
following dataset:
Phase
Ordering
Item to Constrain
Water and Gas

Constraints
Water and Gas
Sub-Cycle
End Date
This radio buttons enable to specify whether the WA

cycle defined starts by a water injection or a gas inj
period
The item to constrain drop-down box enables the us
select from the different nodes present in the injecti
system considered, which one is going to be assign
maximum injection constraints.
This will generally be the injection manifold
This enable to define the maximum water and gas i
rates at one particular point in time during the WAG
This enable to define, for each WAG cycle, the leng
the water injection period and the length of the gas
injection period.
The length of each one of these injection periods ca
either be defined directly by duration OR by specify
total volume of fluid to be injected before changing t
injection phase
The end date section enables to specify the end da
the WAG cycle considered
Each WAG cycle is defined within the main RESOLVE schedule cy

when setting-up a WAG model, it is therefore required to setup the
RESOLVE schedule and then to setup the WAG cycle schedule
361
RESOLVE
2.12.5 Event Management

2.12.5.1Event Management Overview
The event management system in RESOLVE is used to implement relatively complex schedules
in a transparent, user-friendly manner.
These relatively complex schedules can for instance contain conditional events based on a IF...
THEN... structure.
Prior to IPM #5 it was necessary to write Visual Basic scripts to handle such situations. For
some very complex logic this is still sometimes necessary, but to handle many of these
situations in a more user-friendly manner an event management system has been implemented.
There are two stages in setting up an event driven schedule:
The variables that are required for the schedule have first to be published, or exported,
from the client applications.
This might include a GOR from a well in GAP, a compressor power from a plant model
(Hysys / UniSim Design), or a value from an Excel spreadsheet.
See the "Publish Application Variables" section to obtain further information on how this
can be achieved.
The variables published are then used to set up conditional "Events and actions" to
perform when these events are triggered.
In the sections that follow, we consider the system shown below.
It is a REVEAL reservoir simulator model coupled to a GAP production and injection system.
The logic will be the same, however, for any reservoir simulator (or indeed any other application)
that is used.
User Guide
362
The RESOLVE event management system has the following capabilities.

Variables from any of the client applications can be "published" or exported to
RESOLVE to be used in the scheduling. For example, it is possible to pick up well
GORs and water cuts from a GAP model and expose these in RESOLVE for the
purposes of the event management.
Once the variables have been published they can be used to set up conditions of the
form: "IF <variable> <condition> <value>". Up to ten of these conditions can be
AND"ed or OR"d together to form a single condition.
In the event that the condition is triggered (e.g. the oil rate falls below the plateau rate
threshold), actions can be set up. These can be for instance to change the value of a
variable or close a connection in the RESOLVE system.
These actions can also be "ranked" by assigning previously exported variables to each
action. It is then possible to, for example, close a well with the "worst" water cut.
363
RESOLVE
The conditions can be executed as many times as required. Usually, a condition will be
executed just once before being discarded, but it is possible to keep a condition active
for several calls and perform different actions every time it is triggered.
The mechanics of setting up an event management system in RESOLVE are dealt with under the
Schedule | Event Driven Scheduling section.
2.12.5.2Event driven scheduling
2.12.5.2.1 Event Driven Scheduling Overview
This is the second stage of implementing an event management system in RESOLVE.
Variables have to be published from clients applications prior to using this event driven
scheduling section.
This procedure is described in the "Publish Application Variables" section.
To start using the tool invoke Schedule | Event driven scheduling.
The screen appears as follows:
In simple terms, the screen allows the setting up of many conditions (i.e. which can be
aggregated together with AND or OR statements to form a single condition), such that when a
condition is "triggered" an action or several actions will be performed.
A condition is a statement of the form: "IF <variable> <condition> <value>"
The condition can be checked by RESOLVE prior to solving the system (i.e. Pre-solve), after
User Guide
364
solving the system (i.e. Post-solve), or at the start of the run (i.e. Start).
This can be specified by using the schedule section at the top of the screen.
When setting up a condition, it is best to work from left to right across the screen.
The sections indicated are as follows:
Condition 1,
LHS
Condition 1,
RHS
This is the left hand side of the first condition (i.e. the <variable> section).
When one of these cells is prompted, a drop down list appears with all the
variables that can be used as part of a condition.
This includes those variables that were published in the previous step as well
as permanent variables which are present in any RESOLVE forecast, such as
the timestep count.
The permanent variables are described below.
When a variable is selected the unit of the variable will appear in the "Unit"
column
This is the right hand side of the first condition (<value>).
When one of these cells is prompted, a drop down list appears containing all
the variables with the same unit as the variable selected for the LHS.
One of these variables can be selected to form the RHS.
Alternatively a value can be typed in directly.
Also, simple arithmetic expressions can be defined. For example, any of the
following are allowed entries in the right hand side assuming that the LHS has
a variable with units for GOR:
Well2:GOR
Well2:GOR + 200
Well2:GOR / 2
Well2:GOR + Well3:GOR
It is important to note that when defining the RHS with simple arithmetic
expressions, the RHS should NOT be defined in parenthesis. If the
parenthesis are defined, then this will lead to a validation flag raised when
exiting from the screen as shown below:
365
RESOLVE
Condition 1,
<condition>
Additional
conditions
Action
Times to
execute
Four conditions are implemented: less than (<), greater than (>), equal to (=),
and not equal to (<>)
Having set up a single condition, it is possible to AND or OR additional
conditions to this to form an aggregated, single condition.
If one select AND or OR from here, the second condition rows will be enabled
The action button opens the "Action screen", in which the action to perform
when the condition is executed is defined. The button will be highlighted in
green if an action has already been defined
Normally a condition will be triggered once and then discarded, not to be
executed again. This is the default case, as shown. If required, this can be
changed such that a condition can trigger several times. This implements a
logic such as: every time the production falls below a threshold (e.g. up to 10
times, say) perform an action (e.g. bring on a well). An example of this is given
in the "Event Driven Scheduling - Example" section
RESOLVE permanent variables

As well as the variables that are published through the RESOLVE interface, there are certain
variables that are always present when a forecast is performed.
These are as follows:
Time
Timestep
Date
The time since the start of the run in days

The timestep number; if the first solve is being executed the value will be "1"
The date in the RESOLVE forecast, in a format that is consistent with the
international settings of the machine used
T1 -> T200
User Guide
(For both
Pre and
Post-Solve)
Cond1 ->
Cond200
(For both
Pre and
Post-Solve)
366
The time at which conditions 1 to 200 are triggered.

As an example, this allows to force an event to take place at a certain time
after another event has taken place, if the time at which the first event is to take
place is not known at the start of the run.
This would be set up as follows:
Condition 1: if GOR > 1000 then close well A
Condition 2: if time = T1 + 40 then close well B
This will close well B exactly 40 days after well A is closed due to the GOR
limit.
If a condition has not been executed, the time variable Tn will be set to a large
value (3.4e35). To determine in the logic if a condition has taken place, used
the "Cond" variables described below. If a condition has triggered more than
once, the variable will be set to the time that it was last triggered
These are integer variables that specify how many times a condition has been
triggered
Examples
The following example entry forces an event to take place only after the previous condition has
been respected for a specific number of time:
This would be set up as follows:
Condition 1: if GOR > 1000 then close well A
Condition 2: if GOR > 1500 and Cond1 = 1 then close well B
This will close well B when the GOR is higher than 1500 and the first condition has been
respected (i.e. well A has been closed).
An example of using the Event Driven Scheduling can be found here.
2.12.5.2.2 Event actions

The event action is the action that is performed when a condition has been triggered.
367
RESOLVE
The conditions are set up on the "Event driven scheduling" screen.

When the Action button for a condition is pressed, the following screen is presented:
The screen is split into two main parts:

Change
variables
This section enables to modify the values of variables as long as they are
writable.
In the above example,the first action specifies that the mask state of Well1
should be changed to "1", i.e. the well is to be closed (masked).
Note that expressions can be entered here: the second action is asking that
User Guide
Open/shut
connections
368
the gas rate constraint for well 3 should be the gas rate constraint for well 4,
plus 10 MMscf/day
Here, individual connections can be closed or opened.
The two client models are selected from the drop down lists in the first two
columns and then the required connection in the third column.
Finally, the status of the connection (i.e. close / open) has to be selected.
In the case of the reservoir simulator - surface network coupling model, closing
a connection is equivalent to closing or shutting a well
The following additional options are available at the bottom of the screen:
Re-take pass If this option is checked, then RESOLVE will iterate at the current timestep after
through
performing the actions set up in this screen, rather than proceeding to the next
timestep immediately.
system...
This has the advantage of avoiding a "hole" in the plateau rate for instance
when specifying that a well has to be opened when the production falls below
plateau: if this option is selected, as soon as the production falls below
plateau, the well will be open and the timestep at which the drop of production
had first be observed will be re-run, with the new well being activated
...and force a If this is checked as well as the above option, then a full RESOLVE
RESOLVE
optimisation will be performed with the new settings
optimisation
Set system
If a system state has been saved (e.g. from the optimisation results screen)
then the drop down list will be populated with available states. If a selection is
state
made, then when the action is performed the state will be applied to the
system. This might be, for example, the results of a previously performed
routing optimisation.
Note that, as the screen says, the change is made before other changes on
the action screen are applied. This could mean that variables relating to the
set state will be overwritten by other variable changes
Rank actions
This allows specifying a ranking scheme for the actions set up on this screen.
See "Ranking of event actions" for more information
2.12.5.2.2.1 Ranking of event actions
This screen allows to conditionally perform actions by ranking them according to an additional
variable.
The actions should have already been set up in the "Event actions"screen, and the variables
have all been published as described in the "Publish Application Variables" section.
The screen is invoked from the "Event actions" screen and has the following appearance:
369
RESOLVE
The list at the top of the screen is a list of those actions that were defined in the previous screen.
From this list one can select those actions that are to be performed based on a ranking. After
they have been selected then click on the Add button.
The actions to be ranked will appear in the lower section of the screen.
User Guide
370
Those actions that are not selected for ranking will not then be conditional, i.e. they will always
be performed.
After the actions have been added to the lower list, for each action one must select a ranking
variable from the drop down list of the second column.
In the above example, the closure of each well is ranked according to the GOR of the well.
No check is made that the ranking variables are of consistent type (e.g. if quantities are
represented in different units), so care should be taken when setting this up.
By default, the one action with the highest value of the ranking variable will be executed. The
order to execute actions option can be used to invert this. In the case considered, if the "Highest
First" option is selected, the well with the highest GOR of the two wells at the time the condition
is triggered will be the first one of the two wells to be closed.
If the "Lowest First" option is selected, the well with the lowest GOR os the two wells at the time
the condition is triggered will be the first one of the two wells to be closed.
It is possible to make more than one action execute by changing the Count setting: if the count
setting is set to 2, then the two first ranked actions will be executed as soon as the condition is
triggered.
2.12.5.2.3 Event driven scheduling - example

This example will use the event driven scheduling tool described in the previous section.
Although it is not necessarily physically realistic in itself, it highlights many of the capabilities of
the model.
We will use the system described previously and perform the following actions:
When the total oil rate falls below 200,000 STB/d, close all the production wells
35 days after this, open all the wells again
At least 40 days after this, and if the overall GOR exceeds 1,500scf/STB, close
the well with the worst (highest) GOR
At a given date, open up all the wells again
30 days later, close all the connections, starting with the highest GOR well and
finishing with the lowest.
For this example, the event driven scheduling screen will have the following appearance:
371
RESOLVE
Action 1 - When Sep1:OilRate < 200000 STB/day
Action 2 - 35 days after the first condition is triggered
User Guide
372
Action 3 - At least 40 days after the second action if the overall GOR > 1500 scf/STB
Note here that the wells are closed by closing the connections in RESOLVE. This is equivalent to
masking the wells in GAP as was done in the previous actions.
373
RESOLVE
Action 3 - Ranking variables
Action 4 - Open all the wells on 1/6/2003
User Guide
Action 5 - Close all the connections in order of GOR
Action 5 - Ranking variables
374
375
RESOLVE
After the run is complete, the events tab of the log window has the following appearance,
showing the sequence of event that was performed during the RESOLVE forecast:
User Guide
376
2.12.6 Scenario Manager

2.12.6.1Scenario Manager Overview
The scenario manager facility of RESOLVE enables to setup and keep in memory different
scenarios.
This is a very powerful feature of RESOLVE: the scenarios stored here can be submitted to a
cluster for parallel, batch processing. This allows many scenarios to be evaluated at once and
opens the door to other tools (e.g. IFM) to run probabilistic forecasts on coupled models through
RESOLVE.
377
RESOLVE
More information on batch processing with clusters can be found in the "Running Scenarios on a
Windows cluster".
These scenarios can be setup using the event driven scheduling options. One of the main
advantages of using this option will be to be able to rapidly pass from one scenario to another
without having to re-enter all the event driven scheduling data. Moreover, each scenario set of
results will be saved separately, as described in the results section. It will then be made possible
to directly compare results from different scenarios.
When selecting the Schedule | Scenario Manager option from the main RESOLVE menu, the
following screen will be displayed.
The screen is divided in two sections:

Scenario List This section lists all the scenarios setup by the user.
The buttons at the bottom of this section enable to manage the scenarios by
using the Edit / Delete and Clear buttons for instance
Current event This section includes the details of the scenario that is currently activated in
the main RESOLVE schedule section
driven
User Guide
schedule
378
One specific scenario can be passed from the scenario list to the current
event driven schedule by using the Set as current scenario button
In order to setup scenarios, one can refer to the following sections:

"Adding a scenario"
"Editing a scenario"
"Deleting a scenario / clearing the scenario list"
2.12.6.2Adding a scenario
From the "Scenario management" screen, there are three ways of creating a new scenario:
Add an empty
scenario
This will pop up a screen which allows a label for the new scenario to be
entered (by default, the label will be "scenario n"). The scenario that is
created will have no data; in other words, if it is run, the basic model will be
run with no event driven scheduling
Add a copied
The scenario to be copied should be highlighted in the scenario list. After
the "Add copied scenario" button is pressed a screen will be popped up to
scenario
allow the new scenario to be labeled. The resulting scenario will be an
exact copy of the original scenario
Add the current This will copy the current event driven schedule into the scenario manager,
again allowing the new scenario label to be set up first
schedule
However a scenario is generated, it will normally be necessary to "Edit". the scenario data.
2.12.6.3Editing a scenario
From the "Scenario management" screen, a particular scenario can be edited by highlighting
the entry in the scenario list and then clicking on "Edit".
This invokes the "Event driven scheduling" screen for the scenario in question. This screen can
then be used to define the scenario in exactly the same way it was used to generate a standalone forecast.
The event driven scheduling screen is different to the screen used to enter the schedule data for
a single run. This difference is the existence of the "Pre-load actions" button.
The use of this is explained under the scenario example dealing with "Changing global model
data".
379
RESOLVE
2.12.6.4Deleting a scenario
From the "Scenario management" screen, individual scenarios can be deleted or entire
scenario lists can be cleared.
To delete an individual scenario, the entry in the scenario list should be highlighted and the "
Delete" button pressed.
To clear the entire scenario list, the "Clear" button should be pressed.
2.12.6.5Scenario examples
This section includes three examples to illustrate different applications of the scenario
management in RESOLVE.
Basic
This illustrates how to change a single variable in one of the client

application models
Changing global This illustrates how to use different model files (i.e. "realisations") for
different scenario runs
model data
Changing a
This illustrates how to run different scripts with different scenarios
script
2.12.6.5.1 Basic
This is a very simple example. The idea is to set up two scenarios in which GAP is run with two
different separator pressures - 100 psig and 150 psig.
First of all, the GAP separator pressure variable would need to be published into RESOLVE See the "Published Application Variables" section to obtain further information on how to do so.
From the scenario management screen, the new scenarios should be generated by clicking the
"Add Empty Scenario" button twice. The scenarios can be given logical labels, e.g. "100psig"
and "150psig":
User Guide
380
One of these should then be highlighted, and the "Edit" button clicked. The event driven
scheduling screen opens by default in the "Post-Solve" section. These are the directives which
are executed after the entire system is solved (i.e. at each timestep, if it is a forecast model).
In this case, the separator pressure is to be set at the beginning and retained for the entire run.
Switch to the "Start" schedule at the top of the screen (i.e. these are directives which are
executed only once at the start of the run). There is no condition for the separator pressure
change; in this case it is always required.
To indicate this to RESOLVE enter the condition <if timestep = 0> as shown.
Click on the corresponding action button, and enter the action to change the separator pressure
as shown below:
381
RESOLVE
This screen can then be OK"d. The "Action" button of the parent screen should appear
highlighted to indicate that the action has been set. This screen can also be OK"d.
The procedure can then be repeated for the other scenario for the other pressure.
An alternative way to do this would be to generate the first scenario (as above) and then copy
this scenario. The copied scenario could then be edited, and only a single edit (the value of the
separator pressure) would be required to create the new scenario.
2.12.6.5.2 Changing global model data (e.g. model files)
It is sometimes necessary to make large changes to RESOLVE models to be applied in different
scenarios. It is not always possible to accomplish this simply by the dynamic changing of internal
application model variables.
An example of this is the situation where it is necessary to completely change the GAP model
file to a different realisation of the model.
This can be accomplished as follows. A new scenario should be created (as in the "Basic"
example) and edited.
The event driven scheduling screen contains a button labeled "Pre-load actions".
Clicking on this yields the following screen:
User Guide
382
The grid consists of two columns.

The left hand column contains a list of RESOLVE OpenServer variables that can be set by the
user. In the above example, the OpenServer variable corresponds to the GAP model filename.
The right hand column contains a list of the values of the variables.
As soon as the set of models used in the RESOLVE project is reloaded to run one specific
scenario, then the changes specified in this screen through the use of OpenServer variables will
be performed, therefore changing the setup of the models considered before the scenario is run.
383
RESOLVE
The variables are set just before the models are loaded into RESOLVE, and so in this case the
GAP file will be switched from the one saved with the RESOLVE file to the one shown above.
If the runs are sequential (i.e. one following the other, not distributed on a cluster) it may be
necessary to ensure that model(s) are reloaded after the changes in the table are applied. This
step is performed by highlighting the models of interest in the list at the bottom of the screen.
Note that any RESOLVE OpenServer variable can be used here. This feature should be used
with care: clearly, the new GAP model should expose the same sources and sinks as the one
that it replaced.
2.12.6.5.3 Changing a script
It is sometimes necessary to run different RESOLVE scripts, or different versions of scripts, for
different scenarios.
It is not possible to dynamically load different scripts into the model from the scenario manager.
However, the following procedure can be applied to accomplish the same thing.
Consider a case where scenario1 is to execute one script and scenario2 is to execute another.
This can be implemented in a single script as follows:
if (scenario_variable = 1) then
" do code for scenario 1
else
end if
end if
It is then only necessary to create the variable "scenario_variable", which can be set by the
scenario manager, and which can be read by the script.
This can be done with the use of dummy variables. Excel is a useful repository of these, although
there is no reason why unused GAP variables (i.e. in dummy pieces of equipment) can not be
used.
Assuming that Excel is to be used, the following actions can be performed.
Create an Excel Double-click on the icon and OK the resulting screen to activate the Excel
User Guide
384
icon in the
application. There is no need to connect the Excel sources and sinks to
RESOLVE model anything, and there is no need for the Excel model to point to a named
Excel file. For clarity, the Excel model can be given a label such as
"dummy"
The scenario
variable must be
published from
Excel, i.e.
It is not important which cell is used here.

The value of the ("scenario", above) is set at the start of the event driven schedule for the
scenario
scenario:
variable
385
RESOLVE
The value of this This can be achieved by using the following RESOLVE OpenServer string:
variable can be
Resolve.Module[{dummy}].PubVar[{scenario}].value.
interrogated in
The script code then becomes:
the script
scenario_variable
[{scenario}].value"))
cint(DoGet("Resolve.Module[{dummy}].PubVar
else
end if
end if
2.13 "Optimisation" menu

2.13.1 RESOLVE Optimisation : Overview
Several applications that might be used in a RESOLVE model contain an in-built optimisation
capability.
For example, GAP has an extremely powerful SQP (i.e. Sequential Quadratic Programming)
optimiser that allows optimisation to be performed on an objective function while obeying
constraints by adjusting controls that can be set at any level of the system.
User Guide
386
It is assumed in the discussion below that GAP is part of the RESOLVE system, although this is
not necessary to use the RESOLVE optimiser.
The optimiser in RESOLVE takes the optimisation concept further by allowing
constraints, controls, and objective functions to be taken from different systems
modeled in different applications.
For example, consider the case below in which REVEAL (reservoir simulator) is connected to
GAP (surface network model) which in turn is connected to Hysys (plant model).
As the labels suggest, the reservoir simulator provides time dependent reservoir data to the
system. The GAP model contains items which can be controlled (i.e. for example, gas-lift
quantities or wellhead chokes) to optimise on a user-defined objective function. The GAP model
can also contain constraints, for example a water handling constraint at the separator.
If the objective function is to maximise oil rate at the output of the GAP model then the
optimiser in GAP is sufficient for this.
Alternatively, the system as a whole could be constrained by items in the plant, or it may be
important to maximise a quantity at the exit of the plant model.
In this case an external optimiser is required, as these constraints / control parameters cannot
be accessed by the GAP internal optimiser.
387
RESOLVE
2.13.2 RESOLVE Optimisation: Sequential Linear Programming

Sequential linear programming
The optimiser in RESOLVE uses a technique called sequential linear programming (SLP).
This is in contrast to the optimiser in GAP, which is quadratic (SQP) at its core although the
overall algorithm is more complex and is best described under the umbrella term NLP.
Generally, the GAP optimiser will be used to provide starting points to the RESOLVE optimiser,
and for this reason it is useful to have consistent constraints in GAP and RESOLVE.
When RESOLVE performs an optimisation, it starts by making a single "pass" through the
system which may include a GAP optimisation to provide the starting point. After this, linear
equations to describe the system response with respect to the objective function and constraint
equations will be derived by perturbing each of the control variables in turn. A linear optimiser
will then be run on the resulting set of linear equations to obtain a proposed new optimum. In this
optimisation, the controls are bound within appropriate limits to allow for the non-linearity of the
system.
The values for the controls so obtained will then be inserted back into the system. The process
will be repeated over several iterations until convergence between two iterations is achieved. At
each iteration of the optimiser the bounds for the control variables will be adjusted to reflect the
"linearity" of the system.
For more information on the optimisation algorithm, contact Petroleum Experts.
2.13.2.1Troubleshooting
The SLP optimiser is obviously most suited to mostly linear or slightly non-linear systems, but the
sequential nature means that it can handle systems that tend towards the more non-linear. The
optimiser is configurable through the parameters that can be changed on the "Optimisation
summary"screen. In general the defaults provided should be adequate and the optimiser should
adapt to the different systems; nevertheless there may be cases where the performance can be
significantly improved by changing the settings.
One can observe the performance of the optimiser as the results of the successive iterations are
displayed on the optimiser results view when an optimisation is run.
The control results and the function results tabs yield the most information.
The following elements can provide some assistance when analysing the performance of the
optimiser:
The optimiser
This can mean:
iterations are
That the bounds of the control variables at each iteration are too large
and the system is too sensitive to such changes of the control variables.
oscillating on the
User Guide
388
function results
After a few iterations the optimiser should automatically reduce the

bounds, but it might be a good idea to start with reduced bounds for the
control variables; to do this go to the "Edit optimiser control variables
"screen.
That the system has a high degree of non-linearity. Cross-terms in the
system response between control variables are not accounted for in the
linear optimiser and, if these terms are strong this might lead to large
errors in the response predicted from the optimiser compared to the
real system response. Again the optimiser should reduce the bounds
automatically, but it might be a good idea to start with smaller control
bounds
Convergence is One should check the control results tab to see how rapidly the control
variables are changing at each iteration. If the changes are small then the
very slow
optimiser has reduced the control bounds in response to system nonlinearity and then these bounds have not recovered as the bounded
searched region has become more linear. This can be fixed by increasing
the "linear criterion (say 0.05 -> 0.1) or increasing the minimum step growth
(say 0.5 -> 0.8) to prevent the optimiser from reducing the bounds so much
The optimiser is If the optimiser is attempting to increase the objective function and the
actual system response is to reduce the objective function then it is likely
being sent the
that the derivatives are not very reliable. This may be due to the size of the
wrong way
perturbation being taken by RESOLVE to obtain the linear derivatives. One
should check the typical perturbation sizes in the "Edit optimiser control
variables" screen. Some controls, notably wellhead chokes and separator
pressures in GAP, are supplied with good defaults but in general RESOLVE
does not know anything about the control and so is unable to provide a
good perturbation without some user guidance. Also, one might want to
consider using centre perturbation in the control variables
2.13.3 RESOLVE Optimisation: GIRO

2.13.3.1Introduction
Introduction to GIRO
GIRO is designed to solve optimisation problems which involve Integer Variables.
One of the most common problems of this type in Oil/Gas Fields is presented in cases where
Wells/Manifolds Routing opportunities exist. While not limited to them, this type of problems is
what GIRO has been specifically designed for.
Most of the Optimisation problems involving Routing opportunities will also contain continuous
variables (Choke opening, Gas Lift Gas Injection, etc..) as well as multiple constraints. This puts
them into the category of Mixed Integer Optimisation Problems. Considering that most of the
Production Systems have a non-linear response and that the imposed constraints make the
389
RESOLVE
problems non-convex, we are usually dealing with Mixed Integer Non-Convex Non-Linear
Optimisation Problems, one of the most complex optimisation problems to solve.
Due to their complexity, attempts to solve this type of problems (MINLP) directly (using one
single algorithm) have been unsuccessful (extremely limited at their best). This is no surprise
when considering that solving non-convex, non-linear optimisation problems (without including
the integer variables/routing) is already extremely challenging (in particular when dealing with
real physical systems not described by simple mathematical functions).
This is why MINLP are best approached by dividing the problem into two, having a Non-Linear
optimiser dealing with the continuous variables and constraints (for each case we want to
evaluate) while having an Integer Optimiser dealing with the global search of the optimum
routing.
This is the approach followed in IPM where GIRO can be combined with GAPs powerful NonLinear Optimiser to tackle Mixed Integer non-convex non-linear Optimisation problems. GIRO
will then take care of the global search (routing) while GAP takes care of solving every sub
problem generated by each routing case requiring evaluation.
Having GIRO at the RESOLVE level allows also having more than GAP as underlying
application. We can have multiple applications making up the underlying model GIRO will be
evaluating. Moreover, we can also use RESOLVE SLP optimiser underneath GIRO, creating
three levels of optimisation.
GIRO is based on Genetic Algorithm (GA) principles, with the critical addition of a X-Over
Optimisation Algorithm (XOOA) to overcome the main limitation of traditional GAs when applied
to Oil/Gas Fields Routing problems, as explained below.
General Overview on Genetic Algorithms

Genetic Algorithms are a family of computational models based on evolution. These algorithms
are applied to combinatorial problems with a large search space (typically millions of possible
combinations).
Each potential solution to the problem can be encoded using a vector-like structure. For
example, if we are dealing with a problem involving 6 wells where each well can flow to any of
three different manifolds, then each potential solution could be encoded as [a,b,c,d,e,f]. Each
letter adopts a number representing the manifold each well is flowing to.
The potential solution [1,1,2,2,3,1] would then represent wells 1, 2 and 6 flowing to the first
manifold, wells 3 and 4 flowing to the second manifold and well 5 flowing to the third manifold.
Various techniques exist to represent a potential solution using a chromosome-like structure but
conceptually they are all the same.
User Guide
390
Genetic Algorithms basic steps

Step 1
Initial Population
The algorithm starts by selecting an initial population (typically chosen randomly)
Step 2
Evaluating the initial population

Each potential solution is evaluated (solved) and the value of the objective function
(e.g. Production Rate) is used to determine the relative Fitness of each member of
the population (the better the objective function the fitter the member will be)
Step 3
Survival of the fittest

Based on their fitness, a selection of members is done. The fitter a member is, the
more chances of being selected it will have. Selection Methods like Roulette are
used to weight the selection based on their fitness. The objective of this step is to
systematically eliminate the weaker membersSurvival of the fittest
Based on their fitness, a selection of members is done. The fitter a member is, the
more chances of being selected it will have. Selection Methods like Roulette are
used to weight the selection based on their fitness. The objective of this step is to
systematically eliminate the weaker members
Step 4
Creating a new Population (X-Over)

The members selected during the previous step are paired and used to generate a
new population by crossing over their chromosomes. Several methodologies exist.
Usually, a random point in the genetic chain is chosen and then the genes are Xovered between the pairs
Step 5
Loop
The algorithm starts again from step 2 using the new population until some stopping
criteria is met (e.g. only one member survives)
The diagram below illustrates these steps
391
RESOLVE
Main Limitations of Traditional GAs when applied to Oil/Gas Field Routing problems
The most important step in a Genetic Algorithm is the creation of the new population (by the
chromosomes X-over between pairs of selected members from the existing population).
During this step, a new population is created which determines essentially what potential
solutions we will examine next. If a Genetic Algorithm is to become an optimization algorithm,
then the next population to be evaluated should, in essence, be better than the previous. Hence,
within each new population, we are expecting to find better solutions. Additionally, we want to
find a solution as close to the best as possible evaluating as little potential solutions as possible
(efficient).
For the above to be true (the new population to be better than the previous one), exchanging the
chromosomes of two good solution should generate two new cases which are statistically better
than the original ones. This is true, at least in principle, when dealing with theory of evolution
(something GAs are inspired by). If we consider the original members to be two good quality
specimens of a certain species, by crossing over their chromosomes we have a good chance of
generating two new specimens of good quality.
However, when this principle is applied to wells/manifolds routing problems (in particular subject
to constraints and other conditions as described before), the generation of two new good quality
members becomes as likely as if we were simply choosing two new members randomly. That is
because of the interaction between routings (represented by each chromosome).
For example, one well flowing to a certain manifold may only be a good option provided that
manifold is routed to a particular separator. If the manifold is routed to a different separator,
routing the well to that manifold could be the worst option.
User Guide
392
This kind of interaction between routings/integer variables (especially when constraints exist) is
not taken into account in traditional X-Over methodologies (where essentially the impact of each
chromosome in the overall fitness is implicitly considered independent). This is analogue to
linear and non-linear systems. This interaction can be interpreted as a non-linear routing. This
makes Traditional Genetic Algorithm of very limited use on this type of problems.
GIRO X-Over Optimisation Algorithm: A new approach
To overcome the limitation of Traditional Genetic Algorithms (when applied to the kind of
problems we have described), GIRO incorporates a specially designed X-Over methodology
which takes into account the interaction between routings. This interaction is inferred by
learning from the already evaluated cases and applying that learning to drive the subsequent XOvers between members.
Several other modifications to the traditional approach have been done in order to facilitate this
learning.
This obtained knowledge is used to drive the X-over in a controlled manner. The objective is to
provide guidance without fully eliminating the randomness of the search of new cases. The
application is analogue to any global search when there has to be a balance between searching
new areas as well as focusing on the good local areas.
The application of this knowledge can be controlled by the two Optimisation Parameters.
Parameter 1 controls how much influence the learning from previously evaluated cases will have
on the selection of new cases. Essentially how much of this acquired knowledge we want to
apply.
Parameter 2 controls the increase of this weight as more cases are evaluated. The objective is
to apply more and more knowledge as more cases are evaluated (and hence we learn more
about how the system behaves).
It is recommended not to change the default settings unless a full analysis of the response of the
system is carried out. Due to the randomness component of this type of optimization, the
performance of GIRO for any particular problem can only be assessed when look at the results
statistically (i.e. results obtained when solving the same problem hundreds of times). This means
that unless the system allows such analysis then the default settings should be used.
2.13.3.2Formulating an Integer Problem in RESOLVE

Some Definitions:
Control
Variable
A control variable is the reference element which can take different states.
For example, in a well routing problem, the control variables are the wells (or
downstream joint associated to each well). The number of control variables
393
RESOLVE
States
of a control
variable
State
Variables
Values
of a State
Variable
defines the magnitude of the vector which will be used to represent every
possible solution of the problem
Each control variable is associated to different states. The state is used to
identify the current option (e.g. Routing). For example, if a well can be routed
to three different manifolds, the states of the control variable Well are to
manifold 1, to manifold 2 and to manifold 3
These are the variables required to capture the state of a control variable in
a model. These are the variables which RESOLVE needs to control in order
to setup the model in a way that each potential solution can be evaluated. In
the case of a well routing problem, the associated variables would be the
pipelines mask command which need to be controlled by RESOLVE to
change the routing in a model
these are the values associated to a state variable. In the case of a well
routing problem, the state variables can take the values of 0 and 1. 0
indicates that a pipeline is unmasked while 1 would indicate that a pipeline
is masked
2.13.3.3Example1: Well Routing Problem

In addition to the "Petroleum Experts SLP" global optimisation capability, RESOLVE includes an
optimisation algorithm that enables to assess the optimum routing option for the production
network considered.
This optimisation algorithm is labeled as "GIRO" (Genetic Integer Routing Optimisation).
The section below illustrates how this optimisation algorithm can be setup and used.
The example files used in this example can be found in the archive:
Example1 - GIRO - Routing Example 1.rsa

that is located in the Samples directory:
..\Program Files\Petroleum Experts\IPM 7.5\Samples\resolve\GIRO
The following GAP model is considered:

In this example, we have four Wells (W1, W2, W3 and W4), each able to flow to any of three
different manifolds (HP, MP and LP). Each well is connected to each Manifold via pipelines
named: WX to ManY (e.g. W1 to HP, W1 to MP, etc..)
User Guide
394
Setting up the optimization problem

The steps below assume we have already created a RESOLVE model which includes the GAP
model in it.
395
RESOLVE
Step 1: Enable the Global Optimisation in RESOLVE (for Single Solve Calculations).
User Guide
396
Step 2: Setup the Global Objective Function:

In this case we want to maximise Gas Production. This will be selected from the GAP Model,
as shown below.
From \Optimisation\Setup menu..
397
RESOLVE
User Guide
398
399
RESOLVE
That completes the setup of the Objective Function

Step 3: Setup the Routing Control Variables
This can be setup manually or automatically by using the routing wizard. Both methods are
described below.
Setting up the problem manually:
User Guide
The control variables will be setup as W1, W2, W3 and W4.
400
401
RESOLVE
The State Variables are the Pipelines mask variables.
User Guide
402
403
RESOLVE
Now we need to make the association between the State Variables and the Control
Variables. Each Well needs to be associated to the corresponding pipelines.
User Guide
404
Now we define the Control Variables State and assign the values that the State Variables
need to have for each of these States.
Each Control variable will have three possible States: To HP, To MP and To LP
405
RESOLVE
The setup can be now summarised as:

We have four control variables (W1, W2, W3 and W4).
Each of these control variables has three possible states: To HP, To MP and To LP.
Each of these control variables are associated to three State Variables which correspond to
the pipelines status (mask) which connect the wells to the corresponding manifolds
The Control Variables states are hence defined by assigning different values to the
associated State Variables so that, for example, to define the Well 1 State To HP we need
to assign a value of 1 (mask) for the pipelines connecting W1 to manifolds LP and MP and a
value of 0 (unmask) to the pipeline connecting W1 to manifold HP.
Setting up the problem by using the routing wizard:
When dealing with Routing Problems, RESOLVE can populate the previous screens
automatically based on the GAP model topography.
This functionality is accessed by clicking on Generate Routing Controls
User Guide
Then select on Read Topography
406
407
RESOLVE
User Guide
408
RESOLVE will create a list of all potential Routings based on multiple pipelines coming
out of a same joint.
We can then select which ones we want to include in our problem setup, and then click on
Generate Controls
If we want to select all the potential routings, then we can select Select All pipes, as shown
below.
409
RESOLVE
The Control Variables are now setup.
User Guide
410
411
RESOLVE
The existing constraints are not part of the Global Optimisation setup as they should be in the
underlying GAP model (which will be solved optimised for each routing case to be evaluated)
Step 4: Global Setup
Once the Objective Function and Integer Controls have been setup, we can go to
\Optimisation\Summary to define the global settings.
Step 4a: Select the Optimiser to use
User Guide
412
413
RESOLVE
Once GIRO has been selected, we can access the Optimiser Settings by clicking on
Parameters:
User Guide
414
The most important parameters are:

Initial Population: This is the main parameter which allows us to control how many
evaluations (and hence time) we are willing to spend in solving the problem. The higher the
initial population is, the better quality the result will be (although at the expense of longer
number of evaluations).
Update model if improvement better than: This is the criteria which will be used to change
the model setup. This parameter becomes important when GIRO is used during a Forecast
as it controls when the model setup will be changed (as per best solution found).
Retain optimisation of underlying applications: This controls whether the underlying
applications are to be solved optimised or not. In this case, we need GAP to be solved with
optimisation as we need to meet the existing constraints in the GAP model.
The rest of the parameters should be left as default.
Another important feature (optional) for GIRO can be found in the main summary screen, as
shown below.
415
RESOLVE
This validation flag criteria can be used to instruct GIRO to ignore certain solutions.
The main objective of this flag is to prevent GIRO from using bad solutions coming from the
underlying applications (e.g. violating constraints). When dealing with complex models, there
is always the chance that a certain combination (e.g. routing) causes problems and hence the
model does not converge to a valid solution. Unless the model is robust enough to cope with
all possible combinations without having any problem, it is recommended to setup some high
level criteria (e.g. total rate < Constraint * 1.02) to make sure that a potential bad solution
does not destroy the global optimisation.
This validation flag criteria can also be used to instruct GIRO to ignore solutions which do not
make practical sense (although they are still part of the potential combinations).
Step 5: Running the model
User Guide
416
The model is now ready to be run.

The main screen (Calculation Progress) will show the model evaluations.
The corresponding routing options (and results) can be inspected (even during the run) by
selecteing the Optimisation Progress window (from the windows menu)
417
RESOLVE
We can see the value of the objective function for each model evaluation with the best one
highlighted in green. The final result can be seen from the Overall Results tab.
User Guide
418
If the best solution is found to improve the result (compared to the original model setup)
beyond the user-specified tolerance then the model will be changed accordingly.
2.13.3.4Example2: Ful Field Routing Optimisation
Example2 - GIRO Full Field Routing.rsa

The section below illustrates how this optimisation algorithm can be setup and used.
The following GAP model is considered: it is possible to notice that several pipeline routing
options are available within this model, at both the well manifold and the separator level.
419
RESOLVE
In this case, the GIRO optimiser can be used to understand which one of the possible pipeline
routing combinations will be optimum at each prediction timestep.
In order to do so, the following procedure can be used:
Step 1: Create a new RESOLVE model and load the GAP instance.
Step 2: Enable the optimisation
To do so, select one of the two following options in the Options | System Options
section:
- "Full forecast with global optimisation" - This option will enable to optimise the
system at every timestep of
a RESOLVE forecast.
- "Single Solve / Optimisation Only" - This option will enable to solve and optimise
the system at one specific point in time.
User Guide
420
Step 3: Setup the optimisation problem

The optimisation problem can be setup by defining the objective function and the control
variables.
The objective function in this case will be to maximise the oil production at the FPSO.
The control variables in this case will be the different pipeline routing combinations.
It is important to note that when using the GIRO optimisation algorithm, the
RESOLVE SLP global optimisation algorithm will not be used, therefore any
constraints included in the RESOLVE model will be ignored.
However, the use of the GIRO optimiser can be combined with optimisation
algorithms working within each module, such as the GAP optimisation procedure
for instance.
If this is the case, objective function, constraints and control variables defined in
the GAP surface network model will be respected while the GIRO optimisation
421
RESOLVE
estimates the optimum routing options

To setup the optimisation problem, go to the Optimisation | Setup section in the main
RESOLVE menu.
To specify the objective function, select the "Edit" button in the "Objective Function"
section.
RESOLVE will retrieve the list of variables present in the GAP model (i.e. depending on
the size of the model, this might take some time) and the following screen will be
displayed.
User Guide
422
In this case, the objective function is maximising the oil produced at the FPSO: the
equipment selected is then the "FPSO" node and the variable selected is "Oil Rate".
The "Set" button can be used to automatically obtain the OpenServer variable
associated with this variable, as illustrated above.
As the value of this variable is to be maximised during the optimisation process, select
the "Maximise" option.
When using the GIRO optimisation algorithm, the "Minimise" option of the objective
function is ignored: if the objective of the optimisation problem will be to minimise the value of a
certain variable, then the objective function has to be setup so that it maximises the inverse of
the variable considered.
Once the objective function has been setup, it will be required to setup the control
variables. Control variables used in a routing optimisation case will be the status of the
different pipelines considered: these pipelines can either be open or close.
To setup these controls, go back to the optimisation setup screen and select the "Edit"
423
RESOLVE
button next to the "Controls" section, as illustrated below.
The following screen will be displayed:at the top of the screen, select the "Integer
Controls" tab, as illustrated below.
User Guide
424
The routing optimisation control variables can automatically be generated from the GAP
model by using the "Generate Routing Controls" option.
RESOLVE will scan the GAP model topography and will identify all the nodes with more
than one pipeline outlet.
When a GAP model is to be used for routing optimisation, it is important that all the nodes
and pipelines included in this GAP model are labeled.
425
RESOLVE
Click on the "Read Topography" button to list the different pipeline routing options
present in the surface network model, as illustrated below.
User Guide
426
Once the list has been populated, select which pipeline routing options have to be
considered. In this case, pipeline routing options for all the active wells will be selected,
as well as all the pipeline routing options for the separators.
This will account for 2048 possible pipeline routing combinations.
427
RESOLVE
Once the pipeline routing options considered have been selected, click on the "Generate
Controls" option.
This will automatically generate the different control parameters:
User Guide
428
The control variables are the nodes of the surface network model that have more than
one possible outlet pipeline, and the control variables are the status of these outlet
pipelines: either open or close.
Once the control variables have been setup, go back to the main RESOLVE screen, as
the optimisation problem has now been setup.
Step 4: Select the GIRO optimisation algorithm
A summary of the optimisation problem can be found in the Optimisation | Summary
section, as illustrated below.
429
RESOLVE
User Guide
430
By default, RESOLVE will use the "Petroleum Experts SLP" optimisation algorithm. For
routing optimisation purposes, it will be necessary to select the "GIRO" optimiser, as
described in the snapshot above.
The "Parameters" section enables to access the setup of the GIRO optimisation
algorithm.
431
RESOLVE
These parameters have been setup by default to be suitable for most of the cases.
Should you require any guidance when using the GIRO optimiser and these setup
parameters, please contact Petroleum Experts technical support via email:
edinburgh@petex.com.
Step 5: Run the model
Once the optimisation setup has been performed, the model can be run as per a classic
RESOLVE model.
The optimisation progress screen will enable the user to follow the optimisation
calculations that are performed
The control section of the optimisation progress screen will illustrate the different pipeline
routing combinations that are evaluated.
User Guide
432
The function result section of the optimisation progress screen will illustrate the oil rate
obtained for each of these evaluations.
433
RESOLVE
Once the optimisation is converged, the best routing option will be selected and reported
in the overall results section, as illustrated below.
The GAP model will also be modified to represent this pipeline routing option.
User Guide
434
In case a prediction case is run, the GAP model setup will be changed if an improvement
of more than 1% (i.e. this is a default value and can be modified by the user by modifying
the "Improvement Tolerance" parameter in the GIRO optimiser settings) of the objective
function is observed when performing the optimisation.
This is the final configuration achieved:
435
RESOLVE
Step 6: GIRO Optimiser Performance Wizard: How to use it.

RESOLVE includes a wizard that enables to analyse the performance of the GIRO
optimiser. More information can be found here.
The main objective of this wizard is to understand what is the optimum setup of the GIRO
optimiser.
This wizard is accessible through the Wizard | GIRO optimiser performance section of
the main RESOLVE menu.
In the example below, two cases are compared: they have the same GIRO optimiser
parameters, but have different initial populations: 8 and 20.
Once both options are run, the following results are observed:
User Guide
436
The plot illustrates the oil production obtained at the FPSO for the different cases
evaluated vs. the number evaluations required to obtain these results. The red plots
correspond to the case run with an initial population of 8 whereas the green points
correspond to the case run with an initial population of 20.
It is possible to notice that even so in both cases some evaluations reach the maximum
production at the FPSO, the case with a larger initial population is more consistent: most
of its evaluations are close from this maximum. However. the number of evaluations
required to obtain this result is higher, leading to a longer running time.
The "Statistics" button at the bottom right hand corner enables to quantify the results of
437
RESOLVE
the optimiser:
For an initial population of 8, only 25% of the cases evaluated will be within 99% of the
maximum oil produced at the FPSO. 88% of these cases will however be within 95% of
the maximum oil produced at the FPSO.
For an initial population of 20, more than 50% of the cases evaluated will be within 99%
of the maximum oil produced at the FPSO. 98.3% of these cases will however be
within 95% of the maximum oil produced at the FPSO.
User Guide
438
This GIRO optimiser performance wizard can therefore be used to estimate, before a
forecast run for instance, what will be the optimum way of setting up the GIRO optimiser.
2.13.3.5Example3 - Compressor prediction optimisation

This example illustrated how GIRO can be used for optimisation problems which are not
necessarily about routing. GIRO can be used for any optimisation problem which involves (or is
formulated using) discrete variables. These discrete variables could be equipment on/off, pump
and compressor bypass/unbypass or operational speed.
Example3 - GIRO compressor problem.rsa
439
RESOLVE

In this example a gas well produces from a reservoir. Compression is also foreseen in the future.
The objective is to determine if and when to switch on compression based on conditions that the
system maximises at all times the instantaneous revenue.
The following steps:
Step 1: Options.
In the main RESOLVE Options (menu Options/System Options) select the mode Full Forecast
with Global Optimisation:
User Guide
Step 2: The GAP model is connected to Excel.

The Excel instance has the revenue model along with compressor operation costs.
440
441
RESOLVE
User Guide
442
The overall compressor operational cost and the gas sales price are considered to be fixed at
respectively 65000 $/day and 4000 $/MMscf
Step 3: Set up Optimisation Objective function.
In RESOLVE, under Optimisation | Setup the objective function has been defined as
maximizing the revenue in Excel.
Step 4: Setup Integer Controls.

In the Setup | Controls | Edit, there is a tab for the integer controls where the variables may be
setup as shown in figure below.
443
RESOLVE
Step 5: Define State Variables.

Herein, under the tab for equipment bypassing, select the compressors for which the
bypassing option needs to be evaluated.
User Guide
444
Step 6: Add control variables.

Then ADD a control variable and select the compressor: bypass as a control variable. From
the Variable States tab, it is possible to set the state of the compressor, either bypassed or
unbypassed
445
RESOLVE
Step 7: Set up the possible states of the State variables.

Setting up of the integer control will allow for specifying the options 1 and 0 to indicate whether
the compressor is bypassed or not. This is as shown below.
User Guide
Step 8: Select the GIRO optimisation engine

Next in the Optimisation Summary section, select the user optimizer as GIRO.
446
447
RESOLVE
User Guide
448
Step 9: Publish GAP variables

For the GAP model, the compressor bypass flag and the separator production rate may be
published and added to the plot in Module variables/Import Application variables.
449
RESOLVE
As well as the Excel bypass flag and the gas rate

Step 10: Link GAP to Excel
The dynamic link may be created between the GAP instance and the Excel instance.
User Guide
450
This is to pass the bypass flag to Excel, which will be used within Excel to determine how to
perform the revenue calculation.
Step 11: Run the model

The following is a snapshot of running the model, where the separator rate is reported along
with the bypass condition of the compressor. From the results it is possible to see that the
compressor is switched on (bypass flag=0) at the beginning of year 2016, where the use of the
compressor becomes economical, that is to say, the increase of rate due to the compressor
wins over the compressor operational costs
451
RESOLVE
2.13.3.5.1 How to avoid optimising at each time step

In the context of prediction models, where hundreds of time step optimisation calculations are
performed, it is often possible (given no event occurs in the system) to reduce the number of
calculations, hence the run time, by avoiding optimising the system at each step.
To achieve that, create in the Optimisation Summary screen multiple schedules and use the
option 'Disable entry runs until' to switch on/off the optimisation.
In the example below the optimisation is switched off during year 2011, until 1/1/2012.
User Guide
452
453
RESOLVE
User Guide
454
2.13.4 Main Menu : Optimisation Section

The commands available from the optimisation menu are those that are used to set up the data
for the RESOLVE optimiser:
Objective Function
Control variables
Constraints
This menu is only available if the system has been specified to run with optimisation from the
Options | System Options screen.
For more information on the RESOLVE optimisation function, go to the "RESOLVE optimisation
455
RESOLVE
overview" section.
The options underneath this menu are as follows:
Enable
Setup
Summary
Users
Optimisers
This toggles the optimisation function on and off.

If the optimiser has already been setup, this allows to turn the optimisation
off to observe the behaviour of the system without optimisation
This invokes the "Optimisation setup" screen.
It allows the control variables, constraints, and objective functions from all
the system models to be setup in the optimiser
This invokes the "Optimisation summary" screen.
This displays a summary of the optimisation settings and also allows some
of the optimiser settings to be adjusted
This section enables the loading of an external optimisation routine.
External optimisation routines can be linked to RESOLVE using a specific
dynamic library, or DLL.
The format to setup this DLL is available on request, or "Excel" can be
used to create an optimiser
2.13.5 Optimisation setup

This screen allows the setup of the RESOLVE global optimiser.
Controls, constraints, and objective functions can be selected from each of the clients modules
in the RESOLVE system.
For more information on the RESOLVE optimisation function, go to the "RESOLVE optimisation
overview" section.
When the Optimisation | Setup section is invoked, the following screen is produced:
User Guide
456
For each client module in the system a tab is displayed at the top of this screen (i.e. in this case,
there are two GAP models, one production model and one water injection model).
To setup a control variable, select the tab at the top of the screen for the client module in
question. Click on the Edit button next to the "Controls" panel.
This will call up a screen that is specific to the application in question to allow the user to select
control variables from that model.
Constraint equations and objective functions can be set up in a similar manner.
The following snapshot gives an example of what this screen looks like for GAP.
The user guide section for each application driver will provide additional information related to
these screens for other applications.
457
RESOLVE
Using this screen, the following elements can be setup:

Objective
Function
The objective function can be set from the top section of the screen displayed
above.
The procedure to do so is the following:
1. Select the piece of Equipment to which the objective function is to be applied
using the drop-down box given
2. Select the variable that is to be selected as objective function
3. Click on Set: this will automatically retrieve the corresponding OpenServer
variable string in the display box shown.
4. Select whether this variable needs to be maximised or minimised
Contraints The constraints that have to be applied to the module considered can be setup in
the bottom section of the above screen.
User Guide
Controls
458
1. Select the piece of Equipment to which the constraint is to be applied using

the drop-down box given
2. Select the variable that is to be selected as a constraint
3. Click on Set: this will automatically retrieve the corresponding OpenServer
variable string in the display box shown.
4. Select the maximum or minimum value for this variable and set it in the Value
section.
5. Select the constraint relation: is the variable selected to be less or more than
the value specified
The elements of the model that can be controlled in order to obtain the optimum
objective function while respecting the constraints can be setup in that section.
To access this section, one has to select the Controls sub-section, and the
following screen will be displayed.
In this case, the controllable parameter is the separator pressure, which cannot
be fixed to a value lower than 150 psig.

1. If the control variable to setup is the separator pressure, simply press the Vary
separator pressure button and specify eventual maximum and minimum
459
RESOLVE
Integer
Controls
values.
2. If the control variables to setup are consistent with the GAP control variables (i.
e. dP choke and artificial lift parameters), click on Add GAP Controls and
specify the maximum and minimum values for these parameters.
3. If the control variable considered is not included in the two lists above, pick-up
its OpenServer variable string and paste it in the OpenServer variable
section, and specify the maximum and minimum values for these parameters
Integer controls are used for routing optimisation procedures.
A detailed example on how to setup these controls and use them in the context of
routing optimisation can be found in the "Routing Optimisation Setup: An
Example" section
There is no limit to the number of controls, constraints, or objective functions that can be
set up from here (although clearly the performance of the optimiser will be affected).
There is also no limit to the number of different models that the variables can be taken
from.
The panels will be displayed in grey or black depending on whether the variable (or
equation) has been set
2.13.6 Optimisation: multiple optimisers

From IPM7.5, RESOLVE allows a two-level hierarchy of optimisation. In other words, one
optimiser can run within the iterations of another optimiser.
There is no restriction on which optimisers are used, and the addition of the second level of
iterations is entirely optional. However, typically the user may need to meet constraints within a
process model while evaluating routing options using GIRO. In this case, the standard SLP
optimiser could be used as a second level optimiser which is fired at every evaluation of GIRO.
User Guide
460
By default, the second level of optimisation is not enabled (as it is in the above screenshot), so
that old optimisation models will run unchanged. Clicking on the 'Top level' or 'Second level'
buttons will bring up the optimisation summary screen for that optimiser, which enables the
selection of the optimiser type and the associated parameters.
When the model is run, the 'second level' optimiser, if enabled, will run at each iteration of the
'top level' optimiser.
The control variables and constraints are set for all optimisers in the optimisation setup screen. It
is up to the user to select, from the individual summary screens, which controls and/or
constraints are to be controlled or respected by the individual optimiser.
For example, the problem may involved multiple routing options which are to be controlled by
GIRO, with a process constraint which is to be met by an adjustment of the separator pressure.
The top level optimiser would be GIRO, and the summary screen may have the following
appearance:
461
RESOLVE
The selected optimiser is 'GIRO', and the control variables selected are the integer routing
variables. The continuous control (the separator pressure) and the constraint are not selected.
The second level optimiser would be the SLP:
User Guide
462
Input fields
Optimisation
modes of
underlying
applications
Retain optimisation
of underlying
applications...
At the bottom of the screen are some global settings which relate to
behaviour of the overall optimisation
When selected, this setting forces the optimisation of the individual

applications to fire at each iteration of the RESOLVE optimiser(s). For
example, it is possible to allow the powerful GAP NLP optimiser to run at
each iteration of the RESOLVE SLP. This opens up very powerful
possibilities, but needs to be used with some care as RESOLVE should
463
RESOLVE
Reoptimise
applications if...
not be made to control variables which are also going to be controlled

by GAP
If the above option to retain optimisation is not selected, then the
possibility to reoptimise the system if the controls change by more than a
certain tolerance is opened. This option is best illustrated with an
example:
The case where GAP is optimising numerous wellhead chokes to
maximise the production at the separator of a production model should
be considered. In this case, GAP is also coupled to a process model,
and the separator pressure (the pressure of the GAP-process
connection) is varied to meet a process constraint.
In the first pass through the optimiser, GAP optimises the wellhead
choke settings to maximise production. Unless the above 'retain
optimisation...' setting is on, RESOLVE then freezes the calculated
choke settings and varies the separator pressure until the constraint is
met.
Once the constraint is met the original choke settings may not be valid at
the new separator pressure, in the sense that the system could
potentially produce more if re-optimised against the new separator
pressure.
When not in
forecast, use
application
optimisations to
provide starting
point
Starting conditions
of each
optimisation when
underlying
applications are
not optimising
The above setting and tolerance therefore allows the user to force the
system to re-optimise from scratch if the control variable(s) change by
more than the given tolerance. In the above example, the first RESOLVE
optimisation will be followed by a new GAP optimisation starting from
the final separator pressure calculation by RESOLVE
In a standalone (non-forecast) run, the starting point of the optimisation
can be given by an optimisation of the underlying applications (if
possible - not all applications support optimisation, or some need to be
set up specifically to perform optimisation)
This option allows the user to specify whether the system setup obtained
after optimisation is to be kept as a starting point for the next optimised
run, or if all the values of the control variables have to be reset to their
values at the start of the run. This option is only enabled for a forecast
run. Whether the underlying applications are optimising or not is
specified in the main schedule
2.13.6.1Optimisation summary
This screen displays a summary of the settings of a RESOLVE optimiser.
User Guide
464
See the RESOLVE optimisation section for more information on how this optimisation works.
Note that multiple optimisers can be set up which can be nested, and this screen displays the
settings for only one of these optimisers. The nesting of optimisers, and the invocation of this
screen, is explained in the section on multiple optimisation.
When invoked, the following screen is produced:
The top-left part of the screen shows the functions and controls that have been setup (say, for
example, from the "Optimiser setup" screen).
465
RESOLVE
For each category, variables or equations can be selected or unselected by clicking the check
box next to the item to add / remove them temporarily from the optimiser.
Only a single objective function is allowed: To activate it: check the box next to the
objective function.
The control variables have optimisation parameters (such as perturbation size) that may or may
not be set up by the user.
These can be setup by clicking on the "Edit Control Variables" button.
Before an optimisation is ran it is important to make sure these quantities are set
to reasonable values. RESOLVE optimiser does not have a physical
understanding about the quantities that it is due to control so it has to be guided
in this way
The following other details can be specified through this screen:

Schedules
If the run is a forecast then it is possible to schedule different

optimisation conditions at different times in the run.
To use this it is necessary to pre-define at the start of the run all the
constraints, objective functions, and controls that will be used during the
prediction. After this it is possible to change the set of variables or
equations that are used by the optimiser with time.
To add a schedule entry click on the Add button. The schedules run
concurrently and the end date of each schedule is entered in the field
below the schedule list. If this is left blank then the schedule will run to the
end of the forecast.
The set of variables and constraints that are "active" for each schedule
are those which are selected in the list on the left.
Optimisation
parameters
It is also possible to disable the optimiser for a time during the forecast
by clicking on the Disable optimiser for this entry box. This setting
again remains active for the duration of a schedule entry
These values should not normally be changed, exception made of the
"Optimiser" section that enables the user to decide which optimiser to
use: RESOLVE SLP, GIRO (i.e. See the "GIRO" section for further
information) or user-defined optimiser.
User Guide
466
Optimiser
Enables to specify which optimiser is to be used to

optimisation problem specified.
By default, RESOLVE includes two optimisers: the R
SLP and GIRO (i.e. See the "GIRO" section for furth
information) optimisers (i.e. specially designed for r
optimisation problems). Should the user have added
its own optimisation routine, this routine will be listed
drop down box and could be selected
Maximum step growth and

Minimum step growth
The control variable bounds are grown or shrunk at e

iteration depending on the results of the last iteration
values give the maximum and minimum allowable gr
The maximum number of iterations allowed for the o
Convergence is achieved when two subsequent iter
achieve the same result. This is the tolerance on this
Determines the rate at which control bounds can be
or decreased
Maximum iterations
Obj Fn and Constraint
Tolerance
Linear criterion
2.13.6.1.1 Edit Optimiser Control Variables

This screen is invoked from the "Optimisation Summary" screen.
It is important to set the suitable perturbations and initial bounds for each
control quantity to a suitable value, as RESOLVE optimiser does not have a physical
understanding about the controls that it is changing. The RESOLVE optimiser has to be
guided, and this screen is a convenient place to do this. Certain quantities (such as
wellhead chokes in GAP) have suitable defaults supplied, but this is not the case in
general
The screen as the following appearance:
467
RESOLVE
The following elements can be setup through this screen:

Perturbation
Initial bound
Minimum
perturbation
Centre
perturbation
This is the perturbation that should be applied to the control in order to

obtain its derivatives. RESOLVE attempts to find a suitable default for
any control, but this can be changed here
For each iteration of the "SLP optimiser" the control variables are
bounded to control the optimiser. This gives the initial (i.e. first iteration)
bound. Subsequent iterations increase or decrease the bound
depending on the "linear error"
The perturbation applied to obtain linear gradient information is adapted
depending on the current bound of the control variable in question. If the
bounds become small enough then the perturbation could, in theory,
become small enough to be influenced by, say, the tolerance of the
application solvers in the RESOLVE system. This field allows to set an
absolute minimum on the perturbation that can be taken
If this is set then RESOLVE will perturb this variable between (v-(d/2))
and (v+(d/2)), where d is the perturbation (the default is between v and
v+d). This is generally preferred when trying to get the best possible
gradient data, but it is also slower as RESOLVE has to make two
"movements" to perform the calculation. This may, however, be useful in
systems where the functions are very sensitive to the controls (especially
close to the optimum). Such systems require good quality gradient data,
otherwise convergence can be very slow
User Guide
468
2.13.7 User optimisers

Users can write their own optimisers to tackle RESOLVE optimisation challenges.
This is done by way of a plug-in DLL.
There are two options:
User DLLs
Excel
A DLL (plug-in) template and documentation can be obtained from

Petroleum Experts which explains how to code the optimiser. The
template is in C++. It is possible to use other languages, but it is up to
the user to translate the DLL entry points into the appropriate structure to
enable them to be called from RESOLVE
Excel can be used via a custom interface implemented through the
supplied DLL (pxExcelOptnn.dll). The use of this DLL is explained here
Once a DLL is available (either user-implemented or pxExcelOpt), it needs to be registered in

this screen. The information is stored in the Windows registry so this only has to be done once.
Once the DLL is registered, the optimiser name will appear as an option under the "optimiser"
section of the optimisation "Summary"screen, from which it can be selected.
2.14 "Scripting" Section

2.14.1 Scripting : An Introduction
RESOLVE implements a scripting control that allows for instance complex event-driven
schedules that cannot be setup using the in-build scheduling options to be performed during a
RESOLVE run.
To use this facility, a basic knowledge of Visual Basic and programming will be required.
Examples of how scripting can be used are included in the sample files.
To create or edit a script, go to Script | Edit from the main menu.
The following script editor is then invoked:
469
RESOLVE
Several functions (e.g. "entry points") are called by RESOLVE at predefined parts of the
simulation.
Use the drop down lists at the top of the screen to select the function to implement.
Main Script Options
The following RESOLVE functions / entry points can be considered:
Declarations
PreSolve
This is not a function that is called, but this section allows variables to be
set up and instantiated with initial values
This is called by RESOLVE just before the solve command is sent to a
group of connected modules, after the data has been passed between
the applications. The argument to the function (ModuleList) is a string
that is a delimited list of the modules that form the group, the delimiter
being a tilde "~" character.
For example, in a simple RESOLVE system consisting of three modules
User Guide
470
("ResSimulator1", "ResSimulator2", and "Network") that are connected

together, PreSolve will be called first with an argument
"ResSimulator1~ResSimulator2". After this has been solved and the
data passed up to the network, PreSolve will be called with an argument
"Network".
The argument can be used to check exactly which part of the RESOLVE
system is currently being solved
PostSolve
This is also called with a ModuleList argument. It is called after the Solve
command and after the data has been passed back to the receiving
module
Start
Called at the initialisation of the simulation
Finish
Called at the end of the simulation, to allow post-processing, tidying of
data, etc.
StartofTimestep
Called at the beginning of every timestep
EndofTimestep
Called at the end of every timestep
GetNextTimestepL Routine that enables to obtain the length of the next timestep when
ength(CurrentTime, running the forecast using the adaptive timestep mode
LastTimestep,
ProposedTimestep
, MaxTimestep)
RESOLVE properties
The following list describe the different RESOLVE properties that can be queried from the
script:
Time
Timestep
Timesteplength
Gets the current simulation time, in days

Gets the current simulation timestep
Gets the length of the current simulation timestep
RESOLVE functions
The following list describe the different RESOLVE functions that can be called from the script:
LogMsg(string)
Save()
SaveAs(filename)
Outputs a message to the RESOLVE log window during the run

Saves the current RESOLVE file
Saves the current RESOLVE file as filename
The next three functions may or may not be implemented for a particular link (it is up to the
developer of the link).
They are implemented for all Petroleum Experts products.
GetVar(tagstring)
Gets a variable from a module, the variable being specified by

tagstring. In the case of the Petroleum Experts products, the string is
the OpenServer string for the variable in question. The first part of the
string (e.g. "GAP", or "REVEAL") should be replaced by the module
471
RESOLVE
SetVar(tagstring,
valuestring)
Cmd(tagstring)
alias as entered in RESOLVE

Sets a variable in a module, the variable bring specified by tagstring, as
above
Performs a command specified by tagstring
The next functions are used in conjunction with the above to perform error checking.
IsError()
ErrMsg()
EndRun()
RedoSolve()
RedoSingleSolve()
SetState(statelabel)
GetState(statelabel)
ArrayElement(array,
element)
Determines whether an error has occurred in any module

Returns an error message if IsError() returns non-zero
Terminates a run prematurely
Allows solves/optimisations to be repeated following PostSolve. This
will cause RESOLVE to repeat the solve/optimisation over the entire
system, from the bottom to the top
As above, allows solves/optimisations to be repeated following
PostSolve. This will cause RESOLVE to repeat the solve/optimisation
for the current calculation group (specified by the argument to
PostSolve)
If a system state has been saved (e.g. from the optimisation results
screen) then this function can be called to apply the state to the system.
This might be, for example, the results of a previously performed routing
optimisation
This returns the current state as previously set with SetState. It returns
an empty string if no state has previously been set
Certain applications (notably Hysys) return arrays in forms that VBScript
is not able to access. This function allows the elements of these arrays
to be returned to the script.
An example of this is in the GAP-hysys-constrained.rsl sample file
Debugging
If a debugger is available, then breakpoints can be added and the code stepped through.
The exact functionality depends on the nature of the debugger that is installed.
2.14.2 "Script" Section

The script menu gives access to the scripting facilities in RESOLVE. These allow for instance to
dynamically query variables and perform changes to the system as the run proceeds (for
example, a well in a simulator can be closed when the saturation of water in nearby grid blocks
exceeds a limit).
The following options are available from this menu item:
Edit
Enable
Script
This invokes the script editor. This is described in more detail under the"
Scripting : an introduction" section
This allows the user to toggle the scripting facility on or off so that runs with or
without the script can be compared
User Guide
Execute
function
472
This enables to test the script functionality without taking the time to make a full
run.
This menu item produces a drop down menu consisting of the four functions
that can be implemented in the "Script" (PreSolve, PostSolve, Start, and
Finish).
Select the function that is to be executed.
If a debugger is installed, it will be possible to debug into the function, or
alternatively one can popup message boxes to track the progress of the
function call
If PreSolve or PostSolve are called, then an argument specifying the modules about to be (or
just) solved must be passed. They are passed in the form of a string delimited by tilde("~")
characters.
For example, in the system below, there are three possibilities for the string that is passed:
"Model A", "Model B~Model C~Model D" or "Model E".
If RESOLVE detects that there is more than one possibility, it will display a screen with a drop
down list of the strings. If there is only one possibility, the function will be called with this string.
Import
Export
/ These options allow to export a script file to an external file that can later be
imported into a different RESOLVE case.
This is useful for swapping scripts between different files
Porting IPM 4 This section leads to a description of the potential modifications that have to be
made to a script that was created with IPM 4 to use it in subsequent versions.
> IPM 5
See the "Scripting: IPM5 vs IPM4" section for additional information
2.14.3 Scripting: IPM5 vs IPM4

There are a couple of small differences between the way the scripting is implemented in IPM #5
and consequent releases compared with IPM #4 which may become important when running
473
RESOLVE
files that were developed and saved in IPM #4.

It is not anticipated that the situation will change again in future releases.
The functions "PreSolve" and "PostSolve" are called with an argument list (ModuleList in the
example below):
Sub Resolve_PreSolve(ModuleList)
If (instr(ModuleList,"production") > 0) Then
" Perform a routine
End If
End Sub
This module list is a tilde ("~") delimited list of modules that are currently being solved for, and
so many scripts that implement PreSolve or PostSolve have a protection at the start (the "if"
statement in the example above) to prevent the logic from being called at the wrong point in the
timeline.
Consider the following system, in which a model "Model B" is feeding a model "Model A". Model
B could be a reservoir simulator, Model A could be a surface network GAP model.
In IPM #4, PreSolve and PostSolve would be called once only with the argument "Model
A~Model B" as the solve was carried out per connection.
In IPM #5, PreSolve and PostSolve are called twice. The first time the argument will be "Model
B", the second time it will be "Model A".
The arguments reflect the calculation order as written to the calculation screen when the model is
run. If, therefore, the user want to apply some logic to Model A in the PreSolve function the user
will have to protect against the function being called for Model B using the "instr" function, as
shown in the example above.
User Guide
474
To reinforce the point, consider the modified setup:
In IPM #4, PreSolve and PostSolve would be called once with the string: "Model A~Model
B~Model C".
In IPM #5, PreSolve and PostSolve are called twice. The first time the argument will be "Model
B~Model C". The second time the argument will be "Model A". As before, the user will have to
guard against the logic of the script being executed twice if the user do not wish this to happen.
Note that the calculation order (Run | Calculation order from the main RESOLVE menu) can
affect the number of times that Pre/PostSolve are called.
2.15 Running the RESOLVE Model

2.15.1 "Run Menu"
The menu items under this section are used to control a simulation run as it proceeds.
The options available in this section are:
Validate
Start
Single Step
Single
This performs the "pre-processing" of the run without doing the run itself.
It can be used to perform a simple validation of the system
Commences a run (i.e. from the beginning of the forecast or following a
pause).
If it is starting from the beginning of the forecast, RESOLVE will validate the
system beforehand and display any validation errors
Enables to run a single-step of the forecast: the step will be run and then the
forecast will automatically be paused
If an optimisation run is performed (i.e. either standalone or as part of a
475
RESOLVE
Iteration
(optimiser)
Stop
Pause
Run
Scenarios
Edit
composition
tables
Edit
calculation
order
Edit loops
Debug
Logging
forecast) then this provides the option to just perform a single iteration of the "
SLP" optimisation routine.
This is useful for debugging optimisation runs, as a table of the linear functions
generated by RESOLVE for the objective function can be accessed
Terminates a run
Pauses a run.
During a simulation, the client applications user interfaces are disabled pressing pause will re-enable the applications and allow the user to view
results, etc.
This enables to launch runs for the different scenarios saved in the "Scenario
manager". They can be run sequentially or distributed onto the nodes of a
cluster. Go to the "Running Scenarios" section for further information
"Composition tables" are required when compositional data is being passed
between applications: they will enable to map the compositions from one
application to the other . This is necessary as each application will have its
own set of compositions which may have unique names across the RESOLVE
system (e.g. methane in one package may be referred to as CH4 in another)
RESOLVE works out a "Calculation order", working upstream to downstream
according to the flow of data.
This screen can be used to visualise the calculation order that RESOLVE has
determined, and enables to change the calculation order if the user decides
that a particular model calculation depends on the results of another model.
For instance, if the RESOLVE models contains a script that takes the results
from one model and applies them to another model, both models cannot be
solved simultaneously and the calculation order will have to be modified to
enable the script to work successfully
If RESOLVE detects that there are loops in the system, then this will present a
screen that allows adjusting how the loops are solved.
See the "Edit loops" section for further details
Turns the debug logging on or off.
The debug logging will generate a detailed record of all the data that is passed
between applications during a run which will then be saved with the RESOLVE
file. It allows cases to be debugged remotely without necessarily having
access to all the drivers or applications
Utility functions to view the above debug file or to export it as an ASCII file
Debug file
view / export /
clear
IPR Logging Turns the IPR logging on or off.
The IPR logging will enable to store in RESOLVE all the inflow performance
curves passed from the reservoir models to the well models. This is extremely
useful for troubleshooting purposes, especially to analyse whether for instance
a convergence issue is coming from the quality of the IPRs passed or from the
surface network calculations
User Guide
476
2.15.2 Calculation Order

This screen is invoked from the Run | Edit Calculation Order menu item.
Consider the following case in RESOLVE:
A numerical reservoir simulation model (i.e. modelled with Petroleum Experts REVEAL
package in this case) is connected to a production and an injection GAP model.
One of the objective of this model is to perform a voidage replacement scheme: the production
from the production model will be obtained by a RESOLVE script and then this will be applied as
a constraint, by the script, on the injection model.
477
RESOLVE
When this system is first modelled in RESOLVE, it will determine that the reservoir model needs
to be solved before the data is passed up to the network models, which can then be solved
simultaneously.
When the calculation order screen is first invoked, it will have the following appearance,
specifying that the first element to be calculated is the reservoir model, followed by the
production and water injection surface network models, which are solved simultaneously.
The following elements can be considered in this screen:

Current
calculation
This displays the "groups" of modules that are solved simultaneously.

In the above example, the "reservoir" model is solved first, and then the
"production" and "injection" systems are solved together
User Guide
order
Upstream /
downstream
dependencies
Add
dependency
478
These hierarchical lists just display the dependencies of each module as

determined by RESOLVE.
For example, it is possible to see here that the injection and production
models depend on the reservoir model in the "downstream" dependencies
In the above example, the user does not want the production and injection
systems to be solved simultaneously, as the results of the production system
affect the injection system (i.e. through the script). The calculation order
therefore has to be modified manually, as described below.
The "Wat_Injection" system has to be selected from the "Module" drop down
list, and the "Production" system from the "depends on" drop down list.
Once this has been setup, the "Apply" button can be used to add the
dependency.
At the end of this process, the calculation order will be changed and the
screen will appear as follows:
Note that it is not possible to create circular dependencies in this way.

From this position, if one tried to add a dependency of "Production" on
479
RESOLVE
"Wat_Injection" an error would be displayed:
2.15.3 Edit Loops

This screen is invoked from the Run | Edit loops menu item.
It is also possible to access that screen by right-clicking on the icon of the connection
considered in the graphical view section.
The issue of how a system which contains loops is solved is discussed in the "Methodology"
section.
When invoked, the following screen is displayed:
User Guide
480
In this example, the RESOLVE system contains three models (Production, Main_Process, and
Splitter) which forms a loop.
This setup is extremely common for instance when considering gas lifted systems: the gas
produced is passed from the separator in the surface network model (i.e. GAP in this case) to
the process model (i.e. UniSim Design in this case). The process model calculates the amount
of gas available for gas lift and gas re-injection purposes and passes this volume to an Excel
spreadsheet. The Excel spreadsheet includes a user defined relationship that splits this volume
of gas into gas available for gas lift and gas available for gas re-injection.
The gas available for gas lift is then send back to the surface network GAP model, creating a
loop.
Several iterations are required around this loop for the model to converge: the user will have to
setup the loop to specify for instance how tight the convergence through this loop will be.
In order to do so, the following options are available:
Select loop
This contains a list of the loops in the current system.

In this example, there is only one
Loop elements In a loop, RESOLVE needs to be told which model to solve first when solving
the loop. It will have a guess at which one to solve first (a reservoir simulator
will be solved before a surface network simulator) but this section enables
the user to alter that order
Method
Two methods are available to solve loops within RESOLVE:
481
RESOLVE
Substitution
Gradient
Connection
details
Upstream
connection /
Downstream
connection
Upstream <-->
downstream
source/sink
Variable
The substitution method is the default method: if a loop

between a model A and a model B is considered the
substitution method will send the results of model A to
model B. Model B will use this input and calculate its
output, which will be send to model A as an input via the
loop. Iterations will be taken through the loop until the
outputs and inputs to the loop are consistent on with
another.
This method is perfectly adequate for loops that tend to
converge quite quickly, such as gas lift loops between
Hysys and GAP for instance
The gradient method will calculate the impact of the model
A output on the model B output: this can be done by
perturbating the model B and calculating its output for
instance.
This is particularly suitable for more complex loops that
will take some time with the substitution method
The way a loop is solved is as follows:

RESOLVE starts with the starting model (i.e. model Production in this
case) and passes the data downstream as usual.
RESOLVE continues round the loop until it arrives back at the starting
model and obtains the value of a target variable, which is set up from this
screen.
RESOLVE will continue round the loop several times (i.e. up to the
"maximum iterations" value) until the value for the target variable
converges over consecutive loops. The target variable data for this is set
up on the "Connection Details" grid. Several target variables can be set up
in a list in this grid
Select from the drop down list the model that is the "upstream" or
"downstream" model.
If the upstream model is selected then the downstream model will be filled in
automatically, and vice versa
Having chosen the upstream and downstream models, this drop down list
will contain a list of the source / sink connections between the models. Select
the connection for the target variable that to setup
Select from this list the target variable to converge on.
The choices are:
Liquid rate
Oil rate
Gas rate
Water rate
GOR
WC
CGR
User Guide
Auto-init
Start value
Init? button
Unit
Convergence
Maximum
number of
iterations
482
WGR
If this is checked, then just before the first module of the system is solved the
initial inflow data will be passed from the upstream node to the downstream
node as set in this table
If "Auto-init" is not set then when the loop solve is started, the value entered
here will be passed to the downstream model for initialisation purposes.
This is only available for Qwat, Qoil, and Qgas target variables, as this is the
data passed by RESOLVE
If "Auto-init" is not set then this will cause RESOLVE to interrogate the
upstream node for the inflow value that is currently entered for the target
variable in this system.
In this case, "Model Production, Out-1" will be queried to determine its liquid
rate. This will then be set as the "Start value".
If Auto-init is not checked and there is no start value, then no
initialisation of the loop will take place
Automatically set. The unit of the target variable(s)
This determines the convergence criterion for consecutive passages around
the loop.
It is an absolute value, and should be entered in the units appropriate to the
target variable (as displayed)
The maximum number of passages around the loop
2.15.4 Running Multiple Scenarios

Overview
Scenarios consist of a set of "Event driven schedules" which have been stored in the "Scenario
manager".
The event driven schedules allow a RESOLVE coupled run to be controlled with a series of if ...
then ... else directives.
Here are some examples of the type of scheduling that can be achieved through the event driven
scheduling options of RESOLVE.
At <date1> open well1. At <date2> close well2.
If the water cut in well1 exceeds 0.8, change the separator pressure in the GAP model.
If the GOR at the GAP separator exceeds 5000 scf/STB, bring on a new compressor in
the Hysys plant model.
This run should use a new realisation of the Eclipse reservoir model contained in the
data file NEWMOD.DATA.
Open a set of pieces of equipment in a "drilling queue".
483
RESOLVE
As can be seen, the scheduling is very open ended and should be able to handle most field
events.
A set of these schedules represents different model scenarios. These can be run from the main
RESOLVE menu: Run | Run scenarios.
Running scenarios
When the "Run scenarios" menu item is invoked, the following screen is displayed:
Select from the list those scenarios that are to be to run (i.e. by default, all are selected). The
scenario labels are those applied to the scenarios when they were set up in the scenario
manager.
OK
Use
clustering
The selected scenarios will be run sequentially

If this is selected, then the scenarios can be distributed to the nodes of a "
Running Scenarios on a Cluster: Overview".
Two different types of clusters can be used: LSF or PXcluster
User Guide
484
2.15.4.1Running Scenarios on a Cluster: Overview

This section describes how RESOLVE distributes schedule data onto different nodes of a
Windows cluster.
Further information regarding the use of clusters can be found in the "Clustering Basics" section.
Two types of cluster can be considered:
"Windows"
Cluster
"Mixed"
Cluster
This is a cluster where all the cluster nodes are running a Windows operating
system.
When considering "Windows" clusters, two different clustering softwares are
available, LSF or PXCluster.
The setup and usage of both of these softwares is detailed in the following
sections: "Use of LSF Cluster" and "Use of PXCluster"
This is a cluster where the cluster nodes are running either Windows or another
operating system such as Linux for instance. The setup and usage of this type
of cluster is described in the "Running Scenarios on a Mixed Cluster" section
See also the note on running RESOLVE cluster jobs in windowed or non-windowed modes.
2.15.4.2Windowed and non-windowed modes
When a cluster job is submitted to a calculation node, it runs a copy of the RESOLVE model on
that node. The IPM programs (GAP, REVEAL, etc) may run as part of the model on the
calculation node, i.e:
485
RESOLVE
These applications are designed to work with a user-interface. However, it is possible to run the
scenario jobs with no user interface; this may be desirable if the jobs are to run on a server with
no user logged in.
The mechanism by which the windowed or non-windowed mode is set up is discussed here.
However, if a non-windowed mode is required, it will probably need an adjustment of operating
system parameters to allocate the resources to a non-interactive desktop. The following
describes how this is done.
How to allocate resources to allow windowless running of submitted applications
If no changes are made, then multiple jobs running on a single node, or single jobs with large
resource requirements, may fail. The cause of this problem is known to relate to the Windows
desktop heap setting.
On Microsoft Windows operating systems, the desktop heap is reserved for interactive windows
stations and non-interactive windows stations.
An active Windows station would be a graphical user interface that a user is running on the
desktop.
User Guide
486
A non-interactive station is a process that is running without a graphical user interface.

This is for all Windows-based applications that are running on a Windows system. The desktop
heap is used for all objects (windows, icons, menus, etc....).
It is necessary to adjust the heap allocation for the non-interactive desktop. This should be
carried out with some care: setting the value too high can cause 'Out of Memory' errors to occur
when too many applications are running on the system.
Note: This solution contains information about modifying the system registry. Before making
any modifications to the Microsoft Registry Editor, it is strongly recommended that you
make a backup of the existing registry.
To change the setting perform the following procedure:
1. Click Start > Run > type: Regedit
2. Navigate within the Registry editor to the key:
HKeyLocalMachine\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems
3. Double-click the value 'Windows'
4. Scroll within the value and find 'SharedSection='
5. Edit the section of the string that may read 'SharedSection=1024,3072,512' to the
following:
SharedSection=1024,3072,2048
Note: The third value can be larger than 2048, depending on how many applications are
required to run on the server. There is no exact formula to set the correct value, a suitable value
should be sought by trial and error. However, 2048 should be a good starting point and should
be suitable for most systems.
6. Restart the server.
2.15.4.3Clustering basics
A cluster is a networked group of computers which can be used to perform batch processes.
In the diagram below, a job is submitted to the cluster from a submission node. The job is run on
the processor which has the lowest load. If there are no available processors, the job is held in a
queue until a processor becomes available.
487
RESOLVE
Two types of clusters can be considered: "Windows" clusters, where all the cluster nodes are
running Windows operating systems, and "Mixed" clusters, where some of the cluster nodes are
running a different operating system such as Linux for instance.
Clustering software
Two clustering softwares are implemented in RESOLVE: LSF and PXCluster
LSF is a commercial software that allows both "Windows" and "mixed" clustering.
PXCluster is a clustering software that has been developed by Petroleum Experts
and that is part of RESOLVE. It has been designed exclusively for use with the
Petroleum Experts applications. It allows "Windows" clustering but not "mixed"
clustering.
These softwares enable:
Allows jobs to be submitted to the cluster
User Guide
488
Performs load balancing

Maintains different job queues, e.g. priority, night-time, normal, etc.
Although the use of these softwares has been implemented in RESOLVE, there is no reason why
a different clustering software can not be implemented by an interested user, as RESOLVE has
an open structure.
Please contact Petroleum Experts for more information.
How RESOLVE works with the cluster
When multiple scenarios (i.e. "jobs") are submitted to the cluster, the following sequence of
events occurs:
RESOLVE asks the client modules for a list of all the files that are required to run each
client module. For example, an Excel model just returns to RESOLVE the name of its
Excel file. A GAP or reservoir simulation model will generally have more associated
files than this.
RESOLVE makes an archive of all the project files and copies them to central file
storage. This is a drive with a common UNC name which is visible from all the nodes in
the cluster.
RESOLVE will also copy some binary data files to the central storage. These contain
the scenario data that is to be run.
The scenario jobs are then submitted in a single batch to the LSF / PXCluster queue.
The jobs are run on the nodes as child RESOLVE models.
As each RESOLVE job finishes it writes a results file back to the central storage. This is
then read by the master RESOLVE model.
If any more jobs are pending in the queue, these are executed as the previous jobs
complete.
The diagram below describes this procedure when using the LSF clustering software.
489
RESOLVE
2.15.4.4Running scenarios on a Windows cluster

2.15.4.4.1 Use of LSF Cluster
2.15.4.4.1.1 Overview
LSF is a commercial clustering software developed by Platform.

Its usage has been implemented in RESOLVE and the following sections will describe its setup
User Guide
and usage.
This software enable to:
Allows jobs to be submitted to the cluster
Performs load balancing
Maintains different job queues, e.g. priority, night-time, normal, etc.
2.15.4.4.1.2 Cluster viewing and configuration
This section concerns the viewing of the cluster properties.

To view the nodes of the LSF cluster, go to Wizards | Run LSF configure...
This will call an external application which has the following appearance:
490
491
RESOLVE
The same application is invoked when the scenarios are submitted to the cluster.
The screen is divided into several sections that are described below:
Cluster
information
Cluster
name
This is read from the LSF cluster files and is for informational purposes only.
The cluster can not be edited from this screen
This is the name of the cluster, as supplied by the cluster administrator when
the cluster was originally installed
User Guide
Master
node
Hosts
Host loads
(dynamic)
492
This is the name of the node which is currently the master node of the cluster (i.
e. where mbatchd.exe is running)
This is a list of the hosts. The order of the listing can be changed from the "
Sort By" drop down list. Regardless of this setting, however, computation
nodes (i.e. nodes on which calculations can be performed) are always listed
above client nodes (i.e. nodes which can only submit jobs).
The "Hosts" table consists of a number of columns which are taken from
information passed by LSF. Only those nodes which are available for
computation are shown in white: nodes which can not perform computations
(either because they are only client nodes, or because they are not licensed, or
for some other reason) are shown in grey
This table consists of dynamic load data that is refreshed every 10-15
seconds. The column titles are the identifiers of dynamic resources in LSF: for
more information, please refer to the LSF documentation.
In short, the user should note that nodes which are loaded with a job (e.g. a
reservoir simulation) will show higher numbers across the board. The table is a
simple way of viewing what is currently happening on the cluster
The remainder of the screen is disabled when it is opened in this way (i.e. for viewing and
configuration). The meanings of the other fields in this screen are discussed under the section
on "Running the scenarios in batch" section.
This section concerns the configuration of the cluster nodes.

Configuration of the cluster
As discussed in the section on "Clustering basics", the "slave" nodes of a cluster are essentially
running full RESOLVE models. For remote execution of these models to take place under LSF (i.
e. or presumably any clustering software) privileges must be granted appropriately.
This can be performed by hand or it can also be automated from an LSF client.
To perform the configuration by hand will require an administrator to configure each node of the
cluster individually: the procedure to do so is described in the "Manual Cluster Configuration"
section.
This configuration can also be automated: the procedure to do so is described in the "
Automation of the Cluster Configuration" section.
Manual configuration of the cluster

The specifics of the manual configuration of the cluster for each of the RESOLVE drivers (i.e.
493
RESOLVE
links) that are developed by Petroleum Experts are discussed below.

Petroleum
Experts
products
To use these products, OpenServer privileges must be granted on all the

nodes of the cluster on which the software is to run. These privileges
essentially allow remote access and launch of the OpenServer COM
object.
On each node of the cluster, perform the following configuration:
Windows 2000
Windows XP
1. From the Start | Run Windows menu, run DCOMCNFG.E

2. In the applications list, locate the OpenServer object. This i
"pxserv32 document" (or something similar).
3. Highlight the OpenServer object and click on properties.
4. Under the "Location" tab, select "Run application on this
computer".
5. Under the "Security" tab, change the access, launch, and
configuration permissions to allow full access to the remote
machine.
6. It is generally convenient to allow this access to "everyone"
things simple. If this is not allowed, then the access must be
to the account under which the LSF services are running.
7. Under the identity tab, select "Interactive user".
8. Press OK. The user should NOT need to reboot the compu
The procedure is the same as for Windows NT, but the interfa
slightly different.
DCOMCNFG can be found from Control Panel | Administra
Tools | Component Services.
The application list is gained by expanding Component Serv
Computers -> My Computer -> DCOM config.
The properties screen is gained by right clicking on the req
application and going to "Properties". When setting acces
launch permissions care should be taken to make sure that the
permissions are set for "remote access" (i.e. whether this app
depends on the service pack installed)
Note on the use of firewalls

Firewalls are normally disabled between the nodes of a cluster. If it is essenti
have the firewalls enabled, then port 135 should be opened for DCOM
communications
The correct configuration of a node can be tested with the Wizard utility "
DCOMUTIL.EXE" which is included under the "wizards" menu of
RESOLVE. This can be done by making a remote connection from a
computer to the cluster node. DCOMUTIL should be running under the
same account as the LSF services.
User Guide
Hysys and
UniSim Design
Excel
Eclipse
(all flavours)
494
These process simulators use a DCOM connection similar to the

OpenServer with the Petroleum Experts products.
The same procedure should be followed as for GAP and REVEAL (i.e.
described above).
The only differences are:
The Hysys COM object is called "HYSYS simulator" in the list. The
UniSim Design COM object is called "UniSim Design design simulator".
Under the "Identity" tab, the UniSim Design object can be set to
"launching user". The Hysys object must be set to "interactive user"
As with the objects described above, Excel uses DCOM for its
communication. The same procedure should be followed as above - the
COM object is called "Microsoft Excel application"
This is only supported if Eclipse is run on RedHat Linux (32- or 64-bit)
See the section on "Running scenarios on a mixed cluster" for more information.
The configuration of the LSF cluster can be performed from the Wizards | Run LSF Configure
section of the RESOLVE main menu.
This utility performs two tasks:
Configuring the OpenServer object (pxserver.exe) to have the necessary permissions
to be executed remotely. An account with administrative privileges will be required for
this.
Resetting the RESOLVE instances on each of the cluster nodes to use the factory
defaults. In other words, if RESOLVE is started in C:\PETEX, then it will obtain its
drivers from C:\PETEX, and GAP and REVEAL will also run from C:\PETEX. This is
considered to be the most commonly required behaviour, but it is also possible to set
up individual nodes with different behaviour by running RESOLVE on those nodes and
accessing the functionality in "Drivers | Register drivers".
The screen has the following appearance, and the options available are described below:
495
RESOLVE
Input fields
Directory
OpenServer
This is the path to the executable directory (i.e. the directory which contains
RESOLVE, the drivers, and the OpenServer executable, pxserver.exe) on
the remote machines
This should be selected to configure the OpenServer object (i.e. in the
above directory) with the permissions that it needs to be started from a
remote submission node. If "Use interactive mode" is selected then remote
jobs will be visible, i.e. the user will be able to see RESOLVE and GAP
starting on the remote node, and consequently the user must be logged into
the remote node. If the option is not selected, then the user need not be
logged in to the remote machine. Generally, this will be preferable, although
debugging may be easier if the interface is visible.
User Guide
RESOLVE
drivers
Select
cluster
nodes
496
See the section on windowed and non-windowed running of submitted

applications
This ensures that the drivers (i.e. the DLLs which implement the links to the
client applications) in the above directory are registered with RESOLVE
The nodes on which the configuration task selected is to run are selected
from this list. Only those nodes which are classed as "computation nodes"
are displayed
When Configure ! is pressed, the configuration task will be submitted to each node of the
cluster selected. The status of the task will be displayed in the list box at the bottom of the
screen. Any problems with the job will be shown here.
2.15.4.4.1.3 Running the scenarios in batch
If the "Use LSF clustering" button was selected on the "Running multiple scenarios" screen,
then the "Cluster Viewing" screen will appear.
From here, the usual viewing and configuration tasks can be carried out, but it is also possible to
submit the scenario jobs to the cluster.
The section under "Submit job" will be enabled when the screen is invoked in this mode.
497
RESOLVE
The following selections should be made:

Hosts
Submit to
queue
Host
Select in this list the computation hosts which are to be used in the run.
These are the hosts on which the client RESOLVE models will run. To select
all the nodes, click on "Select all valid"
LSF maintains several different queues to which jobs can be submitted see the LSF documentation for more information. From this list, the queue
to which the jobs are to be submitted should be selected
This governs the selection criterion for how LSF determines which node to
User Guide
preference
Data
directory
Executable
directory
Time outs
498
submit jobs to. Generally, LSF will submit jobs to those nodes which do not
have their CPUs loaded. Occasionally, if a model is memory intensive, it will
be necessary to order LSF to consider the amount of RAM that a machine
has when making its placement decisions
This is a shared directory which must be visible from all the selected nodes
with the UNC path supplied here (for example, \\window32\lsf_6.2\data,
where "window32" is the name of a computer in the cluster). This directory
is where RESOLVE will copy its models, and will also read results and error
data from the various jobs. It is vital that all the nodes and the submission
client have full read / write access to this directory
This is the directory which contains the executables (RESOLVE, GAP, etc).
The directory must exist on all the nodes, but need not be shared. Clearly, if
it is not shared, then a separate installation in the directory supplied must
be made on each node
These are normally left blank. However, some third-party applications may
pop-up error or warning messages when problems occur in their execution.
The messages block RESOLVE and effectively leave it in a "hanging" state.
By entering a timeout, LSF will know to "kill" a job after a certain amount of
time if it has not been completed. Clearly, this has to be used with care as
some runs can take a long time to finish, so a timeout value has to be
selected with this in mind.
If a job is killed through a timeout, it might be necessary to clean up the
processes from the node in question. This is because when LSF kills a job
it does not necessarily clean up all the child processes that were created.
One example may be that HYSYS or UniSim Design would be left behind if
the master RESOLVE model were killed.
Max number
of
simultaneous
jobs ...
Write debug
logs
Note that the Petroleum Experts applications should never block in this
way, as all blocking windows have been removed when run in this mode.
Any suspected deviations from this rule should be reported to Petroleum
Experts
If there is a limit on the number of jobs that can be run at a single time, then
the maximum number should be entered here. This might be a requirement
if there is a limited number of licenses of one of the applications.
Internally, RESOLVE uses a mechanism that is based on LSF resources to
implement this. Specifically, a resource has to be set up (the default name
of which is "resolve") by the cluster administrator which can be used to
restrict the number of jobs. If the resource is not defined, then it will not be
possible to use this feature.
For more information on how the resource should be set up, see "Cluster
administration tasks"
This should be left "off" by default. In certain cases there may be problems
submitting jobs to a node or nodes. In this case, this option can be
selected. During the run a log file will be written in the data directory (i.e.
499
RESOLVE
Save run
files
Write config
to file / Read
config from file
Submit
defined above) with the name: rjob_debug_n, where n is the number of the
scenario that was to be run. This debug file is explained in the "Cluster
troubleshooting" section, or it can be sent to Petroleum Experts
If this is selected, then at the end of every scenario run (i.e. on any node) a "
RESOLVE Archive" will be generated in the data directory. The archive will
contain all the input and output files that are associated with the model to
allow more complete examination of the results. Obviously, this can
generate a lot of data, so the default setting is "off"
These options will write the contents of the screen to a file, or read the
contents of the file and write them to the screen. These options may be
useful for recalling previous configurations, or the configuration file can be
sent to Petroleum Experts for debugging purposes
This submits the jobs selected previously to the nodes selected on this
screen. After submission, the jobs can be "monitored"
IMPORTANT NOTE
A problem has been noted with LSF in which jobs can not be submitted with
executables located on directories which have spaces in them.
In other words, the LSF command: bsub "c:\petroleum experts\ipm 6
\rjobsubmit.exe" fails because of the space between "Petroleum" and
"Experts"
There are two possible solutions:
1. Ensure that all the software is installed on a directory which does not
have spaces, e.g. C:\PETEX.
2. There is a fix supplied by Platform (i.e. the makers of LSF). Enter the
line: LSB_API_QUOTE_CMD=Y in the lsf.conf file on the master node.
The cluster administrator will then have to restart the cluster.
This problem has been noted in version 6.2 of the LSF cluster software
2.15.4.4.1.4 Monitoring the scenario runs
Once the scenario jobs have been "submitted", the status of the runs can be monitored.
There are two sources of status information.
Node status
At the bottom of the job submission screen is an area which displays the
status of all the nodes in the cluster that were selected to run jobs.
It has the following appearance, for example:
User Guide
Run status
500
If an error occurs on any of the nodes (for example, a failure to open the
RESOLVE file), it will be reported here.
If a node reports an error, then this node will be removed from the system
for the duration of the batch run. In other words, all the jobs will be
resubmitted to only the available nodes. If all the nodes fail, then the runs
are aborted
This is the standard RESOLVE screen which displays the status of the
scenario runs.
When run through LSF, the jobs will be displayed in one of four states:
Pending
Running
Completed
Error
the run has been submitted and is being queued

As shown below
the run has been made and the results will be
available at the end
this will only be displayed if there are no available
nodes left for the run, as discussed above
501
RESOLVE
Note that these two screens are refreshed on a timer, and so the information is always slightly
out of date compared with reality.
2.15.4.4.1.5 Aborting the scenario runs
The batch run can be terminated at any time by clicking on the "Abort" button of the "Job
submission screen". This is the button that was used to originally submit the job.
When the "abort" button is pressed, two actions are carried out:
All "pending" jobs (i.e. jobs that are not yet running) are killed.
Jobs that are running are sent a signal to terminate the run. It can take a few moments
for the run to respond to this signal.
If this does not kill the batch run after a reasonable amount of time, then it might be necessary to
kill the jobs from the command line.
Please refer to the "Cluster troubleshooting" section.
2.15.4.4.1.6 Cluster administrative tasks
The following is a list of tasks which must be performed on the cluster prior to RESOLVE runs
being carried out. This assumes that an LSF cluster has already been installed and is working
correctly.
Installation of the software
The IPM software must be installed and licensed on all the nodes of the cluster. It should be
installed at a common path for all the nodes, e.g. C:\PETEX. This is the path which is entered
into the "Scenario run setup" screen.
It is also possible to install the software on a common, shared, directory. This is useful in that
only a single installation is required. However, the disadvantage is more network traffic and
consequently lower performance.
It is possible to have a single, central, installation, and then use a script to copy it to all nodes of
the cluster.
IMPORTANT NOTE
A problem has been noted with LSF in which jobs can not be submitted with
executables located on directories which have spaces in them.
In other words, the LSF command: bsub "c:\petroleum experts\ipm 6\rjobsubmit.
exe" fails because of the space between "Petroleum" and "Experts"
User Guide
502
There are two possible solutions:

1. Ensure that all the software is installed on a directory which does not
have spaces, e.g. C:\PETEX.
2. There is a fix supplied by Platform (i.e. the makers of LSF). Enter the line:
LSB_API_QUOTE_CMD=Y in the lsf.conf file on the master node. The
cluster administrator will then have to restart the cluster.
This problem has been noted in version 6.2 of the LSF cluster software.
Configuration of OpenServer objects and RESOLVE
The OpenServer must be configured for remote access on all the nodes of the system, and
RESOLVE should be set up with the "factory default" settings. This can be done from the "Cluster
Viewing" section.
Configuration of other objects, as required (for example, Hysys, UniSim Design,
Eclipse)
RESOLVE models which reference these applications will not run unless the corresponding
objects have been configured for remote access.
Information on the configuration of Hysys and UniSim Design can be found in the "Manual
Cluster Configuration" section
Information on the configuration of Eclipse can be found under the section on "Mixed clusters".
Eclipse when run on the local PC is not currently supported in this mode.
Setup the shared directory
A shared directory is required that is visible from all nodes with the same UNC path. This
directory is used to copy the required data files for the RESOLVE run and all the scenarios at the
start of a batch job.
For example, it may be decided to set the physical location of this directory on machine_1. This
directory (say sharedir) should then be set up as a share with full read / write access for all
users. The directory could then be referenced from all nodes of the cluster with the UNC path \
\machine_1\sharedir.
Setup the job limitation resource ("resolve")

This is optional. It will be required if there is a possible limitation on the maximum number of
simultaneous runs that can be executed at one time.
The idea is that the LSF "resource" represents a fixed overall quantity which is divided between
the runs as they are started. As the resource is depleted the point is reached where no more
503
RESOLVE
runs can be started until some of the resource is released by a completed run.
The LSF resource must be set up in the cluster configuration files. By default, RESOLVE
assumes that the resource is called "resolve", but is not obligatory. If it is not called "resolve",
then this needs to be communicated to the users who need to enter the resource name in the "
Scenario run setup" screen.
The following edits should be made:
In the conf subdirectory, open lsf.shared.
Add a line as follows:
Begin Resource
RESOURCENAME
TYPE
INTERVAL
DESCRIPTION
# Keywords
mips
Boolean
()
architecture)
resolve
Numeric
()
(Resolve resource limit)
# dec
Boolean
()
(DECStation system)
sparc
Boolean
()
SPARC)
...
INCREASING RELEASE
()
()
()
(MIPS
()
()
()
(SUN
Also in the conf directory, open lsf.cluster.<clustername>.

Add a line as follows:
Begin ResourceMap
RESOURCENAME LOCATION
resolve
(10000@[all])
# tmp2
[default]
# nio
[all]
# console
[default]
End ResourceMap
This creates a resource with a total value of 10000. This value is very important - the
feature will not work unless the value is set to this. The value is shared across all the
nodes of the cluster, which is reasonable as long as no other processes (i.e. apart from
the RESOLVE application) are likely to use the resource.
Once this has been done, the cluster will have to be restarted. This can be done from a
command prompt at any LSF computation node in the cluster.
Type the following:
lsadmin reconfig, and
badmin reconfig
and wait.
User Guide
504
It might take a few moments for the cluster to come back to life.
The feature can be tested from the command line of an server or client host.
Type:
bsub -R rusage[resolve=5000] sleep 60
This submits the job "sleep 60" to the cluster. Repeat this several times (up to ten).
Then type:
bjobs
to view the status of all the submitted jobs. It should only be possible to see up to two jobs
running at once - all the remaining jobs should be queued and in a "pending" state.
Hardlock
RESOLVE when run under LSF must use a Petroleum Experts Hardlock for the licensing.
Please refer to Petroleum Experts or the Hardlock documentation for more information.
2.15.4.4.1.7 Cluster troubleshooting
If there are problems with running scenario jobs on one or more nodes, then it is possible to
troubleshoot these issues from the LSF command line interface.
A list of the most useful commands is given below. Obviously, there are many more commands
than this and they are detailed in the LSF documentation.
lshosts
bhosts
bsub
bjobs
This will list all the hosts in the cluster, including client hosts. If the command is
being executed from a floating client, this will also be included in the list
This lists the computation (server) hosts in the cluster, along with some dynamic
load information
This submits jobs to the cluster. As a test, the command bsub sleep 60 can be
used: this will submit the job sleep 60 to the normal queue, and typing bjobs
(below) should show that the job is either pending or is being executed on some
remote node. If there is a problem with a specific node, the command bsub -m
<computername> sleep 60 can be used. This submits the job to the specific
node computername
This will list the current set of jobs that have been submitted to the queue. If the jobs
were submitted under a different account, then bjobs -u all can be used to view
the jobs of all users. Alternatively, bjobs -u <username> can be used to retrieve
the jobs of a specific user.
The output of the command will have the following appearance:
505
bhist
RESOLVE
The first column contains the job ID. This is a useful figure which is used as the
argument for other commands, below.
This returns information on a specific job. Typing bhist -al <jobid> returns
extended information on the arguments that were passed to the job, its current
status, and how it completed (if it is finished)
Common problems
The "Node Selection" screen does not appear, but returns an LSF error.
This is normally because there is a problem with LSF itself. This can be verified by typing
lshosts and bhosts from the command line. If these commands do not respond
appropriately, then there is a problem with the cluster. If they do, then contact Petroleum
Experts.
One (or more) nodes returned an error message - "failed to open file"
The following tests should be performed.
1. Open the RESOLVE model on the client (submission) host
2. Create an "Archive" of the model on the shared data directory as specified in
the "Node Selection" screen.
3. Open RESOLVE on the computation node that is giving the error. Make sure
that the executable (resolve.exe) that is opened is the one from the directory
specified in the node selection screen.
4. Check that the drivers are all registered, and exist in the directory which was
specified in the node selection screen.
5. Extract the archive and open the RESOLVE model.
If the model can not be opened (which would be expected), identify the reason and rectify
(i.e. it could, for example, be that the version of RESOLVE that is run on the computation
node is older than that on the submission node). If it can be opened, the contact
Petroleum Experts.
The job starts but never completes (on one or more nodes)
To begin with, the incomplete job should be removed from the system. To do this, identify
the job (using bjobs) and then kill it using bkill <jobid>. RESOLVE should detect that the
job has failed and will resubmit the job on a node which is OK, if there is one available.
Having killed the job, it might be necessary to clean up child processes on the computer
in question, for example, Hysys processes.
Once this has been done, then the steps listed above should be followed to open the
model on the remote node. The model should then be run to identify what is causing the
job to hang - typically this will be caused by a message box appearing.
Note that it is possible to set a timeout period in the "Node Selection" screen to prevent a
job from hanging in this way.
One or more of the nodes returns a "version" error message
RESOLVE checks that the models that are opened on the remote computers are opened
with a version of the client software (e.g. GAP) which is compatible with the version on the
User Guide
506
submission computer. If an incompatibility is found, then an error is flagged. Check the

versions of the software that are installed on the remote machines.
One or more of the nodes returns a message saying that "RProxy open has timed out"
This is caused by the RESOLVE process (called RProxy) taking too long to open on the
remote computer. This may be because that computer is heavily loaded with other
processes, or there may be some other reason. Contact Petroleum Experts with a
debug log file for the node in question.
Debug log files
Log files can be generated by making the selection on the "Node Selection" screen. To debug a
specific node, select a single scenario to run and select just the problem node from the list. After
the job has been submitted and is completed (or is hanging, say) then it will be possible to view
the debug log file for the scenario.
The log file will be found in the data directory that was specified on the node selection screen.
The log file can be sent to Petroleum Experts for analysis.
2.15.4.4.2 Use of PXCluster
2.15.4.4.2.1 Overview
PxCluster is a clustering software that has been developed by Petroleum Experts, exclusively
for use with the Petroleum Experts IPM software. It allows multiple nodes to be grouped
together into a cluster, to which IPM jobs can be submitted. The nodes must be running
Microsoft Windows (XP, 2003 server, Vista).
The software can currently be used in two ways:
Distributing multiple realisations of a RESOLVE model onto the nodes of a cluster to
perform a probabilistic forecast, for example.
Distributing individual client models within a RESOLVE model onto the nodes of a
cluster.
2.15.4.4.2.2 Architecture
A PxCluster cluster of nodes requires the following:

A designated master node
A set of subordinate nodes. The master node and the other nodes are identical to the
outside world; the differences are all internal.
A shared drive with a common, UNC-style path that is visible from all nodes. The
shared drive holds a configuration file (pxcluster.cfg) which is read by all the nodes
All nodes must be running the pxcluster service.
507
RESOLVE
An environment variable, PXCLUSTER_ENV, must be set up on each machine to point

to the UNC path of the shared directory.
The number of nodes in the cluster and the location of the master node can both be changed "
Dynamically". The shared directory that contains the "Configuration file" should normally be
located on the master node, but this is not a requirement.
In addition, there are two types of node. Both types of node run the same service (pxcluster.exe).
Client nodes
Computation
nodes
These nodes submit jobs, but do not run calculations

These nodes can both submit jobs and perform calculations
Normally, there will be a pool of nodes which are used for calculations which can be accessed
from a (potentially) large number of client desktops. Client nodes and computation nodes can be
set up by the "Installer" or by hand from the "Configuration file".
User Guide
508
2.15.4.4.2.3 Installation and Maintenance
This section deals with the creation of a cluster, and also how that cluster is maintained, and is
organised as follows:
Installation pre-requisites
Setup utility
Test utility
Adding and removal of cluster nodes
Manually editing the configuration file
Dealing with new builds of IPM
Before creating a cluster with PxCluster, the following tasks should be performed.
A master node should This should normally be a machine which is not removed from the
network and is always on whenever the cluster is to be used. The
be designated
designation of the master node can be "Changed" later, as required
Select an initial set of Again, this set can be adjusted later
subordinate nodes
Create a shared
This shared directory will eventually contain the configuration file;
clearly no critical data should be kept in this directory. The share
directory with share
should normally be physically located on the master node, but this is
permissions set to
not a requirement
allow full access to
everyone
The shared directory Full rights of read and write access should be available for the
should also have full directory
read/write access to
everyone
Before proceeding, the IPM software should be installed and licensed on each node of the
cluster. This could be set up in a shared directory to allow all the nodes to see the software (i.e.
without the need for multiple installations), but there may be performance issues with this. It is
preferable to have a separate installation for each node.
Note also that the installations should be symmetrical, that is each node should "see" the same
path to the IPM executables. It is important to bear this in mind when installing the software on
64-bit machines, for example, where the default installation directory (Program Files (x86)) is
different to that for 32-bit machines.
Once the "Pre-requisites" have been carried out, the cluster can be created or edited using the
PxCluster setup utility.
509
RESOLVE
The PxCluster setup utility can be run from the Start menu (Petroleum Experts IPM xxx |
Utilities | Install PxCluster) or found in the distribution (pxclusterinstall.exe).
It is in the form of a wizard:
Screen 1
setting the PXCLUSTER_ENV environment variable
The location of the shared cluster drive (i.e. described in the "Pre-requisites"
section) should be entered into the edit field at the top of the screen. The "
browse" button can be used to locate the drive in the network neighbourhood.
The drive given here must be visible to all the nodes of the cluster; this means
that it will invariably require a UNC path or some common drive mapping to
represent the drive.
The "Test" button can be used to check that the configuration file (i.e. once it
has been set up) can be read.
User Guide
510
Click "Next" to proceed to the next screen. If the environment variable has been
changed, a reboot will be required at this point (i.e. which the utility will perform
automatically). After the reboot, restart the utility and proceed to the next step.
Clearly, if the environment variable has already been set up the utility will not
prompt for a reboot
Screen 2
setting the cluster nodes
This screen presents a list of the available nodes on the domain and a current
list of the cluster nodes, if any have been set up.
If the cluster is to be built or edited, then the "build pxcluster.cfg" check box
should be clicked. This will enable the rest of the screen.
Add nodes to the cluster by highlighting elements on the left hand list and
clicking the right arrow button.
Remove nodes from the cluster by highlighting elements on the right hand list
511
RESOLVE
and clicking the left arrow button.

A master node should also be selected here. Highlight the required node in the
right hand list and click the master node button.
Screen 3
After the nodes have been set up (if this is required) click the "Next" button to
proceed to the next screen
start the pxcluster service
The PxCluster service must be installed and then started. The buttons on this
screen can be used to do this.
The service is installed as an "automatic" service. This means that the service
will be started automatically when the system is started.
Note that the service will not start if the PXCLUSTER_ENV environment
variable is not set, or if the service can not see the pxcluster.cfg configuration
User Guide
512
file (i.e. which should be located on the cluster shared directory).

If the service fails to start, more information can be found in the "
Troubleshooting" section
The PxCluster
service fails
to start
Installing /
uninstalling
the service
manually
Starting /
stopping
the service
manually
Information on why any service fails to start can be found under the "
Application" section of the Event Viewer. This can be found under the
Control Panel | Administrative tools | Event Viewer.
The usual reasons why the service may fail to start are:
The PXCLUSTER_ENV environment variable has not be set up
The location pointed to by PXCLUSTER_ENV is not visible from the
node in question. Check that the location is valid, and also that the
share permissions on the directory in question are set to allow
everyone to use it. Remember that the PxCluster service runs under
the system account, and not the login account of the computer.
If PXCLUSTER_ENV is set correctly, then it is possible that the
pxcluster.cfg file does not exist or can not be read. Note that the
permissions on the shared drive should also be set to allow full
access to everyone
To install or uninstall the service, open a command prompt and navigate to
the directory which contains pxcluster.exe.
To install the service, type:
pxcluster -install
To uninstall the service, type:
pxcluster -remove
If it is necessary to stop or start the service, then this can be done from the
Control Panel. A list of all services is displayed under Control Panel |
Administrative tools | Services. The entry for PxCluster can be
highlighted, and from here the service can be started or stopped as
required using the various menu options
The test utility can be invoked from the RESOLVE main menu (Wizards | Run PXCluster test
environment) or from the distribution (pxclustertest.exe). It has the following appearance:
513
RESOLVE
The top section lists the nodes in the cluster, their operating systems, their status (OK or invalid/
inaccessible), and how many jobs (i.e. submitted through PxCluster) are being run on each
CPU.
The lower section is a list of the jobs that have been submitted from this node; jobs submitted
from other nodes are not included. The job list indicates the status of each job, where the job is/
was running, and the start and end time of the job (as applicable).
User Guide
514
This utility can be used to test the cluster. The "submit test job" button will submit a job called
"pxsleep" (i.e. this executable is included in the distribution). The job simply "sleeps" for 40
seconds before exiting. All jobs submitted using this button should appear in the job list and be
reflected in the node status list. If more jobs are submitted than available nodes then the
outstanding jobs will be put into a "pending" state and submitted as running jobs complete.
To update the display, the "update" button can be used. Alternatively, checking the "Automatic
update" button will cause the screen to automatically refresh every 20 seconds.
An existing cluster can be edited by adding or removing nodes, or changing the location of the
master node.
Before starting, it is recommended that no cluster jobs are running. Indeed, this is essential if the
master node is to be changed.
The cluster configuration can be changed either from the "Setup utility", or by manually "Editing
the configuration file".
Using the
setup utility
Editing the
configuratio
n file
The setup utility should be started, and the "Next" button pressed until the
"nodes" screen is reached. Nodes can then be added or removed, and the
master node changed, in the usual manner
This is described in the "Edit the Configuration File" section
The configuration file (pxcluster.cfg) is placed at the location pointed to by PXCLUSTER_ENV. It

is a human-readable/editable text file, which is normally generated in the first instance by the "
Setup utility".
A typical configuration file might have the following appearance:
NODE PREC670-WORK1 12734
NODE GX280-WORK2 12735
NODE PREC670-WK3-64 12736
NODE ITSYSTEMS031 12737
NODE DAVE-NW8240 12738
NODE DEV03-PREC360 12739
CLIENT DESKTOP1 12740
CLIENT DESKTOP2 12741
HANDSHAKE_TIME 20
JOB_TIME 5
DEBUG 0
515
RESOLVE
OLDJOB 300
Every so often, the services on the cluster nodes re-read this file. The file can therefore be
edited "in place", and the configuration changes will eventually feed into the cluster.
The file consists of a series of keywords, described below.
NODE
This keyword sets up a cluster node.

The format is:
NODE <machine name> <tcp/ip port>
By default, the ports are different for each node but this is not obligatory. These
ports should be opened through any firewall, although it is infinitely favourable
for the firewall to be removed altogether
CLIENT
This is the same as the "NODE" keyword, but is used to set up a client, rather
than a computation, node
HANDSHAK This keyword gives the time (i.e. in seconds) between handshakes between the
master and the subordinate nodes. The default time is normally fine, and should
E_TIME
normally not be made shorter than this
JOB_TIME
This is the time between checks made on the current job queue. In the case
above, running jobs (both local and on other nodes of the cluster) are checked
every 5 seconds . Again, the default should not normally be made shorter than
the default
DEBUG
This can be set to "1" to enter debug mode. In this case, debug logs will be
written to the directory pointed to by PXCLUSTER_ENV. The log files are
written by the cluster service, and are labeled with the name of the node on
which the cluster service is running
OLDJOB
Jobs that have been completed are retained in the job list for a time given by
the value after this keyword (in seconds). Completed jobs are not processed in
any way, but are merely kept for reporting. After this time, they are removed
from the list
When IPM is uninstalled, it will automatically stop and uninstall the pxcluster service if it is
running. Clearly, this removes the node from the cluster.
When IPM is reinstalled, it creates the pxcluster.exe in the distribution but does not install the
service. This is a task that must be performed before the node can function in the cluster again.
The service can be installed and started from the "Setup utility" or "by hand".
2.15.4.5Running scenarios on a mixed cluster
It is possible to run scenarios in batch on a Windows cluster. It is also possible to run batch
User Guide
516
scenarios when one or more of the applications running under RESOLVE are running under a
different operating system (e.g. Linux).
The only application link that does not (necessarily) run on Windows and is developed and
supported by Petroleum Experts is Eclipse when run on Red Hat Linux. This section is
therefore devoted specifically to this link, although other application drivers that are developed
by third parties could also support a similar functionality. The developers of these links should be
contacted for more information.
To use Eclipse in batch scenarios the "TCP/IP" method of connecting RESOLVE to Eclipse
must be used, which is documented extensively in the "linux_executables_for_resolve_eclipse"
subdirectory of the installation directory.
In summary, there are two possibilities when using this connection:
Eclipse running on a known node (using mpirunfactory_scampi.exe or
mpirunfactory_mpich.exe)
Eclipse running on a known determined by LSF (using mpirunfactory_lsf.exe)
In the first case, the "run factory" creates an Eclipse controller and Eclipse itself. The controller is
always on the same computer as the run factory, but Eclipse can be distributed onto a different
node of the cluster.
In the second case, the "run factory" submits a job to LSF to spawn a "run factory client" on a
(potentially) remote node. This client program then spawns the controller and Eclipse on this
same node.
Eclipse
mpirunfactory
mpieclcontroller
mpieclcontroller
Eclipse
mpirunfactory
To use Eclipse in a batch scenario run, the second form of the connection must be
used.
Architecture
517
RESOLVE
As described in the "Clustering Basics" section, each node of the Windows cluster is running a
copy of the RESOLVE model. Each copy is pointing in turn to an instance of Eclipse on the
remote computer. If the remote computer is running the LSF run factory daemon
(mpirunfactory_lsf.exe) then, as each instance of Eclipse is required, the daemon will spawn the
new instance of Eclipse on an unknown node of the Linux cluster.
2.16 Analysing and Reporting the Results

2.16.1 "Results" Section
This allows the RESOLVE forecast results to be accessed and reported.
View Forecast Results This enables to access the RESOLVE forecast results in a
(table)
TABULAR form.
User Guide
518
Refer to the "Tables of Results" section for further details

This enables to access the RESOLVE forecast results in a PLOT
form.
Refer to the "Plotting the Results" section for further information
View Forecast Plots
This enables to open another plotting window, in addition of any
plotting window already opened.
(new window)
Refer to the "Plotting the Results" section for further information
Generate report
This generates a report of the results of the current run. A screen will
appear with options as to whether to report to the clipboard or a file,
and whether to 'delimit' the entries in the report with some character
(e.g. a comma), or to format the columns with a fixed width
View Scenario Results If RESOLVE has been used to run several sets of scenarios, this will
(table)
enable to retrieve the results of the different scenarios in a
TABULAR form - as all the scenarios results will be automatically
saved once the scenarios have been run, it will be possible to
compare the results from the different scenarios in the plot sections
for instance.
Refer to the "Tables of Results" section for further details regarding
how to manipulate these results
View Scenario Plots
If RESOLVE has been used to run several sets of scenarios, this will
enable to retrieve the results of the different scenarios in a PLOT
form - as all the scenarios results will be automatically saved once
the scenarios have been run, it will be possible to compare the
results from the different scenarios in the plot sections for instance.
Refer to the "Plotting the Results" section for further details regarding
View Scenario Plots
This enables to open another plotting window for scenario results, in
addition of any plotting window already opened.
(new window)
Refer to the "Plotting the Results" section for further details regarding
View Optimisation
Invokes the "Optimisation Results" screen
Results
View IPR log results
If the IPR logging option has been selected prior to the run, then this
section will enable to access the IPR log results: these will consist of
a set of inflow performance curves provided for each well at each
timestep.
It will also contain information regarding the well operating points for
each timestep (i.e. the intersection between IPR and VLP)
View loop results
Invokes the loop results screen
Log Window
Displays the log window.
The log window can be written to by script commands (i.e. see the "
Scripting" section for more information), which is potentially useful for
debugging purposes.
The log file is saved with the RESOLVE file - this menu item can then
be used to display the currently saved log file
View Forecast Plots
519
RESOLVE
2.16.2 Tables of Results

This section , accessible through Results | View Forecast Results (table) or Results | View
Scenario Results (table) enables to access the RESOLVE forecast results in a TABULAR
form.
For each forecast run, the results presented will be the following for each client module:
The variables automatically selected by RESOLVE: for instance when considering a
GAP model, the production rates for the different wells CONNECTED to a reservoir
model through RESOLVE.
The variables selected by the user prior to the run by right-clicking on the client module
icon and selecting the "Output Variables" section.
The screen displayed will be as followed:
The left hand side drop-down box enables to select which results to be displayed, for instance
here the results for the "Well 2" in the "Production" network model for the current run.
User Guide
520
In this screen, the following icon bar appears:
enables to plot these tabular results - It is equivalent to using the "View Forecast
Plots" section described below
enables to create a secondary plot window - It is equivalent to using the "View
Forecast Plots (new window)" section described below
enables to save the results of the current run.
Once selected, the following screen appears: use the "New Stream" section to save
the results of the current run in memory. Once this is done, then these results are kept
within the RESOLVE model and can be consulted / compared to other runs.
2.16.3 Plotting the Results

This section , accessible through Results | View Forecast Plots or Results | View Scenario
Plots enables to access the RESOLVE forecast results in a PLOT form.
When selecting this option, the following screen is displayed:
521
RESOLVE
In order to generate a plot in this screen, the following procedure can be used:
On the left hand side of the screen, select the element to consider - for instance here
Well 2.
User Guide
522
The variables available for Well 2 are displayed in a list in the bottom right hand corner.
sign at
Select one of these variables - here Liquid Produced - and click on the
the bottom right hand corner of the screen. The screen below will appear, which
enables to select multiple streams - here for instance the Well 2 / Separator / Well 1
and Well 1_GL elements are selected: the plot will then plot the liquid produced for all
these nodes.
523
RESOLVE
Click on "OK" and the plot is displayed, as illustrated below:
User Guide
524
The different streams that are plotted are described on the right-hand side of the screen the user can decide which ones to display in the plotting area by using the tick boxes next
to each one of these streams labels.
The following icon bar appears at the top of the plot:
enables to access the plot editing screen illustrated below: this screen will enable to
define the format of the plot in order to tailor it to the user's needs.
525
RESOLVE
enables to automatically come back to the initial plot format - this is particularly useful
when the plot has been zoomed IN or zoomed OUT and the user wishes to come
back to the original display
enables to suppress one or all the streams displayed on the plot
enables to save the results of the current run
enables to save the setup of the plot under a specific name: this is extremely useful as
it enables the user to define one specific plot and to automatically reload it as soon as
a new run has been performed without having to redo the plot setup.
automatically reloads any plots that have been saved
2.16.4 Optimisation Results

The optimisation results screen is displayed every time RESOLVE performs an optimisation. It
can also be invoked from the menu by clicking on Results | View optimisation results. It
contains information that can be useful for debugging optimisation runs.
It has the following appearance:
User Guide
526
The body of the screen consists of four tabbed sections and a Save Results section, as follows.
Ctrl (control)
Results
Fn (function)
Results
This displays, for each iteration, the values that the control variables have
been set to
This is displayed in the above screen capture. It contains a list of the results
for the objective function and the constraint equations.
In the above example, the first row represents the value of the objective
function obtained by RESOLVE following a pass through the system (i.e. at
each iteration of the optimiser). The second row contains the value
predicted for this equation by the optimiser. The third and fourth rows
contain the error term calculated from the first two columns. This term is
used to calculate new bounds for the control variables at the next iteration.
Below is the same information for each constraint equation in turn.
The value in green represents the current optimum found by the optimiser.
A value in red (for constraint equations) represents a constraint violation. A
value in pink is a constraint violation that is within tolerance
527
RESOLVE
Overall
Results
Save results
stream
At the end of the run, this will display the results for the objective function,
the constraint equations, and the controls.
More information is displayed in the panels below: the current iteration, the
convergence status, and the current optimised solution.
Each of the above tabbed screens allows the saving of a system state. The
control and function results screens allow the state of the system at a
particular optimiser evaluation to be saved. The overall results screen
allows the optimum system state to be saved. This state can subsequently
be re-applied to the system, either from the interface or from the event
driven scheduling
In the same way that forecasts results can be saved to a separate screen,
optimisation results can be too.
A screen is displayed prompting to select a label for the new results
screen.
Next time the optimisation results menu item will be prompted, a screen
similar to the following will be displayed:
The left hand side contains a list of the currently saved streams. These
streams can be removed here (except for the current results).
The right hand side contains a summary of the optimisation run that was
performed.
To display optimisation results, highlight the required results in the left hand
User Guide
528
list and click on the display button
2.16.5 Loop Results

This screen, which can be invoked from the Results | Loop Results menu item, contains the
results for the loop iterations that RESOLVE performs when solving a loop.
When displayed, it has the following appearance:
Target Variables The list at the top contains all the target variables for the RESOLVE run.
Highlight the target variable for which the results have to be viewed
Results section The grid on the lower half of the screen contains the results for each pass of
the calculation over the loop (iter #1 and iter #2 in the screenshot above).
529
RESOLVE
If a forecast was performed these results will be given as a function of date,

which is displayed in the left hand column
2.17 "Window" Section

This section provides menu items to manage the main RESOLVE display windows as follow:
Cascade
enables to cascade the view : one window is located on top of another but
slightly shifted so that all the windows are visible.
Tile
enables to tile the main visualisation screen of RESOLVE in equal sections

for each windows: all the windows will be entirely visible, but the scale of
each window will be adapted to fit the size of the screen.
User Guide
Arrange Icons
530
enables to automatically arrange the RESOLVE icons
2.18 "View" Section

This section provides menu items to display / hide:
The toolbar (at the top of the main window)
The status bar (at the bottom of the main window)
The infoviewer (to the left of the main window)
2.19 Appendix
2.19.1 Further Technical Elements - OpenServer
2.19.1.1Overview
The OpenServer is the mechanism by which external applications can interact and control all
the programs in the IPM suite (PROSPER, GAP, REVEAL, PVTP, MBAL, and RESOLVE)
For example a VBA macro in Excel can be used to open, interrogate, and run IPM programs.
The OpenServer functionality that is in RESOLVE operates on the same principles as other
programs.
531
RESOLVE
For more information, see the OpenServer manual that is distributed with the IPM suite.
There follows a brief overview of the functionality of the OpenServer with specific reference to
RESOLVE.
External OpenServer macros can be written to control RESOLVE. These macros can be written
in any language that supports automation, for example: Visual Basic, VBA, VBScript, C++,
Java, Matlab.
Most typically they are written as VBA macros in an Excel spreadsheet; the "OpenServer
example macros" are in this form. An OpenServer macro can call three different functions /
subroutines on the program (RESOLVE) it is controlling.
These are:
retval = DoGet("tagstring") : interrogates a variable in the application (for example, the
schedule start date).
DoSet("tagstring", "value") : sets a variable to the value "value".
DoCmd("tagstring") : performs a command (for example, load a file, perform a run).
In each case, tagstring is a "." delimited string that refers to the variable or command in
question.
For example, to get the start date in RESOLVE, the following string will be used:
retval = DoGet("Resolve.Schedule.StartDate.DateStr")
will return the date in the form of dd/mm/yy (depending on the international settings).
To execute a prediction run, use:
DoCmd("Resolve.Run"),
and so on.
In each case the tagstring starts with the application name (in this case, RESOLVE).
When getting or setting a variable, the rest of the string is a delimited list of child variables until
we get to the required variable (DateStr is a "child" variable of the "StartDate" property, which is
a child of the Schedule data, and so on).
RESOLVE supported OpenServer variables are documenteed in the "Module Variables"
section.
When executing a command, the string simply refers to the command to be executed: these are
documented in the "Commands" section.
There is a quick way to find an OpenServer tagstring if the variable is part of the user interface.
In this case, go to the required screen and press <Ctrl> and Right Click over the variable in
User Guide
532
question.
A screen will appear with the variable tagstring which can then be copied to the clipboard.
Hysys and the OpenServer

The Hysys driver supports the use of the OpenServer (see the "Module variables" section
for further details).
In versions 3.1 and later of Hysys, the Hysys application by default pops up a message
box whenever a file is loaded.
This obviously halts OpenServer - the macro cannot continue until this message box has
been cleared.
To remove the message box, from the Hysys application go to Tools | Preferences |
Simulation Page and uncheck the item: "Confirm before adding if active correlations are
present" under "Stream property correlations".
In fact, the preferences should be set to avoid pop up windows that may interrupt the
OpenServer operation
Note on the use of dates

When a date property is returned it is returned in the form of the number of days since
01/01/1900. This can be useful to perform arithmetic calculations on dates (differences,
etc). To return a calendar date, append the string ".DateStr" (as above) to the tagstring
Empty variables
Variables that are not set (or are blank) in RESOLVE return a large number (3.4e34) when
the OpenServer queries them
Testing OpenServer commands

A very convenient tool exists to do immediate tests of OpenServer tag strings. It can be located
under the Wizards menu: Wizards | Execute Openserver command.
2.19.1.2Top Level Variables
2.19.1.2.1 Top Level Variables : Overview
Properties and Collections
Some variables in RESOLVE are collections of data items.
For example, the Module data below is a collection of the client modules that are embedded on
the RESOLVE interface.
An element of a collection can be accessed with either a numerical index (e.g. Resolve.Module
[0]) or by label in curly brackets (e.g. Resolve.Module[{Network}]).
More details are given below where appropriate.
Certain properties can be interrogated or (depending on whether the collection is read only) set
for all collections.
These are:
Count
Returns the number of objects in the collection

533
RESOLVE
Add
Reset
Remove
Adds an item to the collection.

Example syntax: DoSet("Resolve.Schedule.Add", 1)
Removes all items from the collection
Remove a given item from the collection.
Example syntax: DoSet("Resolve.Schedule.Remove", 1)
Variables at the Top Level, e.g. DoGet("Resolve.DebugFlag")

DebugFlag
IsRunning
IsError
ErrorMsg
EnableOptimisation
Module
Driver
Schedule, ScheduleList
ModLink
Connection
Properties
Optimiser
OptimiserSchedule
AdvancedScheduleStart
Sets or clears the flag that determines whether debug data is

saved during a run.
Example syntax: DoSet("Resolve.DebugFlag", 1))
Returns whether or not RESOLVE is currently performing a
forecast or optimisation run
Returns the error status of the last run that was performed, i.e.
whether the run terminated successfully or not.
If the run failed with an error, this returns the failure message
Sets or clears the flag for performing an optimised solve or
forecast. Finer control of optimisation runs (e.g. setting or
removing controls and constraints from the problem) is available
through the Module data items or the Optimiser Schedule data
items (see below)
A collection of module data items.
To index a given module, the alias or label of the item can be
used: e.g. Module[{Reservoir}].
For more information on Module variables, see "Module
variables"
A collection of drivers registered with the RESOLVE application.
See "Driver variables"
The schedule data, as accessed from the "Schedule" screen in
the interface.
See "Schedule variables"
A collection of individual module connections, containing data
such as the calculation order and adaptive timestepping
sensitivity.
See "ModLink variables"
A collection of connection data items.
See "Connection variables"
The RESOLVE preferences.
See "Properties variables"
The optimisation parameters.
See "Optimiser variables"
In a forecast run these variables control the way the problem can
be changed as a function of time.
See "Optimiser schedule variables"
/ These refer to the various sections of the "Event driven schedule
User Guide
534
AdvancedSchedulePreSolve ". More information can be found in the "Event Driven Schedule
/
Variables" section
AdvancedSchedulePostSolv
e
Scenario
VarLink
See "Scenario manager variables"

This collection refers to the collection of "Variable links" in the
model. See "Variable link variables"
The results variables. This top-level variable is retained for
backwards compatibility. From IPM #6, the results can be
obtained from the "Module variable". Regardless of this, the tag
strings for these variables depend on the case being run and
can always be determined by using the <Ctrl> <Rclick> method
Results
Runtime variables
The following variables are top level variables that can be accessed during a RESOLVE run.
RunOneStep
NextTimestepEnd
CurrentTime
LastTime
Timestep
If a run is performed with a series of "RunOneStep" commands, then

after every command the following variables can be interrogated (all
read-only)
Returns the projected date of the end of the next timestep
The current date at which the run is sitting
The date before the last timestep leading to this one
The (integer) number of timesteps since the start of the run.
The date variables return a double-precision number which is the
number of days since 01/01/1900.
To get a date string the user can append .DateStr to the tag strings
For example:
DoGet("Resolve.CurrentTime") may return 36525.0, while as
DoGet("Resolve.CurrentTime.DateStr") will return 01/01/2000.
2.19.1.2.2 Module variables
2.19.1.2.2.1 Module Variables : Overview
Module Collection
There are no variables specific to this collection. Index individual items by number (Module[0]) or
label (Module[{Network}]).
The collection is read only. Module lists can be manipulated (created/deleted/linked) by calling
an appropriate "command".
Module Item
XPos / YPos
Alias
Driver
The position of the module icon on the main screen

The label / alias given to the module when it was created
Data pertaining to the registration information of the driver (see "
535
RESOLVE
Driver variables")
A collection of source/sink child data for the module (see "SrcSnk
variables")
OptCtrl
A collection of optimisation control variables specific to this module
(see "Module Optimisation variables")
OptConstraint
A collection of optimisation constraint equations specific to this
module (see "Module Optimisation variables")
OptObjFn
The objective function (if present) for this module (see "Module
Optimisation variables")
ShowChildren
Determines whether the module child icons are displayed
(expanded) on the main screen
ProducesComposition Returns whether the module produces compositional / EOS data
s (read only)
BaseComposition
For a compositional module, returns the base set of compositions
that will be used in the run
(read only)
CalcOrder
The calculation order in the RESOLVE system: as specified in the "
Calculation Order" link
StartDate (read only) The start date of the module (which may be different to the
RESOLVE start date).
This could be the start date of a reservoir simulation run, for example
MsgBuffer
When a run is performed, messages (which may be warnings or may
be purely informational) are written to the log window. This string
allows OpenServer access to these messages.
SrcSnk
All the messages output over the entire run are output to a single
buffer.
PubVar
Equip
Results
Resolve.Module[{<module>}].MsgBuffer.Count - returns the number

of messages in the buffer
Resolve.Module[{<module>}].MsgBuffer[n].Msg - returns the text of
message n
Resolve.Module[{<module>}].MsgBuffer[n].Date(.DateStr) - returns
the numeric (or text) date in the forecast at which the message was
logged. If the run was not a forecast run, this value will be empty (see
the note in the "overview"
A collection of published (exported) variables from the module in
question. See "PubVar variables"
A collection of equipment items for the module in question.
The nature of the equipment obviously depends on which module it
refers to. See "Equip variables"
The results from the last run. Full OpenServer strings can be
obtained by using <ctrl> and <rclick> on the "results screen", but
some guidelines are presented below.
To obtain a result value, the following syntax can be used:
Resolve.Module[{<module>}].Results[{<run>}][{<item>}][<index>].
User Guide
536
<variable>
where:
<module>
<run>
<item>
<index>
<variable>
the parent module on the RESOLVE screen

the last run that was performed is referred to by the string
"CurrentRun". Other saved streams are referred to with their
the item in the results, which could be a piece of equipment
feed stream, for example
in a forecast, this is the timestep for which a value is require
the variable name
For example:
Resolve.Module[{Production}].Results[{CurrentRun}][{W1}][1].
GasProduced will return the gas rate for item "W1" in module
"Production", timestep 1, for the last run that was performed.
The variable names can also be enumerated:
Resolve.Module[{<module>}].Results[{<run>}][{<item>}].VarList.
Count will return the number of variables exposed by the item
<item>. The variable labels themselves can be returned with:
Resolve.Module[{<module>}].Results[{<run>}][{<item>}].VarList[n].
Label.
DisableFlag
The label returned from this can be used as the <variable> in the
OpenServer strings shown at the start of the section
Read-only - returns whether a module is currently disabled or not
Commands
Mask
Disable
(DoCmd ("Resolve.Module[{}].Mask()") / UnMask (DoCmd("Resolve.Module

[{}].UnMask()")
These mask or unmask all the connections to or from the module in question
(DoCmd("Resolve.Module[{}].Disable()") / Enable (DoCmd("Resolve.Module
[{}].Enable()")
These disable or enable the module in question. See the description of the
menu ""Edit" commands" for more information
If RESOLVE does not find the module variable in the above list, it will pass the string on to the
driver which controls the application in question. These "variables" are thus considered internal
to the application driver.
2.19.1.2.2.2 Module internal driver variables
If a variable refers to a particular module but can not be found in the "standard module variable
537
RESOLVE
list", RESOLVE will pass the string on to the driver which controls the application in question.
For example, the tagstring:
Resolve.Module[{GAP}].CaseDetails.FileName
does not represent a variable in RESOLVE, and so the string "CaseDetails.FileName" is
passed on to the GAP driver, where it is recognised as referring to the GAP filename.
In the case of IPM products (REVEAL / GAP), the string will be passed on to the OpenServer of
the connected applications if it is not processed by the driver.
For example:
Resolve.Module[{GAP}].MOD[{PROD}].INFLOW[{comp1}].IPR[0].ResTemp
will refer to an internal variable of GAP (a well layer temperature).
To obtain file names from the applications, it is preferable to use the OpenServer "
command" MakeProjectFile().
The OpenServer syntax below is not standardised, while the interface that is used by
MakeProjectFile() is.
For the same reason, equipment items and variables should be obtained from the Equip
collection of the "module variable".
The following sections relate to the Internal driver variables for the following applications:
GAP
Reveal
Hysys
UniSim Design
Eclipse (all types)
Excel
2.19.1.2.2.3 GAP internal driver variables
CaseDetails variable, e.g. Resolve.Module[{GAP}].CaseDetails.FileName

This variable refers to general information on the contents of the GAP icon in RESOLVE.
FileName
HostName
Cluster
ClusterMode
System
Gets or sets the GAP filename to open

The host machine on which to run GAP
Set to "1" to start GAP on the nodes of a cluster. In this case, the
HostName will be ignored
If Cluster is set to 1, this can be set to:
0 - PxCluster
1 - LSF
0 - main system
1 - associated water injection
User Guide
538
2 - associated gas injection

0 - do not calculate the system potential when optimising
1 - calculate the system potential
PredictiveModel
0 - set according to GAP model
1 - always non-predictive
GasLift
If non-zero, include the available system gas lift as a sink icon that can
be connected to (e.g. from a process model or Excel spreadsheet)
GasLiftProps
If the "gaslift" flag (above) is on, this indicates whether the properties
(rather than just the rate) of the lift gas are to be passed
GasLiftWells
If this is on, it indicates that each gaslifted well should have an icon
which can be connected to a lift gas supplier (e.g. a process model or
Excel spreadsheet). Note that, if the lift gas rate is to be optimised then
the quantity passed here rpresents an upper limit on the gas available
for the optimiser. If it is not optimised, then the amount passed is a
fixed quantity that will be entered in the well
GasLiftWellProps
Equivalent to GasLiftProps for the well gaslift. This indicates whether
the lift gas properties for the well lift gas are to be passed
InlineInjection
If this is set, then inline injection elements will be displayed as
additional icons to be connected to on the RESOLVE schematic
UnusedGasLift
If this is set, then the lift gas that is unused by GAP (the total available the total amount used) will be displayed as a separate source icon in
RESOLVE
SeparationStreams For the black oil case, if this is set then the oil, water, gas, and lift gas
streams at the separator level will be represented as separate source
icons in RESOLVE. They will be displayed as child icons of the
separator
StopOnSolverFailure If this is set, then the run will terminate if, at any time, the GAP solver
fails for any reason
SaveSnapshots
This will cause GAP (when run predictively) to always save prediction
snapshots for subsequent debugging. If it is not set, then snapshots will
be saved in GAP according to the internal setting of the GAP model
DebugTables
If the wells are set to perform IPR regression (when connected to a
reservoir simulator), then this flag indicates whether the IPR tables
should also be written (to enable debugging after the run)
UseGradient
If the wells are set to perform IPR regression (when connected to a
reservoir simulator), then this flag indicates whether the rate gradient
from previous timesteps will be used to calculate the GOR and water
cut (or CGR and WGR for gas/condensate wells)
CompItem
e.g. Resolve.Module[{GAP}].CompItem
This returns (or sets) the name of an item in GAP that will be used to
obtain composition names for the entire model, prior to a run. If it is
blank then each connected item will be interrogated in turn to get the
component names, and these sets of names can be different for each
item.
Potential
More information can be found in the "GAP driver composition section"

539
RESOLVE
SS
SourceSink) variable, e.g. Resolve.Module[{GAP}].SS[0].Label

This sets or returns variables specific to individual sources or sinks of
the GAP model
Label
Type
Phase
OSEquipLabel
MatchIPR
IPRModel
Returns the label of the source or sink. For a well, for exa
would be the well label
The following item types may be returned:
Well
Inj Manifold (injection manifold)
Separator
Separator sub-stream
Inflow
Source (GAP source)
Sink (GAP sink)
Total lift gas (lift gas for the entire system)
Unused lift gas
Well lift gas (lift gas icon specific to a given well)
User joint (additional joint selected by the user for output
InlInj (inline injection)
Read-only variable. Values can be:
Liquid
Water
Gas
Condensate
Unknown
The label that would be used to identify the equipment
OpenServer string, if this is applicable.
For example, if this were queried for an item in RESOL
represents a manifold in GAP, it would return "Joint". This
be inserted into the GAP OpenServer string:
GAP.MOD[{PROD}].x[{y}].SolverResults[0].Qoil
where x is the OQEquipLabel returned here, and y is
described above
If this is applied to a well, it sets (or returns) the flag tha
whether an IPR regression is to be applied on any IPR that
from a reservoir simulator
The model that will be used in the IPR regression pe
MatchIPR is set.
0 - always for oil wells. For gas wells, this refers to the F
model.
1 - C and n (gas wells)
2 - Forcheimer pseudo pressure (gas wells)
User Guide
540
2.19.1.2.2.4 Reveal internal driver variables
CaseDetails variable, e.g. Resolve.Module[{Reveal}].CaseDetails.FileName

This variable refers to general information on the contents of the REVEAL icon in RESOLVE.
FileName
HostName
RestartFrom
Sets the REVEAL filename to open

The host machine on which to run REVEAL
The index of the restart file from which REVEAL should be restarted.
0 represents no restart - perform equilibration
GlobalControlMode The global control mode for all the wells in REVEAL.
Values are:
0 - fixed bottom hole pressure
1 - fixed rate
2 - fixed THP
3 - "system response". This is the default for a new model
LoadCompletionDat Specifies whether completion data should be loaded as children under
the individual wells
a
2.19.1.2.2.5 Hysys internal driver variables
CaseDetails variable, e.g. Resolve.Module[{Hysys}].CaseDetails.FileName

FileName
HostName
TransferMode
Sets the Hysys filename to open

The host machine on which to run Hysys
0 - (default) pass all the compositional data to Hysys
1 - pass only the black oil data (effectively mass flow rates,
pressures, and temperatures. Component data is then fixed at the
inlet of the plant model).
SolverOption
The action to take if the Hysys solver fails.

Options are:
0 - ignore any error and continue
1 - log the error to the output window and continue (default)
2 - end the run with the error
ConvergenceTimeOut If a Hysys model cycles continuously, then this option allows a timeout
to be applied. The value is in seconds
NeverForceConvergen If set, this overrides the timeout quantity entered above. The solver
ce
will then never timeout
StartDate
The date at which the plant model comes online. If this is not entered,
then the model is assumed online at the start of the RESOLVE run
FluidPackage
e.g. Resolve.Module[{Hysys}].FluidPackage.Count
A collection of Fluid Package structures (described below).
541
RESOLVE
FluidPackage variable:
Resolve.Module[{Hysys}].FluidPackage[0].Label OR
Resolve.Module[{Hysys}].FluidPackage[{label}].Composition.
NumComponents
Server.SolverStatus
Label / Name
These both return the name of the fluid package
NumComponents
The number of components defined for the fluid package
CompName[n]
The name of the component of index n (0 <= n < NumCo
e.g. Resolve.Module[{Hysys}].Server.SolverStatus
This can be set to the following:
0 - disable solver
1 - enable solver
This is useful if a variable in Hysys is to be changed from the
OpenServer. In this case, the solver should be disabled prior to
making the change so that it does not immediately block the
communication by re-solving the system. When the system is ready
(i.e. all the changes have been made) the solver can be re-enabled.
Alternatively, RESOLVE will force the solver to be re-enabled when it
comes to solving the model itself.
If changes are being made through the RESOLVE "Equip" or "
PubVar" interfaces then RESOLVE will ensure that the solver is not
enabled when the changes are made. This flag is only required now
when legacy code which uses the structures below is used
Other legacy structures

As mentioned, dynamic OpenServer changes to the model should now be carried out through
the "Equip" or "PubVar" interfaces of the RESOLVE "Module " variable.
The following interfaces are retained for backwards compatibility:
Element
Report
OSCache
Schedule
An example of how these are used is in the OpenServer example macro: HysysOpenServerlegacy.xls.
2.19.1.2.2.6 UniSim internal driver variables
CaseDetails variable, e.g. Resolve.Module[{UniSim Design}].CaseDetails.FileName
User Guide
FileName
HostName
TransferMode
542
Sets the UniSim Design filename to open

The host machine on which to run UniSim Design
0 - (default) pass all the compositional data to UniSim Design
1 - pass only the black oil data (effectively mass flow rates,
pressures, and temperatures. Component data is then fixed at the
inlet of the plant model).
SolverOption
The action to take if the UniSim Design solver fails.

Options are:
0 - ignore any error and continue
1 - log the error to the output window and continue (default)
2 - end the run with the error
ConvergenceTimeOut If a UniSim Design model cycles continuously, then this option allows
a timeout to be applied. The value is in seconds
NeverForceConvergen If set, this overrides the timeout quantity entered above. The solver
ce
will then never timeout
StartDate
The date at which the plant model comes online. If this is not entered,
then the model is assumed online at the start of the RESOLVE run
FluidPackage
e.g. Resolve.Module[{UniSim Design}].FluidPackage.Count
A collection of Fluid Package structures (described below).
FluidPackage variable:
Resolve.Module[{UniSim Design}].FluidPackage[0].Label OR
Resolve.Module[{UniSim Design}].FluidPackage[{label}].
Composition.NumComponents
Server.SolverStatus
Label / Name
These both return the name of the fluid package
NumComponents
The number of components defined for the fluid package
CompName[n]
The name of the component of index n (0 <= n < NumCo
e.g. Resolve.Module[{UniSim Design}].Server.SolverStatus
This can be set to the following:
0 - disable solver
1 - enable solver
This is useful if a variable in UniSim Design is to be changed from
the OpenServer. In this case, the solver should be disabled prior to
making the change so that it does not immediately block the
communication by re-solving the system. When the system is ready
(i.e. all the changes have been made) the solver can be re-enabled.
Alternatively, RESOLVE will force the solver to be re-enabled when it
comes to solving the model itself.
If changes are being made through the RESOLVE "Equip" or "
PubVar" interfaces then RESOLVE will ensure that the solver is not
543
RESOLVE
enabled when the changes are made. This flag is only required now
when legacy code which uses the structures below is used
Other legacy structures
As mentioned, dynamic OpenServer changes to the model should now be carried out through
the "Equip" or "PubVar" interfaces of the RESOLVE "Module " variable.
The following interfaces are retained for backwards compatibility:
Element
Report
OSCache
Schedule
An example of how these are used is in the OpenServer example macro: UniSim Design
OpenServer-legacy.xls.
2.19.1.2.2.7 Eclipse internal driver variables
The tag strings for all Eclipse internal driver variables are the same, regardless of the "flavour" of
the driver that is being used. Any differences between the various Eclipse drivers are noted
below.
CaseDetails variable e.g. Resolve.Module[{Eclipse}].CaseDetails.FileName
FileName
The name of the data file to be opened. It does not have to be a local file, or even a
Windows file.
HostName
The name of the host on which Eclipse is to be run. This is redundant if connecting to a
Linux machine running the LSF daemon.
Linux
Set to non-zero if the data file resides on a remote host that is running Linux and the
Petroleum Experts connectivity daemon (mpirunfactory_xxx.exe).
The following are applicable only if Linux is set to non-zero.
ControllerHostName
This is the name of the Linux computer that is running the run factory daemon mpirunfactory_scampi.exe or mpirunfactory_mpich.exe.
PortNumber
The port number that the run factory daemon (above) is waiting on. This is the port
User Guide
544
number that was specified on the command line of the run factory executable when
it was started.
PVTFile (Eclipse 300 only)
OpenEclipse does not give access to the EOS properties of the reservoir fluid(s). For
this reason, RESOLVE must be given the name of the file which contains the PVT data so
that it can be parsed, and the data extracted.
WellManagement
Controls the flag for whether Eclipse controls the well scheduling (on/off) or the connected
application (normally GAP). Note that this refers only to the on/off state of the wells, and
not to well or system constraints (for example) which are handled at the GAP level.
The possible values are:
0 - Eclipse
1 - Connected application (GAP)
DoWellManagementDebugFile
Flag to control whether a well management debug file is written by the Eclipse link driver.
WellManagementDebugFile
The name of the well management debug file that is to be written if the above flag is set.
AbandonShutInWells
The action to take if GAP closes a well on a timestep.
0 - STOP the well (allow x-flow)
1 - SHUT the well
2 - STOP the well (allow x-flow) and do not attempt to bring the well back on
(abandon the well)
3 - SHUT the well and do not attempt to bring the well back on
Temperature
The reservoir fluid temperature.
In E300 models, an attempt will be made to read this from the RTEMP keyword in the
PVT data file.
TemperatureUnit
The unit of the above temperature.
0 - deg F
1 - deg C
2 - deg R
3 - deg K
DebugLevel
Controls the severity level of the messages that are echoed to the RESOLVE logs. Only
messages higher in severity than this value will be output.
The values are:
545
RESOLVE
0 - MESSAGE
1 - COMMENT
2 - WARNING (default)
3 - PROBLEM
4 - ERROR
5 - BUG
OutputTo
Governs where the log messages are output.
The possibilities are:
1 - to the log window
2 - to the output window
3 - to both windows
IPRModel
The IPR model to be used in the run.
0 - Eclipse PI (do not use - legacy only)
1 - Calculated PI (based on well block pressure)
2 - Calculated PI (based on drainage pressure)
If the drainage option is selected, then the following options become relevant:
DrainageMode
The method of calculating the drainage pressure.
0 - not used (legacy)
1 - diffusivity (direct calculation from the grid)
2 - relaxation/build-up (calculation from well tests)
If value 1 (the diffusivity method) is used, then the following options are
applicable:
ImportGrid / GridDebugFile
Specifies that the grid is to be imported, and gives the name of the
file that is used to hold the grid data.
In practice, the grid should already have been imported into
RESOLVE before this option can be used. The process of setting up
the drainage regions can not currently be automated.
If value 2 (the relaxation method is used, then the following options are
applicable:
RelaxationTime
The time (in days) for which the build up calculation should be run. A
nominal value of 2 days is the default.
NumberOfPoints
The relaxation time can be broken down into several sub-timesteps
which are then logged separately in the log file. This can be useful
for debugging.
User Guide
546
LogTransient
Governs whether the buildup points are written to the log window or
not.
NewtonLevel
Set to:
0 - standard explicit coupling (recommended with one of the improved IPR options
described above)
1 - Newton-level coupling.
The Newton coupling is not recommended except for exceptional cases.
This is described in more details in the section on the "Eclipse driver".
If Newton-level coupling is enabled, the following options are applicable:
MaxNewtonIterations
The maximum number of iterations that should be taken by RESOLVE.
NewtonTolerance
The tolerance to be reached before convergence is signalled.
PlotSummary
Set to non-zero to plot the summary vectors from the Eclipse model in RESOLVE.
The following are so-called "advanced options" and should not normally be changed:
GLRThreshold
The GLR at which a liquid well is considered to become a gas well (and vice versa). This
affects the control mode only: if a well is being controlled with a liquid rate and it "turns
into" a gas well, then the control mode will be changed to gas rate.
GLRUnit
The unit for the above quantity.
0 - scf/STB
1 - Mscf/STB
2 - m3/m3
AutoSwitch
Turns the switching from liquid to gas wells (as described) on or off.
SmallTimestep
Eclipse is forced to take a small timestep when a block-pressure IPR is generated as
described in the "Eclipse Advanced Options" section. The size of the small timestep can
be changed here if required.
547
RESOLVE
Group Collection, e.g. Resolve.Module[{Eclipse}].Group.Count,

[{Eclipse}].Group[{name}].Respect
Resolve.Module
A list of the groups that were found in the Eclipse model.

The elements of the group data structure are:
Name
The name of the group
Respect
Governs whether the control under this group in the Eclipse model should be allowed.
Normally (and by default) all group controls are removed so that control can be taken by
GAP. However, there are some circumstances where group control may be useful: this is
described in the "Group Control in Eclipse" section.
Dynamic data that can be returned from Eclipse groups, e.g. Resolve.Module
[{Eclipse}].Group[{Mygroup}].GOPR
The following variables can be used to return values relating to groups from Eclipse during a run.
These variables can therefore be accessed from the "RESOLVE script" to make dynamic
decisions about field management. Note that the group "FIELD" (case sensitive) can be used to
get field information.
GOPR - oil production rate

GWPR - water production rate
GGPR - gas production rate
GOPT - cumulative oil production
GWPT - cumulative water production
GGPT - cumulative gas production
GOIR - oil injection rate
GWIR - water injection rate
GGIR - gas injection rate
GVPR - reservoir volume production rate
GVPT - cum reservoir volume production rate
GVIR - reservoir volume injection rate
GVIT - cum reservoir volume injection rate
These are the most commonly required variables. Other variables are available. A
complete list can be obtained from Petroleum Experts on request.
Dynamic data that can be set in Eclipse groups, e.g. Resolve.Module[{Eclipse}].Group
[{MyGroup}].OPRDLIM
User Guide
548
It is possible to dynamically set group data in an Eclipse model from an OpenServer string
(such as that shown above).
In normal use, RESOLVE will remove Eclipse group controls so that control of the
individual wells by GAP will not be interfered with. This behaviour can be "overridden"
for cases where not all the Eclipse wells are connected to corresponding GAP wells.
Eclipse group controls for the group(s) in question MUST be respected to allow these
OpenServer strings to set variables; otherwise, RESOLVE will simply overwrite the
changes.
As above, the group "FIELD" can be used to set field data. However, this can only make sense
if there are no connections to external modules.
OPRDLIM - oil production rate

WPRDLIM - water production rate
GPRDLIM - gas production rate
LPRDLIM - liquid production rate
VPRDLIM - reservoir fluid volume production rate
PRBLFLIM - production balancing fraction (E100)
OINSRLIM - oil injection rate
WINSRLIM - water injection rate
WINRRLIM - water injection reservoir volume rate
WINRFLIM - water re-injection fraction
WINVFLIM - water voidage replacement fraction (E100)
GINSRLIM - gas injection surface rate
GINRRLIM - gas injection reservoir volume rate
GINRFLIM - gas re-injection fraction
GINVFLIM - gas voidage replacement fraction (E100)
To control the Eclipse Groups on a predefined limit, it is required that the corresponding
keyword is entered in the Eclipse deck. For example, if the objective is to run the Eclipse model
on a standalone basis and it is required to limit the production of gas to a certain limit, then the
GPRDLIM may be used in the Event Driven Scheduling. However for this to be successful, it is
required, that the GCONPROD keyword be defined on the basis of GRAT in the Eclipse deck.
Well Collection, e.g. Resolve.Module[{Eclipse}].Well.Count, Resolve.Module[{Eclipse}].
Well[{name}].Ctrl
A list of the wells exposed from the Eclipse model in RESOLVE.
The elements of the Well data structure are as follows:
549
RESOLVE
Name
The name of the well.
Type
The type of the well.
1 - oil (liquid) producer
2 - oil injector
3 - water injector
4 - gas injector
In Eclipse 300 (older versions), gas injectors also sometimes return "0". This was a bug
in Eclipse.
Ctrl
The control mode for the well. For producers, the list is:
0 - BHP
1 - THP
2 - Oil rate
3 - water rate
4 - liquid rate
5 - gas rate
For injectors, 0 and 1 are the same and:
2 - fixed rate
Dynamic data that can be returned from Eclipse wells, e.g. Resolve.Module[{Eclipse}].
Well[{name}].WOPR
The following variables can be used to returns values from Eclipse during a run. These variables
can therefore be accessed from the "RESOLVE script" to make dynamic decisions about field
management.
WOPR - oil production rate

WWPR - water production rate
WGPR - gas production rate
WOIR - oil injection rate
WWIR - water injection rate
WGIR - gas injection rate
WBHP - well bottom hole pressure
WTHP - well tubing head pressure
WMCTL - control mode
The following return IPR A and B coefficients. It is important to note that these are not
calculated by RESOLVE but reported directly from Eclipse.
WOPIPRA, WOIPRB - well oil IPR A and B coefficients
WGIPRA, WGIPRB - well gas IPR A and B coefficients
User Guide
550
WWIPRA, WWIPRB - well water A and B coefficients
WVPR - reservoir volume production rate

WVPT - cum reservoir volume production rate
WVIR - reservoir volume injection rate
WVIT - cum reservoir volume injection rate
WTPCxxxx - the produced tracer concentration of tracer xxxx
WTICxxxx - the injection tracer concentration of tracer xxxx
These are the most commonly required variables. Other variables are available. A
complete list can be obtained from Petroleum Experts on request.
Dynamic well completion data, e.g. Resolve.Module[{Eclipse}].Well[{name}].Comp.
Count, Resolve.Module[{Eclipse}].Well[{name}].Comp[0].Status
The following variables can be used to access completion data from an Eclipse well during a
run.
COFRL - oil flow rate (+ve or -ve)

COPRL - oil production rate
COPTL - oil production cum
CWFRL - water flow rate (+ve or -ve)
CWPRL - water production rate
CWPTL - water production cum
CWIRL - water injection rate
CWITL - water injection cum
CGFRL - gas flow rate (+ve or -ve)
CGPTL - gas production cum
CGIRL - gas injection rate
CGITL - gas injection cum
CLFRL - liquid flow rate (+ve or -ve)
CLPTL - liquid production cum
CVFRL - reservoir volume flow rate (+ve or -ve)
CVPTL - reservoir volume production cum
CVITL - reservoir volume injection cum
CWCTL - water cut
CGORL - GOR
COGRL - OGR
CWGRL - WGR
COPRFL - free oil production through the completion
COPRSL - vapourised oil production through the completion
COPTFL - cumulative free oil production (E100 only)
COPTSL - cumulative vapourised oil production (E100 only)
551
RESOLVE
CGPRFL - free gas production rate

CGPRSL - solution gas production rate
CGPTFL - cumulative free gas production (E100 only)
CGPTSL - cumulative solution gas production (E100 only)
STATUS - status (on/off)
Dynamic system data, e.g. Resolve.Module[{Eclipse}].System.CPU

The following variables can be used to access Eclipse system data during a run.
Date - the current date.
This is returned as a "date type", which is the number of days since the 1 Jan, 1900. (This
allows operations such as addition and subtraction to be performed simply). To turn it into
a date string in the format of the user current location, use code of the form:
s = DoGet("Resolve.Module[{Eclipse}].System.Date")
MsgBox(cdate(cdbl(s)))
Day / Month / Year
Returns the "day"/"month"/"year" part of the current simulation date
CPU - the CPU time (in seconds) taken by the Eclipse run
Elapsed - the elapsed time since the start of the Eclipse run
NCOMP - the number of components in the Eclipse run. In a E100 run, NCOMP will
equal 2, and the component names will be "BLACKOIL" and "GAS".
COMPNAME - the component at a given index "i", e.g. ...System.COMPNAME[i]
UNCONV - the unit system used in the Eclipse model. 1 = Metric, 2 = Field, 3 = Lab
2.19.1.2.2.8 Excel internal driver variables
CaseDetails variable, e.g. Resolve.Module[{Excel}].CaseDetails.FileName

This variable refers to general information on the contents of the Excel icon in RESOLVE.
The following entries are available:
FileName
Sets the Excel filename to open.
User Guide
552
Macro
Sets the name of the macro to run (under the "Macro" tab of the Excel data entry screen)
PassDateToMacro
Sets the flag that indicates that the date of the current timestep should be passed to the
macro when it is "called".
2.19.1.2.2.9 IMEX/GEM internal driver variables
The following uses "IMEX" and "GEM" interchangeably, unless specifically noted.
CaseDetails variable, e.g. Resolve.Module[{IMEX}].CaseDetails.FileName
This variable refers to general information on the contents of the IMEX icon in RESOLVE.
HostMode
0 - use a specified machine to run IMEX on
1 - run the simulator on a cluster
ClusterMode
If HostMode is set to 1, then:
0 - use PxCluster
1 - use LSF
HostName
If HostMode is set to 0, then this is the computer on which the simulator should run. This
should be an empty string to use the local computer.
SimExeName
The IMEX executable. If this is an empty string, RESOLVE will use the executable from the
"configuration settings".
FileName
The name of the IMEX dataset.
OSType
For a remote run:
0 - Windows architecture
1 - UNIX or Linux architecture
RshCmd
The remote command string (using SSH).
WorkFolder
The working folder, i.e. the folder in which intermediate and data passing files are to be
located
553
RESOLVE
LogFile
Set to non-zero to write the simulation output to a log file (rather than opening up a
command window)
Multiprocessors
Set to non-zero to indicate a multi-processor, parallel run
NumProcessors
The number of processors to be used in a parallel run
IPRModel
0 - block IPR model
1 - corrected IPR model
Data that can be retrieved dynamically during a run
Note that there are syntax differences between these OpenServer strings and the
RESOLVE standards.
Total Counts, e.g. Resolve.Module[{IMEX}].nWell
The well and group counts are retrieved with the following strings:
nWell
The number of wells in the model
nGroup
The number of well groups in the simulation model
nSector
The number of sectors in the simulation model
Examples
DoGet("Resolve.Module[{IMEX}].nWell)
DoGet("Resolve.Module[{IMEX}].nGroup)
Well Variables, e.g. Resolve.Module[{IMEX}].Well[{Well1}].OilRatSC
The well specifier in curly brackets can not be replaced with an index as can be done with the
other modules. (In other words, the syntax "Resolve.Module[{}].Well[0]... is not allowed).
However, IMEX well numbers can be used with a "#" character, e.g.
DoGet("Resolve.Module[{IMEX}].Well[{OIL1}].OilRatSC")
DoGet("Resolve.Module[{IMEX}].Well[{#1}].OilRatRC")
User Guide
Well Variable List

Variable
Description
name
554
Units/Remarks
WelTyp
Well type; Indicates for producer value =

or injector.
-1
1
: producer
: injector
WelLnk
Well link state. Indicates the well is value =

linked to the GAP surface network
0
or not.
Please note at the moment of
initial, all IMEX wells are assumed
to be linked.
1
: linked
: unlinked
TmpBHF
Well bottom-hole temperature
deg.F
PrsBHF
Well bottom-hole pressure
psig
PrsBlkRef
Well reference grid block pressure psig
PrsBlkMow
Well grid block mobility weighted psig

pressure
OilRatSC
Oil rate at stock-tank condition
WatRatSC
Water rate at stock-tank condition STB/day
GasRatSC
Gas rate at stock-tank condition
MMscf/day
OilRatRC
Oil rate at bottom-hole condition
RB/day
WatRatRC
Water rate
condition
GasRatRC
Gas rate at bottom-hole condition MMrcf/day
BHFRatRC
Bottom-hole fluid rate
at
STB/day
bottom-hole RB/day
RB/day
BHFCumRC Cumulative bottom-hole fluid
RB
OnTimeFrc Well on-time fraction

Note: Above well rates represent average rates.
Fraction (0 ~ 1)
Group Variables, e.g. Resolve.Module[{IMEX}].Grup[{Group1}].OilRatSCPrd

If there is no user group defined in IMEX data set, group name FIELD is used to represent all the
wells defined in IMEX data set. Otherwise, a user given top node name can be used.
Example:
DoGet("Resolve.Module[{IMEX}].Grup[{Gather-1}].OilRatSCPrd")
DoGet("Resolve.Module[{IMEX}].Grup[{FIELD}].OilRatRCPrd")
555
RESOLVE
Group Variable List

Variable
Description
name
OilRatSCPrd
Units/Remarks
Oil production rate at stock-tank condition
WatRatSCPrd Water production

condition
rate
at
STB/day
stock-tank STB/day
GasRatSCPr Gas production rate at stock-tank condition

d
MMscf/day
OilRatRCPrd Oil production rate at bottom-hole condition
RB/day
WatRatRCPr Water production

condition
d
rate
at
bottom-hole RB/day
GasRatRCPr Gas production rate at bottom-hole condition MMrcf/day

d
BHFRatRCPr Bottom-hole fluid production rate
d
RB/day
BHFCumRC
Prd
Cumulative bottom-hole fluid production
RB
WatRatSCInj
Water injection rate at stock-tank condition
STB/day
GasRatSCInj Gas injection rate at stock-tank condition
MMscf/day
WatRatRCInj Water injection rate at bottom-hole condition RB/day

GasRatRCInj Gas injection rate at bottom-hole condition
MMrcf/day
BHFRatRCInj Bottom-hole fluid injection rate
RB/day
BHFCumRCI Cumulative bottom-hole fluid injection

nj
RB
Sector Variables, e.g. Resolve.Module[{IMEX}].Sect[{Sector1}].OilInPSC

A sector name with Entire Field or sector number with 0 is used to represent the all the active
blocks of the reservoir model. Please refer to the IMEX user manual.
Example:
DoGet("Resolve.Module[{IMEX}].Sect[{#0}].OilInPSC")
DoGet("Resolve.Module[{IMEX}].Sect[{Entire Field}].OilInPSC")
Sector Variable List
Variable name Description
PrsTPV
Units/Remarks
Average pressure over the total pore psig
User Guide
556
volume
PrsHPV
Average pressure over the hydrocarbon psig

pore volume
VolTPV
Total pore volume
RB
VolHPV
Hydrocarbon pore volume
RB
OilInPSC
Stock-tank oil in-place
STB
MbOInPSC
Stock-tank mobile oil in-place
STB
WatInPSC
Stock-tank water in-place
STB
GasInPSC
Stock-tank gas in-place
MMscf
FrGInPSC
Stock-tank free gas in-place
MMscf
OilInPRC
Oil in-place at reservoir condition
RB
WatInPRC
Water in-place at reservoir condition
RB
GasInPRC
Gas in-place at reservoir condition
MMrcf
Layer variables (IMEX ONLY)

It is possible to query individual well layer data in IMEX. In addition, executive commands can be
carried out to, for example, perform workovers.
Layer count
The number of layers for a given well can be determined.
Examples
DoGet("Resolve.Module[{IMEX}].Well[{#3}].nLayer)
Layer variable list
Note the syntax, in which the first part of the string is LAYER[<well name>][<layer index>]. The
layers are indexed from '1'.
Examples
DoGet("Resolve.Module[{IMEX}].Layer[{#3}][{1}].LaySta)
DoGet("Resolve.Module[{IMEX}].Layer[{#3}][{1}].OilRatSC)
Variable name Description
Units/Remarks
PrsWlb
Wellbore pressure at the depth of the psig

layer
PrsLay
Layer block pressure
psig
LaySta
Layer status
value = 1: Open
0: Shut in
-1 : Closed
557
RESOLVE
Depth
Block centre depth of the layer
ft
OilRatSC
Oil rate at stock tank conditions
STB/day
WatRatSC
Water rate at stock tank conditions
STB/day
GasRatSC
Gas rate at stock tank conditions
MMscf/day
OilRatRC
Oil rate at bottom hole conditions
RB/day
WatRatRC
Water rate at bottom hole conditions
RB/day
GasRatRC
Gas rate at bottom hole conditions
MMrcf/day
BHFRatRC
Bottom hole fluid rate
RB/day
Note: Above layer rates represent average rates. A negative layer rate indicates
the layer is backflowing with respect to its well type: for a producer this would be
an injecting layer or for an injector this would be a producing layer.
<- END IMEX ONLY
Examples
These examples refer to the internal RESOLVE "script".
Example 1
In the script for voidage replacement, replace the summation of well rates by using group rates:
If (InStr(ModuleList, "GAP") > 0) Then
" fallback values for FVFProd and FVFInj
if (Resolve.Timestep = 0) then
FVFProd0 = 1.3
FVFInj0 = 1
end if
" Estimate FVF values for producers and injectors
Qres = Abs(CDbl(DoGet("IMEX.Grup[{FIELD}].BHFRatRCPrd")))
QWsurf = Abs(CDbl(DoGet("IMEX.Grup[{FIELD}].WatRatSCPrd")))
QOsurf = Abs(CDbl(DoGet("IMEX.Grup[{FIELD}].OilRatSCPrd")))
if (Qres > 0 And QWsurf + QOsurf > 0) then
FVFProd0 = Qres / (QOsurf + QWsurf)
End If
Qres = Abs(CDbl(DoGet("IMEX.Grup[{FIELD}].BHFRatRCInj")))
QWsurf = Abs(CDbl(DoGet("IMEX.Grup[{FIELD}].WatRatSCInj")))
if (Qres > 0 And QWsurf > 0) then
FVFInj0 = Qres / QWsurf
User Guide
558
End If
FVFRatio0 = FVFProd0 / FVFInj0
" Get the cumulative voidages so far
VoidProd0 = Abs(CDbl(DoGet("IMEX.Grup[{FIELD}].BHFCumRCPrd")))
VoidInj0 = Abs(CDbl(DoGet("IMEX.Grup[{FIELD}].BHFCumRCInj")))
End If
559
RESOLVE
Example 2
Set the field oil production constraint to 1/1000 of current field mobile oil in-place and also make
the constraint be limited between 7.5 MBBL and 15 MBBL:
"Get IMEX estimated field mobile oil in-place"
Qprod = Abs(CDbl(DoGet("IMEX.Sect[{#0}].MbOInPSC"))) * 0.001
If (Qprod > 15000) Then
Qprod = 15000
elseif (Qprod < 7500) Then
Qprod = 7500
End If
"Set the constraint in the production system
Call DoSet("GAP.MOD[{PROD}].SEP[{Sep1}].MaxQoil", Qprod)
Call LogMsg("max. Oil set to: " + cstr(Qprod))
Example 3
If the well water cut exceeds 10%, then close the worst offending layer.
' get the water cut for well index 3
QOil = CDbl(DoGet("IMEX.Well[{#3}].OilRatSC"))
QWat = CDbl(DoGet("IMEX.Well[{#3}].WatRatSC"))
WCut = QWat / (QOil + QWat + 1.0e-10)
Call LogMsg("Water Cut = " + CStr(WCut))
' number of layers to loop over
nly = CInt(DoGet("IMEX.Well[{#3}].nLayer"))
If (WCut > 0.1) Then
' perform workover
MaxWCutLay = 0.0
ily1 = 0
For ily = 1 To nly
StrLayExpr = "IMEX.Layer[{#3}][{" + CStr(ily) + "}]"
iSta = CInt(DoGet(StrLayExpr + ".LaySta"))
If (iSta >= 0) Then
QLayOil = CDbl(DoGet(StrLayExpr + ".OilRatSC"))
QLayWat = CDbl(DoGet(StrLayExpr + ".WatRatSC"))
' calculate the layer water cut
WCutLay = QLayWat / (QLayWat + QLayOil + 1.0e-10)
If (WCutLay > MaxWCutLay) Then
MaxWCutLay = WCutLay
ily1 = ily
End If
End If
User Guide
560
Next
If (ily1 > 0) Then
StrLayNum1 = CStr(ily1)
DoCmd("IMEX.Layer[{#3}][{" + StrLayNum1 + "}].Shut")
Call LogMsg("Shut Layer: " + StrLayNum1)
End If
End If
2.19.1.2.2.10 PSim internal driver variables
CaseDetails variable, e.g. Resolve.Module[{PSim}].CaseDetails.FileName

These are all options that can be set from the interface in the "data entry screen" of PSim.
FileName
Sets the PSim file name (.dek file) to be run.
DirName
Sets the directory name in which intermediate and output files are stored. This is ignored
if AutoDir (below) is set.
AutoDir
If this is set, then RESOLVE will generate a unique output directory name for every PSim
run which is performed from RESOLVE.
HostName
This is the name of the machine on which PSim will run.
RestartFile
The restart file name for the PSim run.
PSimVersion
A string that represents the PSim version to run, e.g. "2006.00.01.14". If this is not given,
PSim will run the version specified in the "driver configuration" screen.
GlobalProdWellControl / GlobalInjWellControl
These are the global control modes for production and injection wells, which can be
overridden on a well-by-well basis (see below).
IsLinux
561
RESOLVE
This can be set to indicate that HostName (above) points to a Linux machine.
IPRModel
This can be set to:
0: block IPR
1: corrected IPR (recommended)
If the corrected IPR is selected, the pre-calculation welltests must have been performed.
This is currently only possible by using the interface.
DoSmallTimestep
Set this flag to force PSim to perform a small timestep after every synchronisation, as
explained under the "Advanced options" screen.
Well Collection
The number of wells in the PSim model can be obtained by querying the PSim well collection:
nwell = DoGet("Resolve.Module[{PSim}].Well.Count")
Well variable, e.g. Resolve.Module[{PSim}].Well[n].WellType
[{PSim}].Well[{label}].WellType
or
Resolve.Module
Name / Label
(read-only) Returns the name of the well
Welltype (read-only)
Returns an integer which indicates the PSim well type, e.g. -3 for a water injector, as
documented in the PSim manual.
ControlModePrd / ControlModeInj
These are the control modes for a well, as distinct from the global control modes found
under the CaseDetails variable. The following values can be used:
1: BHP control
2: Rate control
3: THP control
HasLiftCurve (read-only)
This is set if the well in question has a lift curve table associated with it.
THPTable (read-only)
The THP table associated with a well (valid only if HasLiftCurve returns a non-zero value).
IsLinked (read-only)
Flag to indicate whether a well is linked in the RESOLVE model.
IPRPreCalculated (read-only)
User Guide
562
Flag to indicate whether the IPR pre-calculation has been performed for this well.
Dynamic well data
The following data is generated during a run, and so can be accessed from the RESOLVE "
script" or an external macro when the run is performed on a "step-by-step" basis. All quantities
are read-only, as they come from the simulator.
SGOil / SGGas / SGWat
The specific gravities of the three phases.
N2 / CO2 /H2S
The impurity content of the production (in ppm).
OilRate / GasRate / WaterRate
The phase rates of the well (in oilfield units - STB/day and MMscf/day).
BHP / THP
Bottom hole and tubing head pressure from the simulator.
CumOil / CumGas /CumWater
Phase cumulatives in oilfield units (MSTB and MMScf).
ResRate / CumRes
The reservoir (downhole) rate and the cumulative downhole production/injection in oilfield
units (RB/day and RB).
HasStarted
Indicates that the well has started, i.e. has had a finite production or injection since the run
started.
2.19.1.2.2.11 Module Optimisation variables
Any module within RESOLVE may have an objective function, constraints, and/or control
variables set up.
These elements can all be accessed through the OpenServer.
Variables common to all three variable types
Enabled
Enables or disables the element in the optimisation. This might be useful to automate
runs with and without certain control variables or constraint equations, or the user may
wish to switch between objective functions. If the user use this flag when performing a
forecast, the control will be enabled or disabled for the entire forecast.
563
RESOLVE
Name
The name of the element, e.g. "Well1 WHP".
Unit
The measurement unit of the quantity for the optimisation element.
Optimiser Control Variables
BoundsMask
Specifies whether the control is bounded:
0 - not bounded
1 - has lower bound
2 - has upper bound
3 - has upper and lower bounds
LowerBound
The lower bound of the control (if applicable through BoundsMask)
UpperBound
The upper bound of the control (if applicable through BoundsMask)
Perturbation
The perturbation to apply to the control, in the appropriate unit (note that this changes
dynamically during the run depending on the current trust region of the SLP: this quantity
is the first pertubation).
InitialBound
The initial "trust" bound to apply to the control, in the appropriate unit. As with the
perturbation, this changes dynamically during the course of the run.
CentrePerturbation
Flag to tell RESOLVE whether to perform a centre-based perturbation on the control
(rather than the usual, default, forward perturbation). See the "optimisation" pages for
more information.
MinimumPerturbation
The minimum perturbation that the control can use. The perturbation is adapted to the
current "trust region"; this prevents the perturbation becoming too small.
Optimiser Constraint Equations
Limit
The value of the constraint (i.e. the limit)
LimitType
The type of the constraint:
User Guide
564
0 - less than
1 - equal to
2 - greater than
Optimiser Objective Function
Maximise
Flag whether the problem is a maximisation or minimisation.
2.19.1.2.2.12 SrcSnk variables
These variables correspond to the sources and sinks exposed by a parent module.
SrcSnk collection
There are no variables specific to this collection. Index individual items by number (SrcSnk[0]) or
label (SrcSnk[{Well1}]).
The collection is read only. Items can be manipulated by calling an appropriate "command".
SrcSnk item
XPos / YPos
The position of the icon on the main screen
Label (read only)
The label applied to the item by the application when the module was loaded
TypeStr (read only)
A string describing the item in question (e.g. "well", "injection manifold")
SSType (read only)
1 - source
2 - sink
3 - source and/or sink, depending on what the item is connected to
IsConnectable (read only)
Is the item marked as connectable (can it, in principle, be connected to some other
item)?
DataProvider (read only)
Data provider or data acceptor.
BiDirectional (read only)
Does/can this item form part of a bidirectional link.
ItemType (read only)
For informational purposes only.
Values are:
0 - none
565
RESOLVE
1 - producer
2 - injector
3 - undefined
PhaseType (read only)
The dominant phase of the item.
Values are:
0 - anything
1 - water
2 - liquid
3 - oil
4 - gas
5 - condensate
IsConnected (read only)
Return whether this item is connected to another item in RESOLVE.
Connection
Return connection data if IsConnected is true.
Label
The label of the item to which this item is connected.
SrcSnk
A further collection of children of this item (as described on this page).
2.19.1.2.2.13 PubVar variables
These variables correspond to the variables that have been exported, or "published", from the
module in question.
Note that it is also possible to perform the exporting from an OpenServer "command".
PubVar collection, e.g. Resolve.Module[{xxx}].PubVar.Count
The PubVar variable is a collection of data structures for each variable that has been exported,
as described below.
PubVar item, e.g. Resolve.Module[{xxx}].PubVar[{variable}].Value
Variable (read-only)
The name of the variable. Once this is known, it can be placed between the curly brackets
({}) that come after "PubVar" to refer to a variable.
Unit (read-only)
User Guide
566
The unit of the variable in question. RESOLVE does not know anything about the unit
systems of the connected modules: indeed, the unit returned here may not exist in
RESOLVE unit database. If a value is returned for this variable, therefore, it will always be
in this unit.
Writable (read-only)
Indicates whether the variable is writable or not in the module.
Value (read-only)
The value of the variable at the current time.
2.19.1.2.2.14 Equip variables
These variables allow the "equipment" that each module supports to be queried from RESOLVE
in a way which is independent of the module in question.
Equip collection, e.g. Resolve.Module[{modname}].Equip.Count, Resolve.Module
[{modname}].Equip[{equip}].Label
The collection of the equipment as supplied by the module to RESOLVE. This equipment is
internal or external to the module: in other words, the equipment list is not limited just to the
sources and sinks that can be viewed on the main RESOLVE screen.
Equip item, e.g. Resolve.Module[{modname}].Equip[0].Label
Label (read-only)
The name of the piece of equipment supplied by the module.
Type (read-only)
The type of the equipment, as supplied by the module
SubType (read-only)
The sub-type of the equipment, as supplied by the module.
Variable (read-only collection)
A collection of variables supported by the equipment in question, as described below.
Variable collection, e.g. Resolve.Module[{modname}].Equip[0].Variable.Count, Resolve.
Module[{modname}].Equip[0].Variable[0].label
A collection of variables.
The items of the variable structure are:
567
RESOLVE
Label (read-only)
The variable label
Unit (read-only)
The variable's unit. All queries on the variable's value will be returned in this unit.
Writable (read-only)
Determines whether or not the variable's value can be set, or whether it is only readable.
Value
Gets or, if it is writable, sets the value of the variable.
2.19.1.2.3 Driver variables

Driver Collection
There are no variables specific to this collection.
Index individual items by number (Driver[0]) or application (Driver[{GAP}]).
Driver Item
InterfaceVersion (read only)
The interface version of RESOLVE that this driver was built with.
Application (read only)
The application implemented with this driver.
NeedsComposition (read only)
Whether the application implemented here is purely EOS and requires compositional
data to function.
ProvidesComposition (read only)
Whether the application can provide EOS data.
AppType (read only)
The application type (for informational purposes):
0 - unknown
1 - reservoir simulator
2 - nodal analysis
3 - process simulator
Description (read only)
A description string describing the application.
User Guide
568
2.19.1.2.4 ModLink variables

ModLink Collection
There are no variables specific to this collection.
Index individual items by number (ModLink[0]).
There is one entry in this collection for every connection between modules.
For example, if module A is connected to module B and module C, there will be two entries in
this collection: A-B and A-C.
This collection is used to hold the calculation order data as well as some adaptive timestepping
data.
ModLink Item
CalcOrder
This is the order of calculation for this module pair. It is the number that is entered on the "
calculation order" screen.
Mod1
This is the name of the first module in the pair (the order is arbitrary).
Mod2
This is the name of the second module in the pair.
The following variables are part of the data required to set up adaptive timestepping in a
RESOLVE prediction.
TargetRMS
This is an array of RMS targets for the target variable (see below).
It is an array over all schedule records, for example the tag string:
Resolve.ModLink[2].TargetRMS[1] will obtain the second (zero indexed) schedule record
RMS target for the third module link object.
TargetVar
Similarly, this is an array of target variables over all schedule records for this module link,
e.g. water cut, THP.
2.19.1.2.5 Schedule variables
There are two variables that relate to the standard forecast scheduling: Resolve.Schedule and
Resolve.ScheduleList.
Resolve.Schedule, e.g. Resolve.Schedule.StartDate
This contains the data that is general to the entire schedule.
StartDate
The start date of the forecast run.
569
RESOLVE
DebugTimesteps
Enables or disables the writing of timestep data to the log window.
This data may be useful for debugging "Adaptive timestepping" runs.
Resolve.ScheduleList, e.g. Resolve.ScheduleList.Count, Resolve.ScheduleList[0].
EndDate
This structure gives access to the list of schedule data that is in the list in the left hand side of the
forecast setup screen.
TimestepMode
Select:
0 - fixed timesteps
1 - adaptive timestepping
InitialTimestep
The fixed timestep for fixed timestep mode, or the initial timestep if adaptive
timestepping is implemented
InitialTimestepType
"Iinitial timestep" is in:
0 - days
1 - weeks
2 - months
3 - years
MaxTimestep (MinTimestep)
Adaptive timestepping only. The maximum(minimum) timestep size at which to grow the
timestep
MaxTimestepType (MinTimestepType)
Adaptive timestepping only. See InitialTimestepType above
MaxTimestepMultiplier (MinTimestepMultiplier)
Adaptive timestepping only. The maximum (minimum) multiplier to take on the timestep
to determine the forthcoming timestep.
ClosedConnectionPenalty
Adaptive timestepping only. The penalty applied to the forthcoming timestep when
objects are not flowing.
EndDate[i]
The end date of the ith schedule record.
OptimisationMode
0 - optimise at every timestep
User Guide
570
1 - no optimisation
2 - optimise at a given frequency
OptimisationFrequency
If OptimisationMode is set to 2, then this is the frequency at which the optimisation takes
place
OptimisationFrequencyType
See InitialTimestepType above
2.19.1.2.6 Connection variables
Connection Collection
There are no variables specific to this collection. Index individual items by number only
(Connection[0]).
The collection is read only. Items can be connected by calling an appropriate "command".
Connection Item
Mod1
The first "module" connected.
Mod2
The second "module" connected.
Source
The first "source/sink" connected.
Sink
The second "source/sink" connected.
The source is considered to be the "data provider" and the sink is the "data acceptor", i.e. the
source/sink status is determined by the data flow direction, and not necessarily the fluid flow. A
case where the fluid flow is different to the data flow direction is that of injector coupling between
a reservoir simulator and a surface network: in this case fluid is passing from the network to the
simulator, but it is the simulator that supplies the network with IPR data.
The data providers have small dots at the top left hand corner of their icon on the RESOLVE
screen.
2.19.1.2.7 Properties variables
These OpenServer variables enable to change the "System Properties" values.
ForecastMode
Select:
0: Full Forecast
571
RESOLVE
1: Full Forecast with Global Optimisation

2: Single Solve / Optimisation Only
EnableScript
Enables or disables the execution of the VB script.
SystemTitle
The title displayed at the top of the main window
DisplaySystemTitle
Toggle the display of the system title at the top of the main window
ReloadOnStart
Reload the applications at the start of the RESOLVE run
RunInParallel
Ensure that applications are timestepped and initialised in parallel. Turning this flag off
causes the applications to be run sequentially always.
2.19.1.2.8 Optimiser parameter variables
This variables relate to the quantities listed on the "Optimisation Parameters" screen.
OptimisationMode
Affects how variables are reset at each timestep of an optimised forecast
0 - keep the controls from the last timestep as the starting point of the new
optimisation
1 - reset the controls to those from the start of the run as the starting point of the
new optimisation
MaxIter
Maximum number of "SLP" iterations.
MaxGrowth
Maximum growth multiplier of the trust region in the SLP (> 1).
MinGrowth
Minimum growth multiplier of the truct region in the SLP (< 1)
ObjFnTol
Tolerance on the convergence of the objective function.
ConstraintTol
Tolerance on how much a constraint can be violated for the solution to be considered
feasible.
User Guide
572
LinearCritereon
The linearity test quantity for the trust region (see the "SLP" description for more
information).
2.19.1.2.9 Optimiser schedule variables
The optimiser schedule consists of a list of "sub-schedules" which terminate at a given date and
which run concurrently; in each sub-schedule controls and constraints can be enabled or
disabled and the objective function can be changed. Alternatively, the optimiser can be disabled
all together.
List
This references a list of the sub-schedules.
For example: Resolve.OptimiserSchedule.List.Count returns the number of subschedules in the list, and Resolve.OptimiserSchedule.List[i]... allows to query the
variables for a given element of the list.
These variables are as follows:
Date
The date of the end of this sub-schedule
DisableAll
If set, this completely disables the optimiser completely for the duration of the subschedule.
Enable
This is an array over all control variables, constraints, and objective functions,
determining whether these individual elements are active or inactive in the subschedule.
They are ordered as follows:
1. Each module in the RESOLVE.Module array:
2. Objective functions for the module
3. Constraints for the module
4. Control variables for the module
2.19.1.2.10 Event driven schedule variables
The Event Driven Schedule variables refer to those variables used in the "Advanced scheduling"
feature of RESOLVE. An example of its use with OpenServer is given in the drilling.rsa
example.
The following structures can be accessed from the top level:
573
RESOLVE
Resolve.AdvancedScheduleStart
Resolve.AdvancedSchedulePreSolve
Resolve.AdvancedSchedulePostSolve, e.g. Resolve.AdvancedSchedulePostSolve[0]
[0].LHS.Expression
These are collections of aggregated conditions that refer to the advanced scheduling Start,
PreSolve, and PostSolve sections respectively.
A single condition would be represented by one item of one of the above collections, e.g.
Resolve.AdvancedSchedulePostSolve[i].
The condition has the following elements:
ConditionExecuted
The number of times the condition has been triggered during a run, e.g. Resolve.
AdvancedSchedulePostSolve[i].ConditionExecuted. At the start of the run this value
should be zero.
TimeConditionExecuted
The last time the condition was executed.
MaxNumberToExecute
The number of times the condition can be executed in a run before it is effectively
removed from the list (or ignored).
Action
A "structure" that represents the action to perform if a condition is triggered, e.g.
Resolve.AdvancedSchedulePostSolve[i].Action.RedoSolve
A single condition is itself a collection of sub-conditions which can be ANDed or ORed
together.
One of these sub-conditions would be accessed using a syntax of the form: Resolve.
AdvancedSchedulePostSolve[i][0].
The elements of this structure are as follows:
LHS
The expression (see below) for the left-hand side of the condition.
RHS
The expression for the right-hand side of the condition.
Condition
1 - greater than (LHS > RHS)
2 - equal to (LHS = RHS)
3 - not equal to (LHS <> RHS)
User Guide
574
The expressions mentioned above consist of a single item: Expression. See the example at the
top of this page.
In addition, the condition contains a collection of AND or OR flags for the sub-conditions.
For example:
DoSet("Resolve.AdvancedSchedulePostSolve[0].Logical[0]", "0") - sets the first entry in
the collection to "AND", i.e. if <A> AND <B>
DoSet("Resolve.AdvancedSchedulePostSolve[0].Logical[0]", "1") - sets the first entry in
the collection to "OR", i.e. if <A> OR <B>
2.19.1.2.10.1 Event driven schedule action variables
The action is the action to take when a schedule condition has triggered.
For example:
Resolve.AdvancedSchedulePostSolve[0].Action.VariableActions[0].Variable returns the
first entry in the list of variables to change.
Resolve.AdvancedSchedulePostSolve[0].Action.VariableActions[0].NewValue
returns
the value of the first entry in the list of variables to change.
Action
The following structures are available from the Action structure.
RedoSolve
Governs whether, after a solve has been performed, the system should be resolved
(effectively, this would be used to "test" the change that has just been made). It is only
available in the PostSolve section of the event driven scheduling.
ClosureActions
Actions which cause the closure of a connection in Resolve.
VariableActions
Actions in which a variable changes value.
RankingActions
Actions, taken from the above lists, which are ranked according to an extra variable.
ClosureActions
For example:
Resolve.AdvancedSchedulePostSolve[0].Action.ClosureActions[0].Connection
575
RESOLVE
Connection
A string that describes the connection to perform the action on. The string is of the form:
A~B, where A and B are the labels of the upstream and downstream objects respectively.
(An easy way to get this string is to use <Ctrl> <RClick> on an existing entry in the list).
Action
The action to perform:
0 - open
1 - block
VariableActions
For example:
Resolve.AdvancedSchedulePostSolve[0].Action.VariableActions[0].NewValue
Variable
The variable string, e.g. Sep_GOR.
NewValue
The new value that the variable is to take
ClosureActions and VariableActions both have a read-only element:
Description. This returns a text description of the action in question.
RankingActions
For example:
Resolve.AdvancedSchedulePostSolve[0].Action.RankingActions.NumberToExecute,
Resolve.AdvancedSchedulePostSolve[0].Action.RankingActions[0].ActionToPerform
RankBy
Corresponds to the "order to execute actions" box on the "Variable ranking" screen.
NumberToExecute
Corresponds to the "count" box on the "Variable ranking" screen.
ActionToPerform
This is the description of the variable that is to be ranked.
For example, a variable description could be obtained by the string:
s
=
DoGet("Resolve.AdvancedSchedulePostSolve[1].Action.
VariableActions[0].Description")
and this variable could be added to the ranking variables by:
DoSet("Resolve.AdvancedSchedulePostSolve[1].Action.RankingActions
[0].ActionToPerform", s)
User Guide
576
RankingVariable
An expression which determines how the variable is ranked
For example:
DoSet("Resolve.AdvancedSchedulePostSolve[1].Action.RankingActions
[0].RankingVariable.Expression", "10")
assigns the value "10" to the ranking of this variable.
2.19.1.2.11 Scenario manager variables

The scenario manager variables give access to the "Scenario Manager" section of RESOLVE.
The variables are all to be found under the top-level structure: Resolve.Scenario.
To add an empty scenario, do:
Call DoSet("Resolve.Scenario.Add", "0")
(this is in common with the syntax for adding entries to any collections).
It is possible to manipulate (e.g. copy) existing scenarios with OpenServer "commands".
The elements of the Scenario structure are described below:
Name
The name of the scenario
e.g. Resolve.Scenario[0].Name.
Once the name is obtained, the name can be used to index the collection, e.g. Resolve.
Scenario[{name}]...
/
AdvancedSchedulePostSolve
/
AdvancedSchedulePreSolve
AdvancedScheduleStart
These are "event driven schedule" structures. They are covered in detail in the "Event
Driven Scheduling Variables" section.
AdvancedSchedulePreLoad
A collection of actions to perform prior to the scenario run being performed
e.g. Resolve.Scenario[0].AdvancedSchedulePreLoad.Count, Resolve.Scenario[0].
AdvancedSchedulePreLoad[0].Name
The actions have the following elements:
577
RESOLVE
Name
The Resolve OpenServer string on which to call DoSet.
Value
The value of the OpenServer variable to set to.
LastRunDate (read-only)
The date that this scenario was last executed.
ErrorStatusMsg (read-only)
The error status of the last run (if any).
Results
Accesses the results for the scenario in question. Use <Ctrl> <RClick> from the scenario
results screen to examine the structure of these.
Example
To change the end date of the RESOLVE run for a given scenario (as part of the
scenario), the following could be used:
Call DoSet("Resolve.Scenario[0].AdvancedSchedulePreLoad.Add", "0")
" add an entry to the preload list
Call DoSet("Resolve.Scenario[0].AdvancedSchedulePreLoad[0].Name", "Resolve.
ScheduleList[0].EndDate")
" set the OpenServer variable for the end of
the run
Call
DoSet("Resolve.Scenario[0].AdvancedSchedulePreLoad[0].Value",
"01/01/2020")
" set the value of the OpenServer
variable (change the date)
This set of instructions will change the end date of the run for Scenario[0].
2.19.1.2.12 Variable link variables
The Resolve.VarLink collection gives access to the "Variable link" objects that allow any
variable to be transferred seamlessly between applications.
There are no elements to the top-level VarLink collection, except the normal operations such as
retrieving the collection count, e.g. Resolve.VarLink.Count.
The VarLink item structure, e.g. Resolve.VarLink[0].Label
An individual VarLink item (e.g. Resolve.VarLink[0]) refers to a sub-collection of variable links
between two RESOLVE modules.
The elements are:
User Guide
578
Label (read-only)
The label assigned to the variable connection, it is always of the form A~B, where A is the
upstream module and B is the downstream module. Once obtained, this can be used to
index the collection, e.g. Resolve.VarLink[0].Label <=> Resolve.VarLink[{label}].
Label
StartModule
The name of the upstream module
EndModule
The name of the downstream module
Mask
Get or set the mask state of the variable connection
Disable
Get or set the disable state of the variable connection
The individual VarLink item described above itself is a collection of individual variable links, e.g.
Resolve.VarLink[{label}].Count, Resolve.VarLink[{label}][0].StartVarID.
The elements of this structure are:
StartVarID
The name of the variable in (exported from) the upstream module.
EndVarID
The name of the variable in (exported from) the downstream module
Shift / Multiplier
The linear transformation applied to the quantity as it is passed (e.g. for unit conversions).
2.19.1.3Commands
The following list describes the OpenServer commands with their arguments. Some of these
arguments may be optional - if this is the case they will be specified by "arg = (default value)".
All the commands are listed on the left hand side of the "OpenServer test screen".
File Handling etc commands
NewFile()
Clears the current RESOLVE file and creates an empty system.
OpenFile(filename, mode = 0)
579
RESOLVE
Opens the file "filename". If mode = 1 the file is opened in "Results Only" mode, i.e. the
client applications are not loaded and the only functionality enabled is the ability to view
the results that were saved with the file.
CloseFile()
Closes down the current model. Equivalent to File | Close from the main menu.
SaveFile()
Saves the current RESOLVE file
It is possible as well to save the current GAP file for instance using the following
OpenServer command:
DoCmd("Resolve.Module[{GAP}].SAVEFILE("""C:\test.gap""")")
SaveAsFile(filename, overwrite = 0)
Saves the current RESOLVE file as "filename". If "overwrite" = 0 (default) the command
will return an error if the file already exists. overwrite = 1 forces the file save.
BrSave()
Performs a broadcast save, i.e. broadcasts a save command to all the client modules.
Note that not all modules (e.g. Eclipse) may implement a Save command (the Petroleum
Experts products always do).
SaveMod(label)
Broadcasts a Save command to the module specified by "label". Note, as with BrSave
above, that not all modules implement the Save command.
CreateArchive(archivefile)
Creates an archive with the given name of the current RESOLVE model. All the RESOLVE
module files will be contained in this archive, and (along with BrSave()) it can be used to
store the state of the model at the end of a run.
ExtractArchive(archivefile, new-path)
Extracts the archive specified by "archivefile" to the path given by "new-path".
MakeProjectFile(file)
Creates a text file ("file") which contains all the module files that are used in the
RESOLVE model.
ShutDown()
Shuts down RESOLVE.
Run Execution commands
Run()
Runs the RESOLVE prediction. This call blocks until the run is complete.
User Guide
580
RunOneStep()
Runs a single step of the RESOLVE prediction. This call blocks until it is complete.
RunEnd(runtoend = 0)
Terminates the current prediction if single-stepping through the run.
If runtoend = 1 the run will be completed to the end of the schedule.
Optimise()
Perform a RESOLVE optimisation.
SaveStream(streamname, maxnames=10000)
This saves the current forecast results under a new stream name called "streamname".
If "maxnames" is set then, if the total number of saved streams exceeds this value, the
oldest stream(s) is/are deleted.
SaveOptStream(streamname, maxnames=10000)
The same as SaveStream() for optimisation results.
Model building
CreateModule(driver, x, y, label)
driver - the name of the driver (or application name), e.g. GAP
x - the x coordinate of the icon on the screen (left = 0)
y - the y coordinate of the icon on the screen (top = 0)
label - the label to give to the module
DeleteModule(label)
label - the name of the module to delete
LoadModule(label)
label - the name of the module to load. This loads the module with the current module
data (e.g. for a GAP module the GAP application will start and load up the required case)
LinkItems(mod1, item1, mod2, item2)
mod1 - the parent module of the first item to link
item1 - the label of the first item to link
mod2 - the parent module of the second item to link
item2 - the label of the second item to link
DeleteLink(mod1, item1, mod2, item2)
Removes a connection between icons. Arguments as for LinkItems()
Exporting variables from client modules
ExportVariable(module,equipment,variable,newvarname)
Exports ("publishes") a variable from the client application specified by "module".
The "equipment" is the item of equipment that "owns" the variable.
581
RESOLVE
The "variable" is the variable name. This can be obtained from an OpenServer string of
the form: Resolve.Module[{xxx}].Equip[{yyy}].Variable[n].Label. In Hysys and UniSim
Design, it can be obtained by right-clicking on the icon and going to the "Object
Browser".
The "newvarname" is the name to which the exported variable will be referred in
RESOLVE.
Examples:
To export a solver variable from GAP.
These can be obtained using the method above.
DoCmd("Resolve.EXPORTVARIABLE
(""GAP"",""Sep1"",""GOR"",""myGor"")
DoCmd("Resolve.
To export ANY variable from GAP
EXPORTVARIABLE(""GAP"",""Sep1"",""GAP.MOD[{PROD}].SEP
[{Sep1}].MaxQoil"",""myConstraint"") (i.e. enter the full OpenServer string)
RemoveVariable(module,variable)
This removes an exported variable. "module" is the name of the client module which has
already exported the variable. "variable" is the name applied to the variable (equivalent to
"newvarname" in the ExportVariable entry above).
RemoveAllVariables(module="")
This removes all the variables exported from "module". If this is defaulted, then all
exported variables from all modules will be removed.
Scenarios and event driven scheduling
AddScenario(name)
Adds an empty scenario to the scenario manager with a given name.
CopyScenario(dest-scenario, src-scenario = "")
Copies an existing scenario (which can be modified later). If the "src-scenario" is
defaulted (i.e. is blank) then it copies the current contents of the event driven schedule to
the new scenario. The new scenario is given the name supplied with "dest-scenario".
NewScenario(name)
The same as AddScenario().
RemoveAllScenarios()
Clears the scenario manager of all its contents.
RemoveScenario(name)
Removes the scenario titled "name" from the scenario manager.
SetScenarioAsCurrentSchedule(scenariolabel)
The reverse of CopyScenario() where src-scenario is defaulted. This copies a named
User Guide
582
scenario "scenariolabel" to the current event driven schedule.

RunScenario(scenario)
Runs the given scenario in the current RESOLVE session (i.e. LSF is not used even if it is
available).
RunAllScenarios(use-lsf=0)
Runs all the scenarios in a single batch job. If "use-lsf" is specified, this will pop-up the
application that allows the selection of LSF nodes for the runs. This will obviously require
some user input and goes against the normal rule of "no user interface components for
OpenServer commands", so a "DoSlowCmd" should be used.
Miscellaneous commands
ChangePath(newpath)
This goes into all the client modules which support the feature and change the model file
path from the current path to "newpath". This does not force a reload of the models: if it is
used, the file should be saved and then reloaded.
ExModOSCmd
This is obsolete.
To execute a command in GAP, the syntax <DoCmd("Resolve.Module[{GAP}].MOD
[{PROD}].Well[{W1}].Mask()> is allowed and preferred.
For instance, to save a GAP file, the following command can be used:
DoCmd("Resolve.Module[{GAP}].SAVEFILE("""C:\test.gap""")")
LinkComponent(module1, item1, component1, module2, item2, component2)
This can be used to map components (if the component names are known in advance)
prior to a compositional run being performed. Its use is explained in the sample macro
comp-mapping.rsa.
2.19.1.4Sample macros
These archives contain the required Excel spreadsheet that implements the macro, as well as
any other associated files.
More information as well as a list of the OpenServer examples provided can be found in the "
Worked Examples" section.
2.19.2 Creating a Resolve optimiser in Excel

2.19.2.1How to create a RESOLVE optimiser in Excel
In IPM #7 it is possible to create an algorithm to solve RESOLVE optimisation problems in an
583
RESOLVE
Excel macro (VBA).

The architecture of this consists of two components:
pxExcelOptnn.dll (where nn is the IPM major version number, e.g. 07). This is the DLL
plug-in which communicates with Excel. It is supplied as part of the IPM distribution.
An Excel spreadsheet which is coded by the user. A sample is provided under the .
\samples\resolve\User_Excel_Optimisation directory of the IPM distribution.
The plug-in DLL needs to be "pointed" at the Excel file created by the user. Once the DLL is "
Registered" this is performed from the "parameters" button of the optimisation "Summary"
screen.
The architecture of the scheme is represented in the following diagram:
The optimiser calls subroutines in the Excel macro. Data (e.g. the control operating points for the
next iteration) are returned to RESOLVE by placing the required values on specified cells on a
worksheet.
Comprehensive information on the data transfer, the workflow, and the operation of the macro
subroutines can be found in the Excel spreadsheet sample provided.
User Guide
584
2.19.3 Known issues

2.19.3.1Known Issues
Running RESOLVE on the Windows 2000 Operating System
If a file browser is prompted to open or save a RESOLVE model, or any file browser under
RESOLVE to open a client file (e.g. GAP, REVEAL, or Hysys) then RESOLVE will hang if the "My
Documents" directory is browsed
This is the result of a bug in the Microsoft system DLL "mydocs.dll" when used with
applications like RESOLVE which operate on COM objects in a multithreaded manner. There is
no workaround to this problem.
As a result, users are forced to set up and use the data directory under the "System preferences
" if running under Win2000. This avoids the possibility that the browser will automatically open in
the "My Documents" directory, but does not stop the user from subsequently browsing to this
directory (in which case RESOLVE will hang).
2.19.4 Further Technical Elements for Distributed Applications

2.19.4.1Distributed Applications
This section describes how applications may be distributed over a LAN or WAN. In general, this
functionality is implemented as part of the driver code and so the procedure to set the links up
depend on the application in question.
Only those drivers written by Petroleum Experts are described here; for help with other drivers
please contact those vendors.
This is divided into the following sections:
Running IPM applications on a remote server
Running Hysys, UniSim Design, and Excel on a remote server
Running Eclipse on a remote server
2.19.4.2Running IPM instances on a remote PC

The procedure below will describe step by step how to connect two PCs and run an IPM
application included in a RESOLVE model on a remote PC.
At the end of the procedure, a flowchart can be found that summarises all the steps described
585
RESOLVE
below.
The communication between RESOLVE and the IPM tools is through the OpenServer, which is
a specialised COM object. The protocol that needs to be configured for the communication to
take place, therefore, is DCOM.
The PC running RESOLVE will be called the Master PC.
The PC running the remote IPM application will be called the Remote PC.
Step 1
Open RESOLVE on the Master PC and Launch the DCOMUTIL wizard that enables
to connect two PCs for remote IPM applications.
Step 2
Browse for the Remote PC name and Test whether the PXServer is working with
the Remote PC.
To do so:
1. Select the Application to consider (i.e. here GAP).
2. Browse for the remote computer and test the PXServer communication
If the PXServer test is positive, this means the Master PC can communicate with
the Remote PC.
If the PXServer test fails, the Master PC is unable to communicate with the Remote
PC and further configuration procedures need to be ran on the remote PC (i.e.
refer to Step 3 and further).
User Guide
586
3. When the PXServer test is positive, test the communication with the Remote PC
by clicking on the Connect button. If all the procedure is successful, a new
window of the remote application should appear on the screen of the remote
computer.
If this is the case, all that needs to be done is to note down the name of the remote
PC and specify it in the RESOLVE section of the application to be run remote, as
illustrated below.
Step 3
(This Procedure should only be followed if the PXServer test on the remote PC
failed)
Note on the use of firewalls with DCOM

A firewall on the target computer will probably disrupt DCOM
communication to that computer.
In this case, either disable the firewall or open up port 135
The configuration of the PXServer object has been automated. An executable is

587
RESOLVE
installed with the IPM software called DComSetupBatch.exe.

From a command prompt on the remote computer, type:
> dcomsetupbatch /os
and repeat the tests on the master PC described in Step 2.
Note that this utility is invoked by LSF to "Automatically configure" all the nodes of
an LSF cluster when clustering is used with RESOLVE.
Local administrative privileges on the remote PC will be needed to run this tool.
If it is still not possible to connect to the remote PC, then follow the steps below on
the remote PC.
Once again, local administrative privileges on the remote PC will be required.
Go to Start | Run and run dcomcnfg
Go to Component Services | Computers | My computer | DCOM config and

check that there is a PXServer 32 Document in that section.
If it does not exist, then go and run the PXServer.exe utility.
User Guide
588
If it exists, then right click on it and select Properties.

In the General subsection: Check if it is pointing towards the right path
In the Location Subsection: make sure that the Run Application on this computer
option is selected.
589
RESOLVE
In the Security subsection: Select the Customise option for all sections and Add
the Group EVERYONE and give that group full control for all three sets of
permissions.
User Guide
590
In the EndPoints section: nothing particular needs to be done

In the Identity section: make sure that the user selected is The Interactive User.
591
RESOLVE
Then, right click on the My Computer icon and select Properties.

Go to the COM security section.
Under "Access Permissions", click on "Edit Limits" and assign "Everyone" (or the
subgroup of users that the user require) local and remote access.
Under "Launch Permissions", click on "Edit Limits" and assign "Everyone" (or the
subgroup of users that the user require) local launch, remote launch, local
activation, and remote activation permissions.
Once this is done, go back one step to the default properties, and make sure that
distributed COM is enabled.
User Guide
592
593
RESOLVE
User Guide
594
595
RESOLVE
User Guide
Step 4
596
Once this is done, retest the PXServer activation (i.e. Step 2): it should now be
possible to see the REMOTE Computer from the MASTER computer, and it is now
possible to run distributed applications along with the RESOLVE model
considered.
The next page contains a flowchart illustrating this procedure.
597
RESOLVE
2.19.4.3Running Hysys, UniSimDesign, and Excel on a remote server

The communication protocol between RESOLVE and these applications is DCOM, which is the
same protocol used between RESOLVE and the IPM tools. The configuration procedure is
therefore very similar.
To enable these applications to be launched remotely, the respective COM objects must be
configured on the target (remote) machines.
The procedure described under Step 3 of "Running remote IPM applications" can be followed,
with the following differences:
The dcomsetupbatch.exe tool is not currently set up to automatically configure these
tools.
The COM object configured for IPM use is called "pxserv32 document".
The corresponding objects for these applications are:
User Guide
598
Excel -- "Microsoft Excel application"

Hysys -- "HYSYS simulator"
UniSim Design -- "UniSim Design Simulator"
Under the identify tab, do not select "Interactive User".
2.19.4.4Running an Eclipse instance on a remote computer
The procedure below will describe step by step how to connect two computers and run Eclipse
included in a RESOLVE model on a remote machine (i.e .PC or Unix).
The machine running RESOLVE will be called the Master machine.
The machine running the remote Eclipse instance will be called the Remote machine.
Running an Eclipse instance on a Remote computer (PC or Unix / Linux).
There are three tools available for the connection to a remote computer running Eclipse:
PVM
(Parallel
Virtual
Machine)
MPI
(Message
Passing
Interface)
TCP/IP
connection
with MPI
This is the original method and has the advantage of allowing the connection to
Linux or Unix platforms (32-bit only).
This was the original protocol supplied with OpenEclipse and is no longer
supported by SIS (although it is still supplied as part of the Eclipse distribution).
PVM is not always robust and the parallelisation of multiple runs in a single
RESOLVE model is not perfect. However, it does allow cross platform
communication, i.e. RESOLVE / GAP on a PC with Eclipse on a UNIX or Linux
system.
The use of PVM is not recommended as it is no longer supported, but notes on
its use can be found in the "PVM Legacy Notes" section
This is the preferred option for local or PC-PC connections. Unfortunately, it
does not allow connections to Linux or Unix platforms.
This is the preferred choice of Schlumberger. There are two implementations of
MPI used by SIS: these are described in the section on the use of MPI
This has been developed by Petroleum Experts to allow the connection
between RESOLVE running on a PC and Eclipse running on Linux (ia32 or x8664). The platform tested by Petroleum Experts is Red Hat Linux (4). It is
preferred over PVM because it is supported by Petroleum Experts and SIS,
and also it is truly parallel
The setup procedures for the two later options are described below:
MPI Setup
Before attempting to configure MPI to connect to a remote Windows PC, the '
Local configuration' of MPI should have been carried out.
On the remote PC, the same setup and configuration of MPI should be carried
599
RESOLVE
out. The major difference between running Eclipse locally and running Eclipse
on the remote machine is that RESOLVE does not know where Eclipse is
installed on the remote machine. This means that the PATH environment
variable must be modified on the remote computer to include the path to the
eclipse_mpi.exe, for example:
PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32
\Wbem;C:\ecl\home;C:\ecl\macros;C:\ProgramFiles\MPIPro\bin;C:\Program
Files\Common Files\AspenTech Shared\;c:\program files\mpich2\bin;C:
\Program Files\SPT Group\FlexLm;C:\ecl\2007.2\bin\pc
The remote connection can be tested under the "EclConfig" wizard; any
problems can be picked up from the MPI log file. Problems that can occur can
often be traced back to Windows security issues such as a running firewall or
difficulties with MPI logging on to the remote server. These issues can usually
be addressed by I.T. staff, and Petroleum Experts can also be contacted for
further assistance.
The environment needs to be set up on the remote PC to allow Eclipse to
obtain a license when it loads a data file, as it would need to be on the local PC
when running Eclipse locally. In other words the variable LM_LICENSE_FILE
needs to be set appropriately, e.g.
TCP/IP
connection
with Scali or
MPICH MPI
LM_LICENSE_FILE=1600@MYSERVER
This is a custom connection that allows the linking of RESOLVE on a Windows
PC with Eclipse running on a Linux workstation (either 32- or 64-bit: ia32 or
x86-64). It also interfaces with LSF running on a Linux cluster to automatically
distribute the Eclipse instances about the cluster.
Complete documentation on this link can be found in the "RESOLVE controlled
remote Eclipse runs on Linux section" as well as with the executables under the
"linux-executables-for-resolve-eclipse" subdirectory of the installation directory
2.19.4.5RESOLVE controlled remote Eclipse runs on a Linux cluster

The following section illustrates the characteristics and setup procedure to be used in order to
run remote Eclipse runs on Linux platforms from RESOLVE.
Note that, from the 2009 release, there are now more options regarding the setup and versions
of MPI that are used to make the connection:
Eclipse version
Processor
Pre-2009
ia32
Pre-2009
2009+
x86_64
ia32
MPI flavour
mpich or Platform MPI(*)
Platform MPI
mpich or Platform MPI
Notes
mpich is free, Platform MPI
is licensed by Platform(**)
User Guide
Eclipse version
Processor
2009+
x86_64
MPI flavour
Platform or Intel MPI
600
Notes
Intel MPI is free
* Platform MPI was formerly known as Scali MPI, or Scali Connect (SMC).
** Platform MPI is recommended for this application, as it is considerably more robust.
Before installing the IPM components on the Linux machine/cluster, the appropriate
MPI installation (i.e. mpich, Scali, or Intel) should have been made and tested. Refer to
the documentation on these applications.
In addition, if LSF is to be used to distribute the Eclipse jobs, then this should be
installed and tested before the IPM components are installed.
Contents
History
Overview
Installation
Setting up the Linux (client) side non-LSF version
Setting up the Linux (client) side LSF version
Administering the daemons
How the software works
Setting up the Windows (RESOLVE) side
2.19.4.5.1 History
Prior to 2007, the standard method of connecting RESOLVE to a remote (Unix or Linux) Eclipse
run was through the PVM protocol.
Support for this by Schlumberger was discontinued from 2007.
For this reason Petroleum Experts developed an alternative approach using OpenEclipse and
the MPI protocol.
2.19.4.5.2 Overview
The architecture is built around two components for LSF and non-LSF runs.
The LSF version allows LSF to distribute the run to an appropriate machine (i.e. one that is not
currently loaded).
The non-LSF version requires the user to specify a machine on which the Eclipse job should be
run.
601
RESOLVE
The components are:

mpirunfactory.exe
mpieclcontroller.exe
Currently, these components are built only for the Red-Hat Linux operating system,
version 4 and 5.
mpirunfactory.exe is a daemon process that spawns Eclipse runs.
mpieclcontroller.exe is the OpenEclipse proxy which acts as an intermediary between RESOLVE
and the Eclipse run.
These two programs are installed on a central Linux32 or Linux64 server. Eclipse runs can then
be spawned on the same server or any other appropriately configured Linux computer on the
network.
The Linux machines (Linux1
Linux5) can be 32 or 64 bit (ia32/x86_64).
The Eclipse models communicate with the RESOLVE controller (mpieclcontroller) using a Linux
MPI protocol.
The RESOLVE Windows PC communicates with the controlling Linux server using low level
socket calls.
There are three flavours of Linux MPI supported:
mpich (32-bit only)
Platform MPI (Scampi) (32- or 64-bit)
Intel MPI (64-bit only, 2009+ version of Eclipse)
2.19.4.5.3 Pre-requisites
Before installing the Linux-side IPM software, the required flavour of MPI must be installed and
must be working satisfactorily. The following tests will be sufficient to show this:
User Guide
Scali MPI
(SMC)
602
The example program 'hello' should be run without error on the local host, and
on other nodes as required, i.e.
/opt/scali/bin/mpimon /opt/scali/examples/bin/hello -- localhost
...ensures that the local installation of SMC is correct.
/opt/scali/bin/mpimon /opt/scali/examples/bin/hello -- remotenode
...will ensure that SMC is working correctly across a cluster, which will allow
Eclipse to run on <remotenode> when the run factory daemon is running on
the local node.
Intel MPI
In addition, /opt/scali/bin/mpimon /opt/scali/examples/bin/hello -- localhost

should work on any node in an LSF cluster on which Eclipse may start
The MPI processes (mpd) need to be running under the user account that will
be performing the Eclipse run. Multiple mpd's can be run for different users.
In other words, the command:
ps -ef | grep mpd
should yield:
python /ecl/tools/linux_x86_64/intel/mpi/3.2/bin/mpd
or something similar.
To start up these processes, follow the instructions in section 2.5 of the
Getting_started.pdf guide in the $ILMPI_HOME/doc directory.
Once this has been set up satisfactorily, the command:
./mpiexec -n 1 -host localhost /ecl/tools/linux_x86_64/intel/mpi/3.2/bin/
mpdringtest
should complete without error. As with the SMC instructions, it should be
possible to perform the same test across nodes, and as a local process on
any node on which LSF can spawn the job
2.19.4.5.4 Installation
This section assumes that the person performing the installation has a working knowledge of the
Linux environment. The following steps require the user to be logged in as root on the Linux
603
RESOLVE
machine.
STEP 1
CREATE NEW DIRECTORY WHERE THE NEW EXECUTABLES WOULD

BE PLACED
In the following, it is assumed that the new executables would be placed under the
directory </home/developer>. A new directory will be created called ecl-ipm75
To do this, the command:
mkdir ecl-ipm75
can be used under the </home/developer> directory
STEP 2
COPY FILES ACROSS FROM WINDOWS INSTALLATION DIRECTORY OF

IPM TO THE STATED TARGET DIRECTORY
There will be a file titled mpi_resolve.tar.gz located in the installation directory of
IPM (which is generally C:\Program Files\Petroleum Experts\IPM 7.5
\linux_executables)
Copy this file across to the target directory on the Linux machine.
STEP 3
SWITCH TO TARGET DIRECTORY

Change the directory to the target directory using the command:
cd ecl-ipm75
User Guide
STEP 4
604
UNPACK THE INSTALLATION FILE

The user must be in the stated installation directory (for the sake of this example it
is /home/developer/ecl-ipm75). Launch the command <gunzip mpi_resolve.tar.
gz>
This will unpack the tar file and place the file mpi_resolve.tar in the installation
directory. The next command will be to extract the archive file using the command:
tar xf mpi_resolve.tar
STEP 5
INSTALLATION
605
RESOLVE
As root run the installation by entering the command:

./install.sh
The installation will require the entering of various entries from the user. These are
described as follows.
STEP 6
DEFINING THE TARGET DIRECTORY

The target directory will be the location where the installation executables will be
placed. In this example we assume this to be /home/developer/ecl-ipm75
Specify this in the target directory section and press enter.
STEP 7
DEFINING THE OPTIONS

Select the option for performing the task. There are four options available
OPTION 0: EXIT
User Guide
606
OPTION 1: INSTALL SOFTWARE ONLY

OPTION 2: SETUP CONFIGURATION
OPTION 3: DO EVERYTHING
As would be expected, there are some configuration files that need to be
placed on the Linux machine. These configuration files could be copied across
from the previous installation if they are already present (eg for IPM 6). If this is the
case the objective would be to install the software only, which is Option 1. The
configuration files will not be written with this option.
If the configuration files are to be freshly written by the installer, Select OPTION 2.
Select OPTION 3 if the objective is to do both.
If the installation of the Linux executables is being performed for the first time, it is
strongly advised that Option 3 be selected. This will guide the person performing
the installation towards setting up the Linux environment as required.
For the sake of this example we shall ask the installer to install the software AND
setup the configuration files. Thus the option to select will be <Do Everything>
which is option number 3.
STEP 8
DEFINING THE LINUX ARCHITECTURE.
607
RESOLVE
STEP 8 will be applicable only if the user has selected option 1 or option 3 in
STEP 7. STEP 8 will not be applicable if the user has selected OPTION 2 in
STEP 7.
Enter whether the machine is 32 bit or 64 bit.
The mpi_resolve.tar.gz file that was installed in step 2 above, is basically a tape
archive (tar) file (like a zip file) which has some files stored in it. These files are
the components that are required to be installed on the Linux Machine. In this tar
file, there are two versions of the installation files available.
a) 32 bit architecture (ia32)
b) 64 bit architecture (x86_64).
Depending upon the option that is selected in this step, the installer will unpack
the correct version of the files and place them in the installation directory. The
procedure to install the components remains the same for both architectures
STEP 9
DEFINING THE NUMBER OF PORTS AND THE BASE PORT:

STEP 9 will be applicable only if the user has selected OPTION 2 or OPTION 3
User Guide
608
in STEP 7.
This option represents the number of ports that are free to be used by the Eclipse
Controller (through which RESOLVE will be communicating with Eclipse). Further
information on how RESOLVE uses these ports is described in this section of this
User Guide.)
Enter the number of ports. The default number of ports is 5. If there are sufficient
numbers of port available, then it is recommended that more ports (10-20) be
created. This reduces the chance of the system running out of ports. Each Eclipse
job that is run will reserve one port; if there are two Eclipse models in a RESOLVE
file, then two ports will be reserved.
After this, the base port needs to be entered. This is the lower end of the range of
ports that will be used. In the configuration below, ports from 12500 - 12509 are to
be used by the RESOLVE-Eclipse connection.
STEP 10
DEFINING THE INSTALLATION DRIVE OF ECLIPSE:

STEP 10 will be applicable only if the user has selected OPTION 2 or OPTION
3 in STEP 7.
609
RESOLVE
Enter the directory where the Eclipse instance has been installed on the Linux
machine/cluster. In this example the location of the Eclipse executable is in
location </ecl/2009.1/bin/Linux>. A directory must be entered - no default is
supplied.
STEP 11
SAVING THE CONFIGURATION FILES:

3 in STEP 7.
The Eclipse path entered in the previous step may be the path for Eclipse across
all machines of a cluster (indeed, this would be the usual setup). Entering 'y' for
this option will mean that any machine which runs Eclipse spawned from this
machine will refer to the same path. If 'n' is entered, then the option will exist to
specify different Eclipse paths for different machines. This is discussed below.
User Guide
610
The installer writes basic versions of the three configuration files described below
STEP 12
EDITING THE CONFIGURATION FILES FOR THE USER PERMISSIONS.

3 in STEP 7.
There are three configuration files that are created during the installation process:
a) .ecl_resolve_config --> configures the TCP/IP ports used by the connection,
and sets up the paths to the Eclipse executables. This file must be suitably
configured when using either the non-LSF or the LSF-enabled versions of the
software. This will normally be set up correctly by the installer; however, more
information on the set up of this file can be found in the section on administering
the Linux daemons.
b) .ecl_resolve_users --> administration file in which privileges can be granted or
refused for RESOLVE Users. This is applicable only to the non-LSF version of the
software.
c) .ecl_resolve_lsf_users --> equivalent file to the .ecl_resolve_users.config for
the LSF implementation, in which queues for individual and default users can be
611
RESOLVE
set up.
Additional empty configuration files are created: .ecl_resolve_env, .
ecl_resolve_env_intel, .ecl_resolve_env_scampi. These can be used to refine the
behaviour of the software (by setting environment variables), but are not
discussed here as they are entirely optional and not necessary for the correct
operation of the software. They are discussed fully under the section on
administering the Linux daemons.
From the above three files, the '.ecl_resolve_users' file is applicable for the NonLSF version. A complete discussion of all of the options in this file can be found
under the section on administering the Linux daemons, which also discusses the
LSF-enabled version. However, the discussion below should be an aid in getting
started.
The file allows for permissions on running the software to be allocated to different
users. It also maps Windows usernames to Linux usernames, so that Eclipse jobs
will be run under the appropriate user account. The following few points describe
the steps that are to be taken in editing and updating this file.
By default the permissions will be set as
<* * 1>
The first * indicates the user name on the Windows server. The Second *
indicates the user name on the Linux server. The number 1 indicates that
permission is allowed for the stated user.
Having the permissions defined as * * means that the users ID which is present
on the Windows server will be passed across through to the Linux server. If for
any reason the users ID does not correspond between the two servers, then this
needs to be specified.
For the sake of this example we shall assume that the users have an individual
windows user ID but do not have a corresponding id on the Linux side. The file .
ecl_resolve_users config file is thus modified to read
<* developer 1>
In this instance, all windows user IDs will be mapped as the user developer on
the Linux server.
It is assumed that the person performing the upgrade is familiar with editing the
config file. Either the VI editor or a graphical text editor can be used.
User Guide
612
For a Linux setup using LSF: the config file that requires modification is the
file .ecl_resolve_lsf_users. The steps that are required in this config file are
largely similar to the ones described above. Further documentation on this can
be found in this section of this User Guide
STEP 13
LAUNCH THE PROCESS.

The process that is launched depends on the flavour of MPI that is required, as
discussed in this section of the guide.
The arguments that are passed on the command line of the different daemons are
described in detail in this section (non-LSF) or this section (LSF). The notes
below should be an aid to getting started for the non-LSF versions. The directory
<install> corresponds to /home/developer/ecl-ipm75 from the notes above.
To obtain a list of the arguments (any flavour of MPI) the daemon in question can
be run with no arguments.
To obtain the version information for the daemon, it can be run with the single
argument '-V' (no quotes).
If using mpich (32-bit only):
<install>/mpirunfactory_mpich.exe 8888 /ecl/tools/linux/mpich/bin @LSERV /
ecl 0 0
where: 3457 is the port that RESOLVE will use to connect to the daemon, /ecl/
tools/linux/mpich/bin is the directory which contains the mpirun executable,
LSERV is the Eclipse licence server, and /ecl is the root directory of the Eclipse
installation.
The fifth argument should be a '0' (as above) if using a pre-2009 version of
Eclipse, or '1' otherwise.
If using Scali MPI (also known as Platform MPI or SMC) (32- or 64-bit):
<install>/mpirunfactory_scampi.exe 8888 /opt/scali/bin 1 0
where: 3457 is the port that RESOLVE will use to connect to the daemon, /opt/
scali/bin is the location of the Scali MPI mpimon executable.
The third argument should be a '0' (as above) if using a pre-2009 version of
Eclipse, or '1' otherwise.
The final argument is normally '0'; putting '1' here turns on extensive logging which
will slow down the run if it is not needed.
613
RESOLVE
If using Intel MPI (64-bit only):

<install>/mpirunfactory_intel.exe 3457 $ILMPI_HOME/bin64 0
where: 3457 is the port that RESOLVE will use to connect to the daemon,
$ILMPI_HOME/bin64 is the location of the Intel MPI mpirun executable. The full
path can be given, although it is usually convenient to take advantage of the
environment variable set by the user.
The final argument is normally '0'; putting '1' here turns on extensive logging which
will slow down the run if it is not needed.
It is possible that Eclipse will not start due to an error opening a shared object:
this will be output to the Linux terminal from which the daemon was launched. In
this case one of the following tasks can be carried out:
1. The variable LD_LIBRARY_PATH can be set in the environment from which
the daemon is launched, i.e.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ILMPI_HOME/lib64
The Intel run factory daemon can then be restarted.
2. Alternatively, the .ecl_resolve_env_intel can be used. Add the line:
LD_LIBRARY_PATH
/ecl/tools/linux_x86_64/intel/mpi/3.2/lib64
(the $ILMPI_HOME environment variable can not be used in this context)

The daemon need not be restarted in this case.
The above mentioned command lines will start the various
mpirunfactory_*.exe processes. Alternatively the file may be included as a
service on the Linux machine
STEP 14
SETTING UP RESOLVE TO RUN ECLIPSE:

The RESOLVE model will then have to be updated to indicate the port that is
being used by RESOLVE to communicate to the MPIrunfactory. This is the port (a)
as described in STEP 13 above and also in this section of the RESOLVE User
Guide. This is as shown below
User Guide
614
For troubleshooting advice, see the troubleshooting section.
Should you require any further information please send an email to edinburgh@petex.com or
contact:
PETROLEUM EXPERTS Ltd.
10 Logie Mill, Edinburgh EH74HG, UK
Tel: +44 (0) 131 4747030
Email: Edinburgh@petex.com
2.19.4.5.5 Setting up the Linux (client) side - running the daemons
This section contains more detailed information (than that given in the installation section) on the
running of the various run factory daemons that are connected to by RESOLVE.
615
RESOLVE
The following sections will describe the setup process for the various flavours of MPI, both LSF
and non-LSF versions:
Setting up with MPICH (non-LSF enabled)

Setting up with Scali MPI (SMC) (non-LSF enabled)
Setting up with Intel MPI (non-LSF enabled)
LSF daemons
In addition, it will probably be necessary to configure the daemons by way of various

configuration files. Information on this can be found in this section.
2.19.4.5.5.1 MPICH
The mpirunfactory_mpich.exe program must be running for RESOLVE to communicate with the
Linux computer.
The program takes several arguments which are detailed below:
<listen port (port a)>
This is the port (port (a)) which is used to communicate with the run
factory
<mpirun-path>
This is the path to the mpirun script, which should be found under
the /ecl/tools directory
<$LM_LICENSE_FILE> The program needs to pass the LM_LICENSE_FILE environment
variable on to the spawned Eclipse run. If the variable is exported to
the terminal then the user can enter $LM_LICENSE_FILE for this
argument. Otherwise the user should enter the value of the
environment variable as entered in the @eclrc script in the macros
directory
<$ECLARCH>
This variable is required by the mpirun script. It should be set to the
installation directory of the Eclipse software, which is usually /ecl
<controller log file (0/1) If the user enter 1 here then the controller will write a detailed log file
of its communication with RESOLVE and Eclipse. This is useful for
>
debugging purposes but should otherwise be turned off
Note that the run factory itself generates a log file (RunFactory_mpich.log) which itemises the
various runs that the program starts.
Example:
./mpirunfactory_mpich.exe 3456 /ecl/tools/linux/mpich/bin @DAVE-NW8240 /ecl 0
Notes:
The standard MPI script uses remote shell (rsh) which is usually installed as part of the
legacy part of the Linux operating system.
The mpirun script usually sets RSHCOMMAND=/usr/kerberos/bin/rsh. It may be
necessary to change this to the correct location of rsh (or create a logical link).
User Guide
616
2.19.4.5.5.2 Scali MPI (SMC)
The mpirunfactory_scampi.exe program must be running for RESOLVE to communicate with

the Linux computer.

<mpimon-path>
<2009+ Eclipse version (1/0)>
<controller log file(0/1)>
The arguments are the same as those of the mpich implementation, except that:
<mpimon-path>
This is the path to the mpimon program (which is the Scali equivalent of mpirun), which
should be found under the /opt/scali/bin directory (depending on where Scali is installed).
<2009+ Eclipse version (1/0)>
If a pre-2009 version of Eclipse is being run (i.e. set in the .ecl_resolve_config file), then
this should be set to '0'. Otherwise, it should be set to '1'.
Example:
./mpirunfactory_scampi.exe 3456 /opt/scali/bin 1 0
Notes:
A full Scali MPI license is required on each node in the system that is running Eclipse
as well as the server node (running the run factory and controller). Contact Petroleum
Experts for more information.
If the controller program is installed in a directory /mydir, then this directory must exist
(or be mounted) on all the nodes which are running Eclipse.
It is always a good idea to run the run factory program in a terminal window to view the
output of the program and/or mpimon when a connection from RESOLVE is made. This
will usually allow the user to debug any problems that can occur. See the section on
troubleshooting for more information.
2.19.4.5.5.3 Intel MPI
The mpirunfactory_intel.exe program must be running for RESOLVE to communicate with the
Linux computer.
<mpirun-path>
617
RESOLVE
<controller log file(0/1)>

The arguments are the same as those of the Scali implementation, except that:
<mpirun-path>
This is the path to the mpirun program, which should be found under the $ILMPI_HOME/
bin directory, assuming that this environment variable was set up by the installer (it should
point to /ecl/tools/linux_x86_64/intel/mpi/3.2, depending on where Eclipse is installed).
Note that there is no argument to specify the pre- or post- 2009 version of
Eclipse. This is because Intel MPI is only supported in post-2009 versions of the
program.
Example:
./mpirunfactory_intel.exe 3457 $ILMPI_HOME/bin64 0
Notes:
There is no need for any additional licensing for MPI when using Intel MPI.
If the controller program is installed in a directory /mydir, then this directory must exist
(or be mounted) on all the nodes which are running Eclipse.
It is always a good idea to run the run factory program in a terminal window to view the
output of the program and/or mpirun when a connection from RESOLVE is made. This
will usually allow the user to debug any problems that can occur. See the section on
troubleshooting for more information.
It is possible that, when the run is submitted from RESOLVE, Eclipse will not start due
to an error opening a shared object: this will be output to the Linux terminal from which
the daemon was launched. In this case one of the following tasks can be carried out:
1. The variable LD_LIBRARY_PATH can be set in the environment from which the
daemon is launched, i.e.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ILMPI_HOME/lib64
The Intel run factory daemon can then be restarted.
2. Alternatively, the .ecl_resolve_env_intel can be used. Add the line:
LD_LIBRARY_PATH
/ecl/tools/linux_x86_64/intel/mpi/3.2/lib64
(the $ILMPI_HOME environment variable can not be used in this context)

The daemon need not be restarted in this case.
User Guide
618
2.19.4.5.5.4 LSF daemons
The LSF setup is very similar to the non-LSF setup, excepting for the following:
The LSF version can use the Scali (SMC) flavour of the Intel flavour of MPI. This must
be installed and working correctly before continuing.
Instead of running mpirunfactory_scampi.exe, run mpirunfactory_lsf.exe.
The argument list can be obtained by running the executable with no arguments. Version
information can be obtained by entering the single argument '-V' (no quotes).
The arguments are as follows:
This is the same as in the interactive version: it is the port that RESOLVE connects
to initially.
<mpimon-path>
The path to the Intel or Scali executables, as in the interactive version.
<scali/intel 0/1>
Enter '0' to use Scali/Platform MPI, '1' to use Intel MPI.
<2009+ version>
Enter '1' is the Eclipse version is 2009 or later, '0' otherwise. If using Intel MPI, this
entry is ignored as Intel MPI is only supported for Eclipse versions 2009 and later.
<lsf-timeout (mins)>
The length of time that RESOLVE will wait for LSF to start the job (in minutes). This
argument is optional. If it is not entered, RESOLVE will wait indefinitely for the job
to start.
Examples:
mpirunfactory_lsf.exe 3456 /opt/scali/bin 0 0
mpirunfactory_lsf.exe 3456 $ILMPI_HOME/bin 1 1 10
For practical purposes it will be necessary to ensure that the executable drive is
mounted across all possible execution nodes. This is a requirement of LSF, but it also
means that the configuration files (e.g. .ecl_resolve_config) will be visible to any job that
starts.
mpirunfactory_lsf (on the LSF head node to which RESOLVE communicates) and
mpirunfactory_lsf_client (submitted by RESOLVE on the cluster) communicate through
tcp/ip after the LSF bsub call has been made. They do this on a range of ports between
5967 and 5987. The port is used only briefly and is then released, but this range of
ports must be opened through any firewall on any node of the system.
619
RESOLVE
Note that the Eclipse data must be visible from all nodes on the cluster which may end up
running it, and all nodes should see the same path to the model.
2.19.4.5.6 Administering the daemons
Both the client programs (LSF and non-LSF) must be run as the root user. Their behaviour is
governed by configuration files which sit in the same directory as the executable.
These configuration files, described below, are listed here:
1. .ecl_resolve_config - mandatory for both LSF and non-LSF implementations
2. .ecl_resolve_users - mandatory for non-LSF implementation only
3. .ecl_resolve_lsf_users - mandatory for LSF implementation only
4. .ecl_resolve_env - optional for Intel or Scampi implementations, LSF or non-LSF
5. .ecl_resolve_env_intel - optional for Intel implementation, LSF or non-LSF
6. .ecl_resolve_env_scampi - optional for Scampi implementation, LSF or non-LSF
Both versions (LSF and non-LSF)
The configuration file .ecl_resolve_config is generated by the installer, but can be edited by
the user later.
It should be placed in the shared directory when using LSF, or otherwise the directory from
which the mpirunfactory is run.
The configuration file consists of two parts:
A listing of the ports that are used by the run factory and the controller.
A listing of the various Eclipse installation directories on each node in the system on
which Eclipse may be run.
A typical configuration file may have the following appearance:
3 5678 5679 5680
mylinux64 /ecl/2008.1/bin/linux_x86_64
mylinux32 /ecl/2008.1/bin/linux
* /ecl/2008.1/bin/linux_x86_64
In this case there are three possible ports to be used by the controller: 5678, 5679, and 5680.
The run factory program will check whether the ports are in use before spawning the programs: if
there are no available ports then an error will be sent to RESOLVE. Each instance of Eclipse that
is spawned by the run factory will use one of the ports named here.
In addition, in this case there is a network computer called mylinux64 which has the Eclipse
executables installed in the directory /ecl/2008.1/bin/linux_x86_64. The starred entry (*) gives
the default Eclipse directory for computers that are not named here.
Note that the run factory program can not start unless it manages to read this file.
User Guide
620
Note that the ports specified in the above file, and the listening port that is used by the
run factory, should be opened through any firewall
non-LSF
version
The
mpirunfactory_mpich.exe)
(mpirunfactory_scampi.exe/mpirunfactory_intel.exe/
This is configured by the .ecl_resolve_users files. This contains a series of lines which map
Windows (RESOLVE) users to Linux users. It can also be used to allow or deny access to
individual users. It should be placed in the directory from which the run factory is executed.
The format of the file is as follows:
<Windows user> <Linux user> <Allow/deny>
The Windows user is the user running RESOLVE.
The Linux user is the user under Linux which will run Eclipse.
To allow access to Eclipse, the last value should be 1. To deny access, the last value should
be 0.
If * is entered for the Windows user then this becomes the default for all users who are not
present in the rest of the file.
If * is entered for the Linux user, then the Linux user will always be set to the Windows user that
is running RESOLVE.
Examples:
**1
This will allow access to any user. The user that runs Eclipse will be the same username
as the user running RESOLVE. If this user does not exist on the Linux system, an error will
be reported. This is the form of the file that is generated automatically by the installer.
winuser1 linuxuser1 1
winuser2 nouser 0
* ecluser 1
The RESOLVE user winuser1 will run Eclipse on Linux as linuxuser1. The RESOLVE
user winuser2 will not be allowed to run Eclipse. All other users will have access, and
Eclipse will be run under the ecluser account.
The LSF version (mpirunfactory_lsf.exe)
This daemon is administered with the .ecl_resolve_lsf_users file. This is similar in form to the
non-LSF version, except that it contains some extra information on LSF parameters for specific
or default users. It should also be placed in the directory from which the run factory is executed.
Examples:
-q resolve
621
RESOLVE
winuser1 linuxuser1 1 m linux1 linux2 q priority

winuser2 linuxuser2 1 *
The RESOLVE user winuser1 will submit Eclipse as an LSF job under the linuxuser1
account. When this user submits a job, the parameters -m linux1 linux2 q priority will be
appended to the bsub command.
The RESOLVE user winuser2 will run as linuxuser2 on Linux. On submission, default
parameters (-q resolve, for submission to a resolve queue) will be appended.
0
**1*
This is the file that is generated by the installer. It allows all users to submit jobs under
their accounts, with no special arguments to the bsub command.
Further options for the LSF version
In addition to the functionality detailed above which is accessed through the .
ecl_resolve_lsf_users file, there is also a script that is called from the mpirunfactory_lsf.exe
daemon which can be used for some special processing.
The script, which must be called lsf_job_handler.sh, is called from the daemon just before the
LSF bsub command is called to launch the job. If the script is not there, then the daemon will
submit the job as it previous versions; the existence of the script is entirely optional.
The script is called with two arguments: the path to the Eclipse deck, and the Eclipse model file.
The script can be used, for example, to pre-process the deck and reserve the licence resources
in the LSF scheduler.
Optional environment files for LSF or non-LSF versions
The files in question are:
1. .ecl_resolve_env
2. .ecl_resolve_env_intel
3. .ecl_resolve_env_scampi
These files allow the setting of environment variables in the environment of the Eclipse run. This
can be useful (for example) for the setting of the LM_LICENSE_FILE variable to allow Eclipse to
obtain a licence, or for the setting of LD_LIBRARY_PATH which can be necessary for some
applications to run (notably Intel MPI, as discussed).
For format of the files consists of a series of environment variable/value pairs, e.g.
LM_LICENSE_FILE
MY_PATH_VAR
@LCSVR01
/home/user
The .ecl_resolve_env file is read by both the Intel and Scampi versions of the software. The .
ecl_resolve_env_intel file is read by the Intel version only. The .ecl_resolve_env_scampi file is
read by the Scampi version only. This structure allows both implementations (Intel and Scampi)
User Guide
622
to be used on the same system.

2.19.4.5.7 Troubleshooting
This section deals with common problems and their diagnosis.
Before reading, note that log files are generated by the daemons, and these are placed in /var/
log. The log files are:
RunFactory_???.log, where '???' is either 'intel', 'scampi', or 'mpich' depending on the flavour of
MPI being used. These are generated by the non-LSF implementation.
RunFactory_lsf.log. This is generated by the LSF daemon, mpirunfactory_lsf.exe.
An additional file is placed in /tmp (this is because the file is written from the user, rather than the
root, account, which does not generally have permissions for /var/log).
RunFactory_lsf_client_???.log, where '???' is the user ID.
These log files are very useful in diagnosing problems with the connection.
Receive the message: 'Unable to connect to remote run factory (x)'
This means that the machine can not 'see' the machine and/or port on which the run factory is
running.
623
RESOLVE
In this case, it is because the port '8889' is not the port which was entered on the command line
of the Linux-side daemon. Alternatively, it may mean that the machine name is wrong, or can not
be recognised in the DNS register.
With this error, it is unlikely that any Linux-side log files will be written.
Receive the message: 'Failed to connect to the controller program - either MPIRun
failed, or the socket could not be accessed'
This means that the spawning of Eclipse failed or the controller could not otherwise be
connected to. There are various possibilities:
1. The path to Eclipse in the .ecl_resolve_config file is incorrect, or Eclipse can not be run for
some other reason (e.g. permissions).
2. The controller executable mpieclcontroller_???.exe is missing from the installation directory,
or can not be run for some other reason (e.g. permissions).
3. The controller would not start because of a dependence on a shared library, which generally
happens with Intel MPI. This needs to be resolved by adding the appropriate
LD_LIBRARY_PATH environment variable, as described in this section.
4. The mpimon or mpirun failed. Check that the standard tests are successful.
5. RESOLVE did not wait for long enough for the Eclipse process to start. This will be apparent
if, after receiving the message, you can see Eclipse and the controller running on the Linux
system:
User Guide
624
> ps -ef | grep eclipse

500
21666
1 0 12:17 pts/3
00:00:00 /opt/scali/bin//mpimon /home/
developer/ecl-ipm75/mpieclcontroller_scampi_2009.exe -- saladin.petex.local -- /
ecl/2009.1/bin/linux_x86_64/eclipse_scampi.exe -- saladin
500
21673 21668 81 12:17 ?
00:00:53 eclipse_scampi.exe-1
(mpi:21666@saladin.petex.local)
If this is the case, then the timeout (which defaults to 20 seconds) can be adjusted from the
Eclipse driver configuration screen.
Depending on whether the LSF or non-LSF version is being used, the answer to this problem is
most likely found in one of the above log files.
Receive the message: 'KPJINI: Error in communicating with socketserver'
This means that the Eclipse job was started successfully, but it (Eclipse) failed almost
immediately.
This is generally because there is a mismatch between the version of Eclipse specified in the .
ecl_resolve_config file (e.g. a pre-2009 version) with that specified on the command line of the
run factory daemon (e.g. a 2009+ version).
Receive the message: 'KPJSTR: Error in communicating with socketserver'
This means that the Eclipse job was started successfully, and started to read the data file, but
Eclipse is crashing for some reason. This could be due to hardware configuration or could be
related to the data file itself.
1) If running the daemon from a terminal, evidence of the crash should be visible and this might
aid with the debugging.
2) The sample file could be used to test the hardware aspects. One of the sample files is
provided on C:\Program Files\Petroleum Experts\IPM 7.5\Samples\resolve\Example_Section_2
\Example_2_5 where there is a RESOLVE archive file. There is an Eclipse file inside this
archive. This Eclipse file may be placed on the linux computer and the connection to RESOLVE
connection may be tested with this approach.
If these first two steps fail then it probably indicates that the setup is failing due to the hardware.
If the hardware is fine, then it indicates something in the model is causing a conflict somewhere
which leads to the crash in Eclipse. Possible reasons for this could be:
3) The usual reason for this is that the user running the Eclipse job does not have permissions
over the output files of Eclipse (e.g. .PRT, .LOG, etc). Try deleting all the output files and then try
again. This situation may arise if another user has previously run Eclipse, and the new user does
not have permissions over the files generated. This can be resolved at the system level, either
by setting up user groups or umasks (this would be an IT task).
625
RESOLVE
4) the restart file version and the Eclipse version being used. It may so happen that the restart
file is created with a certain version of Eclipse, and if some other version of Eclipse is used to
perform the run, then this may fail.
5) If the Eclipse version used is 2008.2, there was a problem with this version where Eclipse
would crash if the .ECLEND file was present, regardless of permissions. This can be worked
around by
*) the *.eclend file should be deleted programmatically before the RESOLVE simulation
is run.
*) use the IPM version 7.5 or above. These versions delete the file programmatically.
*) this issue does not happen with subsequent versions of Eclipse.
2.19.4.5.8 How the software works

When an Eclipse run is required by RESOLVE, the following sequence of events is carried out:
mpirunfactory sits as a daemon process on the Linux system. There is an IP port open
(port (a)) which is set by the user who first runs the daemon.
When RESOLVE wants to execute an Eclipse run it sends a request to the run factory.
The run factory executes an mpirun call to create an Eclipse instance and an instance
of mpieclcontroller.exe. As noted above, the Eclipse instance can be spawned on a
different node on the network. The mpieclcontroller.exe program opens another port
(port (b)) which will be used to communicate with RESOLVE. The identity of port (b) is
set in a configuration file read by the run factory.
RESOLVE connects to the controller through port (b) and Eclipse commands are
channelled to the Eclipse executable through this interface.
The diagram below illustrates the sequence of events described above.
User Guide
626
sx
LSF use
When this option is used, LSF can decide on which node to run Eclipse based on its loadsharing algorithm.
This option must be used if the user are submitting multiple RESOLVE jobs to a
Windows cluster which is calling Eclipse on the Linux cluster (this functionality in
RESOLVE is under the "Scenario Manager").
This option uses exclusively the Scali version of MPI.
When this option is used, the run factory application is effectively split into two separate
627
RESOLVE
applications.
These are:
mpirunfactory_lsf.exe
mpirunfactory_lsf_client.exe
The logic described in the section on interactive use is changed only slightly, as described
below:
After this, the run factory client performs the mpirun call to invoke the Eclipse run and the
mpieclcontroller. Unlike the interactive case, the controller and the Eclipse instance are always
on the same computer. In the interactive case, the controller and the run factory are always on
the same computer, but the Eclipse instance can be distributed, i.e.
User Guide
628
2.19.4.5.9 Setting up the Windows (Resolve) side

Once the Linux-side is set up it should be fairly simple to connect to this from RESOLVE.
There are tasks that must be carried out:
RESOLVE needs to be informed that the connection to the Linux computer is through
MPI and not PVM. This is carried out through the driver configuration screen. From the
RESOLVE menu, go to Drivers | Register Drivers and double-click on the appropriate
Eclipse entry. This invokes the configuration screen:
The options under MPI options refer to the local setup of MPI and are not of interest
here. However, it is necessary to inform that RESOLVE will use MPI rather than PVM.
Under the data entry screen when the Eclipse instance is set up in RESOLVE, the
following options need to be set:
629
RESOLVE
The port number is "port (a)" in the above setup diagrams, i.e. the port with which
RESOLVE will communicate with the run factory. This port is a port on the controller
machine which is also specified here, and which may be different to the machine that
runs Eclipse (as discussed above). If the controller machine is left blank then it is
assumed that the controller is the same machine as the Eclipse host machine.
No special setup needs to be made for the LSF case. In this case the machine
name can be left blank as LSF will decide this. If a machine name is entered then
it will be ignored. The controller machine is still the machine on which
mpirunfactory_lsf.exe is running
2.19.4.5.10 Upgrading the Linux software

Upgrading the Linux software following an upgrade of the IPM software is a simple task. There
are two tasks:
1. Kill the existing process
2. Re-install the software
Step 1: Kill the process
You should first check that there are no Eclipse jobs currently running. This can be done with the
following command:
> ps -ef | grep mpiecl
This will return any instances of the controller process (mpieclcontroller) which is necessary for
Eclipse to be controlled from RESOLVE.
User Guide
630
If there are no jobs running, then proceed to kill the run factory process. The following command
can be issued:
> ps -ef | grep mpiru
This will identify the pid of the process:
root
6837 6812 0 Jul28 pts/1
3457 /opt/scali/bin/ 0
500
21970 31004 0 14:54 pts/9
00:00:00 ./mpirunfactory_scampi.exe .
00:00:00 grep mpiru
The command to kill the job is then:

> kill -9 <pid>
e.g.
> kill -9 6837
Step 2: Reinstall the software
To reinstall the software the installation instructions should be followed. The only difference is
that it will be necessary only to install the software: the configuration tasks that can be automated
from the installer will overwrite the configuration files that are already set up, and so this should
not be done.
2.19.4.6Running IMEX/GEM on a remote computer
The following information describes how the remote execution between the RESOLVE computer
and a remote computer (Windows or Unix/Linux) can be enabled.
This section specifically refers to the case where RESOLVE is connecting directly to the remote
computer. It is also possible to send the job to a Linux cluster, where it may be distributed using
LSF or similar load balancing software from the head node of that cluster.
The IMEX-GAP link DLL (IMEX-2007-xx and later) is able to submit simulation jobs to network
computers via Secure SHELL (SSH). Here the network refers to the intranet/LAN.
The required environments for remote submission are:
The targeted remote computer should be a SSH server (running SSH service) and the
local computer should have a SSH client program installed. The SSH client issues a
ssh command to execute the simulation on a SSH server.
Both local and remote computers should be able to create/read/write files in the folder/
directory where the simulation dataset exists. IMEX and the link DLL exchange data in
631
RESOLVE
that work folder.

SSH Server
SSH Client
Linux and IBM AIX computers are equipped with OpenSSH which provides
SSH Daemon (SSHD) as the SSH service.
Windows computers needs to install third party software to run an SSH
service. For all our tests, WinSSHD ( http://www.bitvise.com/ ) was used to
provide the SSH service for Windows. Tested Windows platform were
Windows Server 2000, Server 2003 and XP 64 bit
The SSH client must be on Windows, because the local machine needs to
run RESOLVE, a Windows based program. There are quite a few software
vendors provide SSH clients on Windows at a low cost. We developed/tested
using CopSSH (http://www.itefix.no/phpws/index.php ) which is an OpenSSH
derived Windows version. The client program has been tested on Windows
2000, XP, XP 64 bit and Vista
After the installation of CopSSH, the user may need to edit the path of
the Windows environment variable to add the SSH bin directory, for example:
C:\Program Files\copSSH\bin.
The installation of CopSSH, will install both the server and client software
on the users PC. The user may want to disable the CopSSH server service
as only the client software is required. This service is called Openssh SSHD
Service
SSH
Settings
There are various approaches that can be used to enable SSH

communication. The following descriptions are intended to give an example of
one approach which was employed in our testing process.
For technical details, the user should refer to the SSH software manual.
The ultimate object of the SSH settings is to allow user to invoke remote
simulation by issuing a one line ssh command at a local command console.
For example, the following command line should directly start the IMEX with
the dataset "dataset1.dat".
ssh l username_on_server simsvr d:\cmgexe\imex.exe
f d:\cmgdata\dataset1.dat
where the simsvr is a remote Windows computer.
Generating
Key Pair
In order to do so, the remote computer (SSH server) should be set so as to

accept the user login without password. Instead of password authentication,
SSH client and server, by default, use key authentication to establish
connection
The user can use ssh-keygen.exe available with CopSSH to generate a
private/public key pair. Using ssh-keyhen.exe, two key files, for example
id_rsa and id_rsapub, should be generated into the folder .ssh, which is
created under the users home directory of the local Windows. A blank
"passphrase" is suggested when doing key pair generation. If the key pair is
User Guide
Registering
the Public
Key in the
Server
Test SSH
Settings in
Linux/AIX for
the CMG
Simulator
Environment
632
made with a passphrase, the passphrase will be asked for each time SSH
attempts to login
For the UNIX/OpenSSH system, the user needs to copy the public key (e.g.
from file id_rsapub) and append it into the file: $HOME/.ssh/authorized_keys.
For the Windows/WinSSHD system, the system administrator needs to start
the WinSSHD Control Panel/ Settings, and in the Access Control/Windows
accounts tree view add the user and then import the users public key
After the above steps are done, the user can test SSH by trying a ssh
command from the local command console:
ssh simsvr set
If the above command gives out the user environment variables in simsvr,
SSH has been successfully set up. This command assumes the users login
name is the same on both the server and the local computer
In order to make sure the SSH login reads the UNIX shell startup file (.cshrc, .
kshrc, etc.) which includes the values for CMG_HOME, LSFORCEHOST and
LD_LIBRARY_PATH, the following should be done in the OpenSSH server:
In users $HOME/.ssh directory, create a file with name environment. Add
one line, ENV=.kshrc, into the file (assuning thw Kshell is used).
Make sure /etc/ssh/sshd_config file contains the next line:
PermitUserEnvironment yes
Above settings ensure that the $HOME/.kshrc is read when SSH does login.
If the $HOME is a shared directory among UNIX machines and those hosts
need different CMG variable settings, the shell startup file can include a case
command to account for different hosts
For example,
case $(hostname) in
simsvr | simsvr1 ) LD_LIBRARY_PATH=/usr/cmg/imex/
Linux_x64/lib:\ /opt/intel/fce/9.1.036/lib;
LSFORCEHOST=lserv; export\ LD_LIBRARY_PATH
LSFORCEHOST;;
aixsvr | aixsvr1) LSFORCEHOST=lserv; export
LSFORCEHOST;;
esca
Known Problems and Solutions

Samba Mount If the work folder/directory is located on a drive under a UNIX platform, and the
user notices an unreasonable delay or even a hanging up on alternating text
file communication between IMEX and RESOLVE / GAP, there can be file
sharing problems caused by Samba opportunistic file locking. The
workaround is to switch off the file locking for all CMG - RESOLVE
633
RESOLVE
communication files.
That is, in the Samba configuration file (e.g. /etc/smb.conf), add a line:
veto oplock files = \ /*.LSImex/*.LSResolve/*.LSGem/
*.LDImex/*.LDResolve/*.LDGem/
Restart the Samba mount. The above switch should be applied for those
mount points where the work folder may be located
Working folder An issue has been identified in which RESOLVE is not able to read data from
on a remote
IMEX or GEM under Linux when the working folder (i.e. used for
communication between RESOLVE and the simulator) is physically located
disk
and mounted on a different machine to the machine which is performing the
calculations.
This issue only affects versions of IMEX/GEM prior to 2007.11.
The situation can be summarised as follows.
There are three machines:
"linux_cpu" - the Linux machine running the simulation
"linux_file" - the Linux machine holding the data
"resolve" - the Windows machine running RESOLVE.
To set this up within RESOLVE, the following settings could be used:
Computer="linux_cpu"
Dataset="/usr/data/cmg/simdata/test.dat"
"/cmg/simdata" is located on "linux_file", and is mounted from /usr/data/cmg/
simdata from "linux_cpu"
Local Path to Work Folder="//linux_file/cmg/simdata"
This configuration is not recommended as it increases network traffic
considerably. However, if it is essential to work in this way a workaround has
been added to the driver. This workaround is not activated by default as it is
not considered a permanent solution.
To activate the workaround, perform the following steps:
Open the Windows registry (regedit)
Go to HKEY_CURRENT_USER\Software\Petroleum
Experts\Resolve\ExtensionDlls60\ImexGapLink
Add the value: RemoteMountWorkaround=1 (as shown below).
Restart RESOLVE and try the run again.
User Guide
634
It has been found that in some situations the problem does not need the
workaround if the "local path to work folder" is mounted on the calculation
machine (linux_cpu), even if this in turn is mounted on the file server. In other
words, in the above example the local path would have the form: "//linux_cpu/
usr/data/cmg/simdata"
2.19.4.7Running PSim on a remote computer
PSim can be run on remote machines connected to the RESOLVE Windows PC on a network.
Linux and Windows architectures for the remote machine are supported.
The communication protocol used between RESOLVE and PSim is mpich. This must be
configured appropriately on the RESOLVE machine and all machines running PSim (whether
Windows or Linux).
More information on the installation and configuration of mpich for Windows or Linux can be
found in the "MPICH setup" section.
The connection to Linux can be made directly, in which case the setup of MPICH is the only
necessary task. Alternatively, it is possible to communicate directly to the head node of a cluster,
635
RESOLVE
which can then distribute the PSim tasks across the cluster through LSF or some other load
balancing software. The setup of this more versatile configuration can be found here.
2.19.4.8RESOLVE controlled CMG/PSim runs on a Linux cluster
When running the CMG simulators (IMEX and GEM) or PSim (of ConocoPhillips), RESOLVE is
able to communicate directly to the head node of a Linux cluster, which is then able to distribute
the simulation jobs to the nodes of that cluster. The distribution can be performed by LSF or
some other distribution tool of the user's choosing. The default is LSF.
This is also possible with Eclipse. Although similar in approach, this is described separately.
The following section describes the setup of this scheme. For simplicity, IMEX and GEM are
referred to collectively as the CMG simulators, or CMG for short.
The methodology and most of the installation is the same for the CMG simulators as for PSim
(COP). Where there are differences these will be pointed out in the instructions.
Contents:
Overview
Installation
Administering the lxresolve.exe daemon
2.19.4.8.1 Overview
The architecture is built around two components.
The components are:
lxresolve.exe. This handles the basic communication with the head node and is
common to CMG and PSim.
lxresolve_client_cmg.exe and lxresolve_client_psim.exe. These are the client programs
distributed from the head node.
Currently, these components are built only for the Red-Hat Linux operating system,
version 4 and 5.
These programs are installed on a central ia32 or x86_64 server. Simulation runs can then be
spawned on the same server or any other appropriately configured Linux computer on the
cluster.
User Guide
The Linux machines (Linux_node_1
636
5) can be 32 or 64 bit (ia32/x86_64).
The simulation models communicate with Resolve using the standard protocol for that simulator.
This is 'file transfer' for the CMG simulators, and MPICH2 for PSim.
2.19.4.8.2 Installation
This section assumes that the person performing the installation has a working knowledge of the
Linux environment. The following steps require the user to be logged in as root on the Linux
machine.
STEP 1
CREATE NEW DIRECTORY WHERE THE NEW EXECUTABLES WOULD

BE PLACED:
It is assumed that the new executables would be placed under the directory </
home/developer>. A new directory will be created called lx-ipm7.0
To do this, the command mkdir lx-ipm7.0 can be used under the </home/
developer> directory
STEP 2
COPY FILES ACROSS FROM WINDOWS INSTALLATION DIRECTORY OF

IPM TO THE STATED TARGET DIRECTORY:
There will be a file titled lx_resolve.tar.gz located in the installation directory of IPM
637
RESOLVE
(which is generally C:\Program Files\Petroleum Experts\IPM 7.5

\linux_executables)
Copy this file across to the target directory on the Linux machine
STEP 3
SWITCH TO TARGET DIRECTORY:

IOn a Linux terminal, change the directory to the target directory using the
command line:
cd lx-ipm7.0
STEP 4
UNPACK THE INSTALLATION FILE

The user must be in the stated installation directory (for the sake of this example it
is /home/developer/lx-ipm7.0). Launch the command:
gunzip lx_resolve.tar.gz
This will unpack the stated file and place the file lx_resolve.tar in the installation
directory. The next command will be to extract the archive file using the command:
tar xf lx_resolve.tar
STEP 5
INSTALLATION
As root run the installation by entering the command:
./install.sh
The installation will require entering the various configuration settings from the
user. These configuration settings are described as follows
STEP 6
DEFINING THE TARGET DIRECTORY

The target directory will be the location where the installation executables will be
placed. In this example we assume this to be /home/developer/lx-ipm7.0
Specify this in the target directory section and press enter
STEP 7
DEFINING THE OPTIONS:

Select the option for performing the task. There are four options available
OPTION 0: EXIT
OPTION 1: INSTALL SOFTWARE ONLY
OPTION 2: SETUP CONFIGURATION
OPTION 3: DO EVERYTHING
As would be expected, there are some CONFIGURATION files that need to be

placed on the Linux machine. These configuration files could be copied across
from the previous installation if they are already present (for a previous IPM
User Guide
638
version). If this is the case the objective would be to install the software only, which
is Option 1. The config files will not be written with this option.
If the configuration files are to be freshly written by the installer, Select OPTION 2.
Select OPTION 3 if the objective is to do both.
If the installation of the Linux executables is being performed for the first time, it is
strongly advised that Option 3 be selected. This will guide the person performing
the installation towards setting up the Linux environment as expected.
For the sake of this example we shall ask the installer to install the software AND
setup the configuration files. Thus the option to select will be <Do Everything>
which is option number 3
STEP 8
DEFINING THE LINUX ARCHITECTURE.

in STEP 7. STEP 8 will not be applicable if the user has selected OPTION 2 in
STEP 7.
Enter whether the machine is 32 bit or 64 bit.
The lx_resolve.tar.gz file that was installed in STEP 2 above, is basically a tape
archive (tar) file (like a zip file) which has some files stored in it. These files are
the components that are required to be installed on the Linux Machine. In this
tar file, there are two versions of the installation files available.
a) One version is applicable for 32 bit architecture and
b) the other is applicable for 64 bit architecture.
Depending upon the option that is selected in this Step 11, the installer will
unpack the correct version of the files and place them in the installation
directory. The procedure to install the components is the same for both types of
architectures
STEP 9
EDITING THE CONFIGURATION FILES FOR THE USER OPTIONS.

in STEP 7.
There are three configuration files that are created during the installation process:
a) .lxresolve_users --> sets up queues or other command line options for the
distribution software (e.g. LSF), as well as setting up individual user permissions
and mappings between Windows user names and Linux user names. This is
639
RESOLVE
described in more detail here.

b) .lxresolve_cmd_ --> dummy administration file in which different software to
LSF can be set up for the distribution of simulation jobs. This is described in more
detail here. If this is to be used, it should be renamed '.lxresolve_cmd' (without the
trailing '_').
c) .psim_client_ports --> sets up the tcp/ip ports that are to be used in connecting
the client program 'lxresolve_client_psim.exe' with Resolve on the Windows PC.
More information can be found under the section which deals specifically with
PSim configuration.
Before continuing to the next step it is important that the configuration files are
configured correctly. If LSF is to be used, it will be necessary to configure the .
lxresolve_users file and the .psim_client_ports file (if PSim is used).
A typical .lxresolve_users file might appear as follows:
0
WindowsUser1
WindowsUser2
LinuxUser1
LinuxUser2
1
1
-m <machine 1>
-m <machine 2>
Here, a Windows user (WindowsUser1) will be mapped to a Linux user

(LinuxUser1) when a job is submitted from Resolve. The LSF options '-m
<machine 1>' will be appended to the command line when the job is submitted.
The figure '1' indicates that both users listed have access rights to the software.
STEP 10
There are many ways to configure the file, but this should be sufficient to get
started
LAUNCH THE PROCESS.
The user must be in the appropriate directory where the installation has been
done. For this example it is </home/developer/lx-ipm7.0>
The command to launch the process is as follows.
In its usual form, it must be run as the root user.
./lxresolve.exe 7777 0
In this case, any processes that the daemon launches (such as the simulation job)
will be run under the user account that was obtained from the contents of the .
lxresolve_users file described above.
If the above command line is run from a non-root account, the daemon will
terminate with an error. However, it is possible to run under a user account by
appending the -nosuid option to the command line:
User Guide
640
./lxresolve.exe 7777 0 -nosuid

In this case, jobs spawned from the daemon will be run under the account under
which the daemon was run; in other words, the daemon will not attempt to perform
a setuid.
The first argument is the port number with which Resolve will communicate with
lxresolve. This must be opened through any firewall.
The second argument is an LSF timeout in minutes. If LSF is not being used, this
will be ignored and the timeout will be fixed at 20 seconds. If it is set to '0' (as
above) then the software will wait indefinitely for LSF to start the job.
The above mentioned command line will start the lxresolve.exe process.
Alternatively this file may be included as a service on the Linux machine
STEP 11
SETTING UP RESOLVE TO RUN ECLIPSE:

a. CMG (IMEX/GEM)
641
RESOLVE
Under the 'cluster' section, LSF (head node daemon) should be selected. The
head node (on which lxresolve.exe is running) and the port number (7777 in the
above example) should be entered.
b. PSim (COP)
User Guide
642
The host method should be set to 'Cluster head node'. The head node (on which
lxresolve.exe is running) and the port number (7777 in the above example) should
be entered.
In the case of PSim, the location of the executable on the Linux file system can be
entered through the 'Executable paths' button on this screen, or defaults can be
entered by configuring the PSim driver.
Should you require any further information please send an email to edinburgh@petex.com or
contact:
643
RESOLVE
PETROLEUM EXPERTS Ltd.

10 Logie Mill, Edinburgh EH74HG, UK
Tel: +44 (0) 131 4747030
Email: Edinburgh@petex.com
2.19.4.8.3 Administering the lxresolve daemon
The behaviour of the lxresolve daemon is governed by the configuration files .lxresolve_users, .
lxresolve_cmd (if present), and .psim_client_ports (if applicable).
The .lxresolve_users file
This file should also be placed in the directory from which the run factory is executed. It has the
following format:
<general LSF options for all users>/<0>
<WinUser1> <LinuxUser1> <allow/deny> <LSF options for this user>
The first line should be '0' if there are no special, user-independent options. Otherwise, LSF
command line options can be entered as per the examples below.
The following lines consist of pairs of users, to allow lxresolve.exe to map a Windows user (from
RESOLVE) to a Linux user (which will run the simulation job).
The third argument of each line should be '1' (to allow access to the Windows user) or '0' (to
deny access).
The fourth argument consists of further LSF options for the user in question. If none are given ('*')
then those options given in the first line will be applied, if present.
Although LSF is discussed here, the options supplied in this file will also be applied to other
softwares used to distribute the tasks, as supplied in the .lxresolve_cmd file (see below).
Examples:
-q resolve
winuser1 linuxuser1 1 m linux1 linux2 q priority
winuser2 linuxuser2 1 *
The RESOLVE user winuser1 will submit the simulation as an LSF job under the
linuxuser1 account. When this user submits a job, the parameters -m linux1 linux2 q
priority will be appended to the bsub command.
The RESOLVE user winuser2 will run as linuxuser2 on Linux. On submission, default
parameters (-q resolve, for submission to a resolve queue) will be appended.
0
**1*
User Guide
644
This is the file that is generated by the installer. It allows all users to submit jobs under
their Linux accounts, with no special arguments to the bsub command. If the Windows
account does not have the same name as the Linux account, the run will fail.
The .psim_client_ports file
Obviously, this is only required when PSim is being used.
The configuration file consists of a listing of the ports which may be used to connect Resolve to
the client program (lxresolve_client_psim.exe).
A typical configuration file may have the following appearance:
5 13900 13901 13902 13903 13904
This is the default produced by the installer.
In this case there are five possible ports to be used by the controller: 13900 - 13904. Each
instance of PSim that is spawned by the run factory will use one of the ports named here.
Note that the lxresolve_client_psim program can not start unless it manages to read this file.
Note that the ports specified in the above file, and the listening port that is used by
lxresolve.exe, should be opened through any firewall
The .lxresolve_cmd file
This is an optional file that allows other software, other than LSF, to act as the distributor of the
simulation jobs. It is generated from the installer as '.lxresolve_cmd_' and should be renamed
without the trailing '_' if it is to be used.
If present, lxresolve.exe will read the contents of the file and use the command line specified
when starting a simulation job (instead of the LSF 'bsub' command). The dummy file generated
consists of the line:
/usr/bin/ssh
meaning that 'ssh' will be used to distribute the jobs.
Clearly, ssh requires a specific computer to be named, which defeats the object of load
balancing. However, as an illustration, the command line arguments for ssh can be appended in
this file, e.g.
/usr/bin/ssh -l dave linux64
Alternatively and more logically, the command line arguments can be added to the .
lxresolve_users file:
0
WinDave LinuxDave 1 -l LinuxDave linux64
645
RESOLVE
and so on.
Chapter
647
RESOLVE
Examples Guide
3.1
Worked Examples - Overview
This section contains some step-by-step examples that will illustrate how to setup models for
various purposes.
The examples concern connections between a variety of different applications, not all of which
are products provided by Petroleum Experts. For more help it might be needed to refer to the
documentation for these applications.
There is also additional help in the help files of the RESOLVE drivers. These can be accessed
from the HelpViewer window of the main RESOLVE screen.
To build these examples the relevant RESOLVE drivers have to be installed.
The examples all use drivers that are part of the standard installation. It is needed to invoke
Drivers | Auto-register latest drivers to ensure that the drivers are installed. Please refer to
the "Driver Registration" section for further information.
The models used in these examples can all be found under the samples sub-directory of the
main installation.
The models are distributed as RESOLVE archives characterised by .RSA extension.
A detailed index of the examples available can be found in the "Worked Examples - Index"
section.
***
3.2
Worked Examples - Index
The examples in this guide are divided in the following general sections:
Example Section 1: Getting Started

Example Section 2: Connection to Reservoir Simulation Tools
Example Section 3: Connection to Process Modeling Tools
Example Section 4: Connection to Excel
Example Section 5: Advanced RESOLVE Examples
Example Section 6: OpenServer Examples
Example Section 7: Additional Examples
The following table can be used as reference for the worked examples included in this guide:
Application
Topic
Examples
License Requirements
Type of
Examples Guide
Area
Guide
Location
Re-Injection of Setting up a
Example 1.1
Produced Gas RESOLVE
model
connecting a
production and
a gas injection
surface network
model, setting
up the schedule,
running a
forecast and
analysing the
results.
Connectivity
Setting up a
Example 2.1
with REVEAL RESOLVE
model
connecting a
production
model, a gas
injection model
and a numerical
simulation
reservoir model.
Setup the
schedule, run a
forecast and
analyse the
results.
Complex
Setting up an Example 2.2
scheduling
internal
using an
RESOLVE script
internal
that enables to
RESOLVE
open wells in
script
the surface
network model
as a function of
the overall
system
production.
Complex
scheduling
event driven
using the event scheduling in
driven
RESOLVE that
scheduling
648
Example
1 RESOLVE
1 GAP
1 MBAL
1 PROSPER
1 OpenServer
Step by Step
1 RESOLVE
1REVEAL
1 GAP
1 MBAL
1 PROSPER
2 OpenServer
Step by Step
1 RESOLVE
1REVEAL
1 GAP
1 MBAL
1 PROSPER
2 OpenServer
Step by Step
1 RESOLVE
1REVEAL
1 GAP
1 MBAL
Step by Step
649
RESOLVE
options of
RESOLVE
enables to open
wells in the
surface network
model as a
function of the
overall system
production.
Automatically Setting up
Example 2.4
run different
several
scenarios for a scenarios in the
single
RESOLVE
RESOLVE
scenario
model and
manager so that
compare the
they can be run
results.
simultaneously
and their results
compared.
Connectivity
Setting up a
Example 2.5
with Eclipse
RESOLVE
model
connecting a
production
model, a gas
injection model,
a water injection
model and a
numerical
simulation
reservoir model
in Eclipse.
Setup the
schedule, run a
forecast and
analyse the
results.
Connectivity
Setting up a
Example 3.1
with Hysys
RESOLVE
model
connecting a
production
model and a
process model
build in Hysys.
Setup the
schedule, run a
forecast and
1 PROSPER
2 OpenServer
1 RESOLVE
1REVEAL
1 GAP
1 MBAL
1 PROSPER
2 OpenServer
Step by Step
1 RESOLVE
1 GAP
1 MBAL
1 PROSPER
1 OpenServer
1 Eclipse
1 OpenEclipse
Step by Step
1 RESOLVE
1 GAP
1 MBAL
1 PROSPER
1 OpenServer
1 Hysys
Step by Step
Examples Guide
Full-field
optimisation
using an
internal
RESOLVE
script
Full-field
optimisation
using the
RESOLVE
optimiser
Complex fullfield
optimisation
using the
RESOLVE
optimiser
analyse the
results.
internal
RESOLVE script
that enables to
lower the
separator
pressure in the
surface network
model to meet a
constraint in the
plant model.
optimisation
problem in
RESOLVE that
enables to lower
the separator
pressure in the
surface network
model to meet a
constraint in the
plant model.
optimisation
problem in
RESOLVE that
enables to
maximise the
molar flow at the
"SalesGas"
stream of the
Hysys model
while respecting
constraints in
both the GAP
and Hysys
models. Once
this is done, the
model will be
modified to
include a
connection to an
Excel
spreadsheet
650
1 RESOLVE
1 GAP
1 MBAL
1 PROSPER
1 OpenServer
1 Hysys
Step by Step
1 RESOLVE
1 GAP
1 MBAL
1 PROSPER
1 OpenServer
1 Hysys
Step by Step
1 RESOLVE
1 GAP
1 MBAL
1 PROSPER
1 OpenServer
1 Hysys
1 Excel
Step by Step
651
RESOLVE
Connectivity
with Excel
Black Oil
Delumping
that calculate
the economics
of the system the optimisation
objective
function will then
be modified so
that the
optimiser
maximise the
revenue from
the system.
It is
recommended
that at least
the Example
3.1 and 3.3 are
performed
successfully
before
attempting this
more complex
example.
Setting up a
Example 4.1
RESOLVE
model
connecting a
production
model and an
economics
spreadsheet in
order to obtain
economic
indicators at
each timestep
and for each
scenario run.
Setting up a
Example 5.1
RESOLVE
model
connecting a
reservoir model
in Eclipse using
a black oil PVT
description and
a process
1 RESOLVE
1 GAP
1 MBAL
1 PROSPER
1 OpenServer
1 Excel
Step by Step
1 RESOLVE
1 Eclipse
1 OpenEclipse
1 Hysys
Step by Step
Examples Guide
Lumping /
Delumping
model in Hysys
using a fully
compositional
PVT
description.
Setting up a
Example 5.2
RESOLVE
model
connecting a
reservoir model
in Eclipse using
a grouped fully
compositional
PVT
description, a
surface network
model in GAP
using a grouped
fully
compositional
PVT description
and a process
model in Hysys
using a detailed
fully
compositional
PVT
description.
Using a direct
connection to
Excel to verify
the mass
balance of
certain
connections.
It is
recommended
that at least
the Example
1.5, 3.1, 4.1
and 5.1 are
performed
successfully
before
attempting this
more complex
1 RESOLVE
1 GAP
1 MBAL
1 PROSPER
1 OpenServer
1 Excel
1 Eclipse
1 Hysys
652
Step by Step
653
RESOLVE
example.
OpenServer Setting up an Example 6.1
Excel macro
usage
that populates
the event driven
scheduling
options of
RESOLVE, runs
the model and
reports the
results.
Excel macro
usage
that extracts the
different
variables
reported by both
a GAP surface
network model
and a UniSim
Design process
model
Excel macro
usage
that add a direct
connections
between two
process
simulation
modules using
Hysys
Excel macro
usage
that implements
the composition
mapping
between a GAP
model and a
UniSim Design
process model
Multiple
This
modelExample 7.1
reservoir
illustrates how
applications in to link a GAP
one model
surface network
model to two
types
of
1 RESOLVE
1 GAP
1 MBAL
1 PROSPER
1 OpenServer
1 Excel
File Only
1 RESOLVE
1 GAP
1 MBAL
1 PROSPER
1 OpenServer
1 Excel
1 UniSim Design
File Only
1 RESOLVE
1 OpenServer
2 Hysys
File Only
1 RESOLVE
1 GAP
1 MBAL
1 PROSPER
1 OpenServer
1 Excel
1 UniSim Design
File Only
1 RESOLVE
1 GAP
1 MBAL
1 PROSPER
2 OpenServer
1 REVEAL
File Only
Examples Guide
reservoir model:
a
REVEAL
model and a
MBAL model. It
also illustrates
how
the
schedule
elements
implemented in
GAP
are
respected by a
RESOLVE
model.
Process
These
Example 7.2
models internal examples (i.e.
scheduling
one
working
with Hysys, one
working
with
UniSim
Design),
illustrate
how
the
process
models internal
schedules are
taken
into
account when
using RESOLVE
.
Combining
This
modelExample 7.3
multiple
illustrates how
process
multiple
simulation
instance of a
models
process model,
using Hysys or
UniSim Design
can
be
combined within
one
full-field
model
and
connected to a
GAP
surface
network model.
Controlling a
This
modelExample 7.4
gas re-injection illustrates how
model based onto
link
a
the production production
1 RESOLVE
1 GAP
1 MBAL
1 PROSPER
1 OpenServer
1 Hysys
1 UniSim Design
File Only
1 RESOLVE
1 GAP
1 MBAL
1 PROSPER
1 OpenServer
3 Hysys
3 UniSim Design
File Only
1 RESOLVE
1 GAP
1 MBAL
1 PROSPER
File Only
654
655
RESOLVE
network and
plant
performances
network to a
process to a reinjection
network,
and
how
the
compositions
are
handled
from one model
to another.
SmartWell /
This
modelExample 7.5
Multilateral
illustrates
the
Wells Modelling modeling
of
smart
/
multilateral
wells, including
downhole flow
controls when
using
a
connection
between a GAP
surface network
model and a
REVEAL
reservoir
simulation
model.
A second model
illustrate the use
of event driven
scheduling
to
open / close
several
perforated
zones of the
smart well as
the function of
the
well
behavior.
Use of the
This
example Example 7.6
internal
illustrates
the
RESOLVE
use
of
RESOLVE
scripty
internal scripting
capabilities: the
main objectives
of this script is
1 OpenServer
1 Hysys
1 UniSim Design
1 RESOLVE
1 GAP
1 MBAL
1 PROSPER
2 OpenServer
1 REVEAL
File Only
1 RESOLVE
1 GAP
1 MBAL
1 PROSPER
1 OpenServer
2 Hysys
2 UniSim Design
File Only
Examples Guide
to modify the
pressure
at
which the GAP
model is run (i.
e.
separator
pressure)
in
order to achieve
a specific target
production.
Voidage
This
modelExample 7.7
Replacement illustrates how
Scheme
the
voidage
replacement
utility can be
used to design
a
voidage
replacement
scheme when
connecting
a
REVEAL
numerical
reservoir model
and
GAP
production and
water injection
surface network
models.
Water ReThis
modelExample 7.8
Injection control illustrates how
with script
to
use
the
RESOLVE
internal scripting
capabilities to
control a water
re-injection
scheme: here,
the
water
produced can
either
be
produced or reinjected in the
reservoir,
provided
the
water saturation
in the reservoir
is kept below a
1 RESOLVE
1 GAP
1 MBAL
1 PROSPER
2 OpenServer
1 REVEAL
File Only
1 RESOLVE
1 GAP
1 MBAL
1 PROSPER
2 OpenServer
1 REVEAL
File Only
656
657
RESOLVE
OpenServer
usage
3.3
certain
userdefined
treshold.
This
macro Example 7.9
illustrates what
variables
are
changed during
the
optimisation.
1 RESOLVE
1 GAP
1 MBAL
1 PROSPER
1 OpenServer
1 Excel
File Only
Example Section 1: Getting Started
3.3.1 Getting Started - Overview

1. Example Introduction
The objective of this section is to demonstrate how to setup a complete RESOLVE model.
The context used in this example is the following:
Two fields are being produced: one oil field and one retrograde condensate field. For the first
five years of the fields life, there is no existing pipeline to export the gas toward the gas market.
Due to environmental reasons, the gas produced cannot be flared.
Therefore, the only solution is to re-inject the gas produced in the reservoirs.
The production system has been modelled in GAP. A gas injection system has also been
designed and modelled in GAP.
The engineers have to check that the gas injection system designed is able to re-inject the gas
produced at every point in time during the first five years of production.
To do so, RESOLVE can be used to connect the GAP production system with the GAP gas
injection system, enabling to model the re-injection capacity at every point in time during the first
five years of production.
2. Licenses Required
Running this example will require the following licenses to be available to the user:
RESOLVE
OpenServer
GAP
PROSPER
MBAL
Before starting with this example, it will be necessary to make sure that the RESOLVE driver for
GAP is registered.
This procedure is automatically performed by selecting Drivers | Auto-register latest drivers
from the main menu as illustrated below.
Examples Guide
658
Once this is done, RESOLVE will return a message confirming the number of drivers that have
been registered.
3. Files Locations
The files required to run this example will be located under:
C:\Program Files\Petroleum Experts\IPM 7.5\Samples\Resolve\Example_1_1
This folder contains a file "Getting_started.rsa" which is a "RESOLVE archive file" that contains
the RESOLVE file, GAP file and other associated files required to go through the example. The
archive file needs to be extracted either in the current location or a location of the user"s choice.
3.3.2 Getting Started - Step 1

Step 1 Objective:
Start a new RESOLVE project and initialise the units
Start RESOLVE, and open a new project using File | New on the main menu bar or the icon
on the shortcut icon bar.
This will enable to open a graphical view window that is going to be used to graphically
represent the different modules used in the model and the existing connections between them.
659
RESOLVE
Select Options | Units and set the input and output units to Oilfield, then select OK.
Examples Guide
660
Now is a good time to save the file using File | Save As..., and enter a file name
(Getting_Started.rsl).
Go to Step 2?

Step 2 Objective:
Create the GAP production system instance
From the main menu, go to Edit System | Add Client program or select the
shortcut bar and from the resulting menu, select "GAP".
icon on the
The cursor, when held over the main screen, will change to indicate that an instance of the
application can be made.
Click in the graphical window to specify the location of the GAP icon, and give the case a label
(for instance: "Production").
661
RESOLVE
The RESOLVE model will then be displayed as illustrated below:
Double-click on the GAP icon and the following screen will appear:
Examples Guide
662
This screen enables to setup the basic options of the GAP connection to be established.
The first step will be to specify the ".GAP" file to be used in the file name section, as illustrated
above.
The file used in that specific case will be: Getting_Started.gap
GAP files can contain up to four different systems: production, water injection, gas injection and
lift gas injection all associated within the same GAP model.
Once the model considered has been chosen through the Browse option, one needs to select
which system is to be loaded in RESOLVE. In this case, we want the production system to be
loaded, so the Main System option is chosen.
The second step is to make sure that the "Always save forecast snapshots" option has been
selected. This will be useful when analysing the results in the step 8 of this step by step guide.
663
RESOLVE
The other options available on this screen are defined in more details in the "Loading and
Editing a GAP case" section.
Select OK and GAP will start up and load the required case (i.e. the GAP model will be opened
on the taskbar at bottom of screen).
It will then query the case for its inputs and outputs and will display these on the screen as shown
below.
The icons can be moved individually by selecting the "move" icon on the toolbar (
) and then
dragging them to the required positions (Groups of icons can be moved by first using the select
icon
, dragging over the group to select them and then dragging them as a group to the
required location).
When selecting the GAP model from the taskbar at the bottom of the screen, it is possible to
notice that the wells from this model are connected internally in GAP to tanks modelled with
MBAL, as illustrated below.
Examples Guide
664
In this model, two reservoirs are being produced through two different surface network systems:
one oil reservoir and one retrograde condensate reservoir.It is possible to note that many of the
wells are masked. In fact these wells are scheduled to come on line at different times during the
forecast.
The icons displayed in the RESOLVE model will therefore include all the data acceptors (i.s.
sinks) for the model, in this case the wells and all the data providers (i.e. sources), in this case
the separators, as illustrated above.
Four separators can be found in this model:
Two of these (OIL SEP and COND SEP) just represent the fixed pressure points at the
top of the oil and condensate systems. These are not important for the purposes of this
example.
The GAS COND and GAS OIL separators represent the gas-separation streams of the
former separators. It is these streams that we would like to reinject into the MBAL tanks
through the injection model.
665
RESOLVE
This production GAP model has an associated gas injection model. It is possible to visualise
both models simultaneously by selecting Window | Tile vertically in the GAP main menu.
It is possible to see that the gas injection system associated to the production system is also
separated in two sections: one section re-injecting in the oil reservoir and one section reinjecting in the retrograde condensate reservoir.
The next step will illustrate how to load the injection system in the RESOLVE model.
Go to Step 1 or Step 3?

Step 3 Objective:
Create the GAP injection system instance in the RESOLVE model
Examples Guide
666
The next step is to load the gas injection system that shall be used to reinject the production gas
into the MBAL tanks.
The gas injection system is going to be taken from the production system GAP file: the injection
system has effectively been associated to the gas production model in the GAP setup. Please
refer to the GAP manual for further information regarding this procedure.
In order to load the injection system, it will be required to create an instance of GAP on the
RESOLVE screen as per the previous step and give this instance a label (for instance:
"injection").
Once this is done, double-click on the new GAP icon and browse for the same file (GAP
production model) as done previously:
667
RESOLVE
This time the system selected should be the "Associated Gas Injection" system as
shown above.
When OK is pressed, the gas injection system is opened and queried for its inputs and outputs.
These consist of four injection wells and two injection manifolds:
In order to achieve produced gas re-injection, the two injection manifolds are to be connected
with the gas streams output from the production system.
Examples Guide
668

Step 4 Objective:
Connect the two GAP modules
In the case of a relatively simple model such as the one considered here, the diverse elements
can be connected directly from the graphical view.
For more complex models including a large number of connections for instance, these links can
be setup automatically using the "Connection wizard".
To connect the systems, go to the "link" mode by pressing the
icon.
To make the links, click and drag between the icons to be connected.
The gas separated from the oil system is to be reinjected into the oil tank, and the gas
separated from the condensate system is to be reinjected into the condensate tank.
To make this happen, connect the GAS OIL separator to the IM1 injection manifold, and
connect the GAS COND separator to the IM3 injection manifold.
At the end the system should resemble the following picture:
669
RESOLVE
What does this link entails?

When a forecast is run, data will be passed between the separators and the injection manifolds.
This data will include the pressures, temperatures, and black oil phase rates. As this is a fully
compositional model in GAP, it will also include the EOS data (molar fractions and EOS
properties) and mass flow rates.
In general, when data is passed between items in RESOLVE a "continuity of pressure" is
assumed, i.e. pressure is assumed continuous across application boundaries. This means that,
in this case, the pressure of the separator will be applied to the injection manifold. The phase
rate will be applied as a constraint on the injection manifold. The result of this is that the
injection system will be allowed to inject as much as it can with an injection pressure
equal to the separator pressure as long as it does not exceed the amount passed from
the production system.
Of course the separator pressure is unlikely to be high enough to allow injection back into the
reservoir. For this reason compressors have been included in the GAP injection system. For
simplicity in this case fixed pressure increases have been used to raise the pressure to allow
injection, although it should be noted that in general this is not a good way to model a
compressor and it is not recommended, as it might lead to negative pressures being observed
in the GAP model.
If all the fluids passed into a GAP injection system are to be reinjected (i.e. regardless of
whether the injection system is able to or not) then it will be possible to use a GAP source rather
than an injection manifold. GAP floats the pressure of these source items to inject all the fluid that
is passed to them and so the continuity of pressure across application boundaries can be
worked around.

Step 5 Objective:
Enter the schedule forecast
Once the links between the different nodes have been setup, it will be possible to specify the
forecast data: start date / end date and timestep length.
To do this, go to Schedule | Forecast data and enter the following data:
Examples Guide
670
The simulation start date happens to coincide with the tank start date and could be found by
clicking on the "Select from client modules" button.
The end date and the timestep length should be entered as shown.
Further informations on the different options of that screen can be found in the "Schedule"
section of the present manual.
Prior to the forecast being run, it will be important to define the variables that have to be
exported to the RESOLVE results.

Step 6 Objective:
Setup the results to be displayed
671
RESOLVE
By default RESOLVE saves a sub-set of the data that is passed at each connection. This is
limited to the pressure and black oil phase rates.
In this example, we would expect to see the pressure, oil produced, water produced, and gas
produced reported for the connections between GAS OIL and IM1 and GAS COND and IM3.
In addition, we would like to see how much of the gas that is produced by the production system
ends up being reinjected.
Also, in the case where all the gas is reinjected, we would like to see how far the wells need to
be choked to achieve this.
The variables that need to be reported in addition of the standard RESOLVE variables are
therefore:
IM1 Gas Rate
IM3 Gas Rate
WINJ1con dP choke
WINJ2con dP choke
WINJ2oil dP choke
WINJ3oil dP choke
RESOLVE can automatically build a list of the GAP variables available and that list can be
reported directly through the RESOLVE interface.
To obtain that list, right-click on the GAP injection icon and select the "Output Variables"
option.
The following screen will be displayed (i.e. this might take some time with models where a large
number of variables have to be retrieved), where one can select the element considered (i.e. for
Examples Guide
672
instance IM1) and the variable associated with it that needs to be reported (i.e. here gas rate)
and use the "Add From List" button to add it to the list of variables to be reported.
Once all the variables mentioned above have been selected, the screen will be displayed as:
Once the variables to be reported have been selected, click OK and proceed to the next step,
which illustrates how to run the prediction forecast.
Make sure that there are no screens left open in GAP as this can interfere with the remote
operation of GAP by RESOLVE.

Step 7 Objective:
Run the forecast
The forecast is now ready to be run.
To start, go to Run | Start or click the "go" button on the toolbar (
).
The first thing that happens is that both modules perform their respective initialisations.
In the case of GAP, this means loading the tank data and initialising them (i.e. running a history if
necessary) to the forecast start date.
For compositional runs, RESOLVE will also obtain the composition names from the different
applications (i.e. in this case, the production and gas injection systems). In general the
composition names used by different applications may be different and thus RESOLVE must be
673
RESOLVE
told which compositions correspond to which across the models. In this case the situation is
simpler; the composition names in the production and injection systems are identical.
Nevertheless, the same process of mapping composition names must be passed through.
The following screen (i.e. the "Composition table" screen) will be presented:
Select the GAS OIL to IM1 connection: the left hand side list will specify the list of components
and their names used by the GAS OIL separator. The right hand side list will specify the list of
components and their names used by IM1.
if the components are in the same order in both list, which is the case here, it will be possible to
click "Add All" to automatically make correspondences between the left and right hand lists.
Once this is done, the following screen will appear, illustrating the component mapping that has
been done for this connection.
If the components were NOT in the same order, then it will have been possible to manually select
each component in the list and click on "Add Individual Connection" to establish the different
connections.
Examples Guide
674
The same procedure has to be done for the GAS COND to IM3 connection.
Once both connections will have their composition mapped, the icon next to each connection will
turn from a red cross to a green tick, illustrating the fact that a full composition mapping has
been performed in the model.
675
RESOLVE
It is important to note that this step will NOT be necessary if linking models that use black oil
PVT descriptions.
Click "OK" to continue the forecast - The status of the run will be displayed in the RESOLVE
"Calculation Progress" screen, as illustrated below.
Examples Guide
676
Once the forecast has been performed, it will be possible to visualise and analyse the results, as
described in the next step.

Step 8 Objective:
Results analysis
The objective of this example is to pass the produced (separated) gas stream from the oil and
gas condensate reservoirs to be injected back into the reservoirs through the injection model.
For the run, GAP performs a solve and optimisation of the production system with the initial tank
data. The production will be taken from the separator gas streams and passed to the injection
system. As mentioned earlier, the pressure will be passed to the injection manifold and the gas
phase rate will be applied as a constraint to the injection manifold. The injection system will then
be solved and optimised while honouring the gas rate constraint. To honour the constraints, the
injection model may have to choke back the injection wells. GAP will then be ready to take a
677
RESOLVE
timestep.
The timestep should be 2 months (i.e. as entered on the "forecast data" screen) but it is
possible to notice that RESOLVE performs a timestep on the 01/12/2005. This is because
RESOLVE is adding an extra timestep to synchronise with the GAP schedule bringing on wells
in the production system. Several subsequent timesteps will also be truncated in this way.
The forecast will take some time to reach 2015, although the run can be ended at any time by
going to Run | Stop or clicking on the stop button on the toolbar.
One can now view the results of the run in two different formats:
To see the results in tabular format, select the Results | View Forecast Results
(Table) section or the following icon:
To see the result in a plot format, select the Results | View Forecast Plots section or
the following icon:
One of the interesting elements of this model is to compare the amount of gas that is produced
to the amount of gas that is injected.
To do so, the following procedure can be used:
Select the Results | View Forecast Plots section or the following icon:
following screen will appear:
. The
Examples Guide
678
Select the "IM1" variable entry in the left hand side list. A list of variables that are
available for display appear at the bottom left hand corner of the screen, as illustrated
below.
679
RESOLVE
button. The following screen

Select the "Gas Injected" variable and click on the
will appear, that enables to select for which nodes of the system the user wishes to
display the evolution of the "Gas Injected" variable. In this case, select both IM1 and IM3
variables, as illustrated below.
Examples Guide
680
Once this is done, click "OK" and the following plot will be displayed, illustrating the gas
injected in both IM1 and IM3 manifolds. It is possible to note that the injection stops for
both injection systems on the 01/01/2010 - This is due to the GAP schedule, that
specifies that both injection systems are MASKED after this date.
681
RESOLVE
The next step will be to compare the amount of gas injected to the quantity of gas
produced for each system, to verify whether the injection systems in place allows to reinject all the produced gas or not.
To do so, the same procedure can be used:
Select the IM1 connection (! not the variable, the connection itself) which will
contain the gas produced by the production system and passed to the injection
system as a constraint in the list of variables on the left hand side of the screen.
Examples Guide
682
Select the "Gas Produced" variable at the bottom of the screen and click on the
button.
The following screen is displayed, enabling to select the connections for which
the gas produced variable has to be displayed. Select both IM1 and IM3
connections, as illustrated below.
683
RESOLVE
Click OK to display the following plot:
Examples Guide
684
It is possible to notice that until 01/01/2010 (i.e. when the injection system is then
switched off through the GAP scheduling) the injection rate is the same as the
production rate: this enables to confirm that the injection system is able to re-inject all
the gas that is produced.
It is also possible to see an increase in production following 2010 due to more wells (i.
e. condensate wells) being brought on.
As the injection and production rates are the same before 2010, chokes are being set
on the injection wells to meet the maximum gas injection constraint.
To do so, select the injection well dP choke variables in the left hand side list and select
dP choke. Add these variables to the plot, as illustrated below.
685
RESOLVE
This plot enables to illustrate the pressure losses required across the wellhead chokes
to meet the gas injection constraints.
Also a very good way to investigate what happens in the model at each timestep, is to go to the
GAP model and reload a prediction snapshot at a specific date.
This is possible because the option to "Always save forecast snapshots" was selected when
the GAP model instances in RESOLVE were created. This automatically tells GAP that
prediction snapshots should be saved at each timestep. (This can also be manually input in GAP
by using the prediction calculations "settings" option).
This can be done by going to the GAP production model (for example) and select Prediction |
Reload prediction snapshots.
Examples Guide
686
This will ask for the file to be saved, and then call up the various timesteps at which snapshots
were saved as shown below.
If we select the date shown, we will reload a snapshot of the model at that point in time.
687
RESOLVE
Examples Guide
688
By double clicking on the Gas oil separator in the production model and going to the results tab,
we can get how much gas was separated from the stream. This volume will be placed as a
constraint in the IM1 injection manifold for that timestep as shown below.
689
RESOLVE
This volume will therefore act as a constraint, enabling the GAP optimiser to calculate the
pressure losses needed across the wellhead chokes to respect this constraint.
3.4
Example Section 2: Connections to Reservoir Simulation

Tools
3.4.1 Example 2.1: GAP - REVEAL Connection

3.4.1.1 GAP-REVEAL : Overview
The objective of this section is to demonstrate how to setup a connection between GAP
production and injection models and a reservoir simulation model setup in REVEAL.
A new discovery has been made - A full field model is required to analyse the behaviour of this
field under different production and injection conditions.
In order to do so, a numerical simulation reservoir model has been setup as well as surface
network models for the production and the gas injection system.
The first objective is to dynamically link the reservoir and surface network models.
the second objective is to understand, based on the full-field production and injection
capabilities, what are the different behaviors that are going to be observed during the field life.
RESOLVE
1
OpenServer
2
REVEAL
1
GAP
1
PROSPER
1
MBAL
1
Before starting with this example, it will be necessary to make sure that the RESOLVE drivers for
both REVEAL and GAP are registered.
Examples Guide
690
been registered.
3. Files Locations
C:\Program Files\Petroleum
\Example_2_1
Experts\IPM
7.5\Samples\Resolve\Example_Section_2
This folder contains a file "GAP_REVEAL.rsa" which is a "RESOLVE archive file" that contains
the RESOLVE file, REVEAL file, GAP file and other associated files required to go through the
example. The archive file needs to be extracted either in the current location or a location of the
user"s choice.
Go to Step 1
3.4.1.2 GAP-REVEAL : Step 1
Step 1 Objective:
Start RESOLVE, and open a new project using File | New or the icon
691
RESOLVE
Now is a good time to save the file using File | Save As..., and enter a file name (e.g. GAPREVEAL.rsl).
Go to Step 2
Step 2 Objective:
Create a REVEAL instance in the RESOLVE model
The next step is to create instances of the various applications that have to be connected
through RESOLVE.
icon.
From the resulting menu, select "REVEAL".
Examples Guide
692
Click on the main screen where to position the REVEAL icon, and give the case a label (say,
"Reservoir").
Double-click on the REVEAL icon - the following screen will appear:
For the file name, browse to the file "Reservoir.rvl" as shown above.
Note that from this screen it is possible to select a remote host on which REVEAL can be run.
This is especially useful in cases where several reservoir models are included in the same
model: in this case it will probably be useful to run these simulations in parallel.
When OK is pressed, REVEAL will start and load the required case.
It will then query the case for its sources and sinks (wells) and will display these on the screen as
shown below.
The icons can be moved by selecting the "move" icon on the toolbar (
them to the required positions.
) and then dragging
693
RESOLVE
Note that we have four producers and four gas injectors linked to the reservoir model.
Go to Step 1 or Step 3
Step 3 Objective:
Create the GAP production and gas injection instances in the RESOLVE model
Repeat the previous step to create an instance of GAP on the RESOLVE main screen.
Label the GAP case created "Production". Browse for the model "Production System.GAP".
Examples Guide
694
Note again that it is possible to start GAP on a remote networked PC. Further information on
running remote instances of the IPM tools can be found in the "Running IPM instances on a
remote PC" section.
Also select the option to "Always save forecast snapshots" under snapshot mode section.
This saves a snapshot of each prediction timestep in GAP, allowing the user to reload a copy of
each snapshot and analyse the performance at that date - this can be particularly useful for
troubleshooting purposes.
When OK is pressed, RESOLVE will take a few moments to load GAP and query the case. The
GAP file contains a production and gas injection model. In the production model, four production
wells, Well1, Well2, Well3 and Well4 are seen. These are the same wells as were identified from
the REVEAL case. It is possible to look at the GAP interface as the GAP model will be open on
the taskbar to confirm the contents of the GAP file.
695
RESOLVE
Once this has been done, the RESOLVE model will be as follows:
Examples Guide
696
697
RESOLVE
Repeat the previous step to create an instance of GAP on the RESOLVE main screen for the
gas injection system.
Label the GAP case created "Gas_Injection". Browse for the case "Production System.GAP"
and select the Associated Gas Injection option. Effectively, both the production and gas injection
models were associated in the GAP model itself: the Production System.gap file will therefore
include both the production and the gas injection model.
When OK is pressed, RESOLVE will take a few moments to load GAP and query the case. Four
injection wells, GInj1, GInj2, GInj3 and GInj4 will be found. These are the same wells as were
identified from the REVEAL case. It is possible to look at the GAP interface to confirm the
contents of the GAP file.
The RESOLVE model display will be as follow:
Examples Guide
698
Go To Step 2 or Step 4
Step 4 Objective:
Establish the connections between the GAP and the REVEAL models
At this stage, the applications can be connected together graphically.
To connect the systems, go to "link" mode by pressing the
icon.
Connect the Well1 icon in REVEAL to Well1 in GAP by clicking into the first icon and dragging
the connection to the second.
Repeat this for Well2, Well3, Well4 and GInj1, GInj2, GInj3 and GInj4.
The following structure is obtained when all connections are made.
699
RESOLVE
Note that it is also possible to make the connections using the "Connection wizard". This is
obtained by invoking Edit System | Connection Wizard under the main menu and is
especially useful when dealing with a large number of connections.
Step 5 Objective:
Finalise the RESOLVE model setup
Before the simulation is run, further changes have to be made to the system configuration.
There are various settings that can affect the way the system behaves.
IPR Control mode in REVEAL
One of the most important elements to consider when establishing a link between a reservoir
simulation model and a surface network model is the way the well inflow performance curves, or
Examples Guide
700
IPRs that are passed from the reservoir model to the surface network model and determine part
of the well performance, are calculated.
A detailed description of the different techniques used to determine these IPRs, along with their
respective advantages and disadvantages, can be found in the "IPR Generation Options"
section.
When considering a REVEAL instance, these options can be accessed by double-clicking on
the REVEAL icon to view the REVEAL data entry screen. Go to the "Case Details" tab.
This will enable to choose whether the IPR calculation in REVEAL is based either on block or
drainage region pressures.
Here, change the IPR model to "Drainage region (advanced)".
This IPR model uses an advanced proprietary method to calculate the well IPR. It is the
recommended IPR generation method as it leads to the more stable and realistic
results.
When using this method, a calculation has to be performed prior to launching the forecast. This
701
RESOLVE
has to be done only once when the RESOLVE model is setup UNLESS the well models
specified in REVEAL are modified. Click on the setup tab and the interface below appears. The
calculate button has to be selected to perform the pre-run calculation required for this method.
Once the calculation is complete, the setup button will become green.
Click "OK" to go back to the main screen.
It is possible to monitor the inflow performance relationships (i.e. IPR curves) that are passed
from the reservoir model to the surface network model at every timestep - to do so, make sure
that the Run | IPR Logging option is selected in the main RESOLVE menu.
Well Control mode in REVEAL
When GAP solves / optimises the system RESOLVE returns the result as an operating point on
the inflow performance relationship that was passed by REVEAL for that well. This operating
point will determine the well performance and will consist of a BHP, THP and phase rates.
The user can select which one of these parameters should be used as the boundary condition to
obtain an updated IPR from REVEAL at every timestep.
REVEAL will then control that well with the fixed boundary condition for the duration of the next
RESOLVE timestep. The settings indicated below show that the wells in this REVEAL model are
controlled between solves according to the system response.
This algorithm enables to select at each timestep the fixed boundary condition that will have the
minimum effect on the accuracy of the prediction.
To setup this option, double-click on the REVEAL icon to view the REVEAL data entry screen
and go to the "Associated Data" tab.
This will enable to choose which well control mode is chosen, as illustrated below.
Examples Guide
702
On this screen, it is also possible as well to select a restart option i.e. If REVEAL is to be started
from the initial state of the reservoir model or from a specified restart stage.
Stop RESOLVE from reloading the models at the start of the run
It is sometimes useful to have RESOLVE reload the files at the start of the run. In some cases the
forecasts may leave wells masked or separator pressures changed in which case when a new
run is started it will be needed to reload the original file.
This option is the default in RESOLVE, however, it can be time consuming, specially when
dealing with large models.
If there is no reason for the models to be reloaded before the start of the run, then it is possible
to modify this option by going to Options | System options and change the settings to "Do not
reload client modules".
If this is the option selected, then RESOLVE will not reload the models at the beginning of the
run, but will use the models that are currently open on the machine.
703
RESOLVE
Step 6 Objective:
Setup the RESOLVE Schedule
Before the simulation is started, it is necessary to specify the run schedule in RESOLVE.
Scheduling in RESOLVE is divided into two parts:
Basic scheduling - timestep length and overall duration
Advanced scheduling - where using a script or the event-driven scheduling module, a
condition-based scheduling can be implemented.
For the purposes of this example, we will be making use of the basic scheduling only.
Examples Guide
704
The advanced scheduling is described in the "Example_2_3" section.

To setup the basic RESOLVE schedule, invoke the schedule screen from the main menu using
Schedule | Forecast data.
The following screen is displayed.
The start date can be selected from the start dates of the various connected modules by clicking
on the "Select from client modules" button. This will display a screen allowing the user to
select the required start date from a list of the various model start dates.
The timestep and schedule duration are also entered here as shown.
Here GAP and REVEAL will be synchronised every 2 months until the schedule completes on
1/1/2013.
705
RESOLVE
Step 7 Objective:
Publish the variables to report in the RESOLVE results section
limited to the pressure and black oil phase rates. In this example, we wish to report all the
variables for the wells and separator in the GAP production model as well as the injection wells
and manifold in the GAP injection model.
RESOLVE can automatically build a list of the GAP variables available and that can be reported
directly through the RESOLVE interface.
To obtain that list, right-click on the GAP production icon and select the "Output Variables"
option.
The above screen will be displayed (i.e. this might take some time with models where a large
instance Well1) and also the variables associated with it that needs to be reported. (e.g. oil
rate).
We wish to report all variables for each well, therefore select Well1 and use the "Add From List
" button to report all its variables.
Once all the variables for all the four wells and separator (sep1) have been selected, the
screen will be displayed as:
Examples Guide
706
Click OK and do the same for the gas injection model. Output all variables for the injection
wells and manifold (IM1) and proceed to the next step.
Step 8 Objective:
Run the prediction forecast
The simulation is now ready to be run.
707
RESOLVE
Two different options can be selected when starting a forecast run:

Running the forecast from beginning to end
To run the forecast from beginning to end without stopping, press the
Note that the run can be paused or stopped with other toolbar icons.
icon.
Running the forecast step by step

To run the forecast from timestep by timestep (i.e. this can be useful to check the
validity of the model setup for the first timesteps for instance), press the "single step"
icon. This is the option that is used in this example.
Note that after each timestep, the run will automatically be paused: one can decide to
run another single step by using the
forecast until the end by using the
icon again, or can decide to run the prediction

icon.
Once the forecast has been started, REVEAL will perform an equilibration calculation. If it was
setup to load a restart file it will do this instead.
The equilibrated reservoir data will be passed to GAP in the form of well IPR curves (i.e. for both
producers and injectors). GAP will use this data to solve and optimise the system. The solution
points will then be returned to REVEAL ready to take the first week"s timestep. Before this, the
RESOLVE forecast enters "pause" mode.
The results of the run for the first timestep can be checked briefly by holding the mouse over a
connection icon:
Examples Guide
To run the rest of the forecast without stopping, press the

paused or stopped with other toolbar icons.
708
icon. Note that the run can be
RESOLVE will complete the run to 2013 taking 2 months timesteps.

Note that some extra timesteps are inserted.
These are put in to coordinate with the reporting dates specified in the REVEAL deck. It will also
coordinate with any events specified in GAP model e.g. wells being turned on or off.
3.4.1.10GAP-REVEAL : Step 9
Step 9 Objective:
Analysing the Results
Results can be obtained in two ways using RESOLVE.
RESOLVE has a set of results - the amount of results reported in the RESOLVE model
is function of the variables that have been published by the user prior to the run itself.
Refer to step 7 for further details.
It is also possible to view all the results of a simulation for any of the client applications
in the application itself.
709
RESOLVE
The results from the client applications are best viewed when the run has completed or is
paused: this is because RESOLVE is controlling the application and it is possible that viewing
application results will interfere with the control. For this reason, application user interfaces are
disabled while the run is proceeding.
The RESOLVE results can be analysed by invoking Results | View Forecast Plots, or by
clicking on the
icon.
These results can also be displayed as the run is proceeding.
For this specific case, we want to first analyse the oil that has been produced for the entire
production system as well as for each individual well.
To do so, go to Results | View Forecast Plots, or by click on the
icon.
All the nodes of the RESOLVE model are listed in the left hand side of the screen. Select the
"Sep1" node.
Examples Guide
710
Once this is done, a list of the variables associated with this node will appear at the bottom of
the screen, as illustrated below.
Select the variable to be viewed, here oil produced and click on the
button.
The following screen will be displayed, when one can define which nodes have to be included in
the oil produced plot. Here we select the separator node as well as all the wells nodes.
Click "OK" and the following plot is displayed, illustrating the oil production at separator level
and for each individual well.
711
RESOLVE
Once this is plotted, it is possible to observe very high production with very sudden decline at the
start of the forecast. From december 2008 onwards, the production decline is much slower.
In order to understand this behavior, it is possible for instance to plot the evolution of reservoir
pressure in the wells and compare it to the amount of gas injected in the reservoir.
In order to create a second plot, use the Results | View Forecast Plots (new window), or
click on the
icon.
Then, use the same procedure than described above to plot the reservoir pressure in the
producing wells and the gas injected at the injection manifold level.
The following plot is obtained:
Examples Guide
712
It is possible to notice that no injection is possible with the current gas injection system at the
beginning of the field life: the reservoir pressure is too high. This leads to a very high well
potential, hence a very large production.
This very large production will lead to a very rapid reservoir pressure decline without pressure
support.
As soon as the pressure passes below 4,200psig, then it is possible to re-inject gas in the
system, and this slows down considerably the reservoir pressure decline, as illustrated above.
Once the results have been analysed, it will be possible to save the results of this run by
selecting the
icon. This will enable to keep the results of this run in memory, in order for
instance to compare it to future runs.
When doing so, the following screen will appear, enabling to provide a name to the result stream
to be saved. Call it "Example_2-1" for instance and click "OK".
713
RESOLVE
It is also possible to save the plot templates if one wishes to go back to the same plot to
visualise results of the next forecast run for instance. To do so, used the
icon in every plot
open, and give a name to each plot. Here, we will save two plots called respectively
"Oil_Production" and "Reservoir_Pressure".
In addition to the forecast results, because the "IPR Logging" option was selected before the
run, it is possible to visualise the different IPR curves that have been passed from the reservoir
model to the surface network model at each timestep.
This can be done by going to the Results | View IPR log results section or by clicking on the
icon.
Examples Guide
714
This enables to select the well to consider and the dates at which the IPR curves have to be
displayed.
In this case, select "Well 1" and "All" dates. Once this is done, click "View".
This will display the following screen, that provides for each date (i.e. the date selection can be
done in the top left hand corner) the IPR data passed from the reservoir model to the surface
network model.
715
RESOLVE
This IPR data can be plotted by using the "Plot" option: after selecting the dates and the
parameters to be displayed in the "Variables" section, the IPR curves are displayed.
Examples Guide
716
Go to Step 8
3.4.2 Example 2.2: GAP - REVEAL Connection with Script

3.4.2.1 GAP-REVEAL-Scripted : Overview
The objective of this section is to demonstrate how to control events in a surface network reservoir simulation coupled model by using the RESOLVE internal scripting capability.
This example is based on the previous example, the "Example_2_1".
network models for the production and the gas injection system. These models have been
dynamically linked through a RESOLVE model.
A capacity constraint of 120,000 STB of liquid per day needs to be respected at the separator
level.
Initially, the status of the system is such that all the production and injection wells are open and
717
RESOLVE
that the capacity constraint has not been setup at the separator level.
The objective of the study is to start the forecast with only one production well open and to
understand at what point in time will the additional production wells have to be put on stream.
In order to do so, an internal RESOLVE script can be written that monitors the liquid production
at the separator and open the production wells when required.
It is important to note that this exact same procedure can be achieved by using the
RESOLVE event driven scheduling capabilities, which does note require any scripting to be
setup. The procedure to do so is described in the "Example_2_3".
RESOLVE
1
OpenServer
2
REVEAL
1
GAP
1
PROSPER
1
MBAL
1
been registered.
3. Files Locations
\Example_2_2
Experts\IPM
This folder contains a file "GAP_REVEAL_Scripted_Start.rsa" which is a "RESOLVE archive

file" that contains the RESOLVE file, REVEAL file, GAP file and other associated files required
to go through the example. The archive file needs to be extracted either in the current location or
a location of the user"s choice.
Go to Step 1
Examples Guide
718
3.4.2.2 GAP-REVEAL-Scripted : Step 1

Step 1 Objective:
Open the RESOLVE file and modify the main model options to be able to handle the
script
Start RESOLVE and go to File | Archive | Extract. Select the GAP_REVEAL_Scripted_Start.
rsa file and extract its contents into a selected location. When the "Open Master File?" question
is prompted, select "Yes".
Once the model is loaded, ensure that the models are set to be reloaded when the forecast
starts by going to the Options | System Options section.
This is important in this case as the script is going to be used to modify the client
application models, so we need to ensure that we are starting from the same initial
state every time we run the forecast.
719
RESOLVE
Save the model as a new file: GAP_Reveal_Scripted_Final.rsl).

Go to Step 2
Step 2 Objective:
Write the internal RESOLVE script
The "Scripting" must either be programmed right from start or imported from another model.
In this case a script is provided to implement the required functionality.
Go to Script | Import and browse to the file "GAP_REVEAL_Scripted.rsc" located in the C:
\Program Files\Petroleum Experts\IPM 7.5\Samples\Resolve\Example_Section_2
\Example_2_2 directory of the main installation.
Click on Script | Edit to view the script that has just been imported.
It is necessary to make sure that the production module is labelled "Production" as
this is hard-coded in the script.
The script is implemented in a language called "Visual Basic Script" (VBS).
For most purposes this is the same as the language used in Excel (VBA).
The script section is divided in the following main functions:
Declarations
This section enables to define variables that are going to be used in the script.
Using VBA, it will be required to define most of the variables used in the code using the
Dim t As Object code line.
Using VBS, this would not be necessary in VBS. It is however sometimes useful to be
able to declare global variables (i.e. variables that keep their values for the duration of the
forecast).
Start
This function is called only once at the start of the forecast, mainly for initialisation
purposes.
Finish
This function is called only once at the end of the forecast, mainly for cleanup purposes.
PreSolve
This function is called for each timestep before every group of models that can be solved
simultaneously is solved.
Examples Guide
720
PostSolve
This function is called for each timestep after every group of models that can be solved
simultaneously is solved.
In the script considered, both the "Start" and "PostSolve" sections are used.
The logic of the script used in this case is described below.
Going through the script step by step enables to identify the three main actions that are
performed by the script, as described below.
Initialising the model
This is the section 1 in the picture above.
It enables to setup the GAP model according to the constraints of the problem:
The wells 2, 3 and 4 are masked at the beginning of the forecast: this enables to
see how long can the system produced at the maximum capacity constraint with
721
RESOLVE
only one production well.

The capacity constraint (i.e. Maximum Liquid Rate = 120,000 STB/day) at the
separator is setup.
Checking the status of the model at each timestep
This section is used at the beginning of each timestep to check the value of the following
variables:
Date of the current timestep
Liquid production at the separator for this particular timestep
Status of the wells 2, 3 and 4: if the "Maskflag" variable of one well is <> 0, then
this well is masked in GAP. If the "Maskflag" variable of one well is = 0, then this
well is open in GAP.
Each one of these variables is exported to the script section of the RESOLVE log
window.
Opening additional wells as required
This section is used to open the wells if the liquid production at the separator is less than
the capacity constraint of 120,000 STB/d.
The wells are opened in the following order: Well 2, Well 3 and Well 4.
Step 3 Objective:
Debug the internal RESOLVE script
This is an optional step which the user can perform if a debugger is installed on the PC being
used.
Debugger programs can be downloaded off the internet. If in any doubts please contact
Petroleum Experts for more information.
From the script editor, click on the line that reads "If SepQLiq < 118000 And MaskFlag2 <> 0
Then" and press F9 to insert a breakpoint.
Another option is to use right-click feature. Exit from the script.
Examples Guide
722
The function can be tested (i.e. without running the forecast) by going to Script | Execute
function | PostSolve.
A screen will be presented asking which ModuleList the function has to pass through: select
"Production" from the drop down list and press OK.
Depending on the debugger a series of messages may appear asking if one wishes to step into
the script.
Once in it will be possible to perform the usual debugging functions, e.g. stepping over lines of
code, examining the values of variables, setting new breakpoints, and so on.
After the user have finished, go back to the script editor in RESOLVE and remove the
breakpoint.
Step 4 Objective:
Run the forecast and Analyse the results
To run the the forecast, press the
other toolbar icons.
icon. Note that the run can be paused or stopped with
RESOLVE will complete the run to 2013 taking 2 months timesteps and running through the
internal script defined at every timestep.
When the forecast is run the first thing that will happen is that the GAP and REVEAL models will
be reloaded. This might take a few seconds.
When the forecast is running, it is possible to go to the "Script" section of the RESOLVE output
log, as illustrated below. This will enable to see all the messages that are published by the script:
in this case, it consists, at each timestep, of the current timestep date, the liquid production rate
at the separator and the mask status of each well.
723
RESOLVE
For instance, it is possible to see from this output log when the wells are opened, as their
respective mask status will be changed to a value equal to 0.
In this case, the liquid production at the separator is equal to 76982 STB/day for the first
timestep. This is lower than the capacity at the separator, and therefore the well 2 is open at the
second timestep, as shown by its mask status being equal to 0.
Other results can be viewed in the usual manner.
For instance, it is possible to go to the Results | View Forecast Plots section and plot the oil
produced at the separator and by each individual well. As this plot setup was saved when the
Example_2_1 was performed, it is possible to simply reload the plot directly by using the
icon.
The following screen is displayed, select the "Oil_Produced" saved plot.
Examples Guide
724
The following plot will be displayed, illustrating the sequence of the well openings programmed
by the script.
Go to Step 3
3.4.3 Example 2.3: GAP - REVEAL Connection with Event Driven

Scheduling
3.4.3.1 GAP-REVEAL Event Driven Scheduling: Overview
725
RESOLVE
The objective of this section is to demonstrate how to control events in a surface network reservoir simulation coupled model by using the RESOLVE event driven scheduling capability.
The idea used by the event driven scheduling facility is that the user is able to set up conditions,
such that when a condition is "triggered" an action or several actions will be performed.
The condition can be checked by RESOLVE prior to solving the system (pre-solve), after solving
the system (post-solve), or at the start of the run.
A capacity constraint of 120,000 STB of liquid per day needs to be respected at the separator
level.
Initially, the status of the system is such that all the production and injection wells are open and
that the capacity constraint has not been setup at the separator level.
The objective of the study is to start the forecast with only one production well open and to
understand at what point in time will the additional production wells have to be put on stream.
In order to do so, the event driven scheduling capability of RESOLVE can be used to monitor the
liquid production at the separator and open the production wells when required.
It is important to note that this exact same procedure can be achieved by using the
RESOLVE internal scripting capabilities. The procedure to do so is described in the "
Example_2_2".
RESOLVE
1
OpenServer
2
REVEAL
1
GAP
1
PROSPER
1
MBAL
1
Examples Guide
726
been registered.
3. Files Locations
\Example_2_3
Experts\IPM
This folder contains a file "GAP_REVEAL_Event_Driven_Scheduling_Start.rsa" which is a "

RESOLVE archive file" that contains the RESOLVE file, REVEAL file, GAP file and other
associated files required to go through the example. The archive file needs to be extracted
either in the current location or a location of the user"s choice.
Go to Step 1
3.4.3.2 GAP-REVEAL- Event Driven Scheduling : Step 1
Step 1 Objective:
event driven scheduling
Start
RESOLVE
and
go
to
File
|
Archive
|
Extract.
Select
the
GAP_REVEAL_Event_Driven_Scheduling_Start.rsa file and extract its contents into a selected
location. When the "Open Master File?" question is prompted, select "Yes".
This is important in this case as the event driven scheduling is going to be used to
modify the client application models, so we need to ensure that we are starting from the
same initial state every time we run the forecast.
727
RESOLVE
Save the model as a new file: GAP_Reveal_Event_Driven_Scheduling_Final.rsl).

Go to Step 2
Step 2 Objective:
Publish the variables to be used for the event driven scheduling
To begin, variables have to be published from the different client modules prior to using these
variables in the event driven scheduling section.
To start using the tool invoke Schedule | Import application variables. The interface below
comes up. This is where the variables to be published for the client modules are published.
Examples Guide
728
For this example, the following variables need to be published.

Mask flag for well2, well3 and well4 - This will provide the status of the wells (i.e. Open
or Closed).
Separator liquid rate.
Max liquid rate constraint at separator.
Click on the production tab and then "Edit variables".
Click on the equipment masking tab. This is where the mask flags for the production wells will be
published. Select well2 and click on the red arrow to publish the variable. Do the same for well3
and well4. The mask flags will return "1" if the item is masked or "0" if unmasked.
729
RESOLVE
Revert back to the OpenServer variables tab. Publish the liquid rate at separator (Sep1).
Examples Guide
730
Click on Constraints (input) variables tab and also publish the maximum liquid rate constraint
at separator. To list the variables in this section, click on the "Rescan button". This is as shown
below.
731
RESOLVE
Click OK and the interface below shows the variables published for the production system.
Examples Guide
732
Once the variables have been published, it will be possible to go ahead with the event driven
scheduling setup.
Click OK to go out of the screen.
Step 3 Objective:
Setup the Event Driven Scheduling
Once the variables have been published, the event driven scheduling section can be setup.
To access the event driven scheduling setup, click on Schedule | Event driven scheduling.
The interface below appears.
733
RESOLVE
In simple terms, the screen allows setting up many conditions (i.e. which can be aggregated
together with AND or OR statements to form a single condition), such that when a condition is
"triggered" an action or several actions will be performed.
the system (post-solve), or at the start of the run. This can be specified by using the Schedule
section at the top of the screen.
The conditions that have to be set for this example are outlined below:
Before the run, i.e. At start, If Date = 01/01/2008 then
Set maximum liquid constraint to 120,000 stb/day
Mask well2, well3 and well4
At the end of each timestep, i.e. Postsolve, if separator liquid < 118,000 stb/day then,
First unmask well2
If the condition becomes true again at a later time, unmask well3
The first condition is entered by populating the event drilling schedule interface as shown below.
Examples Guide
734
With the condition input, the next step is to specify / define the actions to be taken. This is done
by clicking on <no action> tab on the left.
735
RESOLVE
Input the actions as shown above. Mask flag of "1" means the wells will be masked.
Click OK and the <no action> tab will change to <Action>.
This will enable to mask the wells and the maximum liquid rate constraint at the separator at the
start of the run.
Once this is done, then it will be required to set a condition to be checked at the end of every
timestep, to determine the time at which well2, well3 and well4 are to be opened.
This event is to be performed during the "Post solve" as shown below. It can be seen that a
separator liquid of 118,000stb/day instead of 120,000stb/day is used. A little tolerance is given
for the rate to ensure the event occurs only when the condition is fulfilled as the solvers may not
always obtain exact solutions at each timestep. e.g. a solution of 119900 stb/day is still
realistically close to 120,000 stb/day and is not reason to trigger the event.
In addition, we want three groups of actions to be performed, i.e one well (i.e. well2) to be first
unmasked, and later on another well (i.e. well3) to be unmasked and later on another well (i.e.
well4) to be unmasked. This means the condition will be executed three times and thus the "
Times to execute" option should be set to 3.
Examples Guide
736
The action to be taken are input as shown below. The 3 wells are to be unmasked when the
condition is satisfied. However we wish to set a sequence for the unmasking, i.e. wells2, then
well3 and finally well4. This is done by clicking on "Rank icons" button.
737
RESOLVE
We shall select each of the wells in the order of which they shall be unmasked.
To do so, select each well in the top list and click the Add button to add them to the ranking list.
Then, in the "Ranking Variable" section, enter the order in which the wells have to be opened:
the value assigned to well2 is 1, to well3 is 2 and to well4 is 3.
Then, select the order in which the actions have to be executed: the well2 has the lowest ranking
value assigned to it and should be open first, therefore the "Order to execute actions" has to
be set to "Lowest first".
The count value is left to 1: it is only necessary to open one well at a time.
Examples Guide
738
In summary, this means at the first execution of the post solve condition specified previously,
unmask well2, at the second execution unmask well3 and at the third execution of the condition,
unmask well4.
Select OK, and ensure "Re-take pass through system (redo solve) after action has been
performed" is checked as shown on the screenshot below. This ensures that as soon as a
739
RESOLVE
condition is triggered, RESOLVE will perform the required action and will rerun the timestep with
the new event/action to ensure continuity in the solutions.
Click OK twice to go back to the main RESOLVE screen: the event driven scheduling section is
now setup and the forecast is ready to be run.

Step 4 Objective:
Run the forecast
RESOLVE will complete the run to 2013 taking 2 months timesteps and alter the well start times
Examples Guide
740
based on the event driven schedule which has been defined.

3.4.3.6 GAP-REVEAL- Event Driven Scheduling: Step 5

Step 5 Objective:
When the forecast is run the first thing that will happen is that the GAP and REVEAL models will
be reloaded. This might take a few seconds.
When the forecast is running, it is possible to go to the "Event" section of the RESOLVE output
log, as illustrated below. This will enable to see all the messages that are published by the event
driven scheduling, specifying the dates at which the conditions specified are triggered and the
corresponding actions taken.
For instance, it is possible to see from this output log when the wells are opened.
Other results can be viewed in the usual manner.
For instance, it is possible to go to the Results | View Forecast Plots section and plot the oil
741
RESOLVE
produced at the separator and by each individual well. As this plot setup was saved when the
Example_2_1 was performed, it is possible to simply reload the plot directly by using the
icon.
The following screen is displayed, select the "Oil_Produced" saved plot.
The following plot will be displayed, illustrating the sequence of the well openings programmed
by the script.
It is possible to notice that as soon as a new well is open, the GAP optimiser makes it the main
production well: this is due to the fact that the wells that have already been producing for a while
will have a higher WC and potentially higher GOR than the well that has just been opened: the
GAP optimiser will try to maximise the quantity of oil produced at the separator, and will
therefore minimise the water and gas production if possible.
Examples Guide
742
Go to Step 4
3.4.4 Example 2.4: GAP - REVEAL Connection with Scenario

Management
3.4.4.1 GAP - REVEAL Scenario Management: Overview
The objective of this section is to demonstrate how to setup a list of scenarios to be run with an
existing RESOLVE model, how to run them together and how to compare the results.
This is possible by using the scenario management capability of RESOLVE.
The development team wants to run the three following scenarios and compare the results:
Base Case: All four production wells are open for the duration of the forecast - No
capacity limit is set at the separator level.
Scenario 1: Only one well is open at the start of the forecast, well1 - A capacity limit of
120,000 STB/d liquid is set at the separator level - The event driven scheduling
capability is used so that the wells 2, 3 and 4 are open as soon as the production falls
below this plateau production rate.
In order to do so, the scenario management capabilities of RESOLVE are being used.
RESOLVE
1
OpenServer
2
REVEAL
1
GAP
1
PROSPER
1
MBAL
1
743
RESOLVE

been registered.
3. Files Locations
\Example_2_4
Experts\IPM
This folder contains a file "GAP_REVEAL_Scenario_Management_Start.rsa" which is a "

RESOLVE archive file" that contains the RESOLVE file, REVEAL file, GAP file and other
Go to Step 1
3.4.4.2 GAP - REVEAL Scenario Management : Step 1

Step 1 Objective:
event driven scheduling
Start
RESOLVE
and
go
to
File
|
Archive
|
Extract.
Select
the
GAP_REVEAL_Scenario_Management_Start.rsa file and extract its contents into a selected
location. When the "Open Master File?" question is prompted, select "Yes".
This is important in this case as the event driven scheduling is going to be used in
certain scenarios to modify the client application models, so we need to ensure that we
are starting from the same initial state every time we run the forecast.
Examples Guide
744
Save the model as a new file: GAP_REVEAL_Scenario_Management_Final.rsl).

Go to Step 2
Step 2 Objective:
Setup the different scenarios using the scenario manager
To start using this feature, invoke Schedule | Scenario Manager. The interface below comes
up.
On the left there is the Scenario list section that will contain any previously defined event driven
scheduling scenario. This is empty in this case.
745
RESOLVE
For this example, we shall to compare the three following scenarios:

Base Case: All four production wells are open for the duration of the forecast - No capacity
limit is set at the separator level.
Now we shall set up the three scenarios.
Examples Guide
746
Click on "Add empty scenario" at the bottom of the scenario list section to add the first case.
Label this "Base case".
Base case will appear as the first scenario, as illustrated below.
It is now necessary to specify the scenario 1: it first needs to be setup in the event driven
scheduling section and then imported in the scenario manager, as described in the procedure
747
RESOLVE
below.
Please note that this scenario will be the same as the one defined for the event driven
scheduling example: Example 2.3.
Click OK and go back to the main RESOLVE screen and follow the procedure below.
To begin, variables have to be published from the different client modules prior to using these
variables in the event driven scheduling section.
To start using the tool invoke Schedule | Import application variables. The interface below
comes up. This is where the variables to be published for the client modules are published.
For this example, the following variables need to be published.
Mask flag for well2, well3 and well4 - This will provide the status of the wells (i.e. Open
or Closed).
Separator liquid rate.
Max liquid rate constraint at separator.
Click on the production tab and then "Edit variables".
Examples Guide
748
Click on the equipment masking tab. This is where the mask flags for the production wells will be
published. Select well2 and click on the red arrow to publish the variable. Do the same for well3
and well4. The mask flags will return "1" if the item is masked or "0" if unmasked.
749
RESOLVE
Revert back to the OpenServer variables tab. Publish the liquid rate at separator (Sep1).
Examples Guide
750
Click on Constraints (input) variables tab and also publish the maximum liquid rate constraint
at separator. To list the variables in this section, click on the "Rescan button". This is as shown
below.
751
RESOLVE
Click OK and the interface below shows the variables published for the production system.
Examples Guide
752
Once the variables have been published, it will be possible to go ahead with the event driven
scheduling setup.
Click OK to go out of the screen.
Once the variables have been published, the event driven scheduling section can be setup.
To access the event driven scheduling setup, click on Schedule | Event driven scheduling.
The interface below appears.
753
RESOLVE
In simple terms, the screen allows setting up many conditions (i.e. which can be aggregated
together with AND or OR statements to form a single condition), such that when a condition is
"triggered" an action or several actions will be performed.
the system (post-solve), or at the start of the run. This can be specified by using the Schedule
section at the top of the screen.
The conditions that have to be set for this example are outlined below:
Before the run, i.e. At start, If Date = 01/01/2008 then
Set maximum liquid constraint to 120,000 stb/day
Mask well2, well3 and well4
At the end of each timestep, i.e. Postsolve, if separator liquid < 118,000 stb/day then,
First unmask well2
The first condition is entered by populating the event drilling schedule interface as shown below.
Examples Guide
754
With the condition input, the next step is to specify / define the actions to be taken. This is done
by clicking on <no action> tab on the left.
755
RESOLVE
Input the actions as shown above. Mask flag of "1" means the wells will be masked.
Click OK and the <no action> tab will change to <Action>.
This will enable to mask the wells and the maximum liquid rate constraint at the separator at the
start of the run.
Once this is done, then it will be required to set a condition to be checked at the end of every
timestep, to determine the time at which well2, well3 and well4 are to be opened.
This event is to be performed during the "Post solve" as shown below. It can be seen that a
separator liquid of 118,000stb/day instead of 120,000stb/day is used. A little tolerance is given
for the rate to ensure the event occurs only when the condition is fulfilled as the solvers may not
always obtain exact solutions at each timestep. e.g. a solution of 119900 stb/day is still
realistically close to 120,000 stb/day and is not reason to trigger the event.
In addition, we want three groups of actions to be performed, i.e one well (i.e. well2) to be first
unmasked, and later on another well (i.e. well3) to be unmasked and later on another well (i.e.
well4) to be unmasked. This means the condition will be executed three times and thus the "
Times to execute" option should be set to 3.
Examples Guide
756
The action to be taken are input as shown below. The 3 wells are to be unmasked when the
condition is satisfied. However we wish to set a sequence for the unmasking, i.e. wells2, then
well3 and finally well4. This is done by clicking on "Rank icons" button.
757
RESOLVE
We shall select each of the wells in the order of which they shall be unmasked.
To do so, select each well in the top list and click the Add button to add them to the ranking list.
Then, in the "Ranking Variable" section, enter the order in which the wells have to be opened:
the value assigned to well2 is 1, to well3 is 2 and to well4 is 3.
Then, select the order in which the actions have to be executed: the well2 has the lowest ranking
value assigned to it and should be open first, therefore the "Order to execute actions" has to
be set to "Lowest first".
The count value is left to 1: it is only necessary to open one well at a time.
Examples Guide
758
In summary, this means at the first execution of the post solve condition specified previously,
unmask well2, at the second execution unmask well3 and at the third execution of the condition,
unmask well4.
Select OK, and ensure "Re-take pass through system (redo solve) after action has been
performed" is checked as shown on the screenshot below. This ensures that as soon as a
759
RESOLVE
condition is triggered, RESOLVE will perform the required action and will rerun the timestep with
the new event/action to ensure continuity in the solutions.
Click OK twice to go back to the main RESOLVE screen: the event driven scheduling for the
scenario 1 is now setup and can be imported in the scenario manager.
To do so, go back to the Schedule | Scenario Manager section.
Examples Guide
760
The event driven scheduling that has been setup for the scenario 1 now appears on the left hand
side of the screen.
Click on "Add current schedule" and this schedule will be automatically imported in the
scenario manager - name it scenario1.
Once this is done, the scenario manager screen will be as follow:
761
RESOLVE
It is now required to add the third and last scenario, scenario 2.

It is possible to note that this scenario is similar to scenario 1, except for the fact the the capacity
limit at the separator is higher.
Therefore, the easiest way to setup this scenario is to import the current event driven scheduling,
initially setup for scenario 1 and then modify the maximum liquid constraint.
To do so, the following procedure can be followed:
In the scenario management screen, click on "Add current schedule" and name the new
scenario "Scenario 2".
Examples Guide
762
At this point, both scenario 1 and 2 are exactly similar.

To modify the scenario 2, highlight the scenario 2 in the list and select the "Edit" button at the
bottom of the screen, as illustrated above.
This will automatically open the event driven scheduling section associated to scenario 2, as
illustrated below.
763
RESOLVE
It is required to modify the capacity limit associated to the separator for this scenario. This
capacity limit is set in the "Start" section, so it is required to select this section in the "Schedule"
drop down box at the top left hand corner of the screen. The following screen will be displayed.
Go to the Action section and change the maximum liquid capacity at separator to 140000 STB/
Examples Guide
764
day, as illustrated below.
Click "OK" to go back to the event driven scheduling.

As the maximum liquid capacity limit at the separator has been modified, it will also be
necessary to modify the condition which triggers the well opening: the wells should be open
when the liquid rate at the separator falls below 138000 STB/d and not anymore when it falls
below 118000 STB/d.
This has to be modified in the "PostSolve" section of the event driven scheduling, as illustrated
below.
765
RESOLVE
Once this is done, click "OK" to go back to the scenario manager screen, as illustrated below.
Examples Guide
766
The three scenarios are now setup: the model is now ready to be run. Click "OK" to go back to
the main RESOLVE screen to do so.
767
RESOLVE
The third scenario will be created following thesame method used to create the second
scenario. Click on "Add current schedule" and label the scenario as "Event drilling schedule 2".
However, we shall edit this scenario and modify the separator liquid constraint to 140,000stb/
day. This is done by clicking on the scenario itself and then Edit as shown below.
This calls up the event driven scheduling section. The action to set up liquid constraint is found
Examples Guide
768
on the "Start" schedule. Click on Start an then action to change the separator liquid constraint to
140,000stb/day.
769
RESOLVE
Click OK and go back to the main screen.

Step 3 Objective:
Running the scenarios
The scenarios are now setup and the simulation is ready to be run.
This is achieved by clicking on the
icon or alternatively select Run| Run Scenario(s).
The interface below appears where the user can selectively choose which scenarios to run.
Highlight the three scenarios and select OK to launch the run.
Examples Guide
770
Note that "Use clustering" can be selected to run different models on clusters of machines.
See the "Running scenarios on a cluster" section for further information.
Once the run begins, the interface below appears showing the progress run of each scenario.
At the end of the runs, the scenario progress interface will be as shown below.
771
RESOLVE
The three scenarios have been run: it is now possible to analyse and compare the result.
3.4.4.5 GAP - REVEAL Scenario Management: Step 4

Step 4 Objective:
Analysing and comparing the scenarios results
For each scenario that is being run, RESOLVE will automatically save the results. Once all the
scenarios have been run, it will be possible to access these results by going to the Results |
View Scenario Results (Table) to see the scenarios results in TABULAR form or to the
Results | View Scenario Plots to see the scenario results in PLOT form.
In this case, it is for instance possible to compare the liquid produced at the separator for each
of the scenarios.
This can be done by going to Results | View Scenario Plots.
Examples Guide
772
Select the "Sep1" item for the list. A list of variables associated with the separator will be
displayed at the bottom left hand corner of the screen, as displayed below.
773
RESOLVE
Select the "Liquid Produced" variable and click on the
icon.
Select the "Sep1" item for the three scenarios by using the tab on the right hand side of the
screen.
The following plot will be displayed, illustrating the liquid produced at the separator for the three
scenarios.
Examples Guide
774
It is possible to notice that the liquid production for the base case scenario is much higher than
the liquid production for both capacity limited scenarios at the beginning of the run, but then the
production decline is faster.
The plateau rate for the 140,000 STB/d liquid production can only be maintained for about a
year, whereas it can be maintained for nearly 3 years in the 120,000 STB/d scenario.
Using the same method, it is possible to plot the gas and water produced for the three
scenarios:
775
RESOLVE
Based on these results, the user can decide the most suitable case.
Go to Step 3
Examples Guide
776
3.4.5 Example 2.5: GAP - Eclipse Connection

3.4.5.1 GAP-Eclipse : Overview
The objective of this section is to demonstrate how to setup a connection between GAP
production, water and gas injection models and a reservoir simulation model setup in Eclipse.
In order to do so, a numerical simulation reservoir model has been setup in Eclipse as well as
surface network models for the production and the water and gas injection system.
The first objective is to dynamically link the reservoir and surface network models.
the second objective is to understand, based on the full-field production and injection
capabilities, what are the different behaviors that are going to be observed during the field life.
RESOLVE OpenServer
1
1
GAP
1
PROSPER
1
MBAL
1
Eclipse
1
OpenEclipse
1
Eclipse, REVEAL and GAP are registered.
been registered.
It is important as well that Eclipse is configured to run through RESOLVE using either PVM or
MPI. The example also assumes that Eclipse will run on the same machine as RESOLVE is
running.
It can be extended to run Eclipse on a remote PC or machine of another architecture.
More information on the configuration of Eclipse can be found in the "ECLCONFIG.EXE"
section.
777
RESOLVE
3. Files Locations
\Example_2_5
Experts\IPM
This folder contains a file "GAP_Eclipse.rsa" which is a "RESOLVE archive file" that contains
the RESOLVE file, Eclipse file, GAP file and other associated files required to go through the
user's choice.
Go to Step 1
3.4.5.2 GAP-Eclipse : Step 1

Step 1 Objective:
Examples Guide
778
Now is a good time to save the file using File | Save As..., and enter a file name (e.g. GAPEclipse.rsl).
Go to Step 2
Step 2 Objective:
Create an Eclipse instance in the RESOLVE model
The next step is to create an Eclipse instance in the RESOLVE model and load it in the main
RESOLVE screen.
If PVM is used, it is essential that the PVM instance has been started prior to this
step being performed.
From the main menu, go to System | Create instance or select the
icon.
779
RESOLVE
From the resulting menu, select "Eclipse" (this is the E100 black-oil Eclipse driver).
Click on the main screen where the Eclipse icon is to be located, and give the case a label (say,
"Reservoir").
Double-click on the Eclipse icon - the following screen will appear:
For the file name, browse to the file "inject-200.data" as shown above.
Note that from this screen it is possible to select a remote host on which Eclipse can be run.
This is especially useful in cases where several reservoir models have to be run: in this case it
Examples Guide
780
will probably be more efficient to run these simulations in parallel.

Next click on "Start", Eclipse will start and load the required case. It will then query the case for
its sources and sinks (wells) and will display these on the screen as shown below. The icons can
be moved by selecting the "Move" icon on the toolbar (
required positions.
) and then dragging them to the
We see that we have two producers, a water injector, and a gas injector.
The type of the well (which is obtained from the query of Eclipse) can be found by doubleclicking on the separate icons.

Step 3 Objective:
Create the GAP production instance in the RESOLVE model
Label the created GAP case "Network" and browse for the model "production.GAP".
781
RESOLVE
Note again that it is possible to start GAP on a remote networked PC. Further information on
running remote instances of the IPM tools can be found in the "Running IPM instances on a
remote PC" section.
Under snapshot mode section, select "Always save forecast snapshots".This saves a
snapshot of each prediction timestep in GAP, allowing the user to reload a copy of each
snapshot and analyse the performance at that date - this can be particularly useful for
GAP file contains a production, water injection and gas injection models. In the production
model, two production wells, prod1 and prod2 will be found. These are the same wells as were
identified from the Eclipse case. One can look at the GAP interface (i.e. the GAP model will be
open on the windows taskbar) to confirm the contents of the GAP file by clicking on Window |
Examples Guide
782
Tile vertically from the main GAP menu.
Step 4 Objective:
Connect the production wells from the Eclipse model to the production wells from the
GAP production network model.
At this stage we connect the applications together graphically.
icon.
Connect the prod1 icon in Eclipse to prod1 in GAP by clicking into the first icon and dragging
the connection to the second.
Repeat this for prod2.
783
RESOLVE
The following structure is obtained when the connections are made:
Note that it is possible to make the connections using the "Connection wizard".
This is obtained by invoking Edit System | Connection Wizard under the main menu.
Step 5 Objective:
Load the GAP Water and Gas Injection models and connect the wells to their
counterparts in Eclipse
In this example the water and gas injection systems are to be controlled in GAP.
The original GAP file that was loaded earlier contains an associated water injection system and
an associated gas injection system; thus it is possible to create two instances for the GAP water
Examples Guide
784
and gas injection systems in the RESOLVE model.

The procedure to do so is illustrated below for the water injection model.
Create a new GAP instance in RESOLVE as done earlier. Label it "watinj".
Double-click on the icon to obtain the data entry screen:
For the filename, enter the same GAP production system model. This is because the
injection system is associated (i.e. or linked) with the production system in one GAP file.
Consequently, the "associated water injection" option has to be selected from the drop-down
menu for the system.
An advantage of this is that it allows to model production and injection systems of GAP
785
RESOLVE
simultaneously using only a single GAP license.

Press OK and the injection system well (i.e. and injection manifold) will be displayed.
Repeat the process for the gas injection system.
This time the "system" is an associated gas injection system. Label the model "gasinj".
After this, connect the GAP and Eclipse icons together appropriately.

Step 6 Objective:
Setup the Eclipse model options
Before the simulation is run, some further changes can be made to the configuration of the
Eclipse link.
Examples Guide
786
IPR generation options and well control options in Eclipse

One of the most important elements to consider when establishing a link between a reservoir
simulation model and a surface network model is the way the well inflow performance curves, or
IPRs that are passed from the reservoir model to the surface network model and determine part
of the well performance, are calculated.
A detailed description of the different techniques used to determine these IPRs, along with their
respective advantages and disadvantages, can be found in the "IPR Generation Options"
section.
To select these options, double-click on the Eclipse icon to view the Eclipse data entry screen.
Go to the "control data" tab.
787
RESOLVE
The Inflow performance type should be set to "Calculated PI (based on drainage)" with the "
scaling" option.
This option requires a pre-calculation to be performed before running the model.
Click on "Options" and then "calculate" to perform the pre-run calculations required for this
method.
Examples Guide
The calculation will be performed and the results will be as shown below:
788
789
RESOLVE
Click on "OK" and "OK" again to return to the "Load and edit simulation model" interface.
When GAP solves/optimises its system, RESOLVE will return the result as an operating point for
the well on the inflow relation that Eclipse passed for that well, i.e. a BHP, phase rates, and a
THP. Eclipse will then have to control that well with a fixed boundary condition for the duration of
the next timestep. The user can select which boundary condition should be used: either fixed
rate, BHP or THP. The default settings illustrated below show that the wells in this Eclipse model
are controlled between GAP solves with a fixed rate.
Examples Guide
790
Group controls in Eclipse

From this screen there is also the option to clear or respect the Eclipse model group controls.
In general, group controls should be removed from Eclipse data files as they could interfere with
the controlling data that is coming from GAP. However, there are certain cases where these
controls might have to be respected.
One example is where Eclipse is operating a voidage replacement strategy in its injection wells
which are not connected to GAP through RESOLVE. In this case Eclipse might be allowed to
control the injection by group control while the production is controlled through GAP/RESOLVE.
Clicking on "group controls" at the lower left hand corner calls up the interface below.
791
RESOLVE
By default, the group controls established in this model are not respected. Should the user
decide to respect one of the groups controls, this group control would have to be selected by
clicking on the tick box next to its name.
There are other options that may be useful on these screens.
Further information can be found in the "Loading and Editing an Eclipse case" section.
Click "OK" and "OK" again to return to the main screen.
Publish ECLIPSE results.
It is useful to publish the results from the summary section of Eclipse into RESOLVE. This is
done by double-clicking on the icon. Go to the "Miscellaneous" tab and select "Plot summary
vectors in RESOLVE" as shown below.
Examples Guide
Step 7 Objective:
Setup the forecast schedule
RESOLVE scheduling is divided into two parts:
792
793
RESOLVE

Advanced scheduling - where using a script a condition-based scheduling can be
implemented.
For the purposes of this example, we shall make use of the basic scheduling only.
Invoke the schedule screen from the main menu using Schedule | Forecast data.
on the "Select from client modules" button.
This will display a screen allowing to select the required start date from a list of the various
model start dates.
Examples Guide
794
The timestep and schedule duration are also entered here as shown. Enter the data in the
screen shot above.
Here we will synchronise GAP and ECLIPSE every 1 week until the schedule completes on
1/1/2001.
Step 8 Objective:
Publish the GAP variables to report in the RESOLVE results section
limited to the pressure and black oil phase rates. In this example, we wish to report all the
variables for the wells and separator in the GAP production model as well as the injection wells
and manifold in the GAP injection models.
RESOLVE can automatically build a list of the GAP variables available and that can be reported
directly through the RESOLVE interface.
To obtain that list, right-click on the GAP production icon and select the "Output Variables"
option.
795
RESOLVE
instance prod1) and also the variables associated with it that needs to be reported. (e.g. oil
rate).
We wish to report all variables for each well, therefore select prod1 and use the "Add From List
" button to report all its variables.
Once all the variables for all the four wells and separator (Sep1) have been selected, the
Examples Guide
796
Click OK and do the same for the water and the gas injection model. Output all variables for the
injection wells and manifolds (IM1) and proceed to the next step.
3.4.5.10GAP-Eclipse : Step 9
Step 8 Objective:
797
RESOLVE

icon.


icon.
Once the forecast has been started, Eclipse will perform an equilibration calculation. If it was
setup to load a restart file it will do this instead.
points will then be returned to Eclipse ready to take the first week"s timestep. Before this, the
RESOLVE forecast enters "pause" mode.
connection icon:
Examples Guide

798
RESOLVE will complete the run to 2001 taking weekly timesteps.

Note that some extra timesteps are inserted. These are put in to coordinate with the reporting
dates specified in the Eclipse deck.
It will also coordinate with any events specified in Eclipse e.g. wells being turned on or off.
3.4.5.11GAp-Eclipse : Step 10
Step 10 Objective:
799
RESOLVE
clicking on the
icon.
For this specific case, we want to first analyse the oil that has been produced for the entire
production system as well as for each individual well.
To do so, go to Results | View Forecast Plots, or by click on the
icon.
All the nodes of the RESOLVE model are listed in the left hand side of the screen. Select the
Examples Guide
800
"Sep1" node.
Once this is done, a list of the variables associated with this node will appear at the bottom of
the screen, as illustrated below.
Select the variable to be viewed, here oil produced and click on the
button.
The following screen will be displayed, when one can define which nodes have to be included in
the oil produced plot. Here we select the separator node as well as all the wells nodes.
Click "OK" and the following plot is displayed, illustrating the oil production at separator level
and for each individual well.
801
RESOLVE
It is possible to notice that both wells produce for a time before they stop abruptly. This can be
explained by examining the GOR and noting that there is a GOR abandonment constraint of
5000 scf/STB set in GAP. This abandonment constraint could equally be put in the Eclipse data
deck.
The injectors results can also be looked at. It is possible to notice that the injectivity of both
injectors decreases after the production has stopped and the reservoir pressure starts to rise.
Examples Guide
802
In addition, one can plot the Eclipse results that were published through RESOLVE. These can
be seen under the folder "Eclipse" under RESOLVE nodes.
Go to Step 9
3.5
Example Section 3: Connection to Process Modeling

Tools
3.5.1 Example 3.1: GAP - Hysys Connection

3.5.1.1 GAP-Hysys : Overview
The objective of this section is to demonstrate how to setup a connection between a GAP
production model and a plant simulation model setup in Hysys.
In order to do so, a plant simulation model has been setup as well as a surface network model
for the production system. Reservoir behavior is integrated in this model through the use of a
material balance model.
The first objective is to dynamically link the plant and surface network models.
803
RESOLVE
the second objective is to understand, based on the full-field production capabilities, what are
the different behaviors that are going to be observed at the plant level during the field life.
RESOLVE
1
OpenServer
1
Hysys
1
GAP
1
PROSPER
1
MBAL
1
both Hysys and GAP are registered.
been registered.
3. Files Locations
\Example_3_1
Experts\IPM
This folder contains a file "GAP_Hysys.rsa" which is a "RESOLVE archive file" that contains the
RESOLVE file, Hysys file, GAP file and other associated files required to go through the
user"s choice.
Go to Step 1
3.5.1.2 GAP-Hysys : Step 1
Step 1 Objective:
Examples Guide
804
Now is a good time to save the file using File | Save As..., and enter a file name (e.g. GAPREVEAL.rsl).
Go to Step 2
Step 2 Objective:
Create a Hysys instance in the RESOLVE model
The next step is to create instances of the various applications that we wish to connect through
RESOLVE. We shall load the instances on the main screen.
icon.
From the resulting menu, select "Hysys". The cursor, when held over the main screen, will
change to indicate that an instance of the application can be made.
Click on the main screen where the Hysys icon is to be located, and accept the default label
805
RESOLVE
("Hysys").
Double-click on the Hysys icon - the following screen will appear:
For the file name, browse to the file "Case1.hsc" as shown above.
Select the "Transfer upstream composition to Hysys feed stream" option in the "
Miscellaneous options" section above. This enables to specify that the composition at the
output of the GAP model will be passed to the input of the Hysys model. This is only possible
when the GAP model used is either setup to be using a fully compositional PVT description or a
compositional tracking PVT definition.
Note that from this screen it is possible to select a remote host on which Hysys can be run.
Further information on running remote instances of the IPM tools can be found in the "Running
IPM instances on a remote PC" section.
When OK is selected, Hysys will start and load the required case.
When doing so, the following screen might appear:
Examples Guide
806
This is an Hysys confirmation message and can be ignored - This message can be turned off in
the preferences section of Hysys.
It will then query the case for its sources and sinks (input and output feeds) and will display these
on the screen as shown below.
) and then dragging
We see that we have two input feeds and several output feeds.
The inputs and outputs displayed here can be cross-checked with the actual Hysys case.
807
RESOLVE
The Hysys interface can be seen at the bottom of the screen with "Case1.hsc" loaded into it.
Step 3 Objective:
Create the GAP production instance in the RESOLVE model
Browse for the GAP production model titled "model.GAP". Also select the feature "Always
save forecast snapshots". This saves a snapshot of each prediction timestep in GAP,
allowing the user to reload a copy of each snapshot and analyse the performance at that date this can be particularly useful for troubleshooting purposes.
Examples Guide
808
Note that it is possible to start GAP on a remote networked PC. Further information on running
remote instances of the IPM tools can be found in the "Running IPM instances on a remote PC"
section.
GAP production model contains three wells and a separator. It is possible to check the GAP
model (i.e. The GAP model will be open on the windows taskbar) to confirm the contents of the
GAP file.
809
RESOLVE
Examples Guide
810
Step 4 Objective:
Establish the connections between the GAP and the Hysys models
icon.
Connect the Sep1 icon in GAP to the Feed1 icon in Hysys by clicking into the first icon and
dragging the connection to the second.
811
RESOLVE
Examples Guide
812
Note that it is also possible to make the connections using the "Connection wizard". This is
obtained by invoking Edit System | Connection Wizard under the main menu and is
especially useful when dealing with a large number of connections.
Step 5 Objective:
The next step is to select some variables from the Hysys and GAP models that will be added to
the RESOLVE reporting system.
To do this for the Hysys model, right click on the Hysys icon in RESOLVE and select "
Output variables". A progress bar will be displayed: this is RESOLVE querying the plant
model for all the output variables that can be exported to RESOLVE.
Once this procedure is ended, a screen similar to the following will be displayed:
813
RESOLVE
The left hand list is a hierarchical list of all the variables that can be queried in Hysys. They are
ordered at the top level by flowsheet: in this example, there are two flowsheets ("Main" and
"COL1") where "Main" is the main flowsheet and "COL1" is the Depropanizer column. Below
this is a list of streams (marked with a coloured arrow, as shown) and equipment items. When
one of these is opened up (as with "SalesGas", above) a list of variables that pertain to that item
will be displayed. These are the variables that can be added to the RESOLVE reporting system.
To add a variable, highlight the variable on the left and press the "Add" button. Some variables
are arrays, most usually over components (e.g. the component molar fraction array in the screen
capture above). If the user select this variable, all the array variables will be passed across at
once.
In this example, we have chosen to monitor the MolarFlow and MassFlow variables of the
SalesGas stream.
To do so for the GAP model, right-click on the GAP production icon and select the "Output
Variables" option.
Examples Guide
814
instance W1) and also the variables associated with it that needs to be reported. (e.g. oil rate).
We wish to report all variables for each well, therefore select W1 and use the "Add From List"
button to report all its variables.
Once all the variables for all the three wells and separator (Sep1) have been selected, the
815
RESOLVE
All the variables listed in the right hand side column will therefore be added to the list of
variables reported in RESOLVE.
Step 6 Objective:
Examples Guide
816

817
RESOLVE
Here GAP and Hysys models will be synchronised every 2 weeks until the schedule completes
on 1/1/2011.
Step 7 Objective:
Select whether the client modules have to be reloaded each time a forecast is
performed.
It is sometimes useful to have RESOLVE reload the files at the start of the run. In some cases the
forecasts may leave wells masked or separator pressures changed in which case when a new
run is started it will be needed to reload the original file.
This option is the default in RESOLVE and is not necessary for this example, as no changes are
performed on the model. Moreover, having it selected will lead to some time being spend
reloading both the GAP and Hysys model at the beginning of each forecast that is run.
The user can decide to change it, by going to Options | System options to display the
following screen. The setting can be changed in the "Run Initialisation" section.
Examples Guide
Step 8 Objective:
icon.
818
819
RESOLVE


icon.
To start, force RESOLVE to do a single timestep. Do this by pressing the "single step" button (
).
The first action done is the initialisation of both modules. In the case of GAP, this means loading
the tank data and initialising it (i.e. running a history if necessary until the start date of the
forecast is reached). In the case of Hysys, no initialisation is necessary.
RESOLVE will also obtain the composition names from GAP and Hysys. As these can be
different (i.e. "C1" in GAP may be called "Methane" in Hysys) it is important to tell RESOLVE
which composition name refers to which.
The following "Composition Tables" screen will be displayed.
Examples Guide
820
The list on the left is a composition from GAP; that on the right is a composition from Hysys. In
this case the composition names align already so it is possible to just press "Add All" followed
by OK.
GAP will then perform a solve and optimisation of the production system with the initial tank
data. The production will be taken from the separator and passed to Hysys, which will then solve
its system. GAP will then be ready to take another timestep; but before this the RESOLVE
forecast enters "pause" mode.
The results of the run for the first timestep can be checked by holding the mouse over a
connection icon:
821
RESOLVE

RESOLVE will complete the run to 2011 taking two-weekly timesteps.

Note that an extra timestep is inserted on 01/01/2010 to coincide with a schedule event in GAP.
This event is the lowering of the separator pressure to 3600 psig.
Examples Guide
822
3.5.1.10GAP-Hysys : Step 9
Step 9 Objective:
Analyse the results
clicking on the
icon.
Start by plotting the rates from the separator.
Select the "Sep1" item in the left hand side list and the "Oil Produced" in the bottom left hand
side corner. Select the
button.
The following screen will appear:
823
RESOLVE
Select the "Sep1" node and click "OK". The oil produced at the separator will be plotted as
illustrated below.
Examples Guide
824
The same procedure can be used to add the "Gas Produced" for "Sep1", as illustrated below.
It will be possible to notice the increase in production due to the reduction of the separator
pressure in 1/7/2010.
Go to Step 8.
825
RESOLVE
3.5.2 Example 3.2: GAP - Hysys Connection with Script

3.5.2.1 GAP-Hysys-Scripted : Overview
The objective of this section is to demonstrate how to control events in a surface network - plant
simulation coupled model by using the RESOLVE internal scripting capability.
field under different production conditions.
The main objective of the script if to vary the separator pressure applied to the GAP model in
order to meet a constraint in the Hysys model.
The aim is to provide an overview of scripting functionality; in practical terms it is not necessary
to write scripts for this kind of task as the "RESOLVE optimiser"can be used to do this.
In order to meet the constraint it will be required to carry out a series of iterations in which we
take the results from GAP and look for the response from Hysys.
At each iteration we will vary the GAP separator pressure to try and meet the Hysys constraint.
The constraint will be the total molar flow at one of the internal streams in the plant model.
RESOLVE
1
OpenServer
1
Hysys
1
GAP
1
PROSPER
1
MBAL
1
Examples Guide
826
been registered.
3. Files Locations
\Example_3_2
Experts\IPM
This folder contains a file "GAP_Hysys_Scripted.rsa" which is a "RESOLVE archive file" that
contains the RESOLVE file, Hysys file, GAP file and other associated files required to go through
the example. The archive file needs to be extracted either in the current location or a location of
the user"s choice.
Go to Step 1
3.5.2.2 GAP-Hysys-Scripted : Step 1
Step 1 Objective:
script
Start RESOLVE and go to File | Archive | Extract. Select the GAP_Hysys_Scripted_Start.rsa
file and extract its contents into a selected location. When the "Open Master File?" question is
prompted, select "Yes".
This is important in this case as the script is going to be used to modify the client
application models, so we need to ensure that we are starting from the same initial
state every time we run the forecast.
827
RESOLVE
Save the model as a new file: GAP_Hysys_Scripted_Final.rsl).

Go to Step 2
Step 2 Objective:
Write the internal RESOLVE script
The scripting must either be programmed from scratch or imported from another model. In this
case a script is provided to implement the required functionality.
Go to Script | Import and browse to the file "script.rsc" located in the "C:\Program
Files\Petroleum Experts\IPM 7.5\Samples\Resolve\Example_Section_3\Example_3_2"
directory of the IPM tools. The script that has just be imported can be viewed by going to Script
| Edit.
Examples Guide
828
The script is implemented in a language called "Visual Basic Script" (VBS).

For most purposes this is the same as the language used in Excel (VBA). The main difference
is that it is not necessary to "type" variabes, e.g. the VBA line:
Dim t As Object
would not be necessary in VBS. It is sometimes useful to be able to declare global variables (i.e.
variables that keep their values for the duration of the forecast).
As it is possible to see in the example script, it is possible to do this in the "declarations"
section (see below) with lines of the sort:
Dim pres(10) - Declares an array of 10 elements
Dim t - Declares a variable
v = 100 - Declares a variable and assigns it the value of "100"
The example script is split into two sections: "Declarations" and "PostSolve".
Declarations
Most scripts will contain a "declarations" section such as the one above. In this case we are
declaring global arrays that will be used to store rates from Hysys and pressures from GAP, as
well as a global variable (qtarg) that represents the target rate and another (tol) which represents
the tolerance on the solution. The variable "index" will be used as a global counter.
PostSolve
"PostSolve" is one of the functions that is called from RESOLVE during the run. More information
can be found in the scripting section; briefly, the script functions are:
Start
Finish
PreSolve
solved
PostSolve
Called at the start of the forecast (for initialisation purposes)

Called at the end of the forecast (for cleanup purposes)
Called before every group of models that can be solved simultaneously is
Called after every group of models that can be solved simultaneously is
829
RESOLVE
solved
In this case we are examining the results of the system solve and adjusting the model
parameters to obtain a new result, hence we implement the "PostSolve" function.
Going through the script step by step, we have:

1. "PostSolve" is called after the solve for each simultaneously solved group. Each time
it is called the argument (ModuleList) contains a string which lists the models that have
just been solved. In this case the first time PostSolve is called the ModuleList will
contain the string "GAP". The second time it will contain the string "Hysys". We are
interested only when the entire system is solved, i.e. after Hysys is solved. This piece of
code checks the ModuleList string for the sub-string "Hysys".
2. This code uses an OpenServer call to retrieve the oil rate from GAP. The "logmsg"
outputs a string to the RESOLVE log window to inform the user of the oil rate just
Examples Guide
830
obtained.
3. This uses an OpenServer call to obtain the current separator pressure from GAP. It
also obtains the molar flow from the "SalesGas" stream in the Hysys plant model.
These values are then output to the log window.
4. This checks for convergence on the target SalesGas rate (qtarg). If convergence is
achieved we just exit from the routine. If it is not achieved we check the current number
of iterations to see if we have exceeded the maximum number (10), and if we have we
exit the routine.
5. Here we calculate a new separator pressure for GAP to meet the target. If this is the
first time through we just take a pressure difference of 20 psi to see what happens to
the SalesGas rate. If we have at least two previous results we use the gradient of the
pressure against the rate to calculate a new test value for the separator pressure.
6. This sets the new separator pressure as calculated in part (5). We then call
ReDoSolve() to force RESOLVE to start the solve process again from the beginning to
calculate the new SalesGas rate with the calculated separator pressure. This is the
iteration loop.
Step 3 Objective:
Debug the internal RESOLVE script
This is an optional step which the user can perform if a debugger is installed on the PC being
used.
Debugger programs can be downloaded off the internet. If in any doubts please contact
Petroleum Experts for more information.
From the script editor, click on the line that reads "Call logmsg("Output Qoil = " + cstr(Qoil))" and
press F9 to insert a breakpoint. Another option is to use right-click feature. Exit from the script.
831
RESOLVE
The function can be tested (without running the forecast) by going to Script | Execute function |
PostSolve. A screen will be presented asking which ModuleList the function is to be passed to:
select "Hysys" from the drop down list and press OK.
Depending on the debugger a series of messages might be received asking if one would like to
step into the script. Once in the script it will be possible to perform the usual debugging
functions, e.g. stepping over lines of code, examining the values of variables, setting new
breakpoints, and so on.
After this is finished, go back to the script editor in RESOLVE and remove the breakpoint.
Step 4 Objective:
Run the forecast and Analyse the results
RESOLVE will complete the run to 2010 taking 2 weeks timesteps and running through the
internal script defined at every timestep.
When the forecast is run the first thing that will happen is that the GAP and Hysys models will be
reloaded. This might take a few seconds.
Once running, it will be possible to see the iterations over the system being taken as in the
following screenshot:
Examples Guide
832
While the forecast is running it is possible to view the results in the usual manner.
In particular, the pressure in the input feed ("Feed1") and the molar flow in the SalesGas stream
can be monitored. It should be possible to see that the input feed pressure falling as the GAP
reservoir declines and the SalesGas molar flow staying constant at 230 kgmole/hr (withing the
tolerance of plus/minus 1 kgmole/hr).
To complete the exercise these results should be saved as a new results stream by clicking on
the "Save" button of the results screen and giving the results a label (e.g. "scripted"). One can
then perform the run without the script: click "Done" on the results screen and disable the script
by clicking on Script | Enable script (the user will note that the script is currently enabled from
the tick mark next to the menu item).
The results with and without the script can be displayed side by side and should look similar to
the following screen capture.
833
RESOLVE
Examples Guide
834
Go to Step 3
3.5.3 Example 3.3.: GAP - Hysys Connection with Optimisation (1)

3.5.3.1 GAP-Hysys-Optimisation1 : Overview
The objective of this section is to demonstrate how to optimise a surface network - plant
simulation coupled model by using the RESOLVE optimisation capabilities.
The main objective of the optimisation problem is to vary the separator pressure applied to the
GAP model in order to meet a constraint in the Hysys model.
The constraint will be the total molar flow at one of the internal streams in the plant model.
RESOLVE
1
OpenServer
1
Hysys
1
GAP
1
PROSPER
1
MBAL
1
been registered.
3. Files Locations
\Example_3_3
Experts\IPM
835
RESOLVE
This folder contains a file "GAP_Hysys_Optimisation1.rsa" which is a "RESOLVE archive file"

that contains the RESOLVE file, Hysys file, GAP file and other associated files required to go
through the example. The archive file needs to be extracted either in the current location or a
location of the user"s choice.
Go to Step 1
3.5.3.2 GAP-Hysys-Optimisation1 : Step 1
Step 1 Objective:
Enable the optimisation and set the constraint in Hysys
It is first necessary to enable the optimisation. Do this from the Options | System options
menu item and change the "Forecast mode" to "Full forecast with global optimisation", as
illustrated below.
Now the optimisation controls can be setup by going to the "Optimisation | Setup" menu item.
Examples Guide
836
In this case the idea is to meet a constraint in Hysys by varying the separator pressure in GAP. i.
e. the objective function is in Hysys and control is in GAP.
As there is only one control variable there is no means to maximise a different objective function
to the constraint: hence in this case we will set the same objective function to the constraint that
is to be met.
To do this, click the "Edit" button next to the "Objective Function" panel on the Optimisation
setup screen as shown below:
837
RESOLVE
After a few moments, an interface appears and by ticking the "Set objective function" box, the
screen above will be displayed.
A list of all the streams, equipment, and associated variables is displayed.
From this, the molar flow of the SalesGas stream can be selected as shown. Note that this is the
same as the constraint that was set up in the script.
Select the "Maximise" option: the objective function associated with the optimisation will
therefore be to maximise the molar flow at the sales gas stream of the Hysys model.
We can also set the constraint from the "Constraints" tab of the same screen:
Examples Guide
838
Locate the variable in the list, input the constraint (230 kgmole/h) and click on the "Add" button
to add the constraint to the list. Note that several constraints can be added by using this screen.
When this has been done, click on the "OK" button. This enables to go back to the optimisation
screen, where the "objective function" and "constraints" panels will be highlighted.
Go to Step 2
Step 2 Objective:
Set the control parameters in the GAP model
In this step we set up the control variable that is to be used in the optimisation procedure.
This control variable is the separator pressure of the GAP model.
Go to the "GAP" tab of the optimiser setup screen and under controls section click on the "
Controls" button.
839
RESOLVE
After a few moments, following screen will be displayed:
The separator pressure can be added to the list of controls by clicking on the "Vary separator
pressure" button as shown. When this is done, the separator pressure will be added to the
table above. The left hand column is the name of the control and will be used in the reporting
only.
The next column is the GAP OpenServer string that represents the control variable. In general
control variables in GAP are represented by their OpenServer strings (i.e. this means that, in
theory, any variable in GAP can be used as a control variable): in this case the OpenServer
variable that represents the separator pressure is displayed in the table.
The next column is the unit for the control variable. This is picked up automatically by RESOLVE
from the OpenServer string. If the OpenServer string is not recognised as a valid string then
Examples Guide
840
this column will contain an error.

The final two columns are the bounds within which the variable can vary. It is not obligatory to
enter anything here, although it is sometimes a good idea if the system is lightly constrained. By
default the current separator pressure is set as a lower bound. In the example above, we are
allowing the separator pressure to vary between 1500 and 4000 psig.
When the user have finished, click on the "OK" button. This will enable to return to the setup
screen and the "controls" panel for the GAP tab will be highlighted.
Step 3 Objective:
Run the forecast
To illustrate the optimisation process, first run a single step of the forecast (click on the "
button).
"
A series of iterations are going to be taken to meet the constraint. An additional screen (i.e.
optimisation progress) comes up during the run.
At the end of the timestep the screen will have the following appearance:
841
RESOLVE
In the screenshot above, the "function results" tab is displayed. Along the top the iteration
number is displayed : we see here that four iterations have been taken and the constraint was
met (i.e. within tolerance) on the fourth step.
It is also possible to look at the separator pressure set at each iteration by looking at the "
control results" tab.
The simulation can now be run to the end ("
timestep to show the iterations that are taken.
Step 4 Objective:
Analyse the results
"). The above table will be displayed at each
Examples Guide
842

clicking on the
icon.
It is possible to plot the production at the separator as described below:
Select the "Sep1" item in the left hand side list and the "Oil Produced" in the bottom left hand
side corner. Select the
button.
843
RESOLVE
Select the "Sep1" node and click "OK". The oil produced at the separator will be plotted as
illustrated below.
Examples Guide
844
It is also possible to plot the molar flow in the Sales Gas stream from the Hysys model using the
same technique: from this plot, it is possible to notice that the constraint specified in the
optimisation setup has been respected.
Go to Step 3
845
RESOLVE
3.5.4 Example 3.4.: GAP - Hysys Connection with Optimisation (2)

3.5.4.1 GAP-Hysys-Optimisation2 : Overview
The objective of this section is to demonstrate how to optimise a surface network - plant
simulation coupled model by using the RESOLVE optimisation capabilities.
The main objective of the optimisation problem is to maximise the molar flow at the "SalesGas"
stream of the Hysys model while respecting constraints in both the GAP and Hysys models.
The optimisation problem will be defined as follow:
Objective function
Maximise the molar flow of the SalesGas stream
Constraints
In GAP: as for the standalone GAP model - the gas rate at the separator < 9 MMscf/
day
In Hysys: the RebDuty energy flow < 30 GJ/h
Controls
In GAP: as for the standalone GAP model - the wellhead choke settings
In Hysys: the pressure of the "To Reboiler" stream
Once this is done, the model will be modified to include a connection to an Excel spreadsheet
that calculate the economics of the system - the optimisation objective function will then be
modified so that the optimiser maximise the revenue from the system.
RESOLVE OpenServer
1
1
Hysys
1
Excel
1
GAP
1
PROSPER
1
MBAL
1
Examples Guide
846
been registered.
3. Files Locations
\Example_3_4
Experts\IPM
This folder contains a file "GAP_Hysys_Optimisation2.rsa" which is a "RESOLVE archive file"

that contains the RESOLVE file, Hysys file, GAP file and other associated files required to go
through the example. The archive file needs to be extracted either in the current location or a
location of the user"s choice.
Go to Step 1
Step 1 Objective:
Setup the RESOLVE model
The steps required to create and connect models in RESOLVE are assumed to be known.
If there is any doubt please consult one of the earlier step-by-step guides.
Perform the following steps:
Extract the RESOLVE archive file Gap_Hysys_Optimised2.rsa located in the C:
\Program
Files\Petroleum
Experts\IPM
7.5
\Samples\Resolve\Example_Section_3\Example_3_4 folder in the IPM installation
directory.
Create a GAP instance in RESOLVE using the simple.GAP GAP file. Keep all the
defaults in the GAP data entry screen.
Create a Hysys instance in RESOLVE using the simple.hsc Hysys model.
In the Hysys data entry screen, under the "Miscellaneous options" section, select the
option to "Pass only black oil properties (hydrocarbons only)".
Keep the other options defaults.
847
RESOLVE
Connect the LP separator in GAP to the "Feed 1" input stream in Hysys.
At the end of these stages, the RESOLVE model will have the following structure:
Examples Guide
848
RESOLVE must also be set to perform a single solve/optimisation from the "System options"
screen.
It is also a good idea to set RESOLVE to not load client modules when performing a run (i.e. to
save time).
This is shown by the snapshot below.
849
RESOLVE
Go to Step 2
Step 2 Objective:
Perform a single pass through the system to obtain initial (i.e. non-optimised) results.
To do so, disable the optimisation from the Optimisation | Enable menu item.
Right click on the Hysys icon and go to "Output variables". After a few moments the screen to
select variables will be presented.
Add the following variables from Hysys to the RESOLVE reporting:
Examples Guide
The model can now be run with the "Run" (
850
) button.
When the screen to map the module compositions together appears, just press "OK", as only
black oil properties are to be passed to Hysys.
At the end of the run, results can be viewed using the "Results | View Forecast Results
(Table)" (
) button.
Step 3 Objective:
Setup the optimisation problem: Objective Function, Constraints and Controls - GAP
Model
851
RESOLVE
The next task is to set up the optimiser controls, constraints, and objective function.
The following will be entered:
Objective function
Maximise the molar flow of the SalesGas stream
Constraints
In GAP: as for the standalone GAP model - the gas rate at the separator < 9 MMscf/
day
In Hysys: the RebDuty energy flow < 30 GJ/h
Controls
In GAP: as for the standalone GAP model - the wellhead choke settings
In Hysys: the pressure of the "To Reboiler" stream
In this step, we will input controls and constraints for the GAP model.
Go to the optimiser setup screen (i.e. from the main menu invoke Optimiser | Setup).
On the GAP tab click on the "Edit" button of the controls section.
Click on the "Add GAP controls" button (highlighted) to automatically add the GAP model
controls to the RESOLVE control list.
The GAP controls are referred to with their OpenServer strings, as shown.
Examples Guide
852
By default the lower bound is at 0 psi (i.e. which is, of course, a hard physical limit). An upper
bound might be added for each control but this is not necessary.
It is now possible to add the constraint.
Go to the "Obj fn/constraints" tab of the same screen.
853
RESOLVE
The constraint(s) can be automatically setup by selecting the equipment and variable to be
constrained in the corresponding drop-down boxes.
Once this is done, the OpenServer string corresponding to this variable is displayed on the
screen. Set the value to 9MMscf/day.
Note that this screen can also be used to enter an objective function. This is also done using an
OpenServer string to refer to the variable in question.
When the user exit this screen it is possible to notice that the "Controls" and "Constraints"
panels are highlighted, as illustrated below.
Examples Guide
854
Step 4 Objective:
Setup the optimisation problem: Objective Function, Constraints and Controls - Hysys
Model
In this step we set up the control, constraint and the objective function for Hysys model specified
in the previous step.
Go to the "Hysys" tab of the optimiser setup screen.
Click on the Edit button of the controls section and the following screen will be displayed:
855
RESOLVE
Browse to the "Pressure" variable of the "To Reboiler" Stream under COL1 as shown and
click on the "Add" button.
We know that the Hysys model is robust with pressures in the range 1000 - 2000 kPa, so we
enter these as bounds on this control.
Again, this is not obligatory.
Now go to the "Constraints" tab of the same screen.
Examples Guide
856
Browse to the "HeatFlow" variable of the "RebDuty" stream as shown and enter the 3e7 kJ/h
constraint before clicking on the "Add" button.
The constraint will appear in the list at the bottom.
Now go to the "Objective function" tab of the same screen.
857
RESOLVE
Browse to the "MolarFlow" variable of the "SalesGas" stream as shown and select the "
Maximise" option.
This will become our objective function.
When the user have finished, click the "OK" button.
Next we will try to speed up the calculation by modifying the constraints tolerance to a value of
0.05.
This is done under Optimisation | Summary. This modification is only for the purposes of this
example.
Examples Guide
Step 5 Objective:
Run the Optimisation Calculation
858
859
RESOLVE
We can now perform the optimisation with the variables and equations we have set up.
First the user may need to re-enable the optimisation by going to the Optimise | Enable menu
item.
Then click the "Run" (
) button.
The iterations are being performed : The constraints, which are violated at first, are brought
down to the required level.
At the end of the run convergence is reached as RESOLVE is not able to improve the objective
function, and a screen similar to the following is displayed:
Here we are looking specifically at the "function results" tab. The columns represent different
iterations of the optimiser, and the results of the objective function and the constraints at each
iteration. We can see that we have a result of 2016 kgmol/h for the molar flow of the SalesGas
stream while meeting the gas rate and duty constraints.
Examples Guide
860
The control results to obtain these function results can be viewed either from the "control
results" tab or the "overall results" tab, as illustrated below.
Before continuing, save these results for comparison with a later run. Click on the "Save
Results stream" button and accept the defaults from the following screen.
Step 6 Objective:
Provide an additional control parameter
In the previous step we varied the wellhead choke settings in GAP to maximise the objective
function.
861
RESOLVE
A common application for the optimiser is also to change the boundary pressure between GAP
and Hysys (i.e. the GAP "separator" pressure) to maximise the objective function.
We will try this in this step.
To do this, right click on the GAP icon and go to "Optimiser Setup", and then go to the "
Controls" tab. Click on the "Vary separator pressure" button.
The entry highlighted above will be created.

It is possible to set bounds on the new control (i.e. as the user could for the other controls). By
default, the lower bound for this control is set to the current separator pressure, and no upper
bound is supplied. As this system is already constrained there is probably no need to set a limit
on this control. In systems that are largely unconstrained it is probably a good idea to set a limit
to prevent the optimiser from searching for a solution in a region of space that is unphysical.
Examples Guide
862
Click on the "OK" button and re-run the optimisation as before.

At the end of the run, click on the "Overall results" tab. It is now possible to bring up the results
from the previous run (i.e. onto the optimisation progress interface) by clicking on the
optimisation results button (
list.
) and double-clicking on the results of the last run in the resulting
A side-by-side comparison of the results can then be performed:
It is possible to see in the latter case that RESOLVE chose to choke the wells less and to
increase the separator pressure. This allowed both constraints to be met, and as the process (i.
e. with the compression) was running more efficiently there was a rise in the objective function
value from 2016 to 2419 kgmol/h.
863
RESOLVE

Step 7 Objective:
Add an Excel instance to the model: Allow optimisation on revenue
In this step we are going to add an instance of Excel into the system to allow us to perform an
optimisation on revenue.
Add an Excel icon above the Hysys icon in RESOLVE in the usual manner.
Double-click on the icon and enter the data in the screenshot below before pressing OK:
Examples Guide
864
The Excel file, Economic.xls, can be found in the same directory as the other data files. The two
inputs that we create here are to receive the oil and gas streams from Hysys.
After this screen has been validated, the Excel icon can be seen on the RESOLVE screen with
two inputs and a single output. The inputs are to be connected to the gas export and the liquid
(oil) production line from Hysys, as shown:
865
RESOLVE
When Excel is used in RESOLVE, the black oil and compositional data will be passed to Excel
and this data will then be placed on the spreadsheet according to rules specified by the user.
In this case, we want the gas from the GasExport line to be placed in a certain cell and the oil
from the LiquidProd line to be placed in another cell to allow Excel to make an instantaneous
calculation of revenue.
Do this by double-clicking on the Excel icon again, got to the input data tab and entering data
as shown in the screenshots below:
Examples Guide
and:
866
867
RESOLVE
Select "OK" and to check that all is working, it is possible to do a single (non-optimised) pass
through the system.
Disable the optimiser from the menu by invoking Optimisation | Enable and unticking the
option, then run the model (
).
The "Composition map" screen will be presented as RESOLVE detects the new Excel module:
OK can be selected without any action.
After the run it will be possible to look into the Excel spreadsheet (i.e. which will be open on the
windows taskbar) and see the oil and gas rates and the resulting revenues.
Examples Guide
868

Step 8 Objective:
Add an Excel instance to the model: Allow optimisation on revenue - Analyse the
results
In this final step, we will optimise the system on the revenue calculated in Excel. This becomes
our objective function.
First of all we need to set the new objective function. Do this by right-clicking on the Excel icon
and going to Optimiser Setup. Tick "Define objective function" and enter the data as shown
on the following screenshot:
869
RESOLVE
This will tell RESOLVE that we plan to optimise on cell B10 of Sheet1. In the Excel spreadsheet it
is possible to see that this is the total revenue calculation based on unit values for oil and gas (i.
e. B1 and B2).
We also need to tell RESOLVE to switch from the previous objective function (i.e. optimisation of
the SalesGas stream molar flow) to the new objective function (i.e. optimisation on revenue). It is
possible to do this from the "Optimiser Summary" screen as illustrated below:
Examples Guide
870
Run the model in the usual way. At the end of the run it is possible to click on the "Overall
Results" tab and observe results similar to the following:
871
RESOLVE
It is possible to note that, while the Duty constraint is met within tolerance the gas rate is well
below its constraint of 9 MMscf/day. This is because the revenue, at the prices entered in Excel,
is dominated by the oil stream and RESOLVE is optimising that part of the system at the
expense of the gas production.
It should now be possible to adjust the relative prices in Excel to observe the changes made to
the result of the optimisation: as the oil price becomes small compared to the gas price the user
should see that the optimisation results become closer to those of the previous run where the
objective function was simply the molar flow in the gas stream.
3.6
Example Section 4: Connection to Excel
Enter topic text here.
Examples Guide
872
3.6.1 Example 4.1: GAP - Excel Connection

3.6.1.1 GAP - EXCEL : Overview
The objective of this section is to demonstrate how to setup a connection between a GAP
production model and a Excel spreadsheet setup to calculate the model economics.
A new discovery has been made - A full field model has been setup in GAP to analyse the
behaviour of this field under different production conditions.
An Excel spreadsheet has been setup separately to derive the revenue provided by this field.
The team of engineers wishes to have a rapid way of analysing the economics of each of the
different development scenarios they assess using the full-filed model. To do so, the Excel
spreadsheet has to be dynamically linked to the GAP network model: at each timestep, the GAP
network model will pass the production to the Excel spreadsheet, enabling for instance
calculations of instantaneous revenue and other user-defined economics indicators.
RESOLVE
1
OpenServer
1
Excel
1
GAP
1
PROSPER
1
MBAL
1
GAP is registered.
been registered.
3. Files Locations
\Example_4_1
Experts\IPM
This folder contains a file "GAP-Excel.rsa" which is a "RESOLVE archive file" that contains the
RESOLVE file, Excel file, GAP file and other associated files required to go through the
873
RESOLVE
user"s choice.
Go to Step 1
3.6.1.2 GAP - EXCEL : Step 1
Step 1 Objective:
Now is a good time to save the file using File | Save As..., and enter a file name (e.g. GAPExcel.rsl).
Examples Guide
874
Go to Step 2
Step 2 Objective:
Create an instance of GAP in the RESOLVE model
The first instance to be loaded will be the GAP instance.
icon. From the
resulting menu, select "GAP".
Click on the main screen where to position the GAP icon, and give the case a label (say,
"Production").
Double-click on the GAP icon - the following screen will appear:
875
RESOLVE
For the file name, browse to the file "Production.gap" as shown above.
Note that from this screen it is possible to select a remote host on which GAP can be run.
When OK is pressed, GAP will start and load the required case.
shown below.
Examples Guide
876
) and then dragging
Note that we have two producers - Well1 and Well 2. Well 1 ESP is Well 1 converted to an ESP
well and scheduled to come on-stream sometime during the prediction run (i.e. at that point in
time, Well1 will be shut off).
Step 3 Objective:
Create an instance of Excel in the RESOLVE model
In this step we are going to add an instance of Excel into the system.
resulting menu, select "Excel".
icon. From the
Label the Excel case created "Economics". Double-click on the icon and browse for the
spreadsheet Economic_Calculation.xls".
877
RESOLVE
The Excel file, Economic_Calculation.xls, can be found in the same directory as the other data
files. There is only one input and one output.
In this example, the input will be used to receive the oil, gas and water rates from the production
separator. The output is there by default and is not being used in this example as we do not
need to pass information from Excel to another model for instance.
After this screen has been validated, the Excel icon can be seen on the RESOLVE screen. The
input icon of Excel is to be connected to the separator icon from the GAP production model as
shown below:
Examples Guide
878
When Excel is used in RESOLVE, it is possible to pass any variables from GAP to the Excel
spreadsheet.
In this specific case, production rates from GAP have to be placed in certain cells of the
spreadsheet used to allow Excel to perform its revenue calculations. A snapshot of the
spreadsheet is shown below. It is important to note that the spreadsheet used in a RESOLVE
model is defined by the user and therefore can achieve any objective / calculation required by
the user.
The spreadsheet used for this example is just used to provide an illustration of what can be
879
RESOLVE
achieved by connecting an Excel spreadsheet to a client module.
As can be seen above, the spreadsheet is divided into two sections:

Solver Section
The values passed in this section will be overwritten at each timestep.
In this specific spreadsheet, the oil, water and gas rate from the separator are passed to
this section of the Excel spreadsheet in order to calculate instantaneous revenue.
Forecast Section
The values passed in this section will NOT be overwritten at each timestep: they will be
stored in the Excel spreadsheet for each timestep and organised either in a vertical or
horizontal order, based on the user specification.
In this specific spreadsheet, the date, oil, water and gas rate from the separator are
passed to this section of the Excel spreadsheet in order to calculate instantaneous and
cumulative revenues.
In order to specify which variables of the GAP model have to be passed to which cell in the Excel
spreadsheet, it will be required to map the GAP variables to the Excel spreadsheet cells.
To do so, double-clicking on the Excel icon and go to the "Input Data" section. This will enable
to map the variables from GAP that are imported in the Excel spreadsheet, as illustrated in the
snapshot below.
The following elements need to be considered when doing so:
In the Input # section, specify the input number considered
In the Sheet name section, select the name of the Excel worksheet within which the
variables have to be imported.
Examples Guide
880
In the Solver section, map the variables that are imported in the Solver section of the
spreadsheet
In the Forecast section, map the variables that are imported in the Forecast section
of the spreadsheet. Select the way the value have to be ordered when reported in the
spreadsheet (i.e. vertically or horizontally).
Once this has been done, all the variables have been mapped and the forecast can be run.

Step 4 Objective:
881
RESOLVE

Examples Guide
882
Enter the start and end date.

Here GAP and Excel will be synchronised every 2 months until the schedule completes on
01/07/2015.

Step 5 Objective:
883
RESOLVE

icon.


icon.
connection icon:

Examples Guide
884

RESOLVE will complete the run to 2015 taking 2 months timesteps.
Step 6 Objective:
Analyse the Results
The objective of this example is to pass the produced oil, gas and water streams from the
production model to a spreadsheet for economic analysis.
GAP performs its network solve and optimisation at each timestep. The phase production rates
are passed to Excel which calculates an instantaneous revenue. This data is then stored in
forecast section and added up at each timestep to obtain cumulative revenue.
When running the model, this can be seen in the Excel spreadsheet, as illustrated below.
Results of the RESOLVE model can be accessed as described in the "Results" section.
885
RESOLVE
Go to Step 5
3.7
Example Section 5: Advanced RESOLVE Examples
Enter topic text here.
3.7.1 Example 5.1: Black Oil Delumping Example

3.7.1.1 Black Oil Delumping Example : Overview
This example illustrates how to setup a direct connection between a black oil reservoir model (i.
e. Eclipse) and a compositional process model (i.e. Hysys) and how the PVT consistency can
be kept within the model using the black oil delumping technique.
RESOLVE
1
Eclipse
1
OpenEclipse
1
Hysys
1
Eclipse and Hysys are registered.
been registered.
3. Files Locations
C:\ProgramFiles\Petroleum
\Example_5_1
Experts\IPM
This folder contains a file "Black_Oil_Delumping.rsa" which is a "RESOLVE archive file" that
contains the RESOLVE file, Eclipse and Hysys files required to go through the example. The
Go to Step 1
Examples Guide
886
3.7.1.2 Black Oil Delumping Example : Step 1

Step 1 Objective:
Now is a good time to save the file using File | Save As..., and enter a file name (e.g.
Black_Oil_Delumping.rsl).
Go to Step 2
887
RESOLVE

Step 2 Objective:
Create an Eclipse instance in the RESOLVE model
The next step is to create an Eclipse instance in the RESOLVE model and load it in the main
RESOLVE screen.
If PVM is used, it is essential that the PVM instance has been started prior to this
step being performed.
icon.
From the resulting menu, select "Eclipse" (this is the E100 black-oil Eclipse driver).
Click on the main screen where the Eclipse icon is to be located, and give the case a label (say,
"Reservoir").
Double-click on the Eclipse icon - the following screen will appear:
Examples Guide
888
Step 3 Objective:
Setup the Eclipse model options
Before the simulation is run, some further changes can be made to the configuration of the
Eclipse link.
889
RESOLVE
In this case, the Eclipse model is directly connected to the process model: there is no surface
network model linked to Eclipse, therefore all the well control and well scheduling is handled by
the Eclipse model itself.
In this case, the IPR generation option selected is not important, as no IPR data is exchanged
with the connected application.
This option can therefore be left to the default setting.
However, two options are available to control the wells that are connected to the process model
(i.e. here the producing wells only):
Control by Eclipse (Sandface)
In this case, the wells are controlled by Eclipse at the sandface level. The vertical lift
performance for each well is calculated in Hysys and the variable that is fixed in the
system is the bottom hole flowing pressure.
This is the option used in this model, as illustrated in the snapshot below.
Control by Eclipse (Tubing Head)
In this case, the wells are controlled by Eclipse at the wellhead level. The vertical lift
performance for each well is calculated by Eclipse and the variable that is fixed in the
system is the well head flowing pressure.
Examples Guide
890
Step 4 Objective:
Create a Hysys instance in the RESOLVE model
icon.
891
RESOLVE
From the resulting menu, select "Hysys". The cursor, when held over the main screen, will
Click on the main screen where the Hysys icon is to be located, and accept the default label
("Hysys").
Double-click on the Hysys icon - the following screen will appear:
Step 5 Objective:
Establish the connections between the Eclipse and the Hysys models
icon.
Connect the Prod1 icon in Eclipse to the Feed1 icon in Hysys by clicking into the first icon and
Examples Guide
892

Connect the Prod2 icon in Eclipse to the Feed2 icon in Hysys by clicking into the first icon and
Step 6 Objective:
893
RESOLVE
The next step is to select some variables from the Hysys model that will be added to the
RESOLVE reporting system.
To do this for the Hysys model, right click on the Hysys icon in RESOLVE and select "Output
variables". A progress bar will be displayed: this is RESOLVE querying the plant model for all
the output variables that can be exported to RESOLVE.
Once this procedure is ended, a screen similar to the following will be displayed:
The left hand list is a hierarchical list of all the variables that can be queried in Hysys. They are
ordered at the top level by flowsheet: in this example, there are two flowsheets ("Main" and
"COL1") where "Main" is the main flowsheet and "COL1" is the Depropanizer column. Below
this is a list of streams (marked with a coloured arrow, as shown) and equipment items. When
one of these is opened up (as with "SalesGas", above) a list of variables that pertain to that item
will be displayed. These are the variables that can be added to the RESOLVE reporting system.
To add a variable, highlight the variable on the left and press the "Add" button. Some variables
Examples Guide
894
are arrays, most usually over components (e.g. the component molar fraction array in the screen
capture above). If the user select this variable, all the array variables will be passed across at
once.
In this example, we have chosen to monitor the MolarFlow and MassFlow variables of the
SalesGas stream.

Step 7 Objective:
Setup the PVT data transfer option between Eclipse and Hysys
In this case, the fluid PVT properties in the Eclipse model are described using a black oil model,
whereas the fluid PVT properties in the Hysys model are described using a detailed
compositional description.
In order to ensure PVT consistency between the two applications, it will be necessary to use the
BLACK OIL DELUMPING technique in RESOLVE.
This technique will work as follows:
At each RESOLVE timestep, the Eclipse model passes the black oil PVT properties of
the fluid to RESOLVE.
The equation of state used in Hysys (i.e. the DOWNSTREAM composition) has been
specified in the delumping options of RESOLVE.
RESOLVE uses the Target GOR method to calculate the unique composition that will
correspond to the fluid GOR passed by Eclipse: the Target GOR essentially
recombines the oil and gas phases from the downstream composition until the final
composition has the same GOR than the Eclipse fluid. This will enable to obtain a
detailed composition for the reservoir fluid at the timestep considered.
The components from both the Eclipse fluid composition and the Hysys composition
are mapped as usually done for compositional connections in RESOLVE.
In order to setup this technique in RESOLVE, the following procedure can be followed:
Double click on the Hysys module icon and set the "Transfer composition to Hysys feed
streams" option to "Transfer upstream composition to Hysys feed stream" as
illustrated below.
895
RESOLVE
In the main RESOLVE menu, go to Options | Lumping / Delumping | Options and

leave the default settings, as illustrated below.
It is possible to notice that as we are here passing from a black oil PVT to compositional
description, there is no need to specify a lumping rule.
Examples Guide
896
In the main RESOLVE menu, go to Options | Lumping / Delumping | Module Fluid

Characterisations to specify the composition and equation of state characteristics to
be used by the Hysys model.
897
RESOLVE
The Hysys model already has a fluid equation of state definition specified: it is possible
to import it directly to RESOLVE by going to the "Import" button.
Select the Hysys flowsheet and stream to import the equation of state parameters and
composition from, here the Flowsheet "Main" and the Stream "Feed 1" for instance.
Examples Guide
898
The following screen will appear, illustrating the fact that 21 components are present in
the Hysys compositional description of the fluid.
899
RESOLVE
Clicking on the "Setup" button will allow to view the composition imported, as illustrated
below.
Examples Guide
900
Once the downstream composition (i.e. the Hysys model composition in this case) has
been setup, go to Run | Composition Tables to map the components from the
Eclipse derived composition to the Hysys composition.
901
RESOLVE
The screen above is displayed: as the Eclipse model is a black oil model and a fluid
composition is derived from it at each timestep using the "Target GOR" method, select
the "External Delumping" option at the top of the screen, as illustrated below.
Examples Guide
902
For each one of the connections specified on the left hand side of the screen, it will be
necessary to map the compositions.
As in this case all the components are in the same order, it is possible to do so by
selecting the "Add All" option.
Once the compositional mapping has been performed for each connection, the
following screen will be displayed: each connection will be displayed with a green tick
illustrating the status of the compositional mapping for this connection.
903
RESOLVE
This step terminates the PVT setup for this black oil delumping model.
It is now possible to run the model.
Go to Step 6 or Step 8.
Examples Guide
904

Step 8 Objective:
905
RESOLVE
Here the Eclipse and Hysys models will be synchronised every 1 months until the schedule
completes on 01/01/2002.
3.7.1.10Black Oil Delumping Example : Step 9
Step 9 Objective:
Examples Guide
906

icon.


icon.
).
The first action done is the initialisation of both modules. In the case of Eclipse, this means
initialising the reservoir model (i.e. running a history if necessary until the start date of the
forecast is reached). In the case of Hysys, no initialisation is necessary.
If the composition tables have not been setup previously, the composition mapping screen will
be displayed. See the Step 7 for more details on how to setup this screen.
Eclipse will then perform a solve and optimisation of the reservoir model. The production will be
passed to Hysys, which will then solve its system. Eclipse will then be ready to take another
timestep; but before this the RESOLVE forecast enters "pause" mode.
The results of the run for the first timestep can be checked by holding the mouse over a
connection icon:
907
RESOLVE

RESOLVE will complete the run to 2002 taking two-weekly timesteps.

3.7.1.11Black Oil Delumping Example : Step 10
Step 10 Objective:
Analyse the Results
The main objective of this example is to illustrate how to setup a direct connection between a
black oil reservoir model (i.e. Eclipse) and a compositional process model (i.e. Hysys) and how
the PVT consistency can be kept within the model using the black oil delumping technique.
By going to the Results | View Forecast Plots section, it will for instance be possible to
compare the oil produced by the Prod1 well at the Eclipse level and at the Hysys level: both of
Examples Guide
908
them are consistent, as illustrated below.
In addition to this, it will be possible for instance to retrieve the composition of the fluid passed to
every feed of the Hysys model by going to the Results | View Prediction Results (Tables)
section, as illustrated below.
909
RESOLVE
Once the composition is displayed, it will be possible to select the "Properties" section to obtain
the corresponding black oil PVT properties.
Examples Guide
910
3.7.2 Example 5.2: Lumping/Delumping Example

3.7.2.1 Lumping - Delumping: Overview
Context: in an oil field the produced fluid is sent to a small separation plant, which separates the
gas from the oil and sends the gas to an injection network for reservoir pressure support. It is
required to determine a forecast of the system along the time. In particular it is required to
determine:
- the production rate profile
- the injection rate profile, along with the variation of the injection gas along the time.
This example illustrate a complex RESOLVE setup including a REVEAL reservoir model, surface
production and injection network models and UniSim Design model.
The production from the producing wells is gathered by a GAP network model and from this is
delivered to a UniSim Design process model, which separates gas and oil, then it compresses
the separated gas, which is then sent to a GAP injection network model and then re-injected the
gas into the reservoir.
The schematic of the system is reported in the figure below:
911
RESOLVE
Each module uses the PVT modelling approach required (/best) by each tool, that is to say:
The REVEAL reservoir model uses a grouped (6 pseudo components) fully compositional
PVT description
The GAP surface network model (for both the production and the injection sides) uses an
extended fully compositional (20 components) PVT description (i.e. GAP with Fully
compositional option).
The UniSim Design process model uses a detailed fully compositional PVT description (20
components)
The GAP separator is connected to the UniSim Design inlet stream.
Examples Guide
912
It is therefore possible to note that it will be required to make use of the lumping / delumping
capabilities of the IPM suite to be able to ensure PVT consistency when going from a grouped
composition to a detailed composition and vice versa.
The main objective of this example is to demonstrate how to setup the compositional lumping /
delumping capabilities of RESOLVE.
This is a complex example, and therefore it is recommended that the Example 2.5, Example 3.1,
Example 4.1 and Example 5.1 are studied before looking at this example.
RESOLVE
1
REVEAL
1
GAP
1
OpenServer
1
UniSim Design
1
GAP, Excel, Eclipse and Hysys are registered. Note that this operation is not required if it has
been done previously.
been registered.
3. Files Locations
C:\ProgramFiles\Petroleum
\Example_5_2
Experts\IPM
This folder contains a file "Lumping_Delumping.rsa" which is a "RESOLVE archive file" that
contains the RESOLVE file, Eclipse and Hysys files required to go through the example. The
Go to Step 1
3.7.2.2 Lumping - Delumping: Step 1
Step 1 Objective: Start a new RESOLVE project and initialise the units
913
RESOLVE
Access the Controls/EOS and change the range of validity for the Volume Shift, including
negative values:
Examples Guide
914
Now is a good time to save the file using File | Save As..., and enter a file name (e.g. Lumping
_Delumping.rsl).
Go to Step 2
Step 2 Objective: Create REVEAL instance in the RESOLVE model
The next step is to create a REVEAL instance in the RESOLVE model and load it in the main
RESOLVE screen.
icon.
From the displayed menu list, select "REVEAL".

Click on the main screen where the REVEAL icon is to be located, and give the case a label
(say, "REVEAL").
915
RESOLVE
Double-click on the REVEAL icon - the following screen will appear:
In the File name field Browse the REVEAL model Res_A.rvl:
After that, clicking on Ok will return to the main screen and open up the REVEAL model:
Examples Guide
Note: one can use the Move tool

to move the wells in the screen.
The REVEAL reservoir model has overall 5 wells:
- Wells P1, P2, P3 and P4 producers
- Well I1 gas injector
Once the REVEAL deck is loaded, access the input section and select as IPR model the
Drainage region (advanced) (ref. IPR Model topic)
916
917
RESOLVE
Then Select Set up and Calculate. The program will calculate parameters to correct the block
IPR to determine a more representative drainage region IPR.
After the calculation is finished, select OK to go back to the main program panel.
Examples Guide
918
Go to Step 3
Step 3 Objective: Create an instance of GAP for the production network in the RESOLVE
model
The next step is to create the GAP instance for the production network.
icon. From the
Click on the main screen where to position the GAP icon, and give the case a label (say, "GAP_
production").
919
RESOLVE
For the file name, browse to the file "Surface_Network.gap" as shown above.
Examples Guide
920
Note that from this screen it is possible to select a remote host on which GAP can be run.
shown below.
) and then dragging
In the production network there are 4 wells: Prod1, Prod2, Prod3 and Prod4.
Go to Step 4
Step 4 Objective: Create a UniSim Design instance in the RESOLVE model
The next step is to create the UniSim Design instance to be connected through RESOLVE.
icon.
From the resulting menu, select "UniSim". The cursor, when held over the main screen, will
Click on the main screen where the UniSim icon is to be located, and accept the default label
("UniSim").
Double-click on the UniSim icon - the following screen will appear:
921
RESOLVE
Browse for the "Process_Model.usc" UniSim Design model.

The UniSim model will be loaded and will be displayed on the RESOLVE main screen as
displayed below:
Examples Guide
922
Beside the Feed stream, the UniSim process model provides with a liquid product (L2) and two
gas products: To_sales and To_injection.
Go to Step 5
Step 5 Objective: Create an instance of GAP for the injection network in the RESOLVE
model
The next step is to create the GAP instance for the injection network.
icon. From the
Click on the main screen where to position the GAP icon, and give the case a label (say, "GAP
_Injection").
923
RESOLVE
For the file name, browse to the file "Surface_Network.gap" as shown above.
This is the main production model. As this network model is an associated Gas
Injection network model, then select as System "Associated Gas Injection".
Examples Guide
924
shown below.
) and then dragging
Go to Step 6
Step 6 Objective: Establish the connections between the REVEAL, GAP and the UniSim
Design models
icon.
The following connections have to be made:

REVEAL - GAP_production
Connect the P1 icon in Eclipse to the Prod1
and dragging the connection to the second.
icon in GAP by clicking into the first icon

925
RESOLVE
GAP_production - UniSim
Connect the separator Sep1 icon of GAP to the Feed icon of UniSim by clicking into
the first icon and dragging the connection to the second.
UniSim - GAP_injection
Connect the To_injection icon of UniSimto the injection manifiold IM1 icon of GAP by
clicking into the first icon and dragging the connection to the second.
GAP_injection - REVEAL
Connect the injection well Inj1 of GAP to the I1 well icon of REVEAL by clicking into the
first icon and dragging the connection to the second.
Examples Guide
926
Go to Step 7
Step 7 Objective: Setup the PVT data transfer options
In this case, the fluid PVT properties in the REVEAL, GAP and UniSim Design models are
described using a fully compositional model. The difference is that the REVEAL models has
been setup to use a LUMPED composition (6 components), whereas the fluid PVT properties in
the GAP (production and injection) and UniSim Design models are described using a FULL (20
components) compositional description.
927
RESOLVE
For the sake of this example the fluid has been characterised with 20 components. This
characterisation is the 'Full-Ungrouped' composition. Another composition has been obtained
for the same fluid which has 6 components. This 6 component fluid is the 'Lumped' composition,
and has been obtained from the Full-ungrouped composition using the Lumping/Delumping
feature of PVTP.
Please refer to the Examples Guide of PVTP for further information of how to generate
a Full/Lumped equivalent compositions.
This will lead to three types of connections with regards to PVT data exchange:
Connection between REVEAL and GAP
In this case, it is required to pass from a lumped composition to a full (delumped)
composition.
It is therefore required to use a DELUMPING capability (i.e. DELUMPING rule) to do
so.
Connection between GAP (production and injection) and UniSim Design
In this case, as these modules use the same type of composition, all is required is to
pass the compositions from one module to another by mapping the compositions in the
modules
Connection between GAP (injection) and REVEAL
In this case, it is required to pass from a detailed composition to a grouped
composition.
It is therefore required to use a LUMPING capability (i.e. LUMPING rule) to do so.
When a compositional lumping or delumping calculation is required, it will be necessary to
define two equation of state characterisations for the same fluid: one using a lumped
composition (i.e. small number of components, that can be used in a reservoir simulation model
for instance) and one using a full (detailed) composition (i.e. a large number of components, that
can be used in a process simulation model for instance). Both these PVT characterisation
should match the laboratory measurements available for the fluid considered. The PVT
characterisation tool PVTp can be used to perform this double characterisation.
Once this characterisation is performed, a lumping / delumping rule will be defined that enables
to automatically transform one composition into the other.
Both compositions and the lumping rule will de included in the output from PVTp, the .prp file.
The only elements that therefore require to be setup in the RESOLVE model are the
compositions used by the downstream modules of each connection requiring a
lumping or delumping calculation.
In the case considered, the following connections required a lumping / delumping calculation:
Examples Guide
928
Connection between REVEAL and GAP (Production)

In this case the downstream module is GAP_production.
Connection between GAP (Injection) and REVEAL
In this case, the downstream module is REVEAL.
In this model, it is therefore required to setup two downstream compositions in
RESOLVE: the composition used by GAP_production, the composition used by
REVEAL.
In order to setup this PVT transfer technique in RESOLVE, the following procedure can be
followed:
Step 1: Setup the Compositional Modeling options
These options enable to specify the way the composition / EOS characterisations should
be interpreted (i.e. what path to surface is used, what standard conditions are used,
etc...).
Further information on these options can be found in the "Lumping / Delumping" section.
In the main RESOLVE menu, go to Options | Lumping / Delumping | Options and
leave the default settings, as illustrated below.
It is possible to notice that there is no need to define a lumping / delumping rule: it will be
automatically included in the EOS characterisations that are imported.
929
RESOLVE
Step 2: Import the downstream compositions

Three compositions have to be defined in this model: the one used by Hysys and the
one used by Eclipse.
To do so, go to Options | Lumping / Delumping | Module Fluid Characterisations
to specify the composition and equation of state characteristics to be used by each
module.
Examples Guide
Step 2.1: Import the composition for REVEAL

In the Options | Lumping / Delumping | Module Fluid Characterisations
section, select the "REVEAL" tab: the following screen will be displayed.
It is possible to click on "Setup" to import the composition from the REVEAL

model.
After that, select "Import...PRP" in the screen displayed - Browse for the
"Lumped_Delumped_comp.prp" file.
The following composition will be imported:
930
931
RESOLVE
It is possible to note that this composition description includes a detailed (i.e.

"Full" here with 20 components) and a grouped (i.e. "Lumped" here with 6
components) composition.
Passing from one to another is possible through the "OIL6" lumping / delumping
rule, as illustrated below.
Step 2.2: Import the composition for GAP_production

The same procedure is used to import the GAP (production) composition. In the
Examples Guide
932
Options | Lumping / Delumping | Module Fluid Characterisations section,

select the "GAP_production" tab: the following screen will be displayed.
Click on "Setup" and go to "Import...PRP" in the screen displayed - Browse for

the "Lumped_Delumped_comp.prp" file.
The following composition will be imported:
933
RESOLVE
It is possible to note that this composition description includes a detailed (i.e.

"Full" here with 20 components) and a grouped (i.e. "Lumped" here with 6
components) composition.
Passing from one to another is possible through the "OIL6" lumping / delumping
rule, as illustrated below.
Once all compositions have been imported, it is possible to go to the Options |

Lumping / Delumping | Options section: notice that the lumping rule has automatically
been imported, as illustrated below.
Examples Guide
Go to Step 8
Step 8 Objective: Setup the RESOLVE Schedule
934
935
RESOLVE

Examples Guide
936
select the required start date from a list of the various model start dates. In this case the start
date is 1/1/2010
The timestep and schedule duration are also entered here as shown (2 weeks).
All the linked application models will be synchronised every 2 weeks until the schedule
completes on 01/06/2011.
Go to Step 9
937
RESOLVE
3.7.2.10Lumping - Delumping: Step 9

Step 9 Objective: Run the prediction forecast
icon.


icon.
).
The first action done is the initialisation of both modules.
In the case of REVEAL, this means initialising the reservoir model (i.e. running a history if
necessary until the start date of the forecast is reached). In the case of UniSim Design, no
initialisation is necessary.
points will then be returned to REVEAL ready to take the first week"s timestep. The production
will be passed to UniSim Design, which will then solve its system. Before this, the RESOLVE
forecast enters "pause" mode.
Just after starting the run the composition mapping screen will be displayed.
Once the downstream compositions have been setup, from the main screen of RESOLVE,
select Run | Edit Composition Tables. This will allow for mapping the components for each
connection considered.
Examples Guide
938
The left hand side list lists all the connections that have been setup in this model. Select each of
these connections to map the components.
Four types of connections can be considered:
REVEAL - GAP_production: Delumping required
To map the compositions for this connection, select the connection between P1 and Prod1.
In the RESOLVE lumping / delumping option, select "External Delumping".
939
RESOLVE
This option will enable the delumping feature to RESOLVE applied to the compositions defined
in Step 7.
Associate each component of P1(Reveal) to the ones of Prod1(GAP_production) either
selecting each pair of components and clicking on Add Individual Connection or directly
selecting Add All:
Examples Guide
940
Repeat the same for all the connections: P2->Prod2, P3->Prod3, P4->Prod4. Note that once
can also use Copy to All, which will apply the same connections done for P1->Prod1 to the
remaining ones.
This is the set up achieved:
941
RESOLVE
GAP_production - UniSim and UniSim - GAP_injection: components' association

required
GAP_production, GAP_injection and UniSim modules have the same number of components,
that is one should simply connect components by selecting Add Individual Connection (after
selecting the pair of components of Sep1 and Feed) or directly selecting Add All:
Examples Guide
942
REVEAL - GAP_injection : Lumping required

When the composition is passed from the GAP injection system to REVEAL, it needs to be
lumped from 20 components to 5.
Select the Resolve lumping/delumping as External lumping and then associate the components
of the two streams I1 and Inj1:
943
RESOLVE
Once all the composition have been mapped, the PVT setup for this compositional lumping /
delumping model is finished.
Selecting OK, the program will proceed with the prediction, as previously set up.
Go to Step 10
3.7.2.11Lumping - Delumping: Step 10
Step 10 Objective: Analyse the Results
The main objective of this example was to illustrate how to setup a full-field model including
reservoir, surface network and process models all using fully compositional PVT description and
how to make these PVT descriptions consistent by using the lumping / delumping method.
In this model, the individual applications use the following PVT setup:
The reservoir model uses a grouped fully compositional PVT description (i.e. REVEAL
).
The surface network model uses a detailed fully compositional PVT description (i.e.
GAP with compositional option).
The process model uses a detailed fully compositional PVT description (i.e. UniSim
Design).
Examples Guide
944
The results allow to verify the variation of production and injection rate along the prediction time.
For instance, one can check the results for the injector well I1, including the evolution of the gas
composition injected, by using the Results | View Forecast Results section.
When visualising the composition results, it will be possible to display both Lumped and Full
compositions, as illustrated below.
Also, from the results menu one can plot the profile of gas rate injected:
945
3.8
RESOLVE
Example Section 6: OpenServer Examples
3.8.1 Example 6.1: Drilling

3.8.1.1 Drilling : Overview
A full field GAP model has been setup.
There is an existing gas contract with delivery required at a certain rate. the objective of this
exercise is to decide when a new well needs to be drilled such that the total production from the
field is able to meet the required production limit.
This example illustrates how an OpenServer macro can be used to automatically populate the
RESOLVE event driven scheduling capabilities described in Example 2.3.
Examples Guide
RESOLVE
1
OpenServer
1
Excel
1
GAP
1
PROSPER
1
946
MBAL
1
GAP is registered.
been registered.
3. Files Locations
\Example_6_1
Experts\IPM
This folder contains a file "Drilling.rsa" which is a "RESOLVE archive file" that contains the
user"s choice.
Go to Step 1
3.8.1.2 Drilling : Step 1
Step 1 Objective:
Extract the RESOLVE model
Prior to running the model, it is required to extract the archive. The following procedure enables
to do so.
From the RESOLVE main screen, click on File | Archive | Extract, the following screen will
appear:
947
RESOLVE
Browse to the folder required and select the particular *.rsa file to be extracted and click on
Open. The "Extract archive" screen will be displayed. Click on Extract Archive. Browse to a
new directory where the user would like to store the example files and click OK | OK. RESOLVE
will extract all the files required for this exercise to the folder the user have specified.
Examples Guide
948
When the message box "Open Master File" is displayed, click YES if the objective is to open
the RESOLVE file extracted. Click NO if some other file is to be extracted. For the example
drilling.rsl, we shall click on YES.
Go to Step 2
Step 2 Objective:
Open the RESOLVE model
When YES is clicked on the previous screen, RESOLVE will open the file drilling.rsl and a new
message box will appear.
949
RESOLVE
Select YES and specify the location of the GAP model, as specified below.
Make sure that the file name is located in the folder where the files were extracted. Click on OK.
RESOLVE will open the GAP model. The GAP Model will start in a new window and the
RESOLVE screen will look like this,
Examples Guide
950
The model is now open and ready to be run.


Step 3 Objective:
Open the Excel file containing the OpenServer macro required
The associated macro for this file is located in the file Drilling.xls. The location of this file is in the
same folder where the RESOLVE archive files were extracted.
Open the Excel file and make sure that Excel is setup so that it allows to run macros.
Step 4 Objective:
Run the model
951
RESOLVE
When both the RESOLVE model and the Excel file are open, the macro can be executed by
clicking on the Run Forecast button in EXCEL.
When this is done, the following steps are performed:
A connection is established between EXCEL and RESOLVE.
Excel will read the number of wells built in the GAP model.
The macro populates the "Event driven scheduling" RESOLVE feature to simulate a
drilling queue.
Runs the model and plots the profile.
Will start new wells when the total system production reduces below the stipulated rate.
The data is stored in the model so this macro does not have to be run again unless the
GAP model changes (i.e. once the RESOLVE model is saved).
Go to Step 3
3.8.2 Example 6.2: Equipment

3.8.2.1 Equipment : Overview
A full field GAP model has been setup and connected to the corresponding plant model in
UniSim Design.
This example shows how equipment, and the variables associated with the equipment, can be
read from GAP and process models using the RESOLVE OpenServer interface.
Also, having queried the models for the variables, it is possible to export these variables into
RESOLVE for use in "Event driven scheduling" or "Scenario management".
RESOLVE OpenServer
1
UniSim
Design
1
Excel
GAP
PROSPER
MBAL
UniSim Design and GAP are registered.
Examples Guide
952
been registered.
3. Files Locations
\Example_6_2
Experts\IPM
This folder contains a file "Equipment.rsa" which is a "RESOLVE archive file" that contains the
user"s choice.
Go to Step 1
3.8.2.2 Equipment : Step 1
Step 1 Objective:
Extract and open the RESOLVE model
As mentioned in Example 6.1 above, it is required that the RESOLVE Archive file "Equipment.
rsa" be extracted to a suitable directory.
After the stated file has been extracted open the RESOLVE file "Equipment.rsl" and the Excel
File "Equipment.xls."
Go to Step 2
3.8.2.3 Equipment : Step 2
Step 2 Objective:
Run the RESOLVE model
From the Excel spreadsheet, the following steps can be taken:
Use the "Clear Sheets" button to make sure that no other Excel worksheets are active
apart from the "Start" and "Sheet2" worksheet.
Read all the variables
Import the variables in RESOLVE
Add entries to the schedule
Create scenario from current schedule OR
953
RESOLVE
Remove Scenario OR
Set Scenario as current schedule
Go to Step 1
3.8.3 Example 6.3: Variable-Connection

3.8.3.1 Variable Connection : Overview
Two process simulation models are connected together: one main plant model and one single
compressor model.
This example shows how the OpenServer can be used to add generic "Variable connections"
between the two modules.
RESOLVE
1
OpenServer
1
Hysys
2
Excel
1
Hysys is registered.
been registered.
3. Files Locations
\Example_6_3
Experts\IPM
This folder contains a file "Variable_Connection.rsa" which is a "RESOLVE archive file" that
contains the RESOLVE file, Excel file, GAP file and other associated files required to go through
the user"s choice.
Go to Step 1
Examples Guide
954
3.8.3.2 Variable Connection : Step 1

Step 1 Objective:
As mentioned in Example 6.1 above, it is required that the RESOLVE Archive file
"Variable_Connection.rsa" be extracted to a suitable directory.
After the stated file has been extracted open the RESOLVE file "Variable_Connection.rsl" and
the Excel File "Variable_Connection.xls."
Go to Step 2
3.8.3.3 Variable Connection : Step 2
Step 2 Objective:
This example is designed to analyse the sensitivity variable Transfer Efficiency.
Its effect on the Compressor output will be analysed.
Running this macro will perform the following steps:
Input the Transfer Efficiency and run the model
Extract the compressor output and report it to Excel.
Will plot the graph of Compressor Output Vs Transfer Efficiency.
Please note that the RESOLVE model has to be loaded prior to the macro being run.
3.8.4 Example 6.4: Compositional Mapping

3.8.4.1 Compositional Mapping : Overview
This example shows how the OpenServer can be used to populate the "Composition Mapping"
screen when connecting a GAP surface network model and a process simulation tool in UniSim
Design.
955
RESOLVE
RESOLVE OpenServer
1
UniSim
Design
1
Excel
GAP
PROSPER
MBAL
UniSim Design and GAP are registered.
been registered.
3. Files Locations
\Example_6_4
Experts\IPM
This folder contains a file "Compositional_Mapping.rsa" which is a "RESOLVE archive file" that
contains the RESOLVE file, Excel file, GAP file and other associated files required to go through
the user"s choice.
Go to Go to
3.8.4.2 Compositional Mapping : Step 1
Step 1 Objective:
As mentioned in Example 6.1 above, it is required that the RESOLVE Archive file
"Compositional_Mapping.rsa" be extracted to a suitable directory.
After the stated file has been extracted open the RESOLVE file "Compositional_Mapping.rsl"
and the Excel File "Compositional_Mapping.xls."
Go to Step 2
3.8.4.3 Compositional Mapping : Step 2
Step 2 Objective:
Examples Guide
956
This example is designed to read and map the components entered in GAP and in UniSim
Design.
The composition of the fluid is entered in GAP and in UniSim Design, however the titles given to
each component are different. It is required that the component names be mapped when running
the model.
This example is set up to show three conditions.
The Excel file has these three macros for the execution.
Running this macro will enable to perform the following steps:
Run model
In this case, the model will be run without mapping the components. Expectedly, this will
not provide the correct solution as UniSim Design has zero mole % entered as the initial
values. This will generate errors in the Resolve calculation window
Run model with mapped compositions
In this case, the model will be run by mapping the components in GAP and in UniSim
Design. This is done through the excel macro and can be checked after the run has been
performed by going to Run | Edit Composition Tables. Once the model is run with the
mapped compositions, running the model without mapping will not create any errors as
the components have already been mapped.
Map existing compositions
In this case, the mapping will be set between existing composition tables. The model
must have been run at least once before to set up the compositions from the two sides of
the connections.
3.9
Example Section 7: Additional Examples
3.9.1 Example 7.1: Mixed ESP

1. Major Elements Covered
Multiple reservoir applications in one RESOLVE model / GAP scheduling.
This model illustrates how to link a GAP surface network model to two types of reservoir model:
a REVEAL model and a MBAL model. It also illustrates how the schedule elements
implemented in GAP are respected by a RESOLVE model.
RESOLVE
OpenServer
REVEAL
GAP
PROSPER
MBAL
957
RESOLVE
REVEAL and GAP are registered.
been registered.
3. Files Locations
\Example_7_1
Experts\IPM
This folder contains a file "Mixed_ESP.rsa" which is a "RESOLVE archive file" that contains the
user's choice.
3.9.2 Example 7.2: Process Model Scheduling

These examples (i.e. one working with Hysys, one working with UniSim Design), illustrate how
the process models internal schedules are taken into account when using RESOLVE.
When running this model, it will be possible to note the Hysys / UniSim Design scheduling being
taken into account as it will be reported in the RESOLVE log window.
RESOLVE
1
OpenServer Hysys / UniSim

Design
1
1
GAP
PROSPER
MBAL
Hysys, UniSim Design and GAP are registered.
Examples Guide
958
been registered.
3. Files Locations
\Example_7_2
Experts\IPM
This folder contains a file "Hysys_Schedule.rsa" and "UniSim Design_Schedule.rsa" which is a

"RESOLVE archive file" that contains the RESOLVE file, Excel file, GAP file and other
3.9.3 Example 7.3: Multiple Process Instances

This model illustrates how multiple instance of a process model, using Hysys or UniSim Design
can be combined within one full-field model and connected to a GAP surface network model.
An internal RESOLVE script is used in that example for optimisation purposes.
RESOLVE
1

Design
1
3
GAP
PROSPER
MBAL
959
RESOLVE
been registered.
3. Files Locations
\Example_7_3
Experts\IPM
This folder contains files "GAP_Hysys_Multiple_Instances.rsa" and a "GAP_UniSim

Design_Multiple_Instances.rsa" which are a "RESOLVE archive file" that contains the RESOLVE
file, Excel file, GAP file and other associated files required to go through the example. The
archive file needs to be extracted either in the current location or a location of the user's choice.
3.9.4 Example 7.4: Gas Re-Injection

This model illustrates how to link a production network to a process to a re-injection network,
and how the compositions are handled from one model to another.
RESOLVE
1

Design
1
1
GAP
PROSPER
MBAL
been registered.
3. Files Locations
Examples Guide
\Example_7_4
Experts\IPM
960
This folder contains two files "Gas_ReInjection_Hysys.rsa" and "Gas_ReInjection_UniSim

Design.rsa" which are a "RESOLVE archive file" that contains the RESOLVE file, GAP file and
other associated files required to go through the example. The archive file needs to be extracted
3.9.5 Example 7.5: SmartWell

This model illustrates the modeling of smart / multilateral wells, including downhole flow controls
when using a connection between a GAP surface network model and a REVEAL reservoir
simulation model.
A second model illustrate the use of event driven scheduling to open / close several perforated
zones of the smart well as the function of the well behavior.
RESOLVE
1
OpenServer
2
REVEAL
1
GAP
1
PROSPER
1
MBAL
1
been registered.
3. Files Locations
\Example_7_5
Experts\IPM
This folder contains two files "Smart_Well.rsa" and "Smart_Well_Schedule.rsa" which are "
961
RESOLVE
RESOLVE archive file" that contains the RESOLVE file, GAP file and other associated files
required to go through the example. The archive file needs to be extracted either in the current
location or a location of the user"s choice.
3.9.6 Example 7.6: RedoSolve - Scripting

This example illustrates the use of RESOLVE internal scripting capabilities: the main objectives
of this script is to modify the pressure at which the GAP model is run (i.e. separator pressure) in
order to achieve a specific target production.
RESOLVE
1

Design
1
2
GAP
PROSPER
MBAL
been registered.
3. Files Locations
\Example_7_6
Experts\IPM
This folder contains two files "ReDo_Solve_Hysys.rsa" and "ReDo_Solve__UniSim Design.rsa"

which are a "RESOLVE archive file" that contains the RESOLVE file, Excel file, GAP file and
other associated files required to go through the example. The archive file needs to be extracted
Examples Guide
962
3.9.7 Example 7.7: Voidage Replacement

This model illustrates how the voidage replacement utility can be used to design a voidage
replacement scheme when connecting a REVEAL numerical reservoir model and GAP
production and water injection surface network models.
RESOLVE
1
OpenServer
2
REVEAL
1
GAP
1
PROSPER
1
MBAL
1
been registered.
3. Files Locations
\Example_7_7
Experts\IPM
This folder contains a file "Voidage.rsa" which is a "RESOLVE archive file" that contains the
RESOLVE file, GAP file and other associated files required to go through the example. The
archive file needs to be extracted either in the current location or a location of the user's choice.
3.9.8 Example 7.8: Water Re-Injection

This model illustrates how to use the RESOLVE internal scripting capabilities to control a water
re-injection scheme: here, the water produced can either be produced or re-injected in the
reservoir, provided the water saturation in the reservoir is kept below a certain user-defined
963
RESOLVE
treshold.
RESOLVE
1
OpenServer
2
REVEAL
1
GAP
1
PROSPER
1
MBAL
1
been registered.
3. Files Locations
\Example_7_8
Experts\IPM
This folder contains a file "Water_Re_Injection.rsa" which is a "RESOLVE archive file" that
contains the RESOLVE file, GAP file and other associated files required to go through the
user's choice.
3.9.9 Example 7.9: Optimiser Settings OpenServer

The OptimiserSettingsTest.xls macro works with any RESOLVE model that includes an
optimisation section and illustrates what variables are changed during the optimisation.
To work, this macro has to be run on a step by step basis from the visual basic section
of Excel.
This macro is provided more as a template for anybody wanting to work the RESOLVE
optimiser parameters through an Excel macro rather than as an example that is to be
Examples Guide
964
run from beginning to end.

RESOLVE
1
OpenServer
1
Excel
1
GAP
1
PROSPER
1
MBAL
1
GAP is registered.
been registered.
3. Files Locations
\Example_7_10
Experts\IPM
This folder contains a file "OptimiserSettingsTest.xls" which contains the Excel macro for this
example.

Resolve Complete

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Resolve Complete

Caricato da

Copyright:

Formati disponibili

Petroleum Experts

Part 1 Technical Overview

Part 2 User Guide

RESOLVE User's Manual

Optimisation ................................................................................................................................... 284

RESOLVE User's Manual

RESOLVE User's Manual

Part 3 Examples Guide

Exam ple 2.2: ..........................................................................................................................................................

RESOLVE User's Manual

RESOLVE User's Manual

Petroleum Experts Ltd.

Material Balance, Well and Surface Network Model + Process Model:

Numerical Simulation Reservoir Model + Well and Surface Network Model +

RESOLVE User's Manual

Petroleum Experts Ltd.

RESOLVE: How does it work?

RESOLVE User's Manual

2. What happens during a timestep: the RESOLVE dataflow

The process is then repeated until the RESOLVE schedule is completed.

RESOLVE: Summary of Capabilities

User Guide Section

RESOLVE User's Manual

User Guide Section

No fixed concept of upstream

Take full advantage

User Guide Section

Link to any of the IPM tools

Connection to IPMOS - IPM-OS driver

Event driven scheduling options Event Management Example Section 2 |

RESOLVE User's Manual

User Guide Section

Results of each scenario are

Non-Linear Optimisation in GAP Optimisation

Petroleum Experts Ltd.

checked IN and OUT, as well as

User Guide Section

External to RESOLVE using the

RESOLVE User's Manual

User Guide Section

What's New in RESOLVE?

IPM version 7.5

Petroleum Experts Ltd.

RESOLVE User's Manual

Implementation of a generic routing and integer optimisation algorithm (GIRO).

Petroleum Experts Ltd.

Extensions to OpenServer interface to Eclipse

case of a drilling queue

Petroleum Experts Ltd.

Eclipse link driver

Requirements for individual applications

RESOLVE (absolute minimum requirements)

Pentium II class PC (Windows XP or Vista)

3rd party applications

Petroleum Experts Licensing

Petroleum Experts Ltd.

What is in this guide?

Petroleum Experts Ltd.

Contacting Petroleum Experts

Petroleum Experts Ltd.

RESOLVE User's Manual

US based technical support: houston@petex.com

2.3.1 How to Use This Guide?

If the user is new to Windows applications, Petroleum Experts