Post 901 1275120003.ipb

FrontSim
Technical Description
2008.1
Proprietary Notice
Copyright 1982- 2008 Schlumberger. All rights reserved.
No part of this document may be reproduced, stored in a retrieval system, or translated in any form or by any means, electronic or
mechanical, including photocopying and recording, without the prior written permission of Schlumberger.
Use of this product is governed by the License Agreement. Schlumberger makes no warranties, express, implied, or statutory, with respect
to the product described herein and disclaims without limitation any warranties of merchantability or fitness for a particular purpose.
Patent information
Schlumberger ECLIPSE reservoir simulation software is protected by US Patents 6,018,497, 6,078,869 and 6,106,561, and UK Patents
GB 2,326,747 B and GB 2,336,008 B. Patents pending. Schlumberger FrontSim reservoir simulation software is protected by US Patent
2004/0015295A1.
Service mark information

The following are all service marks of Schlumberger:
The Calculator, Charisma, ConPac, ECLIPSE 100, ECLIPSE 200, ECLIPSE 300, ECLIPSE 500, ECLIPSE Office, EDIT, Extract, Fill,
Finder, FloGeo, FloGrid, FloViz, FrontSim, GeoFrame, GRAF, GRID, GridSim, Nodal, NWM, Open-ECLIPSE, PetraGrid, PIPESIM,
PIPESIM FPT, PIPESIM GOAL, PlanOpt, Prodman, Pseudo, PVTi, RTView, SCAL, Schedule, SimOpt, VFPi, Weltest 200.
Trademark information
Silicon Graphics and IRIX are registered trademarks of Silicon Graphics, Inc. OpenGL and the oval logo are trademarks or registered
trademarks of Silicon Graphics, Inc. in the United States and/or other countries worldwide. OpenInventor and WebSpace are trademarks
of Silicon Graphics, Inc. IBM, AIX are registered trademarks of International Business Machines Corporation. Sun, SPARC, Solaris, Ultra
and UltraSPARC are trademarks or registered trademarks of Sun Microsystems, Inc. Macintosh is a registered trademark of Apple
Computer, Inc. UNIX is a registered trademark of UNIX System Laboratories. Motif is a registered trademark of the Open Software
Foundation, Inc. The X Window System and X11 are registered trademarks of the Massachusetts Institute of Technology. PostScript and
Encapsulated PostScript are registered trademarks of Adobe Systems, Inc. OpenWorks and VIP are registered trademarks of Landmark
Graphics Corporation. Lotus, 1-2-3 and Symphony are registered trademarks of Lotus Development Corporation. Microsoft, Windows,
Windows NT, Windows 95, Windows 98, Windows 2000, Windows XP, Internet Explorer, Intellimouse and PowerPoint are either
registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Netscape is a registered
trademark of Netscape Communications Corporation. AVS is a registered trademark of AVS Inc. ZEH is a registered trademark of ZEH
Graphics Systems. Ghostscript and GSview are Copyright of Aladdin Enterprises, CA. GNU Ghostscript is Copyright of the Free Software
Foundation, Inc. Linux is Copyright of the Free Software Foundation, Inc. IRAP is Copyright of Roxar Technologies. LSF is a registered
trademark of Platform Computing Corporation, Canada. VISAGE is a registered trademark of VIPS Ltd. Cosmo is a trademark and
PLATINUM technology is a registered trademark of PLATINUM technology, inc. PEBI is a trademark of Veritas DGC Inc./HOT Engineering
GmbH. Stratamodel is a trademark of Landmark Graphics Corporation. GLOBEtrotter, FLEXlm and SAMreport are registered trademarks
of GLOBEtrotter Software, Inc. CrystalEyes is a trademark of StereoGraphics Corporation. Tektronix is a registered trade mark of
Tektronix, Inc. GOCAD and JACTA are trademarks of T-Surf. Myrinet is a trade name of Myricom, Inc. This product may include software
developed by the Apache Software Foundation (http://www.apache.org). Copyright (c) 1999-2001 The Apache Software Foundation. All
rights reserved. MPI/Pro is a registered trademark of MPI Software Technology, Inc. The TGS logo is a trademark of TGS, Inc. POSC, the
POSC logo and Epicentre are registered trademarks of Petrotechnical Open Standards Consortium, Inc. Red Hat is a registered
trademeak of Red Hat, Inc. This product may include software developed using LAPACK (http://www.netlib.org/lapack/), which is copyright
of its authors. Scali is a trademark of Scali Inc.
Preface
Conventions
Data file, and directory names are shown in Courier, a fixed spaced font, for
clarity.
On some operating systems the file system is case sensitive for example
UNIX. Be aware of this and that the files may not appear as written on your
computer.
We also use the forward slash / as a directory delimiter. This is the standard for
UNIX; on PCs it should be replaced by the backslash \.
The convention for batch files containing groups of operating system commands
is also machine dependent. On PCs batch files will start with the character $, while
UNIX we uses @.
Typefaces used
All regular text is in Palatino font, and headlines at different levels are in different
levels of Helvetica Bold.
Equation variables in text are in Times Italic, for example e = mc2. This is the
same font as is used in formatted equations.
Links and cross-references to other pages in this manual or others are highlighted
in bright blue.
Keywords and other program code items are represented in Courier, a fixed-
space font similar to that seen on DOS and UNIX screens.
Menu items are distinguished from surrounding text by being in Helvetica similar
to settings often found on interactive program screens.
Program variables are in Courier like the keywords.
Standard buttons in interactive programs

Unless specifically stated in the manual the listed buttons perform the following standard
operations:
Apply
Applies the changes you have made in the dialog or panel. The dialog box or panel remains
open.
OK
Applies the changes you have made in the dialog box or panel and closes it.
Close
Closes the dialog box or panel.
FrontSim Technical Description 3

Cancel
Closes the dialog box or panel without applying any changes.
Help
Opens the help page for the screen, dialog box or panel.
In case of problems
Should you find an error, an omission, or something that is not clear, or you simply wish to make
a comment about any part of the documentation, we will be pleased to learn about it so that we
can improve our product. Please send the details in an email to:
documentation@abingdon.oilfield.slb.com
giving full details, or contact your local Support Team who will be pleased to help.
4 FrontSim Technical Description

Table of Contents
List of Figures ..... ...................................................................................................................................................................9
List of Tables ...... .................................................................................................................................................................11
Chapter 1 - Introduction ................................................................................................................. 13

Overview............. .................................................................................................................................................................13
FrontSim features .................................................................................................................................................................15
Ancillary programs ................................................................................................................................................................19
Additional programs..............................................................................................................................................................21
Licenses ............. .................................................................................................................................................................24
Chapter 2 - Allocation Factors....................................................................................................... 25

Introduction ......... .................................................................................................................................................................25
Allocation factor reports ........................................................................................................................................................26
Chapter 3 - Aquifer Modeling Facilities ........................................................................................ 29

Introduction ......... .................................................................................................................................................................29
Numerical aquifer .................................................................................................................................................................30
Carter-Tracy aquifer..............................................................................................................................................................31
Fetkovich aquifer .................................................................................................................................................................33
Constant flux aquifer.............................................................................................................................................................35
Chapter 4 - Time stepping control................................................................................................. 37

Introduction ......... .................................................................................................................................................................37
Time stepping control methods ............................................................................................................................................38
Time stepping control usage examples ...............................................................................................................................43
Chapter 5 - Dual Porosity ............................................................................................................... 51

Introduction ......... .................................................................................................................................................................51
Transmissibility calculations .................................................................................................................................................52
Recovery mechanisms .........................................................................................................................................................54
Facilities specific to dual porosity runs .................................................................................................................................55
Restrictions on dual porosity runs.........................................................................................................................................56
Keyword summary ................................................................................................................................................................57
Chapter 6 - Equations of State ...................................................................................................... 59

Two-parameter equations of state ........................................................................................................................................59
Flash calculations .................................................................................................................................................................62
Three-parameter equations of state .....................................................................................................................................63
Use of the equation of state for hydrocarbon mixtures .........................................................................................................64
Calculation of phase states ..................................................................................................................................................66
Chapter 7 - File Handling in FrontSim........................................................................................... 67

Introduction ......... .................................................................................................................................................................67
File internal format ................................................................................................................................................................69
Graphics post-processors.....................................................................................................................................................71
Chapter 8 - Geologic Model Screening ......................................................................................... 73

Introduction ......... .................................................................................................................................................................73
Theory ................ .................................................................................................................................................................75
Steady State Single Phase Tracer Flow Simulation .............................................................................................................77

Table of Contents
How to use GEOFLOFS .......................................................................................................................................................80
Chapter 9 - Initializing the Study ................................................................................................... 85

Introduction ......... .................................................................................................................................................................85
Data requirements ................................................................................................................................................................86
The equilibration algorithm....................................................................................................................................................88
Calculating the initial conditions............................................................................................................................................89
Chapter 10 - Local Grid Refinement.............................................................................................. 93

Introduction ......... .................................................................................................................................................................93
Local grid refinement ............................................................................................................................................................94
Geometry and grid data in LGRs ..........................................................................................................................................98
Example LGR problem........................................................................................................................................................101
Chapter 12 - Restarts.................................................................................................................... 105

Introduction ......... ...............................................................................................................................................................105
Chapter 13 - Saturation Functions .............................................................................................. 107

Introduction ......... ...............................................................................................................................................................107
Water saturation properties.................................................................................................................................................109
Gas saturation properties....................................................................................................................................................110
Oil saturation properties......................................................................................................................................................111
Three phase oil relative permeability models......................................................................................................................113
Table end points . ...............................................................................................................................................................116
Consistency requirements ..................................................................................................................................................117
Chapter 14 - Saturation Table Scaling .........................................................................................119

Introduction ......... ...............................................................................................................................................................119
Scaling of relative permeability functions............................................................................................................................121
Miscellaneous points...........................................................................................................................................................124
Consistency requirements ..................................................................................................................................................125
Example of end point scaling ..............................................................................................................................................126
Chapter 15 - The Streamline Concept ......................................................................................... 129

Introduction ......... ...............................................................................................................................................................129
The governing equations ....................................................................................................................................................130
The solution strategy ..........................................................................................................................................................132
Chapter 16 - Streamline Tracing .................................................................................................. 139

Introduction ......... ...............................................................................................................................................................139
Chapter 17 - IOR Tracer Logic Guide .......................................................................................... 143

Introduction ......... ...............................................................................................................................................................143
The workflow of building the IOR tracer and truth model....................................................................................................145
IOR tracer logic concepts....................................................................................................................................................151
Keywords and parameters for the IOR tracer model ..........................................................................................................165
Scaling the model to match the field IOR mechanisms ......................................................................................................176
The IOR model simulation output .......................................................................................................................................185
Chapter 18 - Tensor Permeability ................................................................................................ 193

Introduction ......... ...............................................................................................................................................................193
Discretization ...... ...............................................................................................................................................................195
Orthogonality error ..............................................................................................................................................................197

Table of Contents
Chapter 19 - The Oil/Water Front Tracking Saturation Solver .................................................. 199
The Front-Tracking Method ................................................................................................................................................199
Chapter 20 - The Pressure Equation ........................................................................................... 207

Introduction ......... ...............................................................................................................................................................207
Pressure Equation ..............................................................................................................................................................208
Equation Solution Method ..................................................................................................................................................209
Chapter 21 - Multicore Parallel Option........................................................................................ 211

Introduction ......... ...............................................................................................................................................................211
Scalability ........... ...............................................................................................................................................................213
Chapter 22 - Pattern Flood Management .................................................................................... 215

Introduction ......... ...............................................................................................................................................................215
Workflow ............. ...............................................................................................................................................................218
Waterflood Patterns ............................................................................................................................................................220
FrontSim Patterns...............................................................................................................................................................221
Allocation Strategy..............................................................................................................................................................223
Example showing computation of weights..........................................................................................................................226
Aquifers .............. ...............................................................................................................................................................227
Multi-zone Waterfloods .......................................................................................................................................................228
Combining Well Management and PFM Controls...............................................................................................................229
References ......... ...............................................................................................................................................................231
Chapter 23 - Three-Phase Saturation Solver.............................................................................. 233

Introduction ......... ...............................................................................................................................................................233
Streamline solution .............................................................................................................................................................234
Gravity Line Solution ..........................................................................................................................................................236
Mapping the solution between streamlines and the grid.....................................................................................................237
Tuning................. ...............................................................................................................................................................239
Keywords ............ ...............................................................................................................................................................240
Chapter 24 - Total Compressibility Checks ................................................................................ 241

Introduction ......... ...............................................................................................................................................................241
Chapter 25 - Tracer Tracking........................................................................................................ 245

Introduction ......... ...............................................................................................................................................................245
The Tracer Equation ...........................................................................................................................................................246
Chapter 26 - Transmissibility Calculations................................................................................. 249

Introduction ......... ...............................................................................................................................................................249
Chapter 27 - Well Inflow Performance ........................................................................................ 253

Introduction ......... ...............................................................................................................................................................253
Inflow Performance Relationship ........................................................................................................................................254
The connection transmissibility factor (Cartesian grids) .....................................................................................................255
The productivity index.........................................................................................................................................................256
Chapter 28 - Well Modeling Facilities.......................................................................................... 257

Well completions ...............................................................................................................................................................257
Well controls and limits .......................................................................................................................................................259
Group and field control facilities..........................................................................................................................................262

Table of Contents
Chapter 29 - The Wellbore Friction Option................................................................................. 265
Introduction ......... ...............................................................................................................................................................265
Calculating the frictional pressure loss ...............................................................................................................................266
Using the wellbore friction option ........................................................................................................................................269
Chapter 31 - Units ......................................................................................................................... 271

The unit conventions...........................................................................................................................................................271
Conversion factors ..............................................................................................................................................................273
Appendix A - Index ....................................................................................................................... 275

Table of Contents
List of Figures
Figure 5.1 .......... A simple, dual porosity, dual permeability system. .................................................................................53
Figure 8.1 .......... Default relative permeability for oil and water. Gas phase relative permeability is similar......................77
Figure 10.1 ........ Cartesian grid refinement .......................................................................................................................94
Figure 13.1 ........ The default 3-phase oil relative permeability model assumed by FrontSim .........................................114
Figure 13.2 ........ Initial saturations for each zone ............................................................................................................116
Figure 13.3 ........ Ternary diagram showing mobile fluid end-points ................................................................................118
Figure 14.1 ........ Two-point scaling..................................................................................................................................123
Figure 14.2 ........ Three-point scaling ...............................................................................................................................123
Figure 16.1 ........ Streamline tracing through grid, showing points and segments between the points ...........................140
Figure 16.2 ........ Streamline (red) through a single cell ..................................................................................................141
Figure 17.1 ........ Possible workflow for constructing the FrontSim IOR Tracer Model ....................................................146
Figure 17.2 ........ Illustrates the incremental recovery of IOR oil with MWAG ..................................................................147
Figure 17.3 ........ 2D vertical cross-section of a finite difference MWAG truth model ......................................................148
Figure 17.4 ........ 1D Up-scaled MWAG truth model used in FrontSim ............................................................................149
Figure 17.5 ........ Illustration of a 2D full field FrontSim tracer model. ..............................................................................149
Figure 17.6 ........ 3D Finite Difference MWAG truth model. .............................................................................................149
Figure 17.7 ........ 2D Up-scaled MWAG truth model in FrontSim. ....................................................................................150
Figure 17.8 ........ The effective solvent and IOR oil have a master-slave relationship ....................................................153
Figure 17.9 ........ The slope of the mobilization curve reflects the solvent efficiency .......................................................157
Figure 17.10 ...... IOR mobilization curve construction from Truth Model simulations .....................................................159
Figure 17.11 ...... IOR mobilization curve and floodrate ...................................................................................................159
Figure 17.12 ...... Using water as a swing variable to account for solvent, lean gas tracer and produced IOR oil ...........166
Figure 17.13 ...... Decreasing the A parameter raises the mobilization curve. .................................................................169
Figure 17.14 ...... Adjusting breakthrough times by adjusting the APV factors as shown ................................................171
Figure 17.15 ...... Mobilization curve as a function of slug size.........................................................................................176
Figure 17.16 ...... Mobilization curve as a function of injection rate ..................................................................................177
Figure 17.17 ...... Aligning front locations .........................................................................................................................182
Figure 17.18 ...... Example of aligning front locations with the THK parameter ................................................................183
Figure 18.1 ........ Stencil for MPFA flow in 2D between cells (i,j) and (i+1,j) ....................................................................195
Figure 18.2 ........ K-orthogonality error indicator ..............................................................................................................197
Figure 19.1 ........ Fractional flow function approximated by a continuous piece-wise linear function ..............................201
Figure 19.2 ........ Initial saturation at time t1 .....................................................................................................................201
Figure 19.3 ........ Saturation at time t2 with flow from left to right .....................................................................................201
Figure 19.4 ........ Saturation at time t3 with flow direction from right to left .....................................................................202
Figure 19.8 ........ Water above oil ....................................................................................................................................203
Figure 19.9 ........ Linear relative permeability curves .......................................................................................................203
Figure 19.10 ...... Linear flow function ..............................................................................................................................203
Figure 19.11 ...... Linear flow function multiplied by linear oil relative permeability and negative density difference........203
Figure 19.12 ...... Gravity flow function with negative density difference: initial fronts .....................................................204
Figure 19.13 ...... Gravity flow function with negative density difference: after front collisions ........................................204
Figure 19.14 ...... Gravity flow saturation, distribution, initial ............................................................................................204
Figure 19.15 ...... Gravity flow saturation, distribution, snapshot after time t1 ..................................................................204
Figure 19.16 ...... Gravity flow saturation, distribution, snapshot after time t2 ..................................................................204
Figure 19.17 ...... Gravity flow saturation distribution, initial .............................................................................................205
Figure 19.18 ...... Gravity flow saturation distribution, snapshot after time t1 ..................................................................205
Figure 19.19 ...... Gravity flow saturation distribution, snapshot after time t2 ..................................................................205
Figure 22.1 ........ Comparison of water flood simulations. ...............................................................................................215
Figure 22.2 ........ Example of improved reservoir performance with PFM ........................................................................216
Figure 22.3 ........ Typical Successful Waterflood Performance. ......................................................................................218
Figure 22.4 ........ Repeated 5-spot waterflood pattern. P wells are producers and I wells are injectors ..........................220
Figure 22.5 ........ Same model as Figure 22.4 but with a heterogeneous permeability field ............................................221

List of Figures
Figure 22.6 ......... Injector-producer pair streamline bundles.............................................................................................223
Figure 22.7 ......... Showing computed weights a) picture on the left is for alpha=1 and b) picture on the right is for alpha=2.
226
Figure 23.1 ......... Numerical dispersion through the mapping process ............................................................................238
Figure 25.1 ......... Langmuir model ....................................................................................................................................247
Figure 26.1 ......... Y- and Z- transmissibility expressions...................................................................................................251
Figure 28.1 ......... Two-level group hierarchy.....................................................................................................................262

List of Figures
List of Tables
Table 5.1 Dual porosity keywords............................................................................................................................57
Table 6.1 Coefficients m1 and m2: variation with the equation of state ..................................................................60
Table 6.2 The dependence of and on the equation of state ....................................................................................61
Table 8.1 FrontSim behavior when GEOFLOFS is operational. ..............................................................................82
Table 8.2 Combining GEOFLOFS Injection Scheduling with GCONINJE ...............................................................83
Table 10.1 GRID section keywords ...........................................................................................................................98
Table 17.1 Master-slave tracer pairs .......................................................................................................................153
Table 17.2 List of solvent allocation keyword parameters for the RANKWELL injectors ...........................................174
Table 17.3 Incremental oil recovery from a typical injector/producer pair................................................................178
Table 17.4 Different approaches for scaling truth model results .............................................................................179
Table 17.5 Scaling approaches ...............................................................................................................................179
Table 17.6 Example: ................................................................................................................................................180
Table 17.7 Example .................................................................................................................................................180
Table 17.8 Rates reported in the SUMMARY file at the specified time steps..........................................................187
Table 17.9 PVT properties are also treated as input variables ................................................................................187
Table 17.10 Formulae to be used for computing the total well rates of the IOR tracer variables ..............................188
Table 17.11 Formulae to be used for computing the oil well rates of the IOR tracer variables .................................188
Table 17.12 Formulae to be used for computing the gas well rates of the IOR tracer variables ...............................188
Table 17.13 Formulae to be used for computing the water well rates of the IOR tracer variables. ...........................189
Table 17.14 Reporting variables for IOR solvent logic allocation ..............................................................................190
Table 17.15 Reporting variables for the facility limit logic ..........................................................................................190
Table 17.16 Reporting variables in each cell at specified reporting time steps .........................................................191
Table 31.1 Table of the units used for two conventions ..........................................................................................271
Table 31.2 Constants used in the two unit conventions ..........................................................................................272
Table 31.3 Some useful conversion factors.............................................................................................................273

List of Tables
List of Tables
Introduction
Chapter 1
Overview
The ECLIPSE simulator suite

The ECLIPSE simulator suite consists of three separate simulators: ECLIPSE 100 specializing
in black oil modeling, ECLIPSE 300 specializing in compositional modeling and ECLIPSE
FrontSim, specializing in streamline and front tracking.
ECLIPSE 100 is a fully-implicit, three phase, three dimensional, general purpose black oil
simulator with gas condensate options. ECLIPSE 300 is a compositional simulator with cubic
equation of state, pressure dependent K-value and black oil fluid treatments. ECLIPSE 300 can
be run in fully implicit, IMPES and adaptive implicit (AIM) modes.
FrontSim is a three-dimensional, three-phase fluid flow simulator based on a state-of-the-art
streamline concept. FrontSim can perform simulations on large and complex reservoir models
several orders of magnitude faster than standard finite difference simulators, and can achieve
this without grid orientation effects or numerical dispersion.
The streamline concept is based on an IMPES (Implicit Pressure Explicit Saturation) solution.
First the pressure is solved with an implicit numerical method and then the saturation equation
is solved using an explicit method. The pressure is used to compute a velocity field which is, in
turn, used to compute streamlines. The saturation equations are solved on the streamlines using
front tracking and numerical methods.
About this manual

This manual contains the technical descriptions of the principal features in the simulators. (The
data file structure and the data requirements for each keyword are described separately in the
"FrontSim User Guide".) A flag table at the start of each chapter indicates which of the
simulators contain the corresponding feature. The flag table also indicates whether the feature
is a Special Option that must be purchased separately.
FrontSim Technical Description Introduction 13

Overview
In chapters that are relevant to all simulators, some paragraphs or sections may apply to only
one of the simulators. These are distinguished by margin notes such as that containing the word
FrontSim as shown below.
FrontSim Example of margin note.
If you are reading this manual online (for example, the PDF file), you may click on
A cross reference (for example, "Local Grid Refinement" on page 93). This takes you to
the relevant chapter or section of the manual (or of another manual).
A hyperlink (for example, the WCONPROD keyword). This takes you to the relevant
keyword description in the User Guide.
14 Introduction FrontSim Technical Description

Overview
FrontSim features
Free format input

Input data for FrontSim is prepared in free format using a keyword system. Any standard editor
may be used to prepare the input file. Alternatively ECLIPSE Office may be used to prepare
data interactively through panels, and submit runs. Its help facility contains most of the
FrontSim User Guide.
Geometry options
The FrontSim corner-point geometry option is unique and allows extremely complex
geometries to be constructed to give a faithful representation of the reservoir geology. The
programs FILL, GRID or FloGrid can be used to prepare corner-point data for FrontSim or
ECLIPSE. GRAF, GRID or ECLIPSE Office may be used to display the grid in a variety of
ways. For example, in a large 3D study, you may request a number of XZ cross-sections to be
displayed simultaneously. Transparent areal overlays of the grid are useful for precise checking
against geological maps.
Corner-point geometry is especially useful for highly faulted reservoirs. The grid may be
distorted areally to fit along fault lines and displaced vertically to model complex scissor faults.
The resulting non-neighbor grid transmissibilities are computed automatically by FrontSim.
Flow across displacement faults is handled efficiency by the FrontSim solution procedures.
See "Transmissibility Calculations" on page 249 for further information.
Non-neighbor connections
In conventional grid systems each cell has only one neighboring cell in each direction (two in
each dimension). Thus in 2D grids, each cell can have up to four neighbors, and in 3D grids each
cell can have up to six neighbors. Flow only takes place between neighboring cells.
FrontSim will generate the non-neighbor connections arising from displacement faults
applications automatically, and calculate their transmissibilities. If you are using the Local Grid
Refinement, FrontSim will also handle the non-neighbor connections arising from the third
application automatically.
Non-neighbor connections give rise to off-band elements in the Jacobian matrix and these are
included in the procedure used to solve the linear equations.
Run-time dimensioning
All of the internal arrays in FrontSim are dimensioned at run time to minimize the use of
computer memory. Most of the data required for FrontSim to compute the size of its internal
arrays is deduced from the dataset. Space is saved by not storing unnecessary data for inactive
cells.

FrontSim features
PVT and rock data
FrontSim honors pressure and saturation function data precisely as it is specified by the user. It
does not follow the practice, common in the industry, of smoothing the data by interpolating to
a fixed number of equally spaced saturation intervals.
Different table numbers can be used for different parts of the reservoir. Thus, for example,
separate saturation tables can be entered for each type of rock.
Saturation table scaling

The connate, critical and maximum saturation end points of the relative permeability and
capillary pressure curves may be input separately for each grid cell within the reservoir or,
alternatively, as a series of depth tables for regions within the grid. The scaling option allows
you to specify relative permeability and capillary pressure data which are functions of a
normalized saturation. In addition, it allows the modeling of reservoirs where depth variations
occur in the initial critical or connate fluid saturations.
See "Saturation Table Scaling" on page 119 for further information.
Tracer tracking
The Tracer Tracking option is a general facility to determine the movement of marked fluid
elements during a simulation run. It may be used, for example, to differentiate the movement of
water injected by different wells and initial aquifer water, or to predict the variation in salinity
or concentrations of other chemical species.
See "Tracer Tracking" on page 245 for further information.
Individual well controls

FrontSim has a comprehensive set of options for controlling individual wells. Producers can
operate at a specified value of the oil rate, water rate, liquid rate, gas rate, reservoir fluid voidage
rate, and bottom hole pressure. The engineer supplies a target value for one of these quantities,
and limiting values for the bottom hole pressure. The well will operate at its specified target as
long as none of the limits is violated. If a limit is going to be violated, the well will automatically
change its mode of control to keep operating within its allowed limits. Injection wells have a
similar set of controls. Target values can be supplied for the injection rate at surface conditions
and reservoir conditions, and target or limiting values can be supplied for the bottom hole
pressure.
To aid the process of history matching, production wells can be placed under an additional type
of control. Their observed oil, water and gas rates are input, and the well can be made to produce
at the equivalent liquid or reservoir fluid volume rate. Thus the rate of pressure decline should
be approximately correct even when the water cut and gas-oil ratio are not fully matched. Both
the observed and calculated flow rates are written to the SUMMARY file for graphical
comparison.
Production wells can also be subject to an additional class of economic constraints. A producer
will be automatically shut-in if its oil, gas or liquid rate falls below an economic limit, or if its
water cut, gas-oil ratio or water-gas ratio exceeds the specified upper limit.

FrontSim features
See "Well controls and limits" on page 259 for further information.
Group and field production controls

The simulator contains facilities to control the collective behavior of groups of wells, or the field
as a whole. The overall production rate of oil, water, gas, liquid or reservoir fluid (that is
voidage) from one or more groups can be made to meet a specified target.
The groups target rate is apportioned between all its producers in proportion to their production
potentials, but ensuring that no well violates its individual pressure limits. When the group no
longer has enough potential to meet its production target, the production rate will decline.
The same set of controls and limits can also be applied to the overall field production. See
"Group and field control facilities" on page 262 for further information.
Crossflow and co-mingling in wells

When a well is completed in more than one grid block, the flow rate from each grid block is
proportional to the product of three quantities:
1 The transmissibility between the grid block and the well bore.
2 The mobility of the phase in the grid block at the perforations.
3 The pressure drawdown between the grid block and the well bore.
FrontSim takes full account of all three quantities when apportioning a wells target flow rate
between its various grid block connections. This is especially important in cases where a well
is completed in two or more layers of a reservoir with poor vertical communication, where the
drawdown at each layer can be substantially different.
The crossflow facility can be turned off if the engineer does not wish this to occur.
Highly deviated and horizontal wells

There is no restriction on the location of the completions within each well. A highly deviated
well can be completed in a number of grid blocks that do not all belong to the same vertical
column. In fact a well can be completed in several grid blocks within the same layer, enabling
the simulator to model wells completed in horizontally-adjacent grid blocks. The Wellbore
Friction option may be used to investigate the effects of friction pressure losses along the wells
perforated length, which could be important for horizontal wells.
Fine grid equilibration

The initial pressures and saturations in the reservoir grid blocks can be calculated by the
equilibration facility. Each phase in the reservoir is given a hydrostatic pressure gradient,
dependent on its local density. The saturations are determined from the local pressure
differences between the phases, using the capillary pressure tables.

FrontSim features
A common practice is to set the fluid saturations within each grid block equal to the local
saturations at the center of the block. However, this procedure can produce significant errors in
the Fluids-in-Place estimation when a large grid block contains a fluid contact or part of a
transition zone. FrontSim has an option to improve the accuracy of the Fluids-in-Place
calculation in this situation. The fluid saturations are averaged to obtain the overall fluid
saturations within the block. The method takes account of the shape of grid blocks.
See "Initializing the Study" on page 85 for further information.
Aquifers
Aquifers may be represented by a choice of two analytic models, a constant flux model and a
numerical model. The analytic models are the Fetkovich aquifer and the Carter-Tracy aquifer.
The constant flux model allows you to specify the flow per unit area at any time during the
simulation. The numerical model consists of a sequence of aquifer cells connected together in
one dimension. The innermost cell of the numerical aquifer sequence may be connected to any
number of reservoir cells. The depth, dimensions, porosity, permeability, etc., of each aquifer
cell may be specified separately, giving the user complete flexibility in defining each aquifer.
See "Aquifer Modeling Facilities" on page 29 for further information.

FrontSim features
Ancillary programs
Ancillary programs available with FrontSim are described below.
FILL
FILL generates unconventional grid systems based on corner point geometry. Grids may be
distorted to fit along fault lines. Sloping displacement faults, complex scissor faults, distorted
wedge shaped grids etc. may be generated easily using FILL.
As its name implies, FILL is specially designed to interpolate sparse data which may only be
known at a few points on the grid. Missing values are filled in to generate complete grid data
files for FrontSim. For example, rock properties such as porosity need only be specified at a few
points in each grid layer and FILL will provide the rest.
GRAF
GRAF provides an easy to use, menu driven graphics capability.
Typical uses of GRAF are:
Line graphics showing, for example, field pressure against time.
Grid graphics showing the reservoir grid including faults.
Dynamic solution displays showing animated color time displays of saturations or
pressures etc.
Line graphics are generated from SUMMARY files created by FrontSim at each report time. Each
SUMMARY file contains data relating to field, group, well, connection, region and cell quantities
recorded at intermediate timesteps. Thus the SUMMARY files (like the Restart files) may be used
to monitor runs in progress.
Grid graphics are generated from a GRID file created by FrontSim at the start of a simulation
run. GRID files contain the locations of the corners of each cell in the reservoir, and may be used
to display the grid in a variety of ways.
Dynamic solution displays are generated from RESTART files created by FrontSim at
prescribed times. RESTART files contain detailed information such as saturations and pressures
for each grid cell. Their main purpose is to enable FrontSim to be restarted at the prescribed
times. However, they may also be used in conjunction with the GRID file to generate color
displays of saturations and pressures. You can step forwards or backwards through color
sequences creating animated displays of water floods, gas coning events etc.
As well as color-filled solution displays, GRAF provides options for contours, arrow plots and
transmissibility displays. Hard copy output of GRAF can be generated on a a wide range of
plotters and printers.
Note GRAF does not support .SLNxxxx file formats.

Ancillary programs
GridSim
GridSim is a software tool for Windows (98/NT/2000) PCs or UNIX/X-terminals to visualize
results from - and edit input to - the FrontSim and ECLIPSE reservoir simulators. These
simulators are compatible for most of the files read and saved by GridSim. FrontSim will
however also write extra files containing streamline data.
GridSim also has an import feature for VIP grid and graph files, and for ACRES grid files.
(ACRES is the ARCO in-house simulator.)
In addition to grid and data viewing, GridSim features editing capabilities for block arrays,
corner point node depths, well perforations, and other tools. It works just as well at your desktop
PC or X-terminal as on a dedicated 3D workstation, since it is only dependent on 2D graphics
in hardware; the 3D mapping is done system independently in software.
GridSim uses Windows or X/Motif graphical user interface and Postscript hardcopy facilities.
The program exploits the mouse as an intuitive tool for 3D grid viewing operations (rotate,
zoom, etc.) and for clicking/selecting block areas, nodes, etc. The philosophy is to provide the
reservoir engineer with a quick and easy-to-learn tool for simulation results and input, that also
has the potential for more experienced and complex use. The macro file input feature expands
its versatility both for interactive and batch use.

Ancillary programs
Additional programs
Programs which may be purchased as additions to the basic FrontSim system are described
below.
FrontSim options
IOR tracer logic
The IOR tracer logic extension increases the modeling capability of the program. This special
extension may be purchased separately as required.
ECLIPSE Office
ECLIPSE Office provides an interactive environment for the creation and modification of Black
Oil and Compositional models, the submission and control of runs, the analysis of results and
report generation. Data sets may be created using a PEBI gridding module, correlations for PVT
and SCAL data, keyword panels, or input from other pre-processors. Panels exist for all
FrontSim keywords. Tools are provided for the management of cases within a project. Run
management is provided for submitting, monitoring and controlling simulator execution. New
interactive graphics are used to view results.
FloGrid
FloGrid is an interactive 3D product that constructs fluid flow simulation grids and properties.
FloGrid imports geological data in most popular map and 3D geological model formats,
including the POSC Rescue format. Simulation grids can be exported in FrontSim and other
formats. FloGrid provides full 3D visualization of the data - wells, maps, geocellular models,
faults and simulation grids.
FloGrid supports the generation of both structured and unstructured grids. Structured
(Cartesian) grids are optimized to fit to selected faults and the boundary, with remaining grid
nodes placed to minimize orthogonality errors. Faults that are not explicitly gridded may be
automatically zig-zagged. For 3D geological models, simulation layering can, optionally, be
determined using algebraic and flow based techniques to automatically identify simulation
layers that best capture the flow characteristics of the fine scale models.
Unstructured PEBI and tetrahedral (PetraGrid) grids can be tailored to honor all boundaries,
wells and faults. They support rectangular and radial refinements around wells, and general
refinements consisting of a rectangular, triangular or hexagonal grid within a specified
polygonal region.
FloGrid also provides a suite of algebraic and flow based single phase upscaling tools that
calculate appropriate simulation block properties from the fine scale geologic or stochastic
property grids.

Additional programs
FloViz
FloViz is an interactive 3D visualization system for the display and analysis of reservoir
simulation results. FloViz has a simple to operate graphical user interface and provides faster
3D interaction and animation of simulation results. It runs on both PCs and workstations.
FloVIz allows multiple views (which can be tailored), through the use of slave viewers, of the
reservoir with independent slicing, property, and time animation. Model rotation can be shared
across the views. FloViz can display both structured and unstructured grids, and, also,
streamlines. The program contains a host of new options to allow easier visual interpretation of
the grid and its results.
GRID
GRID is an interactive program used to build reservoir models, design simulation grids and
produce input data for FrontSim. The basic geological model consisting of contours, faults, map
features and well locations may be digitized or input directly from industry standard map files.
The geological model is used as a background display to aid the construction of the simulation
grid.
Features include color graphics, corner-point or conventional geometry, sloping or vertical
faults, areal, cross sectional or three dimensional displays, contouring back of grid properties to
compare with original input data, flexible easy to use editing and comprehensive help facilities.
Locally refined and coarsened grids can be prepared and displayed, for use with the Local Grid
Refinement option.
The ECLMAP options in GRID provide facilities for handling seismic shot line data, volumetric
calculations and depth conversion of seismic horizons or map grids.
PlanOpt
PlanOpt is an interactive tool to assist you in choosing the potential locations of vertical
production wells during development. PlanOpt applies pre-defined screening criteria to each
column of grid blocks in a 3D simulation model to determine which could sensibly
accommodate a production well. A vertical well is completed in each column of cells that
satisfies the criteria. A simulation run is then used to rank the wells and the least effective wells
are eliminated. This cycle is repeated until the optimum well locations have been identified.
PVTi
PVTi is an interactive Equation of State (EoS) package used for the analysis of laboratory
measurements performed to determine the phase behavior of reservoir fluids. The quality of the
laboratory measurements can be tested through material balance checks. Laboratory
experiments can be simulated using a variety of cubic EoS, and any discrepancies between
calculated and measured data can be minimized by regression of one or more EoS parameters.
The EoS model can then be used to generate data suitable for use in FrontSim and VFPi.

Additional programs
SCAL
SCAL is a tool to help you effectively use laboratory derived relative permeability and capillary
pressure measurements in reservoir simulation. The program has facilities to read in laboratory
data, perform quality control such as curve smoothing, group data according to lithological
parameters and end-point values, transform the laboratory data into rock curves suitable for
FrontSim, and automatically assign these curves to grid cells on the basis of rules which you set
up (for example, as a function of porosity / permeability / lithological parameters). The output
consists of a series of INCLUDE files, for both the PROPS and REGIONS sections. The program
has facilities for 3D visualization of simulation grids and 3-phase relative permeabilities, and
for experimenting with FrontSim end point scaling options. The behavior of SCAL can be
extended or modified by the use of user-programmable command scripts to, for example,
implement a company confidential algorithm.
Schedule
Schedule imports production data from a variety of common sources including PA, OilField
Manager and Finder, and generates the corresponding FrontSim production control keywords.
Production data can also be extracted from existing FrontSim models. The program has
advanced graphic display features which simplify the editing, validating and averaging of
production data. Timesteps on which rates are averaged are based on a user defined combination
of calendar periods and reservoir events such as well completions, shut-ins and simulations.
All the main categories of production data necessary for simulation can be handled by Schedule.
These typically take the form of well deviation surveys, historical production and injection
volumes and completion data. A key feature of Schedule is the capability to generate accurate
and representative COMPDAT keywords with time-varying connection factors calculated from
perforation data specified in terms of measured depths and formations. Corrections are made for
deviated wells, partial penetrations and multiple completions within a single cell.
Schedule has comprehensive facilities for creating prediction run controls for FrontSim.
Controls can be set for wells, groups and the field. Wells can be created by defining IJK
locations or by digitizing in the 3D Viewer, where simulation results can be used as a backdrop
to aid placement.
Schedule can also prepare data for input to the Multi-segment Well model. It can read data
describing casing, liner and tubing characteristics and locations of chokes, packers and inflow
control valves.

Additional programs
Licenses
To run FrontSim, and also to run the additional FrontSim option, you need to obtain an
appropriate FLEX license.
In addition, a DATACHECK license is available, which allows FrontSim to run a dataset in
NOSIM mode to check for data errors without taking up a full license. A DATACHECK license
will also allow a cross-section simulation case (either NX=1 or NY=1) to run.
The FLEX license checking procedure checks for the availability of an appropriate license for
an FrontSim Options when a keyword activating the feature is encountered. In most cases the
activating keyword is in the RUNSPEC section and is thus encountered at the beginning of the
run.

Licenses
Allocation Factors
Chapter 2
Introduction
If the ALLOC mnemonic in the RPTSCHED keyword is set, FrontSim will generate allocation
ECLIPSE 100
ECLIPSE 300
reports in the .prt file or a separate .alloc file. in ASCII-format. If the ALLOC mnemonic
SPECIAL is set to 1 - a simple report is generated including allocation factors and pore volumes (drainage
x FRONTSIM area) for wells and for injector-producer pairs. If you want an extended report that also includes
surface rates, surface volumes etc. the mnemonic should be set to 2 (.prt) or 3 (.alloc).
Determine allocation factors

The allocation factor for a producer P from an injector I is the sum of the streamline rates
(bundle) coming from injector I divided by all the streamline rates coming to producer P. The
allocation factor for an injector is computed in a similar way. The production/injection rates that
are not represented by a well (such as PSIDE, PNODE, FLUXSIDE and aquifers) are
represented by I-edge and P-edge.
In general the allocation factor for a well should add up to 1.0 (unity); but for compressible
models this is not always the case, as the flow rate varies along the streamlines. The flow rate
going into the bundle is not the same as the flow rate coming out of the bundle.
FrontSim Technical Description Allocation Factors 25

Introduction
Allocation factor reports
The allocation factors are computed every report step (frequency set by RPTSCHED).
Below is a description of the contents of the .alloc file:
Well names. Each well has one line of output for the total of the well and one for each
bundle associated with this well. A bundle is a set of streamlines that connects an injector-
producer pair.
Flow directions (for extended reports)
Rate for the well or for the bundles. This is the total rate at reservoir conditions. For
extended reports surface rates and surface volumes are also included
Allocation factor. Bundle rate divided by well rate.
Pore Volume. The pore volume represented by the bundle or well.
I-edge. Injection not represented by an injector - which is the boundary conditions (PSIDE
etc.).
P-edge. Production not represented by a producer - which is the boundary conditions
(PSIDE etc.).
The total pore volume not visited by any cell and the total pore volume for the reservoir are
also reported.
Examples
Example 1
Using RPTSCHED ALLOC = 3, for complete output
26 Allocation Factors FrontSim Technical Description

.
FrontSim Technical Description Allocation Factors 27

Example 2
A flux of 160 rm3/d is set at the left and right boundaries of the reservoir - no wells included,
RPTSCHED ALLOC = 1.
Allocation fractions at steps: 1 - 91.25 Days (02 Apr 1997)
Wells Rate(M3/D) Fraction PoreVolume(M3)
I-edge -160.00 1.000 8e+006

I-edge - P-edge -160.00 1.000 8e+006
P-edge 160.00 1.000 8e+006
P-edge - I-edge 160.00 1.000 8e+006
PV not visited by any streamline: 0

Total: 8e+006
Allocation factor usages

A bundle is defined for a set of streamlines connecting between a producer P and an injector I.
A streamline injector pattern is defined as a set of bundles connecting all producers to a pattern
injector. Construction of an injector pattern can be used to compute quantities of dynamic
injector volumetric, rate and sweep efficiency. These pattern variables can be used for purposes
of maintaining, enhancing or weakening an injector pattern at run time for optimizing water
flooding and for maximizing field oil production at run time.
FrontSim provides injector based water flooding optimization workflow through the use of
keyword WCONINJP. Such workflows support user supplied lists of static pattern producers. It
also supports computing of dynamic list of producers and its allocation factor and sweep
efficiency based on computed streamline injector pattern. Summary vector outputs are provided
for pattern injector rates, volumes and sweep efficiency. For further details of summary vectors
please refer to "FrontSim User Guide".
28 Allocation Factors FrontSim Technical Description

Aquifer Modeling Facilities
Chapter 3
Introduction
This chapter describes the aquifer models available in FrontSim. These are:
x ECLIPSE 100
x ECLIPSE 300 Numerical aquifers
SPECIAL
x FRONTSIM Carter-Tracy aquifers
Fetkovich aquifers
Constant flux aquifers.
Numerical aquifers are represented by a one-dimensional row of cells within the simulation
grid. The other three types of aquifer, classed as analytic aquifers, are represented by
computed source terms in the reservoir grid cells with which they connect.
FrontSim Technical Description Aquifer Modeling Facilities 29

Introduction
Numerical aquifer
A numerical aquifer is modeled by a one-dimensional row of cells. A set of cells in the
simulation grid is nominated to represent the aquifer, which may then connect to specified faces
of the reservoir (using the AQUCON keyword).
The properties of the aquifer grid blocks (length, cross-sectional area, porosity, permeability,
initial pressure, depth, PVT and saturation table numbers) may be declared explicitly using
keyword AQUNUM in the GRID section, or if the properties for the aquifer cells are defaulted,
they are taken from the grid block values using data entered in the GRID and EDIT sections.
This enables the aquifer properties to be independent of its actual position within the grid.
The aquifer should be connected to a face of the reservoir using AQUCON. The first cell of the
aquifer declared in AQUNUM connects to the specified faces of the reservoir by non-neighbor
connections. The set of cells defining the aquifer are connected together (possibly by non-
neighbor connections) in the order specified in AQUNUM. The aquifer cells are isolated from the
grid except for these connections.
The one-dimensional rows of cells each have cross-section, length and depth, but no further
information concerning their shape.
The transmissibility between two aquifer cells is thus given by:
CDARCY-
TR = --------------------------- [EQ 3.1]
1 Ti + 1 Tj
with
2 PERMX i XSECT i
T i = -----------------------------------------------------
-
LENGTH i
where
PERMX i is the permeability of aquifer cell i
XSECT i its cross-section
LENGTH i its length.
This expression is used for transmissibilities between aquifer cells in both radial and cartesian
geometries. However, in connecting the first aquifer cell to a grid block, the appropriate radial
or cartesian transmissibility from the block edge to the centre is used (see the AQUCON
keyword).
If required, a transmissibility multiplier may be applied to the calculated transmissibility
between the first aquifer block and the nominated connecting face of the reservoir, using
keyword AQUCON, in order to aid history matching.
No multiplier is applied to the transmissibility of the inter-block connections within the one-
dimensional aquifer. The values of transmissibility multipliers for the grid (MULTX etc.) entered
in the GRID section do not apply to any numerical aquifer connections.
For the AQUNUM keyword, if the initial aquifer pressure is not entered (by choosing the default
value) or even if a negative value is specified, then the initial pressure is calculated to place the
aquifer as near as possible in equilibrium with the reservoir.
Summary quantities for a numerical aquifer may be obtained by defining each aquifer as a fluid-
in-place region. It is then possible to examine the aquifer inflow performance and pressure
support supplied to the reservoir.
30 Aquifer Modeling Facilities FrontSim Technical Description

Numerical aquifer
Carter-Tracy aquifer
The Carter-Tracy aquifer model is a simplified approximation to a fully transient model, which
avoids the need for superposition. The method uses a table that supplies a constant terminal rate
influence function. Although the theory has been developed for a radially symmetric reservoir
surrounded by an annular aquifer, the method is applicable to arbitrarily-shaped reservoirs.
The two main parameters that govern the behavior of the aquifer are the time constant (with the
dimension of time):
2
w C t r o
Tc = --------------------
- [EQ 3.2]
ka c1
where
ka is the aquifer permeability
is the aquifer porosity
w is the viscosity of water in the aquifer
Ct is the total (rock + water) compressibility
ro is the outer radius of the reservoir (or inner radius of the aquifer)
c1 is 0.008527 (METRIC, PVT-M); 0.006328 (FIELD); 3.6 (LAB)
and the aquifer influx constant (with the dimension of total influx per unit pressure drop)
2
= c 2 hC t r o [EQ 3.3]
where
h is the aquifer thickness
is the angle astounded by the aquifer boundary from the centre of the reservoir, in degrees
divided by 360
c2 is 6.283 (METRIC, PVT-M); 1.1191 (FIELD); 6.283 (LAB).
The time constant T c is used to convert time t into dimensionless time t D via
t-
tD = ---- [EQ 3.4]
Tc
The Carter-Tracy model uses tables of dimensionless time versus a dimensionless pressure
influence function. The default table is for an infinite reservoir with constant terminal rate as
given by van Everdingen and Hurst, but you may supply alternative tables using AQUTAB in the
PROPS section.
The Carter-Tracy model expresses the pressure drop at the aquifer boundary in terms of the
dimensionless pressure influence function PID by
Q
p a0 p = ------a PI D(tD) [EQ 3.5]

where
Qa is the aquifer inflow rate

p a0 is the initial pressure of water in the aquifer
p is the average water pressure on the aquifer/reservoir boundary.
The average inflow rate from the aquifer to a grid block i over a simulator time interval [ t, t + t ]
is calculated as
Q ai = i { a b [ pi ( t + t ) p i(t) ] } [EQ 3.6]
where
p ai W a(t)PI D (t + t)D
1- ------------------------------------------------------------------------
a = ---- [EQ 3.7]
T c PI (t + t) t PI ( t + t )
D D D D D
and

b = ----------------------------------------------------------------------------------
- [EQ 3.8]
Tc [ PI D(t + t) D tD PI D ( t + t )D ]
where
p ai is the pressure drop pa0 + g ( d i da ) p i ( t + t )
PID is the derivative of PID with respect to t D
i is the area fraction for each connection.
Here, the area fraction for each connection is given by:
mi Ai
i = ------------------
-
mi Ai
where
Ai is the area of the block face communicating with the aquifer
mi is an aquifer influx coefficient multiplier.
The aquifer influx rates calculated from [EQ 3.6] contribute the residual for the implicit
equations solved by FrontSim at time t . The cumulative aquifer influx W a(t) used in [EQ 3.7]
is updated explicitly at the end of the timestep.
The aquifer properties (compressibility, porosity, initial pressure, depth, radius etc.) should be
defined using keyword AQUCT, and the aquifer connections to one or more faces of the reservoir
should be made using the keyword AQUANCON.
If the initial aquifer pressure is defaulted, it will be calculated from [EQ 3.11] such that the
aquifer is in initial equilibrium with the reservoir.
The aquifer should also be given a table number for the influence function table that it should
use. Influence function tables may be supplied with the AQUTAB keyword in the PROPS
section. FrontSim has a built-in default influence function table (table number 1), which
represents the constant terminal rate solution for an infinite aquifer as given by van Everdingen
and Hurst.
For Tracer Tracking runs, the initial concentrations of water phase tracers in the aquifer may be
supplied using the keyword AQANTRC in the SOLUTION section.
(For more information, see [Ref. 19].)

Fetkovich aquifer
The Fetkovich aquifer model uses a simplified approach based on a pseudosteady-state
productivity index and a material balance relationship between the aquifer pressure and the
cumulative influx.
This model assumes that the pressure response is felt uniformly throughout the entire aquifer.
The Fetkovich model is best suited for smaller aquifers which may approach a pseudo steady-
state condition quickly.
The aquifer inflow is modeled by the equation:
Q ai = d ( W ai ) = J i [ p a p i + g ( d i d a ) ] [EQ 3.9]
dt
where
Q ai is the inflow rate from the aquifer to the connecting grid block i
W ai is the cumulative influx from the aquifer to grid block i
J is the specified Productivity Index of the aquifer
i is the area fraction for the connection to grid block i
pa is the pressure in the aquifer at time t
pi is the water pressure in a connecting grid block i
is water density in the aquifer
di is the grid block depth
da is the datum depth of the aquifer.
The area fraction for each grid block connection is given by:
mi Ai
i = -----------------
- [EQ 3.10]
mi Ai
where
Ai is the area of the block face communicating with the aquifer
mi is an aquifer influx coefficient multiplier.
For vertical faces, the areas A i are multiplied by the net-to-gross ratio of the connecting grid
blocks. You may specify the influx multiplier mi to help with the history matching process.
The pressure response in the aquifer is determined by the material balance equation
Wa = C t V w0 ( p a0 p a ) [EQ 3.11]
where
Wa is the cumulative total influx from the aquifer
Ct is the total (rock + water) compressibility of the aquifer
V w0 is the initial volume of water in the aquifer

Fetkovich aquifer
p a0 is the initial pressure of water in the aquifer.
If the tracer option is used, FrontSim will also account for the inflow of the tracer from the
aquifer.
The aquifer performance essentially depends on two parameters, the aquifer time constant and
the productivity index. The aquifer time constant is given by
C t V w0
Tc = --------------
- [EQ 3.12]
J
and has the dimension of time.
Under the assumption of uniform reservoir pressure in the connecting grid blocks, and by
integrating [EQ 3.9] and [EQ 3.11], the average influx rate over the time interval t is expressed
as
1 exp ( t T c )
Q ai = i J ( pa p i + g ( d i d a ) ) ---------------------------------------
-
[EQ 3.13]
t T c
which is the form used by FrontSim to compute the influx rates.

At the end of each timestep, the aquifers cumulative total influx is incremented and its pressure
is updated using [EQ 3.11].
By varying the aquifer volume and the productivity index, the Fetkovich model can encompass
a range of aquifer behavior from steady state to the pot aquifer. If the product C t Vw0 is given
a large value, so that the time constant is very large, the behavior approaches that of a steady
state aquifer, in which the pressure on the external boundary does not change. Alternatively, if
the productivity index is given a large value so that the time constant is small, the behavior
approaches that of a pot aquifer, in which the pressure is in approximate equilibrium with the
reservoir at all times.
The aquifer properties (compressibility, porosity, initial pressure, depth, productivity index etc.)
should be defined using keyword AQUFETP, and the aquifer connections to one or more faces
of the reservoir should be made through the keyword AQUANCON. If the initial aquifer pressure
is defaulted, it will be calculated from [EQ 3.9] such that the aquifer is in initial equilibrium with
the reservoir.
For Tracer Tracking runs, the initial concentrations of water phase tracers in the aquifer may be
supplied using the keyword AQANTRC.
SUMMARY file quantities for the aquifer are output, named AAQR (influx rate), AAQT
(cumulative influx) and AAQP (aquifer average pressure). For more details, see [Ref. 18].

Fetkovich aquifer
Constant flux aquifer
A constant flux aquifer has its water influx rate specified directly by the user, instead of being
calculated by an analytic aquifer model. But for the purpose of dimensioning etc., it is classed
with the other analytic aquifer models. One use of a constant flux aquifer is to model rainfall
influx for environmental applications.
The water flow rate into a grid block from a constant flux aquifer is given by:
Q ai = F a A i m i [EQ 3.14]
where
Q ai is the inflow rate from the aquifer to the connecting grid block i
Fa is the aquifer flux, entered by the user
A i is the area of the connecting face of grid block i, which is calculated directly from the cell
geometry
mi is the aquifer influx multiplier.
The aquifer should be defined with the AQUFLUX keyword in the SOLUTION section, and the
aquifer connections to one or more faces of the reservoir should be made via the keyword
AQUANCON. To achieve time-dependency, the flux may be modified during simulation by re-
entering the AQUFLUX keyword in the SCHEDULE section
For Tracer Tracking runs, the concentrations of water phase tracers in the aquifer may be
supplied using the keyword AQANTRC.
SUMMARY file quantities for the aquifer are output, named AAQR (influx rate) and AAQT
(cumulative influx) in the SUMMARY section. It is then possible to examine the aquifer inflow
performance and pressure support supplied to the reservoir.

Time stepping control
Chapter 4
Introduction
FrontSim supplies user time stepping control keywords to determine time step size at run time.
These keywords are in following three categories:
1 DATES or TSTEP
2 NEXTSTEP, MINSTEP, MAXSTEP
3 TSCRITFS.
The FrontSim time stepping controller prioritizes low category over high category keywords.
Specifically DATES or TSTEP are reporting step keywords, NEXTSTEP, MINSTEP, and
MAXSTEP are manual step keywords to control or sub-divide reporting steps.
Keywords are prioritized in the listed order (NEXTSTEP has higher priority than MINSTEP, and
MINSTEP has higher priority than MAXSTEP) within the same category.
TSCRITFS is an automatic time stepping control keyword which includes four methods. Any
number of these methods can be used at the same time. Each user-activated method computes
an autostep, and the FrontSim auto time stepping controller chooses the smallest autostep
among user-activated methods.
FrontSim can internally determine a Half Reporting step when the selected time step (from the
time step controller) is more than 50% of the current remaining reporting step. This Half
Reporting step is made to facilitate SUMMARY section reporting needs.
FrontSim Technical Description Time stepping control 37

Introduction
Time stepping control methods
Reporting steps
DATES and TSTEP are standard keywords to specify reporting steps. Reporting steps define the
primary target dates honored during run time.
Time stepping control may shorten a reporting step, to allow pressure solution to converge, to
capture water cut, and to serve other purposes.
You can specify very large reporting steps, for instance on the order of 5 to 10 years. The time
step controller can compute appropriate manual and automatic steps suitable for the model.
Manual time stepping control

NEXTSTEP, MINSTEP and MAXSTEP are manually set, user-entered time stepping controls.
Refer to the "FrontSim User Guide" for more details.
Manual time stepping is simple but it provides limited control. When working with automatic
time stepping, manual time step keywords can provide more precise control.
Automatic time stepping control

TSCRITFS provides several automatic time stepping tuning facilities. These include fluid
volume control, pore volume control, pressure control and flux control. Automatic time
stepping control is helpful when shortening report steps improves accuracy. Time stepping is
one of the many tuning options the user should consider to improve solution quality.
Flux automatic time stepping is for advanced use for tuning a model with possible instability.
In general, FrontSim time stepping should provide (but does not guarantee) an improved
solution. It is your decision when and whether to activate such control.
Fluid volume time step control

The fluid volume step limits the maximum phase fluid volume change V Resv
Phase to MXFVCHG
N
fraction of total pore volume PVTotal :
N
N MXFVCHG PV Total
t FV = MIN ------------------------------------------------------
Resv
- [EQ 4.1]
V Phase t
where:
N
tFV is the estimated fluid volume step at the current time step N (days). The MIN is defined
as the minimum of oil, water and gas phases fluid volume time steps present.
MXFVCHG is the user input fraction limit (dimensionless); this ratio is the mnemonic
MXFVCHG in keyword TSCRITFS.
38 Time stepping control FrontSim Technical Description

N
PV Total is the total fluid volume in reservoir condition at the current time step.
Resv
V Phase t is the estimated phase fluid volume throughput rate,
Resv Resv Resv

V Phase t = V InFlux V OutFlux Phase t
Resv Resv
where V InFlux is the influx volume which includes wells and boundary influx, and V OutFlux is the outflux
volume which includes wells and boundary outflux.
Change of fluid volume rate is determined by the fluid volume throughput due to injection and
production rates. The fluid volume autostep controller is designed to capture events such as
watercut or change of maximum phase fluid volume within the current time step.
Pore volume time step control

Pore volume step is based on limiting the maximum convection throughput, which is
N
MXTHRUPT PV within one pore volume time step:
N
N MXTHRUPT PV Total
t PV = -----------------------------------------------------------------
- [EQ 4.2]
MAX ( V Inj t, V Prod t )
where
N
t PV is the estimated pore volume autostep for the current step N (DAYS),
MXTHRUPT is the user input parameter to set the model pore volume fraction change limit. This
is the mnemonic MXTHRUPT in keyword TSCRITFS.
N
PV Total is the phase pore volume sum at time step N,
MAX ( VInj t, V Prod t )
is the estimated maximum of total volume injection and total volume production throughput rate
at the time step N (in reservoir conditions).
Pressure change time step control
Pressure time step control estimates a pressure rate of change ( dP d t) Est within time step N, to
limit the maximum change of average pressure change to MXDELPA PN within one pressure
step:
N
t Pressure = MXDELPA
N P
----------------------------------------- [EQ 4.3]
Est
( dP dt )
where:
N
t Pressure is the estimated pressure autostep for the current step N(DAYS),
MXDELPA is the user input parameter to set the model pressure change limit. This is the
mnemonic MXDELPA in keyword TSCRITFS,
N
P is the model average pressure at time step N,
Est
( dP dt ) is the estimated average pressure rate of change during current time step N.

A pressure time step can be used to limit pressure change during each run time step. FrontSim
estimates the rate of change of field pressure based on the difference between injection and
production and a weighted total compressibility for the entire field.
The pressure time step may be modified when the actual pressure change within a time step is
larger than the estimated change. This results in a pressure REDO step. The size of a pressure
step can be controlled by a criterion to limit the maximum variations among neighboring
pressure steps to a constant ratio. This ensures that the pressure time step does not alternate from
a very large step size to a very small step size. Large variations among time steps can induce
instability at run time. In practice, this mechanism is activated only for long reporting steps (in
practice, reporting steps of at least 31 days).
The MXDELPA times the average pressure in the above equation is substituted by an absolute
pressure difference in the case that MXPA is set in TSCRITFS.
Flux change time step control

Flux time step control determines a flux autostep by comparing the averaged flux change
between two previous time steps, and by computing a flux step based on this change:
N
N T Remain
t Flux = ----------------------
- [EQ 4.4]
M
N
t Flux is the estimated flux autostep for the current step N,
N
T Remain is the remaining part of the current reporting step to be shortened for the current flux
autostep,
M is an integer multiplier to shorten the current remaining reporting step.
where:
M is estimated as the ratio of a composite flux measure and a user-supplied limit:
N [EQ 4.5]
Composite
M = -------------------------------------
-
MXFLUXCHG
MXFLUXCHG
is the user input limit to scale the model flux change limit. This is the mnemonic MXFLUXCHG
in keyword TSCRITFS.
N
Composite is an estimate of composite model flux change as functions of:
cell flux change FluxN and pore volume throughput change PVN for the current time step N.
where:
This scales the difference in measure between model average cell flux and model pore volume
throughput:
N N N
Composite = PV Flux [EQ 4.6]
where:
N
PV is the relative pore volume change over two previous time steps,
N
Flux is the relative model cell flux change over two previous time steps.

N1
N MAX ( PV Throughput )
PV = 1.0 --------------------------------------------------
- [EQ 4.7]
N
MAX ( PV Throughput )
N1
is pore volume throughput in the previous time step N-1, computed max.
MAX ( PVThroughput )
throughput as described in the Pore Volume time step control.
N
is pore volume throughput in the current time step N, computed in the same
MAX ( PVThroughput )
manner as described in the Pore Volume time step control.
Note that pore volumes are in reservoir conditions.
where:
N1
N F cell
Flux = 1.0 ------------
- [EQ 4.8]
N
F cell
N1
F cell is the cell flux measure in the previous time step N-1,
N
F cell is the cell flux measure in the current time step N.
where:
Cell flux measure F cell has multiple modes. The flux time step may decide to use either the mean
cell flux mode, or the max cell flux mode. Using max flux mode typically leads toward smaller
flux autosteps to further control possible instability.
Because flux time step control is based on computing flux changes NComposite between two
previous time steps, flux time step is only computed/enforced one time step after it is activated.
Other time stepping facilities are enforced on the same time step as they are activated.
Flux time step control may internally compute a control flux step with averaged flux time steps
during a previous report step. The control flux step appears as Estimated flux autostep within
the message prior to its use. The purpose is to even out variations of actual flux autostep during
a (large) reporting time step, and to improve pressure solve convergence speed. Slower
convergence can occur due to use of uneven flux autosteps.
Flux time step control is a second-order time stepping mechanism whose usage often increases
when some type of flux anomaly or instability occurs. Flux time step control makes an effort to
resolve this type of difficulty and to help continue the current run.
Pressure solver convergence time step control

When the pressure solver convergence control is activated in TSCRITFS FrontSim will attempt
to re-solve the pressure with a shorter time step. The new time step is set to a fraction,
DELPCONV in TSCRITFS, of the previously attempted time step. FrontSim continues to cut
the time step until the pressure solver converge or the calculated timestep is less than MINSTEP.
When the time step has been chopped and the pressure solver converged, FrontSim for the
following timesteps attempts to gradually increase time step length by a factor of 2 until your
defined time step length is reached.
Internal time stepping control logic

The FrontSim time stepping controller enforces two sweeps in each time step in order to
calculate the proper time step.

Sweep one is prior to the pressure update; the time step is computed by enforcing the following
three priorities:
DATES or TSTEP defines report steps
NEXTSTEP, MINSTEP and MAXSTEP define user-set manual time stepping limits
TSCRITFS defines the smallest auto time step computed by all activated automatic
timestepping facilities.
The FrontSim timestep controller computes a maximum time step satisfying all the above
priorities.
Sweep two is post pressure update to provide possible timesteps, updated with pressure
information:
MINSTEP checks if the newly computed autostep is smaller than MINSTEP
TSCRITFS defines the maximum autosteps with updated pressure fields.
When sweep two is enforced, it may REDO pressure field updates with the revised timestep.
FrontSim console message indicate a REDO event and the time step reason will become
Updated Reason. The REDO event may happen many times during one time step; this
typically signals certain kinds of difficulties or instabilities at run time.
When a model runs into difficulty at run time, the time step control can issue various reasons
such as PRESSURE, Flux Step, MINSTEP, HalfRep.
Note A simple converged model should not lead to complex auto time stepping decisions
like those described above.

Time stepping control usage examples
Illustration
Here is a simple example of how the pore volume throughput and fluid change control can work:
A quarter five-spot, two-phase, one front (100%water / 100% oil) propagating from injector to
producer. 100% oil initially, in RESV conditions. Rates were set to 1%PV/day; injection rate is
equal to production rate.
With a 0.1 limit on pore volume throughput and 0.05 on fluid change, the fluid change would
initially govern timesteps, with the front displacing 5% of the PV for each timestep. This is a 5-
day time step. After breakthrough, the rate of change of fluid will be reduced because of the
water produced. Timesteps will increase until the watercut at reservoir conditions reaches 0.5.
At that time the timesteps will continue at 10 days, limited by the throughput of 0.1.
If one thinks of the reservoir as one cell:
Fluid volume change time step control limits the change of saturation in the cell in one
timestep, by 5% in the example above
Pore volume throughput time step control limits the amount of mass one can inject/produce
from this cell in one timestep, by 10% in the example above
Pressure change time step control limits the maximum change of pressure in the cell,
currently as a fraction of the current average pressure.
Examples
The following run time examples activate the respective time control facilities:
Example 1
Fluid volume step
@--Message at time 10 May 2003 step 10:

@ Fluid Volume AutoStep 0.06
Step 10 Time 0.45 --> 0.51 Reason: FV Step
Pressure : 29 5.9e-006
Saturation : Generated 204 starting points (SLN density 1.000000).
Memory for streamlines, allocated: 0.4MB Usage: 0.709
CPU Pressure : Asm 0.0 Sol 0.0 Vt 0.0 Tot 0.0
CPU Saturation : Tot 0.1
Mem heap(Mb) : 10.0
CPU Cumulative : Asm 0.0 Sol 0.0 Vt 0.0 Sat 1.0 Tot 1.1
PV 1.000001e+002 at ref. pressure
PV 1.000001e+002 RC 60.43% PAV 3.8888e+003
WIP 6.967155e+001 CWF -4.653439e+001 WIIP 2.300002e+001 MW -0.14%
OIP 3.032854e+001 COF 4.653440e+001 OIIP 7.700007e+001 MO 0.14%
GIP 0.000000e+000 CGF 0.000000e+000 GIIP 0.000000e+000 MG 0.00%

Example 2
Pore volume step

@ Pore Volume AutoStep 0.10
Step 1 Time 0.00 --> 0.10 Reason: PV Step
Mem heap(Mb) : 9.8
PV 1.000001e+002 RC 12.99% PAV 3.5686e+003

Example 3
Fluid volume step followed by MAXSTEP

Mem heap(Mb) : 10.0
PV 1.000001e+002 RC 60.43% PAV 3.8888e+003
Step 11 Time 0.51 --> 0.66 Reason: MaxStep
@ PROD ->changing to BHP control due to low bhp (-257.5 ->limit is 14.5)
@--Warning at time 10 May 2003 step 11:
@ In a run with incompressible PVT-data and BHP as target for wells,
@ there can be large variations of field pressure vs time
Mem heap(Mb) : 10.0
PV 1.000001e+002 RC 61.07% PAV 4.1699e+003

Example 4
Pressure step followed by REDO fluxstep
@--Message at time 1 July 1994 step 20:

@ Pressure AutoStep 50.50
Step 20 Time 242.00 --> 292.50 Reason: Pressure
Pressure : 8 3.9e-007 1 3.7e-003
Pressure : 5 6.3e-006 2 5.8e-005
Mem heap(Mb) : 144.8
PV 3.467478e+009 RC 0.76% PAV 6.7775e+003
WIP 2.906918e+009 CWF -1.903350e+004 WIIP 2.907015e+009 MW 0.00%
OIP 2.592855e+008 COF 1.981651e+006 OIIP 2.612205e+008 MO -0.00%
@--Message at time 20 August 1994 step 21:
Pressure : 6 6.9e-006 1 5.8e-003
Pressure : 7 1.6e-007 2 8.0e-005
@--Message at time 20 August 1994 step 21:
@ Redo TimeStep with Flux AutoStep 44.50
Step 21 Time 292.50 --> 337.00 Updated Reason: FluxStep
Pressure : 6 9.7e-006 1 3.7e-003
Pressure : 5 1.0e-005 2 4.7e-005
PV 3.467019e+009 RC 1.04% PAV 6.7289e+003

Example 5
Estimated fluxstep (control flux step) followed by Flux step and Pressure step. The estimated
FluxStep is computed during one of the previous reporting steps and used as a guess:
Report 12 Time 791.00 --> 973.00 (01 Jul 1996) StopTime: 3348.00
@--Message at time 1 January 1996 step 32:
@ Estimated Flux AutoStep 46.00
Step 32 Time 791.00 --> 837.00 Reason: FluxStep
Pressure : 8 8.6e-006 1 4.4e-003
Pressure : 6 3.1e-006 2 3.6e-005
@ Redo TimeStep with Flux AutoStep 28.43
Step 32 Time 791.00 --> 819.43 Updated Reason: FluxStep
Pressure : 8 3.7e-006 1 3.0e-003
Pressure : 5 4.8e-006 2 2.4e-005
Mem heap(Mb : 146.9
PV 3.460583e+009 RC 5.78% PAV 6.1384e+003
Pressure : 7 2.7e-006 1 2.8e-003
Pressure : 4 7.9e-006 2 1.6e-005

PV 3.460353e+009 RC 6.10% PAV 6.1281e+003

Example 6
Fluid volume followed by HalfRep and Report steps

Mem heap(Mb) : 10.0
PV 1.000001e+002 RC 60.43% PAV 3.8888e+003
Step 11 Time 0.51 --> 0.75 Reason: HalfRep
@ PROD ->changing to BHP control due to low bhp (-257.5 ->limit is 14.5)
@--Warning at time 10 May 2003 step 11:
@ In a run with incompressible PVT-data and BHP as target for wells,
@ there can be large variations of field pressure vs time
Mem heap(Mb) : 10.0
PV 1.000001e+002 RC 61.39% PAV 4.1723e+003

Step 12 Time 0.75 --> 1.00 Reason: Report
Saving : FSTIMESTP_C1_MOBILITY.SLN0001
Mem heap(Mb) : 11.4
PV 1.000001e+002 RC 62.00% PAV 4.0030e+003
Saving : FSTIMESTP_C1_MOBILITY.X0001
Example 7
Fluid volume followed by HalfRep, MINSTEP and Report steps.
Note that MINSTEP is activated only during the REDO checking stage, followed by a HalfRep
step.

Mem heap(Mb) : 10.0
PV 1.000001e+002 RC 61.91% PAV 3.9997e+003
Step 10 Time 0.90 --> 0.95 Reason: HalfRep

@ Activate MinStep 0.09 due to autostep checking
Step 10 Time 0.90 --> 0.98 Updated Reason: MinStep
Mem heap(Mb) : 10.0
PV 1.000001e+002 RC 62.12% PAV 3.9973e+003
Step 11 Time 0.98 --> 1.00 Reason: Report

Saving : FSTIMESTP_C1_MOBILITY.SLN0001
Mem heap(Mb) : 11.6
PV 1.000001e+002 RC 62.18% PAV 3.9909e+003
Saving : FSTIMESTP_C1_MOBILITY.X0001

Dual Porosity
Chapter 5
Introduction
This chapter describes the Fractured Reservoir option, which is a separately licensed extension
x ECLIPSE 100
x ECLIPSE 300
to FrontSim. The implementation uses a special 3-phase compressible, dual porosity
x FrontSim formulation suitable for streamline simulation as published in [Ref. 32].
SPECIAL
In a dual porosity reservoir, fluids exist in two interconnected systems:
The rock matrix, which usually provides the bulk of the reservoir volume
The highly permeable rock fractures.
If the matrix blocks are linked only through the fracture system, this conventionally could be
regarded as a dual porosity single permeability system, since fluid flow through the reservoir
takes place only in the fracture network with the matrix blocks acting as sources. Dual porosity
runs are specified by the keyword DUALPORO in RUNSPEC.
To model such a system, two simulation cells are associated with each block in the geometric
grid, representing the matrix and fracture volumes of the cell. In FrontSim the porosity,
permeability, depth etc. of these may be independently defined. A matrix-fracture coupling
transmissibility is constructed automatically by FrontSim to simulate flow between the two
systems due to fluid expansion, capillary pressure etc.
In a dual porosity run of FrontSim the number of layers in the Z-direction should be doubled.
FrontSim associates the first half of the grid (the first NDIVIZ/2 layers) with the matrix blocks,
and the second half with the fractures. In such runs NDIVIZ must therefore be even; FrontSim
checks that this is the case.
FrontSim Technical Description Dual Porosity 51

Introduction
Transmissibility calculations
The matrix-fracture coupling transmissibility terms that exist between each cell of the matrix
grid and the corresponding cell in the fracture grid are proportional to the cell bulk volume,
being of the form:
TR = CDARCY K V [EQ 5.1]
where by default:
K is taken as the X-direction permeability of the matrix blocks,
V is the matrix cell bulk volume (note that this is not the pore volume, having no porosity
factor), and
is a factor of dimensionality LENGTH2 , to account for the matrix/fracture interface area per
unit volume, that is the size of the blocks in the matrix volume.
Kazemi [Ref. 4] has proposed the following form for :
1 1 1
= 4 ----
- + ----- + ----- [EQ 5.2]
l 2 l 2 l 2
x y z
where lx, ly and lz are typical X, Y and Z dimensions of the blocks of material making up the
matrix volume. ( l x , l y and l z are thus not related to the simulation grid dimensions).
Alternatively, as acts as a multiplier on the matrix-fracture coupling, it may simply be treated
as a history matching parameter.
can be specified as a single value for the whole field or on a cell by cell basis using the
keyword SIGMAV. If is defined on a cell by cell basis then the values corresponding to the
first NDIVIZ/2 layers are used. If is printed out then the values in the first NDIVIZ/2 layers
are copied in to the lower NDIVIZ/2 layers.
The intrinsic permeabilities of cells in the fracture system are equal to the specified values
multiplied by the fracture porosities to yield effective fracture permeabilities. If the NODPPM
keyword is used then the intrinsic permeability is used rather than the effective permeability.
That is, when NODPPM is not specified, then within the fracture cells, the input PERMX, PERMY
and PERMZ are modified using PERMX ( fr ) = PERMX ( fr ) PORO ( fr ) .
If the dual porosity option is selected, the matrix blocks have no mutual transmissibilities.
52 Dual Porosity FrontSim Technical Description

Figure 5.1 A simple, dual porosity, dual permeability system.
1,1,1
Matrix Cells
Matrix Fracture NNC
1,1,3
1,1,1
Fracture Cells
1,1,3

Recovery mechanisms
In a dual porosity system the majority of the oil is contained in the matrix system, but the
production of oil to the wells is through the high permeability fracture system. In such a system
an injected fluid does not sweep out oil from the matrix block. Production from the matrix
blocks can be associated with various physical mechanisms including:
Oil expansion
Imbibition
Oil expansion
As the pressure drops in the fracture system, oil flows from the matrix to equilibrate the matrix
pressure with the surrounding fracture pressure. This production mechanism can be thought of
as expansion of the oil within the matrix block, either above the bubble point or by solution gas
drive below the bubble point.
Imbibition
In a typical water wet system the matrix rock has a positive water-oil capillary pressure. If water
is introduced into the fracture, the water flows under capillary forces into the matrix system,
displacing oil.
The water imbibition process is modeled in FrontSim by specifying different saturation table
numbers for the matrix and fracture cells respectively. The matrix cells typically have a water-
oil capillary pressure, while the fracture cells usually have zero capillary pressure.
In gas-oil systems the oil is the wetting phase and tends to imbibe into the matrix.

Recovery mechanisms
Facilities specific to dual porosity runs
Fracture permeabilities
It is necessary to be clear about what the input fracture permeability represents. By default
FrontSim multiplies the input fracture permeabilities by the fracture porosity to generate an
effective permeability. If the input fracture permeabilities themselves represent the effective
value, then the NODPPM keyword should be used in the GRID section.
Matrix-fracture relative permeabilities

Usually two sets of saturation functions (relative permeabilities and capillary pressures) are
supplied, one for the matrix cells and one for the fracture cells. The SATNUM keyword in the
REGIONS section is used to associate the tables with the appropriate grid blocks. As FrontSim
upwinds the flows, a phase flow from matrix to fracture takes the relative permeability
calculated from the phase saturation in the matrix using the matrix table. Flow from the fracture
to the matrix uses the fracture saturation and table.
Simplified grid input

The keyword DPGRID may be used to simplify the construction of grids for dual porosity runs.
This keyword enables grid data to be entered for the matrix cells only (the first NDIVIZ/2
layers), the missing values for the remaining fracture layers being obtained from the
corresponding matrix cell.

Facilities specific to dual porosity runs
Restrictions on dual porosity runs
The following restrictions apply to dual porosity (DUALPORO) runs.
Wells connect only to fracture cells - not to matrix cells.
Each active matrix cell must connect with an active fracture cell.
LGRs are not supported.

Restrictions on dual porosity runs
Keyword summary
Table 5.1 shows a summary of dual porosity keywords.
Table 5.1 Dual porosity keywords
Keyword Status Brief Description of Data

DUALPORO Switch in RUNSPEC Initiates the dual porosity model.
SIGMA SIGMA or SIGMAV Matrix-to-fracture coupling factor for the entire grid.
required
SIGMAV SIGMA or SIGMAV Matrix-to-fracture coupling factor for the current
required box.
DPGRID Optional Enables user to enter grid data for the matrix cells
only.
NODPPM Optional Specifies that permeabilities in the fracture cells are
not to be multiplied by the fracture porosity.
SATNUM Recommended To specify different saturation region to the matrix
and fracture cells.

Keyword summary
Keyword summary
Equations of State
Chapter 6
Two-parameter equations of state

Note FrontSim uses ECLIPSE 300 software for all equation of state calculations.
ECLIPSE 100
x ECLIPSE 300
SPECIAL ECLIPSE 300 incorporates four equations of state and two additional variations to the Peng-
x FRONTSIM
Robinson equation.
When an equation of state is selected, this is used to obtain Z-factors and phase fugacities, to be
used to define inter-phase equilibrium and fluid densities.
The equations of state are:
PR - Peng-Robinson
RK - Redlich-Kwong
SRK - Soave-Redlich-Kwong
ZJ - Zudkevitch-Joffe-Redlich-Kwong.
These equations of state are implemented in generalized form using Martins equation, [Ref. 20]
and [Ref. 21].
The generalized form of such an equation of state is:
Z3 + E2 Z 2 + E1 Z + E0 = 0 [EQ 6.1]
with:
E2 = ( m 1 + m 2 1 )B 1 [EQ 6.2]
2
E1 = A ( m 1 + m 2 m 1 m 2 )B ( m 1 + m 2 )B
E0 = [ AB + m 1 m 2 B 2 ( B + 1 ) ] [EQ 6.3]
FrontSim Technical Description Equations of State 59

The coefficients m1 and m2 depend upon the equation used. Refer to Table 6.1 for details.
Table 6.1 Coefficients m1 and m2: variation with the equation of state
Equation of State m1 m2
Redlich-Kwong 0 1
Soave-Redlich-Kwong 0 1
Zudkevitch-Joffe 0 1
Peng-Robinson 1+ 2 1 2
The cubic equation for the Z-factor may be solved to obtain Z-factors for the liquid and vapor
phases. Generally three solutions are obtained.
The distinction between the liquid and the vapor phase is then made by choosing the smallest
root as Z-factor for the liquid phase, and the largest root as Z-factor for the vapor phase.
Fugacity coefficients are calculated using:
A 2 B Z + m 2 B B i
ln ( f i ( px i ) ) = ln ( Z B ) + --------------------------- --------i -----i ln -------------------
- + ----- ( Z 1 )
( m 1 m 2 )B A B Z + m 1 B B
where: [EQ 6.4]
i = Aij xj
j
n n
A = xjxkAjk
j = 1k = 1
n
B = x j Bj
j=1
Ajk = ( 1 jk ) ( A j A k ) 1 / 2
and jk are binary interaction coefficients, normally between hydrocarbons and non-
hydrocarbons.
These four equations express the mixing laws used in all the equations of state.
The variables are defined by the following equations:
P rj
Aj = a ( T, j ) ------
- [EQ 6.5]
T2 rj
P rj
Bj = b ( T, j ) ------
- [EQ 6.6]
T rj
a ( T, j ) and b ( T, j ) are functions of the acentric factor w j and the reduced temperature T rj .
For Redlich-Kwong:
60 Equations of State FrontSim Technical Description

1 / 2
a ( T, j ) = ao T rj [EQ 6.7]
b ( T, j ) = bo [EQ 6.8]
For Soave-Redlich-Kwong:
1 / 2 )]2
a ( T, j ) = ao [ 1 + ( 0.48 + 1.574w j 0.176w j2 ) ( 1 Trj [EQ 6.9]
b ( T, j ) = bo [EQ 6.10]
For Zudkevitch-Joffe:
1 / 2
a ( T, j ) = ao F aj ( T )T rj [EQ 6.11]
b ( T, j ) = bo F bj ( T ) [EQ 6.12]
For Peng-Robinson:
1 / 2 ) ]2
a ( T, j ) = ao [ 1 + ( 0.37464 + 1.54226w j 0.26992w j2 ) ( 1 Trj
b ( T, j ) = bo [EQ 6.13]
As T r = T T c , the SRK and PR forms for a and b may be expanded as a polynomial in

1 T 1 / 2 , for example,
a ( T, j ) = A + B T 1 / 2 + CT [EQ 6.14]
The normal PR form can be optionally modified for large acentric factor, using the factor
( 0.379642 + 1.48503w j 0.164423w j2 + 0.016666w j3 ) rather than
( 0.37464 + 1.53226w j 0.2699w j2 ) for w j > 0.49 . This correction is invoked by use of the
PRCORR keyword.
a0 and b0 are constants depending upon the equation of state, as shown in Table 6.2.
Table 6.2 The dependence of a0 and b0 on the equation of state
Equation of state a b
0 0
RK, SRK, ZJ 0.4274802 0.08664035

PR 0.457235529 0.07796074
In the program, these default values may be over-written if required by the use of the OMEGAA
and OMEGAB keywords.
The Zudkevitch-Joffe equation contains additional temperature factors, denoted F aj ( T ) and
Fbj ( T ) multiplying the usual RK temperature dependence. These are adjusted to match the
pure-component fugacity values along the vapor pressure line, and to observe the correct
component liquid density.
In the program the required variation of component saturation pressure and liquid density with
temperature are obtained using correlations of Reidel, and Gunn and Yamada. These
correlations require the input of the normal boiling point and the reference liquid density at a
specified reference temperature.

Flash calculations
For a thermodynamic system to be in equilibrium, it is further required that the fugacities in the
liquid and vapor phases must be equal for each component:
fiL = fiV [EQ 6.15]
As described above, the fugacities are functions of temperature, pressure and composition:
f i = f i ( T , p, x i ) [EQ 6.16]
The fugacities can be calculated directly from an equation of state.

Equilibrium constants (otherwise known as K-values) for each component can be defined as:
y
K i = ----i [EQ 6.17]
xi
The mole fractions of each component in the liquid and vapor phases are given as:
zi
x i = ------------------------------
- [EQ 6.18]
1 + ( K i 1 )V
K i zi
y i = ------------------------------
- [EQ 6.19]
1 + ( K i 1 )V
If K-values are used to specify inter-phase equilibria, these two equations are used to specify
the liquid and vapor compositions directly, with K-values obtained by table look-up as functions
of pressure.
Viscosity evaluation
In compositional mode the phase viscosity values are obtained using the Lorentz-Bray-Clark
method.

Flash calculations
Three-parameter equations of state
The traditional weakness of the two-parameter equations of state (EoS), such as the Peng-
Robinson, Redlich-Kwong, etc. is their poor prediction of liquid properties, especially liquid
densities and saturations.
The critical compressibilities predicted by the Van der Waals, Redlich-Kwong and Peng-
Robinson equations of state are Z VdW
c
RK pr
= 0.375 , Z c = 0.333 and Z c = 0.307 . But hydrocarbons are
known to have Z c < 0.29 .
Peneloux et al. proposed a molar volume correction, referred to as volume shift, which adds a
third parameter to the EoS, and, in turn, greatly improves liquid property estimation.
For a mixture of N components, the phase molar volume Vmol, p is given by:
V mol, p = EoS
V mol ,p zi ci [EQ 6.20]
i=1
where
p = ( liquid, vapor ) represents the phase of the system
EoS is the molar volume of the phase predicted by the traditional 2-parameter EoS
Vmol,p
zi = ( x i, y i ) are the liquid and vapor mole compositions
c i constitute a set of volume corrections.
The component corrections are usually related to set of dimensionless shift parameters s i , by:
c
si = ----i [EQ 6.21]
bi
where:
b, i RT ci
b i = ---------------------
-
p ci
The shift parameters are entered in the dimensionless form using the keyword SSHIFT.

Three-parameter equations of state
Use of the equation of state for hydrocarbon mixtures
A typical oil is composed of many millions of components. The equation of state has one value
of A and one value of B to model the phase behavior of this mixture.
For example the PR EoS is as follows:
RT - ------------------------------------------------
P = ----------- A [EQ 6.22]
V B V(V + B) + B(V B)
In a typical reservoir simulation model, 4-8 components and pseudo-components are used to
define the mixture. Each component has a value of T c , Pc , Vc or Z c , , a , b and binary
interaction coefficients, ij (that increase or decrease the forces between component pairs), that
must be specified in the fluid characterization process.
These parameters for pure components, such as Methane or Nitrogen, and usually considered
fixed. Thus, the simulation engineer must alter the remaining component parameters so that the
resulting calculated phase behavior matches the experimental data. This phase behavior
matching process is carried out with the PVTi program.
Calculation process to determine the amount of

liquid and vapor present in a grid block and the
phase compositions at equilibrium
The ECLIPSE 300 iteration process to converge a solution consists of linear, non-linear
(Newton) and flash iterations. The final solution at the end of a timestep for each grid block
consists of a pressure; water, oil and gas saturations; liquid and vapor molar fractions; and mole
fractions of each component in the liquid and vapor phase.
This section will describe the iteration process to flash the mixture in each grid block to
determine the molar volumes and composition at equilibrium.
After the linear problem converges, we have a new pressure, water and molar densities for each
grid block.
A stability test will tell us if there are one or two hydrocarbon phases. If there are two
hydrocarbon phases, then K-values, K i , are assigned to each component, i, from the previous
iteration, or, if none exist, from Wilsons formula, stated below:
exp 5.37 ( 1 i ) 1 ------ 1-

T ri
K i = ----------------------------------------------------------------- [EQ 6.23]
Pri
Then, given z i and Ki , ECLIPSE 300 solves the Flash Equation for the molar fraction of vapor,
V. Details of this Flash Equation are shown overleaf.
nc
zi ( Ki 1 )
g(V) = 1------------------------------
+ V ( Ki 1 )
- = 0 [EQ 6.24]
i=1

ECLIPSE 300 then solves this equation for the mole fractions of each component in the liquid
and vapor phases,
x i = z i [ 1 + V ( K i 1 ) ] , i = 1, 2, n c [EQ 6.25]
y i = ( K i z i ) [ 1 + V ( K i 1 ) ] , i = 1, 2, n c [EQ 6.26]
The compressibility factor is defined as Z = PV

------- . As a result, the Peng-Robinson equation of
RT
state can be expressed in terms of Z:
3 2 2 2 3
Z Z ( 1 b ) + Z ( a 3b 2b ) ( ab b b ) = 0 [EQ 6.27]
where
AP -
a = -----------
2 2
R T
b = BP
-------
RT
The solution of the cubic equation gives, in a two phase region, three real roots. The largest root
is the compressibility factor of the vapor phase, and the smallest positive root is the
compressibility factor of the liquid phase.
With the current information, ECLIPSE 300 calculates the fugacity of each component in the
liquid and vapor phases.
When a grid block is in equilibrium at a given pressure and temperature, the fugacities of all
components must be the same in the liquid and the vapor. In other words,
f Li = f Vi .
A convergence criteria is then used to determine if a grid block is in equilibrium (if is very
small),
nc
fiL 2 <
-----
-1
fiV
. [EQ 6.28]
i=1
If equilibrium is not achieved, then a new estimate for the K-values are made and the iteration
process continues with a new solution of the Flash Equation, etc. Using successive substitution,
the new estimate of the K-value is:
NEW OLD fiL

Ki = Ki -----
- . [EQ 6.29]
f iV
After equilibrium is achieved, ECLIPSE 300 begins the next non-linear iteration.

Calculation of phase states
A cell in a compositional run may be water-filled, or in a one or two phase hydrocarbon state.
The one phase states may possess a saturation pressure, usually lower than the current pressure,
at which a second hydrocarbon phase will appear. For temperatures above the cricondotherm
however, such a pressure will not exist, and the cell composition will lead to a single
hydrocarbon phase at all pressures.
The appearance of a two phase state is detected by application of the Michelsen stability test
[Ref. 22]. This is carried out anew at each timestep, and does not involve assumptions
concerning the state of the cell carried over from previous steps.
By default ECLIPSE 300 uses the stability test for all cells, avoiding saturation pressure
tracking altogether.
The Michelsen stability test involves the minimization of a function G* as a function of a trial
phase composition Y, starting from both liquid and vapor-like initial estimates. If a non-trivial
minimum can be found with G* < 0 the hydrocarbon mixture is unstable, and a flash calculation
may be performed to establish the phase split.
It is possible to cast the Michelsen stability test in a residual form and use a Newtonian method,
but this is not entirely suitable, as:
There are generally two minima to G*, and the Newton method can converge towards a
local maximum as easily as a minimum.
Newtons method involves order N 3 operations per iteration, due to the matrix operations
involved. As a number of iterations are required from each initial Y, this becomes
expensive.
A better method, which also yields quadratic convergence near the solution, is the BFGS
iteration [Ref. 23]. This is a minimization method, using an approximate Hessian constrained to
be symmetric and positive definite. In the early stages of the iteration an accelerated successive
substitution method is effective, using a two-point GDEM technique [Ref. 24].

Calculation of phase states
File Handling in FrontSim
Chapter 7
Introduction
A number of files may be produced by FrontSim for each simulation run.
x ECLIPSE 100
x ECLIPSE 300 These are:
SPECIAL
x FRONTSIM PRT file Main printer output RPTSCHED and RPTPRINT
keywords
GRID file Grid geometry file GRIDFILE keyword
INIT file Initial Data file that contains grid INIT keyword
properties and saturation table data.
Can be read into the graphics packages.
RESTART file Restart runs / grid graphics file RPTRST, RPTSCHED and
RPTSOL keywords
SMSPEC file Specifications for summary file
SUMMARY file Line graphics file RPTLINFS keyword
SLNSPEC file Specifications for streamline file
STREAMLINE file Streamline output data RPTRST and RPTSLN
keywords
ALLOC file Allocation factors and pore volumes RPTSCHED
RFT file Data wells describing fluid conditions in WRFTPLT
the wellbore or the connecting grid
blocksat selected times in the run.
RSM file RSM (Run Summary) report in either OPTIONFS
EXCEL format, for Cougar for example,
XML format or ECLIPSE format.
FrontSim Technical Description File Handling in FrontSim 67

Introduction
The production of all of these files, except for the main printer output (the simulation log), may
be controlled by the user with the keywords indicated. The contents, and hence the size, of the
printer output file are controlled using the RPTSCHED, RPTRST, RPTLINFS, RPTSOL and
RPTSLN keywords.
In addition, you can choose whether the RESTART and SUMMARY files are to be unified (see
the RUNSPEC section keywords UNIFIN and UNIFOUT).
You should be aware of which types of file it is appropriate to use on your system. Some
guidelines are given here.
Formatted files are standard 80 character card image files, which may be straightforwardly
transferred between different computers. All the files generated by the FrontSim programs can
be converted from formatted to unformatted files or vice-versa using the utility program
Convert.
In general, unformatted non-unified files should be used, giving efficient use of disk space and
allowing the user to examine output as the simulation progresses. Unified files should be used
if the number of files being produced is a problem. Unified files will reduce the size of your
catalog considerably, but not the amount of disk space used.
68 File Handling in FrontSim FrontSim Technical Description

Introduction
File internal format
All ECLIPSE suite files, including FrontSim, consist of a series of data blocks each headed by
a descriptor record. The block descriptor record comprises
An 8-character keyword which identifies the data in the block.
A 4-byte integer containing the number of elements (NEL) in the block.
A 4-character field specifying the type of the data in the block.
Permitted values are
INTE for standard (4 byte) integers
REAL for single precision (4 byte) floating point reals
LOGI for standard (4 byte) logicals
DOUB for double precision (8 byte) floating point reals
CHAR for characters.
Note If the data type is CHAR, then NEL is the total number of CHARACTER*8 elements.
The contents of the block follows the descriptor (on a new record). Each data block
must be read back in the same block structure as it was written out.
The header/record structure enables files to be converted from formatted to unformatted form,
or scanned for a specific item. For example, a RESTART file will contain a record header with
an identifier of PRESSURE, type REAL, with the number of elements set to the number of
active cells in the study.
In the formatted case the actual formats used for the data blocks are:
Integers 6(1X,I11)
Reals 4(1X,E16.8)
Double Precisions 3(1X,D22.14)
Logicals 25(1X,L2)
Character strings 7(1X,A1,A8,A1)

The header line is written using a format (1X, A1, A8, A1, 1X, I11, 1X, A1, A4, A1). The A1
fields are used to output quotes so that the data may be read using list input.
LOGIHEAD 20 LOGI
F F F T F T F F T F F F F F F F F F F F
ZGRP 1 CHAR
G
IWEL 72 INTE
1 1 3 3 1 1
3 2 2 0 1 0
1 2 0 2 0 -100
0 0 0 0 1 1
0 0 0 0 0 0
0 7 0 0 0 0
5 1 1 1 1 1
1 4 4 0 1 0
1 2 0 1 0 -100
0 0 0 0 1 1
-1 0 0 0 0 0
0 7 0 0 0 0
PRESSURE 15 REAL
.39684106+004 .39684106+004 .39684106+004 .39684106+004
.39684106+004 .39872349+004 .39872349+004 .39872349+004
.39872349+004 .39872349+004 .40060627+004 .40060627+004
.40060627+004 .40060627+004 .40060627+004
For further information on formats of specific files, please contact your Schlumberger Support
office.

Graphics post-processors
Files written by FrontSim to be accessed by the graphics post-processors are described in
"FrontSim Files" in the "ECLIPSE File Formats Reference Manual".

Geologic Model Screening
Chapter 8
Introduction
This chapter describes the application of the GEOFLOFS keyword.
ECLIPSE 100
ECLIPSE 300 The GEOFLOFS keyword encapsulates the functionality required to perform multi-phase fluid
x FrontSim flow simulation using an incompressible rock and fluid model. The transport phenomena
SPECIAL
modeled is limited to advection and gravity segregation. The purpose of these simulations is to
understand the impact of geology on flow in order to guide the 3D model building process or to
perform quick investigations on the geology in a given simulation model.
FrontSim is an extremely efficient tool for performing incompressible fluid flow simulations on
multi-million cell geologic models, both in terms of memory requirement and speed. Especially,
for two phase oil-water simulations the front tracking solution along streamlines can be 5-7
times or more fast than other methods.
The GEOFLOFS keyword consists of three records and provides a fast and easy method for
creating simple flow simulations. A suite of standard results commonly used for geologic
analysis are produced automatically. This output can be complemented by using any of the
standard reporting options. The simplest application of GEOFLOFS could be to produce
streamlines for visualization of connectivity or a tracer type simulation to estimate connected
volumes. The simulations can be extended to study the effects of fluid viscosity and relative
permeability, for example, to define cut off points or to screen multiple model realizations.
The experienced user of FrontSim will find that it is possible to model incompressible
simulations using a combination of existing keywords. However, it is much easier to use the
GEOFLOFS keyword. It is possible to conduct simulations or visualize streamlines as soon as
the geological grid and properties are created without the need for detailed fluid and rock
physics data. Additionally, it is possible to take existing simulation models and run them
incompressible mode with very little modifications to the keyword deck. Most keywords maybe
retained in the deck without invalidating the run. (See Table 8.1 for details).
FrontSim Technical Description Geologic Model Screening 73

Introduction
FrontSim is a 64-bit, multi-threaded application enabling it to process large models in parallel
on multi-core computers. GEOFLOFS simulations will by default use as many cores as is
available to provide the maximum power when working with multi-million cell geologic
models. This access to unlimited cores is available with the base FrontSim license for
GEOFLOFS applications only. For non-GEOFLOFS simulations the appropriate parallel multi-
core license will be required.
74 Geologic Model Screening FrontSim Technical Description

Introduction
Theory
In many respects GEOFLOFS simulations are more like flow experiments rather than reservoir
simulations in the conventional sense. The experiments are in a way similar to laboratory
experiments on core to measure permeability, anisotropy, fractional flow, recovery, etc., except
that now numerical experiments are done using models.
Streamline simulation relies on tracing the flow field and then solving the transport of different
flow phases along discrete flow paths. Discretization of the flow field leads to construction of
stream tubes with each stream tube being associated with a particular flow rate. A streamline
can be imagined as the line through the centre of a stream tube. It is inefficient to compute
stream tubes for 3D problems. However, it is easier to construct streamlines in 3D and
associated them to stream tubes in an implicit manner. Thus we can assign pore volumes to
streamlines. This property of streamlines allows us to easily analyze connectivity and connected
volumes in a geologic model.
The time-of-flight (TOF) is a unique property associated with a streamline. At any point on a
streamline the TOF is the time taken by a neutral tracer to arrive at that point from a source/
injector. Alternatively, TOF can also be defined as the time taken to travel a sink/producer.
Mathematically, it is defined as:
5

ut
= ---- ds [EQ 8.1]
0
where
= time of flight
= porosity
ut = Darcy velocity
s = distance along the streamline
PVi = Q i i [EQ 8.2]
where
Q = flow rate in streamline i
i = TOF atend of streamline i
Streamlines are traced using a numerical velocity field computed using the pressure solution and
Darcy's law on the geologic model grid. Details are given in "Streamline Tracing" on page 139.
An incompressible flow simulation will have a balanced injection-production scheme using
sources/injection wells and sinks/production wells. All fluid flow paths or streamlines will start
from sources/injectors and end in sinks/producers. Sources and sinks can be setup in various
configurations and as required to study specific connectivity issues related to a model. They
need not be restricted to the existing or planned well locations.
Streamlines are launched from the source or injection wells by distributing the injection rate
equally among a set of streamlines. The number of streamlines used depends on various model
factors. Each streamline has associated with it a certain amount of fluid flux that remains
constant at every point along the streamline as fluids are assumed incompressible.
The equation describing the flow of incompressible, immiscible fluids and ignoring gravity and
capillary pressure is given in [EQ 8.3]:

Theory
( t p ) = q i [EQ 8.3]
where
t = total mobility
p = pressure drop
n0
qi = total flow rate = qj

j1
A difference form of [EQ 8.3]) with gravity terms added if required, is solved to compute the
pressure at each grid block on the geologic model. Using the pressure and the total mobility as
defined below the velocity at the interface between grid blocks is computed and used to generate
streamlines. Total mobility is defined as follows:
n0
t = j [EQ 8.4]
1
where
j = jth phase
np = total number of phases
k
j = ----j
j
kj = effective permeability to phase j

j = viscosity of phase j
and
k j = k k rj
k = permeability of porous medium

k rj = relatively permeability to phase j
FrontSim uses a sequential solution procedure, where the pressure variables are computed first,
as described above, and then the saturation variables are updated by transporting the various
fluid phases along the streamlines.

Theory
Steady State Single Phase Tracer Flow Simulation
Single Phase Tracer Type

Observe that in order to analyze connectivity and connected volumes for a given model we
essentially need to trace streamlines and compute the time-of-flight. The sources and sinks or
injector and producer wells act essentially like probes to test the model at given locations. The
flow experiment can be set up as follows. Define a set of injection and production wells in the
geologic model and maintain a constant throughput of injection and production, i.e. equal
reservoir volumetric rate of injection and production. Inject tracer and follow its movement
through the reservoir while computing flooded volume.
GEOFLOFS simulations mimic tracer injection by injecting water into a oil filled reservoir
rather than tracer. The water is given exactly the same properties as the oil, so in effect there is
one phase flowing through the model. Along every streamline we want a single water shock-
front hence making any recovery calculations purely a function of the geology and locations of
sinks and sources.
We achieve this done by using linear relative permeability curves (Figure 8.1) and the equal
viscosity for all the phases. Specifically, the default viscosity of oil and water are set to 1cp and
the relative permeability ranges from 0 to 1 with 0 residual saturations for all phases. The end-
point mobility ratio is 1 and the total mobility is constant at 1 for the full range of saturations.
There is only one shock front as seen from the fractional flow curve.
Figure 8.1 Default relative permeability for oil and water. Gas phase relative permeability is similar
We thus solve for incompressible 'tracer-type' displacement of oil ('red water') by water ('blue
water') to compute reservoir connectivity, floodable volumes, drainage volume, etc. The
reservoir is 'filled' with oil and water is injected through injectors. The total oil production for a
specific pore volume of water injected gives a measure of the connected reservoir volume
flooded for a given configuration of wells. If we applied the same experiment to many scenarios
or realizations of the geologic model for a reservoir we could discriminate between them based
on the oil production or breakthrough time etc. Alternatively, we could use such flow
experiments to compared fine scale models with their upscaled versions.

Multi-phase Flow
In some reservoirs recovery can be dominated as much as by geology as by fluid and rock-fluid
interactions. Of course actual recovery in the field is dependent on a whole host of parameters.
However, here we are considering flow experiments to enable us to conduct a preliminary
screening of geologic models. GEOFLOFS aims at progressively increasing the amount of fluid
physics to a certain degree deemed important for geologic model screening. Therefore, single
phase tracer type simulations can be extended to incompressible, immiscible, multiphase
simulations with gravity segregation.
GEOFLOFS simulations assume oil, water, gas and rocks are incompressible and there is no
dissolved gas or vaporized oil. It also assumes there is no shrinkage and assigns unit formation
volume factor to all phases. Density and viscosity of fluids can be different for each phase but,
are by definition, constant.
The default relative permeability curves are linear as shown in Figure 1. However, the user can
assign realistic relative permeability for specific rock types. The option to switch the default
curves is available in Record 3 of the GEOFLOFS keyword. End point scaling is supported.
The solution to the steady state single phase tracer problem above requires only one
computation of the pressure and velocity field. For multi-phase problems we do not need to
solve for pressure due to expansion/compaction but we do need to account for mobility
variations on pressure. This is evident from analysis of [EQ 8.3] and [EQ 8.4].
When the density of the fluids is widely different then it is advisable to switch on gravity
segregation. Introducing mobility and gravity into the simulation means that we can no longer
ignore the need to have more frequent updates of the pressure field. The user can enter the
number of pressures updates desired and switch on gravity in Records 2 and 3 of the GEOFLOFS
keyword. A thumb rule of oil-water simulations is to use around 20-30 pressure updates for
every pore volume of water injected. For higher contrast mobility and large differences in phase
density, e.g. gas phase, more pressure updates will be required. In addition, pressure field needs
to be re-computed whenever wells open or close or the rates change.
By default, models will be initialized with a single fluid (oil) at hydrostatic pressure using the
average depth of the model as datum. You can choose to use a more realistic equilibration using
fluid contacts and pressure or through enumeration using pressure and saturation arrays. Use
Item 3 of record 3 of the GEOFLOFS keyword to read the relevant keywords from the Solution
section.
Boundary Conditions
For incompressible simulations it is essential that the fluid influx equals the efflux or injection
balances production. The most common method to achieve this condition is to let wells produce
at a fixed bottom-hole pressure and assign rates to injectors. Alternatively, both injectors and
producers can be controlled using bottom-hole pressure or an overall voidage replacement is
established by rate control. Setting rate controls on both injectors and producers should be
avoided especially if the connectivity between them cannot be ensured by some sort of static
analyses. Simulations can also be performed with pressure boundary conditions without the
need for wells.
The GEOFLOFS feature distinguishes between 'types' of flow simulations based on whether the
simulation uses wells or just pressure boundary conditions. The type of simulation must input
using GEOFLOFS and controls the how subsequent input data and output are handled. There are
currently 3 types of simulations as defined below
1 Simulations using wells to control flow behavior.(Type 2)

2 Simulations using pressure boundary conditions at the edges of the model. (Type 3 and 4)
Note Type 1 will be introduced in future versions.
Type 2 simulations require the definition of wells as producers and injectors in the Schedule
section. The default well controls in GEOFLOFS assume that producers are on bottom-hole
pressure control and injectors on rate control. The total injection rate is specified in Record 2 in
terms of fraction of HCPV to be injected in a specified period of time.
It is possible to override the default injection controls in the GEOFLOFS keyword and opt to use
controls defined in the Schedule section. It will be the users responsibility to ensure that
conditions of incompressibility are honored.
Most geologic model screening applications will consider steady state operating conditions for
wells. However, GEOFLOFS will support rate changes corresponding to well events as long as
the incompressible flow conditions can be maintained.
Type 3 and 4 simulations do not use wells and instead use constant pressure boundary conditions
at opposite edges of the grid. The simulations are restricted to 2 phases (oil-water) only. In
general type 3 and 4 simulations are more restrictive than type 2 simulations.
Type 3 refers to a pressure gradient being applied from the left side of the grid towards the right
side, and Type 4 to a pressure gradient from back to front. The direction of flow can be reversed
by specifying a negative pressure gradient. Wells are not considered and will be ignored if
present in the SCHEDULE section.Type 3 and 4 simulations are strictly limited to one time step
and it is not possible to change the pressure boundary conditions during a run.
Type 3 and 4 simulation models can only be initialized using the default method (100% oil). The
pressure difference to be applied is entered in Record 2 of the GEOFLOFS keyword. By default
it will be taken to be 50% of the average pressure. The injected phase is water. The simulation
duration is controlled by the specified fraction of HCPV to be injected or a fixed time whichever
occurs earlier. The number of streamlines to be used for the simulation can be fixed
approximately around a given number.
Time Stepping and Reporting

FrontSim performs a pressure calculation at every user defined time step or report step.
However, the transport of phases along the streamlines is computed at much finer intervals of
time (saturation steps) within the span of a pressure step. Hence, it is possible to report well and
field level production/injection reports at frequent intervals even with a single simulation step.
The majority of GEOFLOFS simulations are expected to require minimal number of time steps.
For steady state single phase flow simulations only require one step.
When variations in mobility and gravity are introduced more pressure computation steps will be
required to maintain sufficient accuracy. The saturation solver time steps will fit into the
duration of the individual pressure steps. The GEOFLOFS feature produces a set of default
reports that take this into account automatically.
As in most classical reservoir engineering methods the GEOFLOFS feature allows the use of
fraction of hydrocarbon pore volume injected as a measure of time. As different realizations of
a geological model are likely to contain different volumes of initial hydrocarbons, specifying
injection controls in terms of HCPV provides another basis for comparison of computed
recoveries.
Injectors are assigned rate based on injection potential and the total injection calculated using
the HCPV derived after initialization of a given model realization.

How to use GEOFLOFS
In most applications single phase or two phase oil-water displacement simulations are sufficient
to screen reservoir models. For example, use single phase flow simulation for analysis of
connectivity, continuity and anisotropy, and oil-water flow simulation with gravity segregation
for analysis of sweep efficiency. It is recommended to start with the simplest simulation and
gradually increasing the complexity in line with screening criteria. Although 3-phases; oil, gas
and water, are supported it is primarily intended to cover reservoirs with aquifers and gas caps
and we would like to retain this contact definition in the model. Gas injection or solution-gas-
drive recovery process simulation is not intended.
The wells used in flow simulations can be existing wells or new user-defined pseudo wells. It
is advisable to use wells located judiciously in the model to investigate reservoir heterogeneity,
anisotropy, continuity and connectivity. The location of existing wells alone may not allow
proper coverage during the investigation of connectivity for the entire reservoir. Hence, it may
be desirable to use a hypothetical set of simple vertical wells. In Petrel it is possible to perform
a static connected volume analysis using wells. Connected volume property can be computed
using the geometrical modeling process. In particular, it may help to screen whether or not
compartments have both injectors and producers. A compartment with only a producer or only
an injector is unsuitable for modeling incompressible flow and the simulations will fail.
GEOFLOFS is intended for flow simulations with constant well production/injection rates or
pressure, although variations in rate or pressure are supported.
It is also possible to use GEOFLOFS on existing reservoir simulation models. The GEOFLOFS
keyword will cause FrontSim to ignore some of the data in the simulation deck and run a
reduced physics simulation (See Table 8.1). This has the advantage of performing quick
screening simulation, for example visualize streamlines, without having to make major changes
to the deck. The only portion of the deck that may require editing is the SCHEDULE section.
This maybe required in order to define the source/sink points, modify historical production
control and well control adjustments to maintain incompressibility conditions.
Type 3 and 4 simulations are intended to primarily assist in the gridding and upscaling process.
It is recommended to have regular models or section of models without any inactive cells on the
boundary edges. If there are large amount of inactive cells then flux analysis for gridding
purposes will not be accurate. In that case it is advised to extract section of the model that is
more regular along the edges.
For type 3 and 4 simulations it is possible to control, approximately, the number of streamlines
used in a simulation. Thus a fine scale model and its upscaled equivalent can be simulated using
approximately the same number of streamlines. One way of comparing fine and coarse scale
models is to use the TOF distribution at the production end of every streamline. The comparison
can be made by plotting the inverse of TOF versus streamline number for the fine and coarse
models. FrontSim reports the relevant data in a table at the end of the print file. Instead of
reporting each streamline FrontSim normalizes the streamlines numbers (streamline number/
total number of streamlines) and bins the streamlines into 0.01 fractions and reports the average
inverse of TOF for each bin. This report is produced by default only for type 3&4 simulations.
If the default output is suppressed, the report is not produced. The user can override this by
setting OPTIONFS (56) to 1(default bin size) or number of bins required.
The minimum requirement to use GEOFLOFS is a corner point grid with porosity and
permeability. This means that flow simulations can be conducted as soon as a 3D grid becomes
available. Since the focus is on geology the grid and properties can be large and complex.

How to use GEOFLOFS
GEOFLOFS is best used with Petrel grids, using the OPF file format, in a workflow where
multiple realizations / scenarios are generated and simulated as defined by scripts built using the
Petrel process manager or the uncertainty editor.
Setting up a simulation
The process to set up a single GEOFLOFS simulation of type 3 or 4 is as follows:
1 In Petrel, create grid and populate with porosity and permeability.
a Add faults and fault property as required.
b Pinch out layers if necessary. If the model boundary is irregular consider extracting a
uniform grid.
c Perform a static connectivity analysis and inactivate those groups of cells that do not
include a source or sink.
2 Open the Define simulation case process window and create a new case using the grid
above.
3 Check the tick box in the Results panel to Run simulation even if validation fails.
4 Export/write the simulation case to file.
5 From the Advanced panel open the keyword editor and insert the GEOFLOFS keyword in
the RUNSPEC section.
a Enter 3 or 4 as the first parameter of the first record to define the type of simulation.
6 Run the simulation.
FrontSim executes a type 3 or 4 simulation using the grid and default values for all the other
parameters.
7 Visualize streamlines, grid cell values, line plots, etc.
Type 2 simulations
For type 2 simulations the following additional steps are required.
1 Create vertical wells or use the existing set of wells and completions.
a Group the wells into folders depending on whether they are injectors or producers.
2 Open the development strategy process and define the well controls for producers and
injectors. For example, add a rule for bottom hole pressure controls for producers and group
rate control for injectors.
3 Drop the development strategy into the case created in 2 above.
4 Continue with the rest of the steps in a similar fashion as documented in 3 to 7 above
making the appropriate inputs.
User defined saturation functions

1 To employ user defined saturation functions create the relevant rock physics model and
drop it into the case.
2 Enter the appropriate directives in GEOFLOFS Record 3 to use the user defined data instead
of defaults.

How to use GEOFLOFS
Default Reports
GEOFLOFS runs produce default output for line graphs, grid cell displays, streamline display.
This output can be supplemented by requesting additional output through various keywords.
Details on the default reports produced when using GEOFLOFS are available in the FrontSim
user guide.
Restrictions
It is important to know the keywords / features that are supported or ignored when GEOFLOFS
is used together with other FrontSim keywords/features.
1 All compositional and IOR scaleup related features and keywords are not supported when
GEOFLOFS is used. Existence of these keywords in the data file will cause FrontSim to
issue an error message and stop.
The rest of the keywords are supported or ignored as follows:
Table 8.1 FrontSim behavior when GEOFLOFS is operational.
Keywords/Features Supported Keywords/Features Ignored

Data File
Section Run Type
Run Type = 2 Run Type = 2 Run Type =3,4
=3,4
RUNSPEC All except NOGRAV All NOGRAV replaced X
GRID/EDIT All All except as X Aquifers, JFUNC
noted
PROPS All saturation functions, None PVT, Tracer, Temperature modeling All
end point scaling, aquifers
REGIONS Saturation, fluid in place None PVT, equilibration and rock All
SOLUTION Equilibration, enumera- None Depth variation, tracers and restart All
tion, aquifer
SUMMARY All relevant keywords All relevant No change in behavior from normal runs
keywords
SCHEDULE All except as noted under Tuning key- Historical controls, VFP tables, temperature, All except tuning key-
ignored category words only tracer. GCONINJE will be ignored if target is words
specified in GEOFLOFS.
Note Some of these restrictions will be lifted in future versions of FrontSim.

How to use GEOFLOFS
Type 2 runs
Combining GEOFLOFS Injection Scheduling with GCONINJE for Type 2 Runs.
Table 8.2 Combining GEOFLOFS Injection Scheduling with GCONINJE
Record/option
GEOFLOFS Record 2 Set Set Set Set Set Set
Parameter 2: HCPV Frac-
tion
GEOFLOFS Record 2 Set Set Set Set Set Set
Parameter 3 Simulation
Duration
SCHEDULE Section: Set Set Set Set Set Set
GCONINJE
SCHEDULE Section: Set Set Set Set Set Set
TSTEP
Error Error Error OK Error OK Error OK OK

How to use GEOFLOFS
How to use GEOFLOFS
Initializing the Study
Chapter 9
Introduction
The initial reservoir conditions can be defined in one of three ways:
x ECLIPSE 100
x ECLIPSE 300 1 They can be read from a RESTART file generated by an earlier run (see keyword
SPECIAL RESTART).
x FRONTSIM
2 They can be set directly in each grid block, using the keywords PRESSURE, SWAT, SGAS,
RS or PBUB, and RV or PDEW.
3 They can be calculated by the equilibration facility.
The equilibration facility is a means of calculating the initial conditions on the basis of
hydrostatic equilibrium. If necessary, the reservoir can be divided into separate equilibration
regions in which hydrostatic equilibrium exists independently of the other regions. Within each
equilibration region all the grid blocks must use the same pressure table for their PVT
properties, but they can use different saturation tables.
FrontSim Technical Description Initializing the Study 85

Introduction
Data requirements
The data quantities required by the equilibration facility are entered using the keyword EQUIL.
For each equilibration region, you should specify the pressure at a given datum depth, the
positions of the gas-oil and water-oil contacts, and the value of the capillary pressure at each
contact. If there is no gas cap, the gas-oil contact should be placed above the top of the reservoir;
and likewise if there is no mobile water, the water-oil contact should be placed far enough below
the bottom of the reservoir to exclude the transition zone.
Black oil
In black oil mode gas condensate problems, the vaporized oil concentration (Rv) in the gas can
be set in a similar manner. Either Rv or the dew point pressure (Pdew) may be entered as a
function of depth using the keywords RVVD and PDVD respectively. If a table of Rv versus depth
(or Pdew versus depth) is not referenced by a particular equilibration region, the vaporized oil
concentration in under-saturated gas is everywhere set equal to the saturated Rv value at the gas-
oil contact. At any position in the reservoir, the Rv value obtained from a table or the default
setting is subject to an upper limit equal to the saturated Rv value at the local pressure.
The datum depth for the pressure can lie anywhere in the equilibration region, unless the default
setting of Rs or Rv is required. If in a live oil problem an Rs or Pb versus depth table is not
referenced for the region, the datum depth must be set at the gas-oil contact. The same
restriction is imposed in gas condensate problems whenever an Rv or Pdew versus depth table is
not referenced.
In gas-water problems, instead of a gas-oil contact and a water-oil contact there is a gas-water
contact. There is no need to enter any data concerning the non-existent oil phase. But it is also
possible to have a gas-water contact in a three-phase problem; namely in a gas condensate
problem where all the oil is initially vaporized in the gas phase. In this case the water-oil contact
and the gas-oil contact should both be placed at the gas-water contact.
Initial composition with respect to depth

In compositional mode, an extra complication exists: as well as ensuring that the initial
saturations are in equilibrium, the thermodynamic equilibrium between phases must be
considered. Two methods exist of setting up the initial composition variation, which is usually
with depth:
1 For single hydrocarbon phase initial states, such as condensates above the dew point, or oils
above the bubble point. No gas-oil phase contact exists within the reservoir. However, this
option should be used for supercritical reservoirs in which a smooth transition exists
between oil and gas, the saturation pressure being less than the fluid pressure throughout
the depth range.
Use ZMFVD to specify the initial composition with respect to depth. The gas-oil contact
may be set above or below the reservoir if the single phase hydrocarbon is an oil or gas. In
the supercritical case the gas-oil contact depth may be set to a point within the reservoir.
The simulator sets the phase identification method to produce a phase change at this depth.
For a condensate field the oil-gas contact depth is set to the oil-water contact depth. This
identifies the study as a condensate to the simulator.
86 Initializing the Study FrontSim Technical Description

Data requirements
2 For cases in which there is a gas-oil contact within the reservoir, and the vapor composition
is known.
Use ZMFVD to specify the initial vapor composition. A retrograde dew point pressure
calculation will be performed for the vapor and the pressure is set to this at the contact. The
composition of the liquid in equilibrium with the saturated vapor will be used below the
contact. As pressure increases with depth this is undersaturated.
3 For cases in which there is a gas-oil contact within the reservoir, and the liquid composition
is known.
Use ZMFVD to specify the initial oil composition. A bubble point pressure calculation will
be performed for the liquid and the pressure will be set to this at the contact. The
composition of the vapor in equilibrium with the saturated liquid will be used above the
contact. As pressure decreases above the contact this may yield an oil phase upon flashing.
If so, only the vapor is used, so that saturated vapor only exists above the contact.
The selection of the option required is made using the tenth argument of the EQUIL keyword.
The 11th argument may be set to 1 to suppress the setting of the pressure at the contact to the
saturation pressure at the contact in options 2 and 3 above. This will yield a system which is not
in initial equilibrium, but will honour the specified pressure.
Equilibration methods such as those described above are the normal method of initializing a
simulation. The aim is to set up a static initial configuration: one in which phases present are in
equilibrium and in which the interblock flows are zero.

Data requirements
The equilibration algorithm
The main keyword involved in this is EQUIL, in the SOLUTION section. This enables the
water-oil and oil-gas contact depths to be set. If either of these contacts is not required, it may
be set outside the depth range of cells in the reservoir. For example, for an all-condensate
initialization, set both contact depths below the lowest cell.
Given the fluid densities, the equilibration procedure sets up saturation against depth curves
such that, in the transition zone when two phases are mobile, the hydrostatic pressure variation
is balanced by the capillary pressure between the phases. This can be done on a finer grid than
that used for the simulation, the resulting saturations being integrated over the cell volumes at
the end of the equilibration to provide a starting point for the simulation.
In general, the use of a fine grid equilibration yields a more accurate fluid in place, but may lead
to some fluid movement upon starting the simulation.
Basic hydrostatic equilibration

The reservoir can be divided into a number of equilibration regions in which hydrostatic
equilibrium exists independently of other regions. Cells are associated with these tables using
the EQLNUM keyword. Cells in a given equilibration region should have the same pressure table
number, and different cells in different equilibration regions should be non-communicating.
For each equilibration region, the fluid contact depths, the capillary pressures at these depths
and the pressure at a given datum depth are specified. In black oil models the dissolved gas
concentration or the bubble point pressure may be entered as a function of depth using the
keywords RSVD and PBVD respectively. In gas condensate models the vaporized oil
concentration or the dew point pressure may be entered as a function of depth using the
keywords RVVD and PDVD respectively.
The datum depth for the pressure can lie anywhere in the equilibration region.
In gas-water problems, the water-oil contact and the gas-oil contact should both be placed at the
gas-water contact. The gas-water capillary pressure should then be supplied as a function of the
water saturation.
The water-oil and gas-oil contacts should also be placed at the same depth for three phase
condensate cases in which the initial state is above the dew point.

The equilibration algorithm
Calculating the initial conditions
Within each equilibration region, the calculation is performed in two stages. The first stage sets
up an internal table of phase pressures, and Rs and Rv for black oil mode simulations, against
depth. The second stage interpolates this table to obtain the fluid conditions in each grid block
in the region.
The internal table stores the values of the phase pressures (Po, Pw, Pg). If in black oil mode, the
dissolved gas concentration (Rs), and in gas condensate problems the vaporized oil
concentration (Rv), are also stored at a number of depths within the equilibration region. The
depth points are spaced equally throughout the region.
Between each pair of depth points in the table, the pressure gradient of each phase is calculated
iteratively using a density consistent with the average pressure within the depth step. If the
datum depth lies in the oil zone, the oil pressure values are calculated first, stepping from the
datum depth up to the top and down to the bottom of the equilibration region. The water pressure
on the oil-water contact can now be obtained, and the water pressure values are calculated.
Similarly the gas pressure values are calculated starting from the gas-oil contact. In black oil
mode, the Rs values are calculated from an Rs or Pb versus depth table supplied in the input data,
or by defaulting to the saturated Rs value on the gas-oil contact. The Rs values are subject to an
upper limit equal to the saturated Rs value at the local pressure. The Rv values are obtained in a
similar manner in gas condensate problems.
In the second stage of the equilibration calculation, the local fluid conditions are determined in
each grid block in the equilibration region. The internal table is interpolated to obtain the values
of Po, Pw, Pg, Rs and Rv at the grid block center depth. The water saturation is determined by
inverse look-up of the water capillary pressure table (entered with keyword SWFN or SWOF) for
the grid block, such that
Pcow(S w) = P o P w [EQ 9.1]
If P o P w exceeds the highest capillary pressure value in the SWFN/SWOF table (corresponding
to the lowest saturation value Swmin), the water saturation is set equal to Swmin.
If P o Pw is less than the lowest capillary pressure in the table (corresponding to the highest
saturation value Swmax), the water saturation is set equal to Swmax and the oil pressure is
adjusted to follow the water pressure gradient.
The gas saturation is similarly determined by inverse look-up of the gas capillary pressure table
(keyword SGFN, SGOF) for the grid block, such that
Pcog(S g) = P g P o [EQ 9.2]
If Pg Po is less than the lowest capillary pressure value in the table (corresponding to the lowest
gas saturation value Sgmin), the gas saturation is set equal to Sgmin.
If P g Po exceeds the highest capillary pressure in the table (corresponding to the highest gas
saturation value Sgmax), the gas saturation is set equal to Sgmax and the oil pressure is adjusted
to follow the gas pressure gradient.
In black oil problems, the R s value is simply interpolated from the internal table at the grid block
depth. However, if there is a non-zero gas saturation at that depth the R s value is re-set to the
saturated Rs value at the local pressure. The Rv value is obtained in a similar manner in gas
condensate problems.

Since the water and gas saturations outside the transition zones are set to the respective end-
point values in the saturation function tables, the end-points of the two tables must be consistent.
Normally the lowest gas saturation in the SGFN or SGOF table should be zero (so that S g = 0
below the gas transition zone), and the highest gas saturation in this table should be 1 S wmin (so
that S o = 0 above the gas transition zone). The lowest water saturation value in the SWFN or
SWOF table should be the connate value (so that S w = S wco above the water transition zone), and
the highest water saturation in this table should be 1.0 (so that S w = 1.0 below the water
transition zone). The consistency requirements between saturation tables are detailed in
"Saturation Functions" on page 107.
In cases where the water-oil and gas-oil transition zones closely overlap, the treatment outlined
above may produce negative oil saturations. For example, where the water-oil transition zone
extends above the gas-oil transition zone, the water saturation ( S w > S wmin ) and the gas saturation
( S g = S gmax ) will add to more than 1.0. If this occurs, the water and gas saturations will be
recalculated from the gas-water capillary pressure, which is taken as the sum of the water-oil
and gas-oil capillary pressures
Pcow(S w) + P cog(S g = 1 S w) = P g P w [EQ 9.3]
Note If the saturation tables contain values of P cow for any value of Sw , FrontSim
automatically equilibrates taking account of the capillary pressure. However, FrontSim
currently ignores capillary pressure for the remainder of the simulation. An option to
set SWCR based on the initial saturation is available in OPTIONFS, parameter 37.
Accurate fluids in place calculation

There is a choice of methods to calculate the initial fluid in place values (the initial oil, water
and gas saturations) in each grid block. These are selected using the ninth argument of the
EQUIL keyword, which specifies the number of sub-layers (N) used to obtain the initial
saturations:
Center-point equilibration (N=0)

The simulator sets the fluid saturations in each grid block according to the conditions at its
center. This is the fastest method, and yields a stable initial state since the phase pressure
differences in the simulation are also taken between cell centers. But it is the least accurate
method, particularly in cases where the fluid contact passes through large grid blocks.
Black Oil Fine grid equilibration N 0

FrontSim computes a volumetric average for the cell. This computation is not exactly equivalent
to the ones used by ECLIPSE 100 and ECLIPSE 300. That is, if the OWC passes through a cell
then FrontSim analytically calculates the fraction of the volume of the cell above the OWC and
the fraction of the cell below the OWC. The oil saturation So is equal to the fraction of the
volume above the contact and water saturation Sw is equal to the fraction of the volume below.
A similar calculation is performed for cells with the GOC contact passing through them. The
values of Rs and Rv are those at the cell center.

Compositional Horizontal fine grid equilibration (N<0)
The top and bottom halves of each grid block are each divided into -N layers of equal thickness,
and the saturations are determined locally in each layer. The phase saturations for the block are
set equal to the average of the saturations in each layer. This option provides a more accurate
calculation of the fluids in place, but may yield a solution which is not completely stable in the
initial state.

Local Grid Refinement
Chapter 10
Introduction
The Local Grid Refinement option allows enhanced grid definition near wells. The local models
x ECLIPSE 100
x ECLIPSE 300
are 3D Cartesian. Local models may have more layers than the global model. Transmissibilities
x SPECIAL between the local models and the global model are computed automatically by FrontSim. The
x FRONTSIM properties of the cells in the local grid can be inherited from the Global grid or specified
explicitly for the refined cells.
FrontSim Technical Description Local Grid Refinement 93

Introduction
Local grid refinement
Cartesian refinements
Cartesian refinements (the only type of refinement supported by FrontSim) are specified by
keyword CARFIN. For example, to replace layers 3 and 4 in column (2,3) of the global model
with a 5*5*8 Cartesian refinement with new porosities and permeabilities:
CARFIN
-- NAME I1-I2 J1-J2 K1-K2 NX NY NZ NWMAX--
'LGR1' 2 2 3 3 1 1 5 5 1 /
PORO
200*0.2 /
EQUALS
'PERMX' 500 /
'PERMY' 500 /
'PERMZ' 50 /
/
ENDFIN
This creates a refinement which looks like Figure 10.1 (in the areal direction).
Figure 10.1 Cartesian grid refinement
The primary purpose of ENDFIN is to revert FrontSim to reading data for the global grid
system.
Placing wells in local grids

To place a well in a local grid, use keywords WELSPECL and COMPDATL instead of
WELSPECS and COMPDAT. WELSPECL is similar to WELSPECS except that there is an
additional item - the name of the local grid - between the group name and the I-J location.
COMPDATL has exactly the same items as COMPDAT. In these keywords the I, J and K locations
of the wellhead and the connecting cells refer to the cell coordinates in the local grid system.
The I and J locations of the connecting cells must be entered explicitly in COMPDATL, and
should not be defaulted as they can be in COMPDAT.
94 Local Grid Refinement FrontSim Technical Description

To complete well PRODUCER in layers 9 to 11 of the refined grid named 'SOUTH', in all four
theta sections of the innermost block:
WELSPECL
-- WELL -- GROUP -- LOCAL GRID -- LOCATION -- BHP -- PREF
-- NAME -- NAME -- NAME -- I J -- DEPTH -- PHASE
'PRODUCER' 'G' 'SOUTH' 1 1 8060 'OIL' /
/
COMPDATL
-- WELL -- LOCATION -- OPEN -- SAT -- CONN -- WELL
-- NAME -- IR JTH K1 K2 -- SHUT -- TAB -- FACT -- DIAM
'PRODUCER' 1 1 9 11 'OPEN' 0 -1 0.4 /
'PRODUCER' 1 2 9 11 'OPEN' 0 -1 0.4 /
'PRODUCER' 1 3 9 11 'OPEN' 0 -1 0.4 /
'PRODUCER' 1 4 9 11 'OPEN' 0 -1 0.4 /
/
Wells not completed in local grid systems should have their specification and connection data
set with the keywords WELSPECS and COMPDAT as normal. FrontSim checks that these wells
are not completed in a cell that is host to a refined grid system.
Defining local grid block sizes

Most GRID section keywords may be inserted between CARFIN and ENDFIN to alter refined
grid block properties from those of the host cells.
Local grid block sizes can be defined in terms of fractions of the host grid using the following
keywords, which are especially useful if the global grid has been defined in corner geometry:
NXFIN, NYFIN, NZFIN Define number of local cells in each host cell
For example, to define a local grid of 5 layers in a host of 2 layers:
CARFIN
--NAME I1 I2 J1 J2 K1 K2 NX NY NZ
LGR2 3 4 1 2 5 6 4 2 4 /
--Two global cells in x-direction to become 4 local cells

--with three local cells in first global, 1 in second
NXFIN
3 1 /
Two global cells in x-direction to become 4 local cells, with three local cells in the first global
cell, 1 in the second.

Defining local grid rock properties
By default, values of porosity, permeability, transmissibility multipliers, etc., are copied to local
grid cells from the global host cells. In most cases this is adequate, but it is possible to define
properties directly for some or all of the cells within a local grid by specifying grid arrays
between the CARFIN/ENDFIN or REFINE/ENDFIN pairs. When the end of the GRID section
is reached, any values that have not been explicitly defined for local cells are then copied from
the global host cells. For example:
CARFIN
-- NAME I1-I2 J1-J2 K1-K2 NX NY NZ NWMAX
'NORTH' 5 10 5 10 1 4 18 18 8 5 /
EQUALS
'PORO' 0.3 1 18 1 18 1 4 /
'PERMZ' 50.0 1 18 1 18 1 4 /
'NTG' 0.9 1 18 1 18 1 8 /
/
MULTIPLY
'PORO' 0.5 6 13 6 13 1 2 /
'NTG' 0.2 6 13 6 13 1 2 /
/
ENDFIN
This defines the porosities only in the top four layers on the local grid, and these are
subsequently modified for the top two layers with the MULTIPLY keyword. The porosities for
cells in the bottom four layers will be copied from their host cells in the global grid.
Region data and end point scaling

By default, cells in the local grid systems will be assigned REGIONS section data values
(SATNUM, PVTNUM etc.) and end-point scaling data (if the option is active) from their
corresponding global host cells. In many cases this will prove adequate.
However it is possible to modify selected data quantities from the REGIONS and PROPS
sections within local grids, using the REFINE keyword. This keyword operates in exactly the
same way as the CARFIN keyword in the GRID section, and can be applied in either the
REGIONS or PROPS sections. Any data following a REFINE keyword is applied to the named
local grid refinement until either another REFINE keyword or an ENDFIN keyword is
encountered. An example that sets SATNUM values in a local grid containing 250 cells is:
REFINE
'CARF882' /
SATNUM
125*1
125*2 /
ENDFIN
For Cartesian refinements, transmissibilities between the local and global grid are calculated
from the usual formulae.

A report on transmissibilities between the local and global grids can be obtained by using switch
16 in OPTIONFS.
Treatment of transmissibility multipliers in local grids

It is possible to enter transmissibility multipliers MULTX, MULTY, MULTZ etc. for local grids
between the CARFIN/ENDFIN and REFINE/ENDFIN pairs in the GRID section. If any of these
multipliers are not defined for the local grid, they are inherited from the host cells of the global
grid according to the following rule: The multiplier on the transmissibility between two adjacent
local grid cells is set to the global multiplier in the appropriate direction at a cell boundary of
the global grid, and is set to 1.0 otherwise.
Timesteps
FrontSim solves LGRs using the same timestep as the global grid. There is no local
timestepping option.
Restrictions on the use of local grids

1 Partially overlapping LGRs are not allowed.
2 Aquifers cannot be attached to local grids. FrontSim ignores any aquifer connections to
refined cells.
3 The EDITNNC keyword for the global grid should not refer to non-neighbor connections
connecting refined cells in the global grid.
Treatment of wells in local grids

Wells are placed in local grids by using keywords WELSPECL and COMPDATL instead of
WELSPECS and COMPDAT. The I, J and K locations of the wellhead and connections refer to
the cell coordinates within the wells refined grid system.
Problems with local grid wells

When a well is under rate control, its potential flow rate in a local grid system can be much
larger than it would be in the un-refined global grid. This is because the connecting grid blocks,
whose pressures are used in the potential calculation, are much smaller in the local grid system.
In calculating the potential, the assumption is made that the pressures in the connecting grid
blocks will not change if the well flow rate increases from its current value to its potential value.
While this may be a reasonable assumption in the global grid, it is not true for highly refined
local grids. The smaller the connecting grid blocks are, the more optimistic will be the potential.

Geometry and grid data in LGRs
Transmissibility data
In general, if grid data are not specified for a local refinement (by inserting keywords between
CARFIN and ENDFIN) then they are derived from the properties of the host cells. The user
should note the following conventions used for default local permeability and transmissibility
data.
Transmissibility multipliers
Transmissibility multipliers (MULTX, MULTY, MULTZ) are applied to the X+, Y+ and Z+ faces
of each grid block. For a local refinement, multipliers can be copied from the host grid only if
the positive face of the local cell coincides with a host cell face; otherwise, a default value of
1.0 is used. If this is inappropriate, transmissibility multipliers should be explicitly defined for
the local grid.
Note For connections between local and global cells, the transmissibility multipliers for the
adjoining global block are used for flows in the X-, Y- or Z- directions. The local grid
block multipliers are used for flows in the X+, Y+ or Z+ directions.
Pore volumes
The pore volume of a refined global cell may differ from the sum of the pore volumes of the
local cells which it contains, either because the local porosities and net-to-gross ratios differ
from the values for the host cell or because of discrepancies in geometry.
After computing the local pore volumes, FrontSim replaces the pore volume of the host cell with
the sum of the refined pore volumes. Pore volume reports are produced after any modifications
have been made.
Alphabetical list of GRID section keywords

allowed within a local grid
Refer to the "FrontSim User Guide" for a further description of each keyword.
Table 10.1 GRID section keywords
Keyword Description
ACTNUM Identifies active grid blocks.
ADD Adds specified constants to specified arrays in the current box.
BOX Re-defines the current box.
COORD Defines the lines which contain all grid block corner points for each (i, j)
and for each reservoir in the grid.

Table 10.1 GRID section keywords
Keyword Description
COPY Copies data in the current box from one specified array to another.
DXV, DYV Vector of X direction, Y direction grid block sizes.
ENDBOX Re-defines the current box to encompass the whole grid.
EQUALS Sets specified arrays to specified constants in the current box.
MINPV Sets a minimum pore volume that each cell must have to be active.
MULTIPLY Multiplies specified arrays by constant values in the current box.
MULTX/Y/Z/ Transmissibility multipliers
X-/Y-/Z-
NTG Grid block net-to-gross ratios for the current box.
NXFIN, NYFIN, Sets the number of local cells in each global cell of a local grid refinement
NZFIN
PERMX, PERMY, Specifies the permeability in the X, Y or Z direction for the current box.
PERMZ
PORO Grid block porosities for the current box.
ZCORN Depths of grid block corners.

Example LGR problem
RUNSPEC
RUNSPEC
FRONTSIM
TITLE
Well in lgr
DIMENS
10 10 1 /
METRIC
OIL
WATER
START
1 JAN 1998 /
TABDIMS
1 1 /
WELLDIMS
5 8 2 5 /

Example LGR problem
GRID
GRID
GRIDFILE
0 /
INIT
DXV
10*100 /
DYV
10*100 /
DEPTHZ
121*2000 /
DZV
100 /
PORO
100*0.5 /
PERMX
100*100 /
PERMY
100*100 /
PERMZ
100*100 /
CARFIN
LGR01 4 7 4 7 1 1 8 8 1 /
PERMX
64*200 /
PERMY
64*200 /
PERMZ
64*200 /
ENDFIN
PROPS
PROPS
PVDO
304 1 4 /
PVTW
304 1 0 0.42 /
RSCONSTT
0 0 /
DENSITY
780 1014 1 /
SOF2
0.35 0
0.92 1 /
SWFN
0.08 0 0
1 0.36 0 /
REGIONS

Example LGR problem
SOLUTION
SOLUTION
EQUIL
2000 300 2150 /
SUMMARY
SCHEDULE
TUNEFSPR
1 5* /
TUNEFSSA
0 /
WELSPECL
P1 A LGR01 2 4 1* LIQ 3* 1* 3* /
/
WELSPECS
I1 B 1 1 1* LIQ 3* 1* 3* /
I2 B 10 10 1* LIQ 3* 1* 3* /
I3 B 1 10 1* LIQ 3* 1* 3* /
B 10 1 1* LIQ 3* 1* 3* /
/
COMPDAT
I1 0 0 1 1 1* 1* 1* 1* 1* 1* 1* Z /
I2 0 0 1 1 1* 1* 1* 1* 1* 1* 1* Z /
I3 0 0 1 1 1* 1* 1* 1* 1* 1* 1* Z /
I4 0 0 1 1 1* 1* 1* 1* 1* 1* 1* Z /
/
COMPDATL
P1 LGR01 1 4 1 1 1* 1* 1* 1* 1* 1* 1* X /
P1 LGR01 2 4 1 1 1* 1* 1* 1* 1* 1* 1* X /
P1 LGR01 3 4 1 1 1* 1* 1* 1* 1* 1* 1* X /
P1 LGR01 4 4 1 1 1* 1* 1* 1* 1* 1* 1* X /
P1 LGR01 5 4 1 1 1* 1* 1* 1* 1* 1* 1* X /
P1 LGR01 6 4 1 1 1* 1* 1* 1* 1* 1* 1* X /
P1 LGR01 7 4 1 1 1* 1* 1* 1* 1* 1* 1* X /
P1 LGR01 8 4 1 1 1* 1* 1* 1* 1* 1* 1* X /
/
WCONPROD
P1 1* RESV 4* 1500 /
/
WCONINJ
I1 WATER 1* RESV 2* 0.25 FVDG /
/
WECON
P1 1* 1* 1 1* 1* /
/
TSTEP
730 /

Example LGR problem
TSTEP
730 /

Example LGR problem
Restarts
Chapter 12
Introduction
A run can be restarted by supplying a complete data file, and taking the initial solution from the
x ECLIPSE 100
x ECLIPSE 300
RESTART file. It is possible to restart a run with, for example, altered permeability data; but in
SPECIAL general such changes are not recommended.
x FRONTSIM
To do a restart from (say) the 11th report time of run BASE, the procedure is:
1 Think of a new file name root - say R1.
2 Copy the data file BASE.DATA into R1.DATA.
3 Edit R1.DATA.
In the SOLUTION section, delete all equilibration or enumeration keywords, and any
analytic aquifer keywords. Insert the RESTART keyword to specify the restart file and
report number.
In the SCHEDULE section delete the well and time-stepping keywords up to and including
the restart time, at report number 11 in the example. Modify the SCHEDULE data after
report 11 as required.
4 Submit the run with R1 as the root filename.
RESTART
'BASE' 11 /
Alternatively the SKIPREST keyword can be used skip all keywords (except the ones listed
below) until the time of restart.
FrontSim Technical Description Restarts 105

Introduction
Requesting RESTART files in FrontSim
By default, the restart data written at each report time are stored in separate RESTART files. The
suffix of the files indicates the report number at which the data was written. Optionally, the time-
dependent restart data written at each report can be stored in a single Unified Restart file
instead. If you wish to produce a Unified RESTART file, enter the keyword UNIFOUT in the
RUNSPEC section. To enable FrontSim to read a Unified RESTART file, the keyword UNIFIN
must be present in the RUNSPEC section - otherwise FrontSim looks for non-unified RESTART
files.
To create RESTART files from which a later run can restart, the procedure is:
1 Set the mnemonic BASIC in the RPTRST keyword =3. It will result in the automatic
generation of RESTART files at specific intervals of time set with the FREQ switch.
2 A RESTART file can also be generated at time 0.0 days, containing the initial solution, by
setting the mnemonic RESTART in the RPTSOL keyword to 2. There must be at least one
TSTEP or DATES keyword present to generate the time zero RESTART file.
SCHEDULE section data not stored in the

FrontSim RESTART file
Apart from the exceptions detailed below, all the SCHEDULE section data from the base run is
written to the restart file and applied in the restart run. The exceptions are the following
keywords, whose data is not carried over on the RESTART file:
Reservoir property keywords - boundaries, aquifers, etc.: AQUFLUX, FLUXSIDE, PNODE,
PSIDE and PSIDEH.
Simulation controls - output, tuning, etc.: FSSOLVE, FSWEAKW, GOCADOUT, GUIDERAT,
MAXSTEP, NEXTSTEP, MINSTEP, TSCRITFS, OPTIONFS, RANKING, RPTLINFS,
RPTPRINT, RPTRST, RPTSCHED, TUNEFS1D, TUNEFSPR and TUNEFSSA,
WRFTPLT.
Other keywords that need to specified: VFPPROD, VFPINJ, WELLSTRE, WINJGAS,
WPIMULT, WTMULT, WSOLVENT, WCONINJP.
Notes on RESTARTS in FrontSim

1 The following data cannot be changed at a restart:
a The grid dimensions NDIVIX, NDIVIY, NDIVIZ, and the number of active cells.
b The unit convention.
c The type of well model for existing wells.
2 Passive tracers can be added in a flexible restart, even if the base run had no tracers. They
should be initialized as usual in the SOLUTION section with keyword TBLK.
106 Restarts FrontSim Technical Description

Introduction
Saturation Functions
Chapter 13
Introduction
Relative permeabilities are entered as tables (keywords SWFN, SGFN, SOF2 and SOF3 or the
x ECLIPSE 100
x ECLIPSE 300
alternative family SWOF and SGOF). Saturation values need not be specified at equal intervals,
SPECIAL and are used in the specified form, rather than being interpolated onto regular intervals.
x FRONTSIM
All the saturation functions may be entered in multi-table form; tables are associated with cells
using the SATNUM keyword.
There are two families of keywords that define the saturation-dependent properties of the
reservoir fluids. The difference between them is that the first family allows you to enter the oil
relative permeabilities in the same tables as the water and gas relative permeabilities, while in
the second family the oil relative permeabilities must be entered in a separate table versus oil
saturation.
Either family can be used; however, keywords from different families must not be mixed in the
same run.
Note FrontSim does not fully support capillary pressure. For compatibility with ECLIPSE,
values must always be supplied. If capillary pressures are supplied, FrontSim
automatically equilibrates taking account of the capillary pressure. However, FrontSim
currently ignores capillary pressure for the remainder of the simulation. See
"Initializing the Study" on page 85 for more information.
The keyword families are described below:
Family (i)
SWOF sets water relative permeability, oil relative permeability in water, and water-oil capillary
pressure as a function of water saturation. This is required for 2 or 3 phase systems with both
water and oil.
FrontSim Technical Description Saturation Functions 107

Introduction
SGOF sets gas relative permeability, oil relative permeability in gas at connate water, and oil-
gas capillary pressure as a function of gas saturation. SGOF is required for 2 or 3 phase systems
with both gas and oil.
Family (ii)
SWFN sets water relative permeability and capillary pressure as a function of water saturation.
This is required for 2 or 3 phase systems with water.
SGFN sets gas relative permeability and capillary pressure as a function of gas saturation. This
is required for 2 or 3 phase systems with gas.
SOF3 sets relative permeability of oil in water, and oil in gas at the connate water saturation, as
a function of oil saturation. SOF3 is required for 3-phase systems.
SOF2 sets oil relative permeability as a function of oil saturation. This is required for 2-phase
systems with oil.
108 Saturation Functions FrontSim Technical Description

Introduction
Water saturation properties
An example data table for the SWFN keyword is given below. The data for the SWOF keyword
is similar but with an additional column containing oil relative permeabilities.
-- SWAT KRW PCOW

-- (PSIA)
SWFN
.22 .0 7.0
.3 .07 4.0
.4 .15 3.0
.5 .24 2.5
.6 .33 2.0
.8 .65 1.0
.9 .83 .5
1.0 1.0 .0 /
The water saturations must be entered in ascending order.

The third column is the oil-water capillary pressure ( Pcow = Po Pw ).
Three saturation values in the table are of special interest:
S wcr The critical water saturation. This is the highest saturation value for which the relative
permeability is zero. At saturations above this value, water is mobile. Note that a critical water
saturation must be defined (the SWFN or SWOF table must contain a water saturation for which
k rw = 0 ). In the example above, S wcr = 0.22 .
S wco The minimum water saturation value in the table. The Equilibration calculation (see
keyword EQUIL) sets the water saturation to this value in grid blocks that lie above the water
contact (or water transition zone). In this respect S wco is the connate water saturation. In the
example shown above, S wco = S wcr . If for any reason the connate water saturation is less than
the critical value, the table should begin with the connate value. For example, for Swco = 0.2 and
S wcr = 0.22 , the table should begin with the lines
.20 .0 7.0
.22 .0 7.0
.3 .07 4.0
etc.
S w max
The maximum water saturation value in the table. The Equilibration calculation sets the water
saturation to this value in grid blocks that lie below the water transition zone.
In the example shown above, S w max = 1.0 , which results in the water zone being fully saturated
with water.

Gas saturation properties
An example data table for the SGFN keyword is given below. The data for the SGOF keyword
is similar but with an additional column containing oil relative permeabilities.
-- SGAS KRG PCOG

-- (PSIA)
SGFN
.0 .0 0.0
.04 .0 .2
.1 .022 .5
.2 .1 1.0
.3 .24 1.5
.4 .34 2.0
.5 .42 2.5
.6 .5 3.0
.7 .81 3.5
.78 1.0 3.9 /
The gas saturations must be entered in ascending order.

The third column is the oil-gas capillary pressure ( Pcog = P g P o ).
Three saturation values in the table are of special interest:
S gcr The critical gas saturation. This is the highest saturation value for which the relative
permeability is zero. At saturations above this value, gas is mobile. Note that a critical gas
saturation must be defined (the SGFN or SGOF table must contain a gas {or liquid} saturation
for which krg = 0 ). In the example above, Sgcr = 0.04 .
S gcoThe minimum gas saturation value in the table. The Equilibration calculation (see keyword
EQUIL) sets the gas saturation to this value in grid blocks that lie below the gas contact (or
water transition zone). In this respect Sgco is the connate gas saturation. Normally Sgco = 0.0 ,
as in the example above.
S g max The maximum gas saturation value in the table. The Equilibration calculation sets the gas
saturation to this value in grid blocks that lie above the gas transition zone. Normally
S g max = 1.0 S wco , as in the example above, with S wco = 0.22 as in the first SWFN table example
in this chapter.

Gas saturation properties
Oil saturation properties
The relative permeabilities of oil in water, and oil in gas and connate water, are entered either
in keywords SWOF and SGOF, or with keyword SOF3 (or SOF2 in a 2-phase run).
The relative permeability tables are not used in the calculation of the initial saturations. The
equilibration calculation sets oil saturations using the formula So = 1 Sw S g .
An example data table for keyword SOF3 is given below. If Family (i) were being used, the k row
data would be included in keyword SWOF and the krog data would be included in keyword
SGOF.
-- SOIL KROW KROG

SOF3
.0000 .0000 .0000
.2000 .0000 .0000
.3800 .0045 .0000
.4000 .0050 .0040
.4800 .05292 .0200
.5000 .0649 .0360
.5800 .1130 .1000
.6000 .1250 .1460
.6800 .3450 .3300
.7000 .4000 .4200
.7400 .7000 .6000
.7800 1.0000 1.0000 /
The oil saturations must be entered in ascending order in column 1. Columns 2 and 3 contain
the corresponding oil relative permeabilities for oil-water systems, and for oil-gas-connate
water systems respectively.
Five saturation values in the table are of special interest:
S oco The minimum oil saturation value in the table. This is the connate oil saturation.
Normally, S oco = 0.0 , as in the example above.
S ocr The critical oil saturation. This is the highest saturation value for which both the oil-water
and oil-gas permeabilities are zero. At saturations above this value, oil is mobile in the three-
phase region. Note that a critical oil saturation must be defined (the SOF3 table must contain
an oil saturation for which both krow and krog are 0). In the example above, S ocr = 0.20 .
S orw The Residual Oil Saturation in the oil-water system. This is the saturation at which the oil
relative permeability in the oil-water system becomes zero (So at which k row = 0 ). In the
example above, Sorw = 0.20 .
S org The Residual Oil Saturation in the gas-oil system. This is the saturation at which the oil
relative permeability in the gas-oil system becomes zero ( S o at which krog = 0 ). In the example
above, Sorg = 0.38 .

S o maxThe maximum oil saturation value in the table. This should be equal to 1 S wco as
determined from the SWFN table. The two oil relative permeabilities should be the same at S o max
(both represent a case with So = So max , S w = S wco and S g = 0 ). FrontSim reports an error if this
condition is not satisfied.

Three phase oil relative permeability models
A choice of three different formulae are available for calculating the 3-phase oil relative
permeability at particular water and gas saturations, from the input relative permeabilities of oil
in water and oil in gas and connate water.
The default model for the 3-phase oil relative permeability is based on an assumption of
complete segregation of the water and gas within each grid cell. The model provides a simple
but effective formula which avoids the problems associated with other methods (poor
conditioning, negative values etc.). FrontSim also contains options for using either of the
modified three phase oil relative permeability models suggested by Stone. These models are
summarized by Aziz and Settari, [Ref. 25].
The default model assumed by FrontSim is shown in Figure 13.1. The oil saturation is assumed
to be constant and equal to the block average value, S o , throughout the cell. The gas and water
are assumed to be completely segregated, except that the water saturation in the gas zone is
equal to the connate saturation, Swco . The full breakdown, assuming the block average
saturations are S o , S w and S g (with S o + S w + S g = 1 ) is as follows:
In a fraction S g ( Sg + S w S wco ) of the cell (the gas zone),
the oil saturation is So
the water saturation is S wco
the gas saturation is S g + S w S wco
In a fraction ( S w Swco ) ( S g + S w Swco ) of the cell (the water zone),
the oil saturation is So
the water saturation is S g + S w
the gas saturation is 0
The oil relative permeability is then given by
S g k rog + ( S w S wco )k row
k ro = ------------------------------------------------------------
- [EQ 13.1]
S g + S w S wco
where
is the oil relative permeability for a system with oil, gas and connate water (tabulated as a
k rog
function of S o )
k rowis the oil relative permeability for a system with oil and water only (also tabulated as a
function of S o )

Figure 13.1 The default 3-phase oil relative permeability model assumed by FrontSim
Swco 1-So-Swco So
0
Gas
Oil
Sg/(Sg+Sw-Swco)
Water
1-So So
Stones first model (Modified)

The second model available in FrontSim for calculating values of the three phase oil relative
permeability is a modified version of the first model suggested by Stone [Ref. 26] and is
available with keyword STONE1 in the PROPS section. The formula is
k ro = k rocw SSo Fw F g [EQ 13.2]
where
k rocw is the value of the oil relative permeability in the presence of connate water only
SS o = ( S o S om ) ( 1 S wco S om ) when S o > Som
F w = k row ( k rocw ( 1 SS w ) )
F g = k rog ( k rocw ( 1 SS g ) )
where
SS w = ( S w S wco ) ( 1 S wco S om ) when S w > S wco
SS g = S g ( 1 S wco S om )
In these formulae S o , S w and S g denote block averaged values for the oil, water and gas
saturations in a grid cell. k rog denotes the oil relative permeability for a system with oil, gas and
connate water, and krow denotes the oil relative permeability for a system with oil and water
only. Both two phase oil relative permeability functions are tabulated as functions of oil
saturation in the input data. k rocw denotes the oil relative permeability in the presence of connate
water only.
S om is the minimum residual oil saturation. By default Som is taken to be the minimum of the
critical oil-to-water saturation and the critical oil-to-gas saturation, min ( Sowcr, S ogcr ) .

Stones second model (Modified)
The third model provided in FrontSim for calculating values of the three phase oil relative
permeability is a modified form of the second model suggested by Stone [Ref. 27]. The formula
is
k row
------------ k rog- + k k k
k ro = k rocw k - + k rw ------------ rg rw rg [EQ 13.3]
rocw k
rocw
where krog denotes the oil relative permeability for a system with oil, gas and connate water;
k row denotes the oil relative permeability for a system with oil and water only. Both sets of two
phase oil relative permeability functions are tabulated as functions of oil saturation in the input
data. k rocw is the oil relative permeability in the presence of connate water only.
Note Note the values of kro produced by this formula can be negative. FrontSim
automatically changes any negative kro values produced to zero.
The calculation of three phase oil relative permeability using Stones method 2 is enabled by
means of STONE2 keyword in the PROPS section of the input data.

Table end points
In the equilibration calculation (see keyword EQUIL) the water and gas saturation values are
determined from the maximum and minimum saturation values in the water and gas saturation
tables. The oil saturation values are thus defined consequentially from these values. The initial
saturations in each zone are shown in Figure 13.2.
Figure 13.2 Initial saturations for each zone
Sg = Sg max
GAS ZONE Sw = Swco
So = 1 - Sg max - Swco
GAS - OIL TRANSITION ZONE
Sg = Sgco
OIL ZONE Sw = Swco
So = 1 - Sgco - Swco
OIL-WATER TRANSITION ZONE
Sg = Sgco
WATER ZONE Sw = Sw max
So = 1 - Sgco - Sw max

Table end points
Consistency requirements
The oil, water and gas saturation tables, for each particular saturation table number region, must
obey certain consistency requirements. These are detailed below.
1 S g max must not exceed 1 S wco
Normally, if there is no oil in the gas cap, S g max = 1 S wco .
2 S gco must not exceed 1 S w max
Normally, there is no initial free gas below the gas cap, and the water zone is fully saturated
with water, thus S gco = 0 and S w max = 1.
3 S o max must equal 1 Swco
4 k row(S o max) must equal krog(So max)
5 k rw(S w = 0) = k rg(S g = 0) = k row(S o = 0) = k rog(S o = 0) = 0 .
Otherwise, phases can be mobile even at zero saturation and there is nothing to stop saturations
going negative.
Mobile fluid requirements

In order to ensure that at least one fluid remains mobile in the three-phase ternary diagram,
FrontSim also checks for the following:
1 S ocrw + S wcr < 1
2 S ocrg + S gcr + S wco < 1
FrontSim issues a warning if these conditions are not satisfied. When SCALECRS is used, this
would lead to an error because in an oil-water run, for example, K rw would be scaled between
S wcr and 1 S ocrw that is a null range if the first condition is not satisfied.

Figure 13.3 Ternary diagram showing mobile fluid end-points
Water 100%
So=Sowcr
Sg=Sgcr
So=1-Swcr Sw=Swcr So
So
S =1-S
g wcr
Sw=Swco
Oil 100% So=1-Sgcr So=Sogcr Gas 100%

Saturation Table Scaling
Chapter 14
Introduction
The FrontSim saturation table End-point Scaling option allows you to redefine values for the
x ECLIPSE 100
x ECLIPSE 300
connate, critical and maximum saturations in the saturation tables describing the flow of the
SPECIAL reservoir fluids. The scaling facility is useful for modeling reservoirs which contain an initial
x FRONTSIM depth variation of either the connate or critical saturations for one or more of the phases present.
It has applications in general cases where the saturation function data for the reservoir fluids
depend on a normalized saturation variable.
The End-point Scaling option is enabled by the ENDSCALE keyword in the RUNSPEC section.
Separate re-scaling is done on relative permeability pressure curves. Generally, each is a two-
point rescaling, two saturation values in the tables being moved to new positions. There is also
an option to apply a three-point rescaling to the relative permeability curves only.
In a three phase model there are eight saturation table end points which may be identified:
SWL - connate water saturation. This is the smallest water saturation entry in a water saturation
table.
SWCR - critical water saturation. This is the highest water saturation for which the water is
immobile.
SWU - maximum water saturation. This is the largest water saturation entry in a water saturation
table.
SGL - connate gas saturation. This is the smallest gas saturation entry in a gas saturation table.
SGCR - critical gas saturation. This is the highest gas saturation for which the gas is immobile.
SGU - maximum gas saturation. This is the largest gas saturation entry in a gas saturation table.
SOWCR - critical oil-in-water saturation. This is the highest oil saturation for which the oil is
immobile in an oil-water system.
SOGCR - critical oil-in-gas saturation. This is the highest oil saturation for which the oil is
immobile in an oil-gas-connate water system.
We shall refer to the saturation end points taken from the saturation tables in the input data file
as the unscaled saturation end points.
FrontSim Technical Description Saturation Table Scaling 119

Introduction
The End-point Scaling option enables you to define new values for any of the above eight
saturation end points for each grid cell, subject to maintaining a consistent set of saturation
tables within each grid cell. The appropriate subset of the above eight end points is applicable
in two phase runs. The new values defined using the scaling option will be referred to as the
scaled end points.
When relative permeability values need to be computed at a particular saturation, a linear
transformation is used to determine the equivalent saturation to be used for look-up in the
unscaled table.
120 Saturation Table Scaling FrontSim Technical Description

Introduction
Scaling of relative permeability functions
There are two options available for the scaling of relative permeabilities. In the default case, the
scaling process preserves relative permeabilities at two saturation nodes. The following end
points are assumed for each phase relative permeability:
Krw: SWCR & SWU
Krg: SGCR & SGU
Krow: SOWCR & (1.0-SWL-SGL)
Krog: SOGCR & (1.0-SWL-SGL)
An alternative scaling of relative permeabilities can be invoked by using the SCALECRS
keyword in the PROPS section. The second form of scaling preserves the relative permeabilities
at three saturation nodes. In 3-phase, oil-water or oil-gas runs, or runs which use the miscible
flood option, the following end points are used:
Krw: SWCR, (1.0-SOWCR-SGL) & SWU
Krg: SGCR, (1.0-SOGCR-SWL) & SGU
Krow: SOWCR, (1.0-SWCR -SGL) & (1.0-SWL-SGL)
Krog: SOGCR, (1.0-SGCR -SWL) & (1.0-SWL-SGL)
In gas-water runs, the following end points are used if the second form of relative permeability
scaling is selected:
Krw: SWCR, (1.0-SGCR) & SWU
Krg: SGCR, (1.0-SWCR) & SGU
The second method for relative permeability scaling can be interpreted in two phase runs as
preserving the values of relative permeabilities at both ends of the 2-phase mobile region.
Convergence problems can arise in certain cases when using this form of scaling if the
intermediate end point begins to approach the maximum saturation for one of the phases. For
example, in an oil-water problem in which the residual oil saturation to water tends to zero at a
certain depth, the saturation (1.0-SOWCR) begins to approach SWU and this can in turn lead to a
discontinuity in the water relative permeability as Sw S w max .
For example, we consider the scaling of the water relative permeability function K rw ( SW ) at a
water saturation SW where the scaled and unscaled critical water saturations are SWCR and
S wcr , scaled and unscaled oil-in-water critical saturations are SOWCR , and S owcr , scaled and
unscaled connate gas saturations are SGL and S gco , and scaled and unscaled maximum water
saturations are SWU and S wmax .
With the two point scaling method, the water relative permeability K rw ( SW ) is then evaluated in
the input saturation table at the new saturation SW , where
( SW SWCR ) ( S wmax S wcr )
SW = S wcr + ----------------------------------------------------------------------
- [EQ 14.1]
SWU SWCR
so that K rw is evaluated by lookup in the input table using
K rw ( SW ) = K rw ( SW ) ( table ) for SWCR SW SWU . For SW SWCR then K rw ( SW ) = 0 and

for SW SWU then K rw ( SW ) = K rwmax ( table ) .

With the three point scaling method, then if SR is the displacing critical saturation of the
associated phase saturation (SR) of the associated phase.
SR = 1 SOWCR-SGL in water/oil or gas/oil/water runs
SR = 1 SGCR in gas/water runs
and Sr is the value of the displacing critical saturation in the table
S r = 1 S owcr S gco in water/oil or gas/oil/water runs
S r = 1 S gcr in gas/water runs
The two cases are:
SWCR SW SR
( SW SWCR ) ( S r S wcr )
SW = S wcr + ------------------------------------------------------------
- [EQ 14.2]
SR SWCR
SR SW SWU
( SW SR ) ( S wmax S r )
SW = S r + -------------------------------------------------------
- [EQ 14.3]
SWU SR
and also for SW SWCR then K rw ( SW ) = 0 and for SW SWU then
K rw ( SW ) = K rwmax ( table ) . [EQ 14.4]
The two- and three-point scaling equations are similar for K rg , K row and K rog with alternate
definitions of the critical and displacing critical saturations.
Scaling of the relative permeability values

(vertical scaling)
It is possible to scale the relative permeability at the maximum phase saturation and at the
critical/residual saturation of the associated phase.
The scaled relative permeabilities can be specified on a block by block basis, or alternatively
the depth variation can be specified using the ENKRVD and ENDNUM keywords. The KRW, KRG,
KRO keywords and their derivatives are used to set the relative permeabilities at the maximum
phase saturation, while the KRWR, KRGR, KRORW, KRORG keywords and their derivatives are
used to set the relative permeabilities at the critical/residual saturation of the associated phase.
The resultant scaling of the water relative permeability is shown below. Gas and oil relative
permeabilities are scaled in an equivalent manner.
If the KRWR keyword has not been used, the KRW keyword has the effect of scaling the relative
permeability value calculated from the appropriate saturation table after the scaled saturation
end points have been accounted for. Hence:
KRW(grid block)
K rw = K rw(table) ------------------------------------------ [EQ 14.5]
K rw max(table)
The K rw max(table) is taken to be the value at either the maximum saturation of the saturation
table or at SWU if this has been specified.
If the KRWR keyword has been used, then the scaling will honor the K r at the critical saturation
(SR) of the associated phase.

SR = 1 SOWCR-SGL in water/oil or gas/oil/water runs
SR = 1 SGCR in gas/water runs
Hence the two cases are:
1 SWCR SW SR
KRWR(grid block)
K rw ( S ) = K rw(S) ---------------------------------------------- [EQ 14.6]
K rw(S r)(table)
2 SR SW SWU
( K rw(S ) ( table ) K rw(S r) ( table ) ) )

K rw ( S ) = KRWR + -------------------------------------------------------------------------------------
- ( KRW KRWR ) [EQ 14.7]
( K rwmax ( table ) K rw(S r) ( table ) )
If the value of K rwmax = K rw ( SR ) , a linear function is assumed between KRWR and KRW. If the
table end points are the same, that is SR = SWU in the water case, then the action taken depends
on whether the alternative scaling method is being used (see the SCALECRS keyword). If the
alternative scaling is active, then both KRWR and KRW are honored with a linear function
between the two points. If the default scaling is used, then the KRWR is ignored.
The two-point scaling is illustrated in Figure 14.1:
Figure 14.1 Two-point scaling
Unscaled Scaled
KRW
Krwmax
Swcr Swmax SWCR SWU
and the three-point scaling is exemplified in Figure 14.2:

Figure 14.2 Three-point scaling
KRW
Unscaled Scaled
Krw
KRWR
Krwr
Swcr Sr Swmax SWCR SR SWU

Miscellaneous points
The End-point Scaling option is activated using the keyword ENDSCALE in the RUNSPEC
section. The directional scaling options are activated by specifying the appropriate arguments
of ENDSCALE.
The end point saturations may be supplied in one of two ways:
by cell, using the keywords SWL, SWCR, SWU, SGL, SGCR, SGU, SOWCR, SOGCR; or,
by depth, using the ENPTVD keyword.
The cell keywords need not specify data for the whole field - any unset values will not cause an
error, (as for PORO), but imply that they are to be obtained from the default values for the cell,
or from ENPTVD, if present.
If both SWL, SOGCR and ENPTVD are used, values taken from ENPTVD are used to fill in any
unset data, as long as the endpoint table number is not 0. End point table numbers are set in the
REGIONS section, using ENDNUM, and default to 1, but a value of 0 may be entered.
The overall process is thus:
1 If keywords SWL and SOGCR are present, use the value
2 If not, and ENPTVD is present with non-zero ENDNUM, use this
3 Otherwise, use defaults obtained from tables.
When the End-point Scaling option is activated, the scaling keywords are entirely optional. If a
particular end point keyword is not present in the input data file, the unscaled end points are
substituted and used in the scaling calculations.
Data checking is performed on the rescaled saturation tables in each cell. The checks ensure that
the connate, critical and maximum saturations are in increasing order and that the rescaled tables
are consistent for each phase. In the case of directional scaling, the data checking is performed
on the rescaled tables for each grid face.

Miscellaneous points
The oil, water and gas saturation tables, for each particular saturation table number region, must
obey certain consistency requirements. Essentially these are described for unscaled tables in
"Consistency requirements" on page 117. The same requirements apply to the scaled endpoints.
1 SGU must not exceed 1.0 - SWL.
If this condition is violated, the gas saturation in the gas cap will be re-set to 1.0 -SWL, to
prevent a negative oil saturation. Normally, if there is no oil in the gas cap, SGU = 1.0 - SWL.
2 SGL must not exceed 1.0 - SWU
If this condition is violated, the gas saturation in the water zone will be re-set to 1.0-SWU,
to prevent a negative oil saturation. Normally, there is no initial free gas below the gas cap
and the water zone is fully saturated with water, thus SGL = 0.0 and 1.0 - SGL = 1.0
Otherwise, phases can be mobile even at zero saturation and there is nothing to stop saturations
going negative.
The K rw max(table) is taken to be the value at either the maximum saturation of the saturation
table or at SWU if this has been specified.
When the alternative three-point end point scaling method is invoked using keyword
SCALECRS, the scaling uses the three nodes SWCR, SR and SWU where
SR = 1 SOWCR(grid block) SGL ( grid block ) in water/oil or gas/oil/water runs
ECLIPSE 100, FrontSim SR = 1 SGCR(grid block) in gas/water runs
In order to ensure that at least one fluid remains mobile in the three-phase ternary diagram,
FrontSim also checks for the following:
1 SOWCR + SWCR < 1.0
2 SOGCR + SGCR + SWL < 1.0
FrontSim issues a warning if these conditions are not satisfied. When SCALECRS is used, this
would lead to an error because in an oil-water run, for example, K rw would be scaled between
SWCR and 1.0 - SOWCR, which is a null range if the first condition is not satisfied.

Example of end point scaling
The following will produce the same results in a run:
With end point scaling
SGL
50*0.00 50*0.00 /
SGCR
50*0.10 50*0.20 /
SGU
50*0.99 50*0.98 /
SOWCR
50*0.05 50*0.22 /
SOGCR
50*0.08 50*0.21 /
SWL
50*0.01 50*0.02 /
SWCR
50*0.20 50*0.22 /
SWU
50*1.0 50*1.0 /
SGFN
0.0 0.0 0.0
1.0 1.0 0.5 /
SOF3
0.00 0.0 0.0
1.00 0.8 0.8 /
SWFN
0.0 0.0 1.0
1.0 1.0 0.0 /

With multiple tables
SGFN
0.0 0.0 0.0
0.1 0.0 0
0.99 1.0 0.5 /
0.0 0.0 0.0
0.2 0.0 0
0.98 1.0 0.5 /
SOF3
0.00 0.0 0.0
0.05 0.0 0.0
0.08 0 0.0
0.99 0.8 0.8 /
0.00 0.0 0.0
0.21 0.0 0.0
0.22 0.0 0
0.98 0.8 0.8 /
SWFN
0.01 0.0 1.0
0.2 0.0 0
1.0 1.0 0.0 /
0.02 0.0 1.0
0.22 0.0 0
1.0 1.0 0.0 /
REGIONS
SATNUM
50*1 50*2 /

The Streamline Concept
Chapter 15
Introduction
FrontSim is a three-phase, three dimensional black-oil reservoir simulator where the solution
ECLIPSE 100
ECLIPSE 300
mechanism is based on a streamline concept. This chapter briefly describes this concept in
SPECIAL general and, more specifically, how it is implemented in FrontSim. The objective is to describe
x FRONTSIM the process for a single timestep and some of the artifacts rather than the technical mathematical
details. For details the reader is encouraged to read some of the recent papers on the topic. See,
in particular, [Ref. 1], [Ref. 2], [Ref. 16] and [Ref. 17] in the Appendix C in the "FrontSim User
Guide".
Using streamlines for modeling subsurface flow has been in the literature for a number of
decades, dating at least back to the 1950s. The main motivation for using streamlines to solve
for the fluid flow is the computational speed, but it is also attractive that the streamlines forms
a natural grid for the transport equation where a choice of numerical method can be applied. In
the 1990s there were a number of new developments for streamline simulation that brought it
back into the limelight. Modern streamline simulators now include 3D irregular and faulted
grids, changing well controls, compressibility, and gravity segregation as well as multi-
component, multiphase flow.
Streamline simulators are particularly effective in solving fine scale, geologically complex and
heterogeneous systems, and water flooding studies are frequently carried out using streamline
simulation.
FrontSim Technical Description The Streamline Concept 129

Introduction
The governing equations
The black-oil formulation for conservation of each fluid phase reads:
( b S ) + ( b v ) = q
t w w w w w
((b S + R b S )) + (b v + R b v ) = q
t o o v g g o o v g g o
((b S + R b S )) + (b v + R b v ) = q
t g g s o o g g s o o g
[EQ 15.1]
where the velocities vi (Darcys law) are defined as:
v o = o ( P w o GVD )
v w = w ( P o w GVD )
v g = g ( P g g GVD )
k
i = K ----i [EQ 15.2]
i
K is the permeability of the rock

ki is the relative permeability of phase i
i is the viscosity of phase i

i is the density of phase i
bi is the inverse formation volume factor of phase i
Rs and Rv are respectively the dissolved gas and vaporized oil
Si is the saturation of phase i
is the porosity
g is the gravity constant
qi is the source/sink term for phase i
P is the oil phase pressure

Ci is the compressibility of phase i and t is total
130 The Streamline Concept FrontSim Technical Description

The numerical approximations of these equations generally are based on a finite-difference
IMPES or fully implicit formulation. The IMPES formulation uses operator splitting to separate
one equation for the pressure so that the pressure solution can be found separately from the
equations modeling the movement of fluids. This approach recognizes the different nature of
these equations and the potential advantage of using different numerical approaches for solving
them.
Making the assumption, the capillary pressure Pc=0, the pressure equation can be written as
p
v t + Q = C t +
t v i c i p

[EQ 15.3]
i = o , w, g
The total Darcy velocity vt is defined by (Pc=0)

v t = t P o +
jj j g [EQ 15.4]
[EQ 15.3] and [EQ 15.4] are used to find the pressure distribution for a given saturation
distribution. The pressure equation is solved implicitly with a finite-difference method.
The saturation/concentration equations read:
( n S n ) [EQ 15.5]
- + ( n Fn ) = 0
----------------------
t
with F defined by [EQ 15.2].

The solution strategy
FrontSim is based on a sequential approach where the governing equations for pressure and
saturations are solved sequentially. The IMPES (Implicit Pressure Explicit Saturations) method
is based on a sequential approach as well, but suffers severely from the timestep length-limiting
CFL (Courant-Friedrich-Levy) condition that occurs as fluid can not move more than one cell
during one timestep. One of the advantages of the sequential approach over the fully implicit
approach is the opportunity it gives to use a fit for purpose numerical method for each of the
equations to be solved. FrontSim solves the near elliptic pressure equation implicitly (as
IMPES) and the near hyperbolic saturation equations are solved with a streamline method where
a variety of fit-for-purpose numerical methods can be chosen on each streamline and gravity
line.
The computations required within one single timestep with user-defined boundary conditions
including well flow targets are:
1 Solve the pressure equation for the timestep.
a Compute the total Darcy velocities based on the pressure potentials.
2 Compute a set of streamlines to represent the computational domain for the saturation
solver.
3 Map saturations or concentrations onto the streamlines.
a Solve the saturation equation individually on each of the streamlines.
b Solve for the gravity segregation.
4 Accumulate all the solution variables on each individual streamline or gravity line to form
the solution on the global grid at the end of the timestep.
Update the time dependant information and repeat these steps for each timestep in the
simulation.
Each of the steps is described in more detail below.
Solve the pressure equation for the timestep

The pressure equations [EQ 15.3] and [EQ 15.4] are solved for the timestep based on rock
properties, current fluid distribution and boundary conditions. The rock properties are the static
user-defined data in the model such as permeabilities, porosities net-to-gross etc. These are
defined on a discretized domain, the grid, which is the same as the numerical grid used to
discretize the pressure equation. The pressure nodes are assumed to be in the center of each grid
cell.
From the static data and the grid geometry the transmissibilities between the grid cells are
computed. The transmissibilities are constant throughout the simulation. For more on the
transmissibility calculations see "Transmissibility Calculations" on page 249.
Since FrontSim is based on a sequential approach, the pressure solution is calculated for the end
of the timestep based on the saturations at the beginning of the timestep.

The boundary conditions can be open wells with given targets and limits, aquifer models,
pressure boundaries and flux boundaries defined by the user. These conditions can change for
any user-defined timestep. Due to the sequential approach the rate targets for the wells are
always translated into total (sum of phase/components) rate at reservoir condition in FrontSim.
If the split between the phase rates are changing considerably during the timestep, FrontSim
might have difficulties to honor exactly a target set for one single phase-rate. This is a common
feature of any IMPES type simulator, but since the timesteps are a lot larger for streamline-
based simulators, this artifact becomes more visible. It is recommended to use total reservoir
rates as target if possible.
Beware that if the compressibility in the model is set to zero (incompressible fluids and rock),
the right hand side of the pressure equation (3) is zero. The restrictions on such a model is that
the total flow rate in has to equal to the total flow rate out of the model at reservoir conditions.
The method for calculating the pressure is basically the same as for traditional IMPES
simulators and described in more detail in "The Pressure Equation" on page 207.
Both traditional 7-point as well as more complex 27-point finite difference schemes are
available for discretizing the pressure equation.
Compute the total Darcy velocities based on the pressure

potentials
The total Darcy velocity, equation [EQ 15.4], is needed for the streamline calculations. In
FrontSim the flow rates at every grid cell face or non-neighbor connection (NNC) represent the
velocity field. The flow rate is computed as the total flow rate at reservoir conditions normal to
the connection. This computation is trivial, and is based on the pressure equation [EQ 15.3] and
[EQ 15.4].
The total flow rate at reservoir conditions can be output to the restart file by activating the
mnemonics FLOTOT in the keyword RPTRST.
Compute a set of streamlines that represent the

computational domain
This procedure consists of two main operations.
The first is to generate a set of streamline start points that can accurately represent the flow in
the model. This is often referred to as Streamline Distribution.
The second is the actual tracing of each unique streamline passing through these points.
Streamlines and important properties

For practical purposes a streamline can be seen as a trajectory in the Darcy velocity field. It is
defined as a set of points in 3-dimensional space. The most important properties along the
streamline for simulation purposes are the total flow rate and time-of-flight (TOF). The TOF is
the time for a particle to travel between two points on a streamline, usually defined as the time
from the start of the streamline to a given point on the streamline.
An important derived property is the pore volume represented by the streamline. It can be
calculated by multiplying the flow rate with the change of TOF in any segment along the
streamline.
The streamline is represented by the set of points where the streamline intersects the grid cell
faces. A finer resolution is possible, but does not add to accuracy in the simulation.

The geometrical coordinates of the streamline are not an important property for the simulation
itself, but necessary for visualization of the streamlines. The streamlines can be output to files
to support streamline plots in a post-processor. See keyword RPTSLN.
Generate streamline startpoints

A streamline start point is a point on the streamline to where the flow rate represented by the
streamline is assigned. This point can be anywhere in the grid depending on the algorithm to
select the streamlines. Usually it is a point in a source or sink or in a cell that was not visited by
any of the originally computed streamlines. The tracing operation traces both backward and
forward from this point to create the streamline.
Each streamline is assigned a flow rate at the start point that is carried through the streamline.
The accuracy of the simulation partly depends on the streamlines to accumulate correctly to the
rate in the wells. The operation to generate the start points will look for sources and sinks in the
grid and assign start points to the cell faces of grid cells that are connected to such. For
incompressible flow the flow rate assigned to a streamline will not vary along the streamline
and therefore be equal at both endpoints. For compressible flow the algorithm is more complex.
For example, for primary depletion with no injection the streamlines can start from any grid cell
in the model, often at a boundary, and the flow rate will increase along the streamline consistent
with the compressibility in each of the grid cells it traces through.
For incompressible flow, FrontSim will by default distribute start points at each active source
(injectors, aquifers etc.) in the model. For compressible flow, FrontSim will by default distribute
streamlines at both sources and sinks in the model. The method to be used for streamline
distribution can be altered by the user with parameter 9 in keyword TUNEFSSA.
Number of streamlines
The number of streamlines necessary to represent the computational domain varies with a
number of parameters. Most significantly are the number of grid cells in the model, the number
of wells and magnitude of flow. The number of streamlines in FrontSim will by default be
approximately 10% of the number of active cells plus a number associated with the number of
active wells. This is usually more than enough. Since the speed of the simulation partly depends
on the number of streamlines computed it can be scaled by a user-defined multiplier. For
experienced users the streamline density multiplier available in keyword TUNEFSSA is
frequently used to speed up the calculations by setting it to a number less than 1.0.
FrontSim also has new methods to automatically remove unnecessary streamlines by examining
how well the volumes in the grid cells are preserved by the streamlines.
These can optionally be activated. See keyword OPTIONFS.
Addlines
When all the streamlines through the generated start points have been traced, FrontSim will look
for cells that have not been visited by streamlines to add streamlines when appropriate. This
procedure can be switched off by setting parameter 5 of keyword TUNEFSSA to NO. The cells
in question are naturally cells with very low flow and usually do not contribute much to the
overall solution.

Tracing the streamline
Basically the algorithm is an iterative process where an entry point is traced to an exit point for
every grid cell that the streamline traces through. The time-of-flight variable and the flow rate,
if a compressible case, are updated for the exit point given the values at the entry point. The
process stops whenever a source/sink is reached or the flow rate is less than a minimum. This
minimum flow rate can be scaled by the user, keyword TUNEFSSA, parameter 7.
There are more details on this process in "Streamline Tracing" on page 139.
The set of streamlines are always updated whenever a new pressure solution is calculated, which
normally is for each timestep in the simulation. The shape of the streamlines can change
considerably between timesteps. The main reason is change in boundary conditions like flow
rates in wells or wells that are turned on and off. Change of mobility due to the change of
saturation and pressure distribution in the previous timestep can also have a large impact on the
shape and TOF on the streamlines.
Map saturations/concentrations on to the

streamlines
1D grids
The set of streamlines with its properties forms the discretization of the computational domain
on which the saturation is solved. The streamline concept is based on a coordinate
transformation from physical space to a coordinate system following the flow directions (Total
Darcy flow). The governing 3D mass conservation equations can be reformulated in terms of
TOF.
The underlying resolution of the saturations is the pressure grid and an updated saturation
distribution on this grid is needed for the pressure solver for each timestep. The points, in terms
of TOF, where the streamline crosses the global grid cell faces are the basic discretization for
the 1D numerical grid. This is referred to as the streamline discretization.
The 1D numerical discretization along the streamlines depends on the method used to solve the
saturation equation. If the Front-Tracking method is chosen the streamline discretization is used
directly.
For three-phase simulation a finite difference method is used to solve the saturations on the
streamlines. These methods can have difficulties converging when the pore volumes in the 1D
grid varies and some are very small. Small pore volumes will increase the CPU time, so a more
uniform grid is applied along the streamline. The streamline discretization is used as a starting
point and the points are kept where the properties along the streamline have a distinct change
in, for example, saturation region, PVT region or endpoint scaling parameters. The rest of the
points are distributed as evenly as possible.
Mapping saturations
Front-tracking method
For the front-tracking method, the saturations for each segment on the streamline can simply be
picked up from the individual constant values in the actual cell in the underlying grid.

A more accurate method for preserving front-positions is available as an option for the front-
tracker. A mapping algorithm is available to map the saturations from another set of streamlines
(previous timestep) directly on to the new set of streamlines. This algorithm is CPU and
memory intensive and should only be used if it is very important to avoid any numerical
dispersion. This method can be activated through the keyword TUNEFSSA, parameters 3 and 4,
and is not available for three-phase cases. It is not recommended for cases where the gravity
segregation is on.
Finite-difference methods
Since the cells in the 1D grid for the finite difference methods does not necessarily coincide with
the cells in the underlying grid the saturations and other properties that is needed on the
streamline is averaged from the corresponding cells in the underlying global grid. The averaging
is described in "Three-Phase Saturation Solver" on page 233.
Solve the saturation equation individually on each

of the streamlines
In FrontSim there are three available 1D saturation solvers that can be used on the streamlines.
Front-tracking method
For two-phase cases the default solver is the front-tracking method. This method accurately
tracks movements of fronts on the streamline. The speeds of the fronts are calculated as a
function of the slope of the fractional flow curve. The method is very fast and accurate for
models with low compressibility such as water-oil cases. A similar approach is used for tracer
flow, and tracers in FrontSim can only be combined with two-phase models using the front-
tracking algorithm.
Finite Difference Methods.

For three-phase cases there are two different finite difference methods available. The different
options can be selected by using the first parameter of keyword TUNEFS1D. The default option
is the FULLIMP method on the streamline. This method is a fully implicit standard finite
difference method to solve for both pressure and saturations along the streamlines. The method
is described in more detail in "Three-Phase Saturation Solver" on page 233.
An explicit volumetric Finite Difference Method is also available (TUNEFS1D with parameter
1 set to EXPL). The method is based on a volumetric approach and an upstream scheme. This
is usually faster than the FULLIMP method, but does not account for the pressure change due
to change of saturation distribution during the time step.
Solve for gravity segregation

Gravity lines
By use of operator splitting the conservation equation is split into two parts, one for the
streamlines and one for the gravity segregation. The equation is solved in two sequential steps.
First solve for the convective part along the streamlines and then, using the saturation solution
from the streamlines as initial values, solve for the gravity segregation due to density differences
in the gravity direction.

Gravity lines are usually vertical columns in the grid. FrontSim will solve for each vertical
column in the pressure grid individually.
Numerical methods for the gravity lines

The numerical methods used to solve along the gravity lines are usually the same as is used to
solve along the streamlines. If the front-tracking method is used on the streamlines it will also
be used on the gravity lines.
Beware that the sources and sinks (wells and boundary conditions) are only relevant for the
streamlines, not the gravity lines.
Map the solutions on each individual streamline/gravity

line to form the solution on the global grid
When the saturation solver has finished each individual streamline/gravity line the solution will
be mapped down to the global grid.
In this procedure all the volumes on the streamlines going through the same cell is accumulated.
Most parameters will be pore volume weighted for the cell.
As an example, the water saturation SW j in a grid cell number j is:
SW j = ( PVstr SWstr ) PVj

The sum is taken over all segments in all streamlines going through cell number j .

Streamline Tracing
Chapter 16
Introduction
Tracing the streamline is the process whereby we create the unique streamline passing through
ECLIPSE 100
ECLIPSE 300
a specified point in 3D space. From this starting point the streamline is traced backward and
SPECIAL forward to create the complete streamline. The algorithm is iterative and rests on calculating the
x FRONTSIM exit point in a grid cell given an entry point, repeated until a stop criterion is reached.
Streamline parameters
From the perspective of the saturation solver there are three properties needed to define the
streamline. They are time of flight (TOF), flow rate and a pointer to a unique grid cell in the
underlying numerical grid. The flow rate and TOF are defined in points along the streamline,
and the grid cell pointer is defined for each linear segment between the points defining the
streamline. For the grid cell pointer to be unique, there have to be points defined for every grid
cell face that the streamline passes through. The grid cell pointer is used for picking up relevant
information defined on the grid and to map solution variables between the streamline and global
numerical grid.
Figure 16.1 shows how points and segments are defined with respect to the grid.
FrontSim Technical Description Streamline Tracing 139

Introduction
Figure 16.1 Streamline tracing through grid, showing points and segments between the points
Points
Segments
The streamline method does not require the boundaries of a streamtube to be calculated. The
streamline can be thought of as the center of a streamtube and the combination of the TOF and
flow rate is used to calculate the pore volume in any of the streamline segments.
For a segment i on the streamline the pore volume PV is calculated as:
PV i = dTOF i Q i
where dTOF is delta TOF and Q is the total flow rate into segment i at reservoir conditions.
The 3D space coordinates are not used for the simulation itself, but necessary for any
visualization of the streamlines. They are calculated for output purposes only.
Tracing through a single grid cell

The algorithm used to trace the streamline through a single cell is often referred to as the Pollock
method. For details see [Ref. 32].
The starting point for the method is a single cell with flow rate calculated for each of the cell
faces. The flow rate is assumed to be uniform on each of the faces. As a result of the pressure
equation the total flow rate in/out of each of the faces can be calculated based on the total Darcy
velocity.
The total velocity v t is defined by
v t = t P o + ( j j j )g [EQ 16.1]
Pollocks algorithm is based on three assumptions within one grid cell:

1 Uniform flow rate on each cell face
2 Linear variation velocity field in each coordinate direction
3 Orthogonal grid.
The flow rate calculated from the pressure equation complies with assumption (1).
140 Streamline Tracing FrontSim Technical Description

Introduction
FrontSim supports general corner point grids which definitely is not orthogonal. To comply with
(3) an isoparametric transformation on to a unit cube is needed for each of the grid cells.
The streamline tracing in FrontSim is done entirely on a unit cube. The coordinates in the
following equations are assumed to be in the unit cube coordinate system.
Details on this transformation can be found in several papers. See [Ref. 3] in the bibliography.
For the bi-/tri-linear velocity field (3) the interstitial velocity v in the x-direction is defined as:
v x = v x0 + m x ( x x 0 )
m x = ( v x1 v x0 ) ( x 1 x 0 )
[EQ 16.2]
where 0 and 1 denote the two cell faces in the x-direction. The y- and z-directions are analogous.
Figure 16.2 Streamline (red) through a single cell
Vy1
Y1
Exit (Xb, Yb, Zb)
Vx0 Vx1
X0,Y0 Vy0 X1
Entry
(Xa,Ya,Za)
In Figure 16.2 the streamline enters the Y0 face of a single cell and exits the X1 face through
the exit point Xb, Yb, Zb .
Given the entry point ( Xa, Ya, Za ) , the exit point ( Xb, Yb, Zb ) , Vx = dx dt and integrating
equation [EQ 16.2], the dt (or delta TOF) can be expressed as
dtx = ln ( ( v x0 + m x ( x b x x0 ) ) ( v x0 + m x ( x a x x0 ) ) ) m x [EQ 16.3]
Due to the orthogonal unit grid cell the dt for each of the faces can then be calculated separately.
Since the streamline must exit the cell faces inside the cell, there is only the minimum of these
dt functions that applies.
Once the dt is known, the exit point coordinates can be calculated by the following equation.
x b = x x0 + ln ( v xa exp ( m x dt ) v x0 ) m x [EQ 16.4]
The y- and z- directions are analogous and can be obtained by substituting x with y and z in
the above equation.
FrontSim Technical Description Streamline Tracing 141

Introduction
As mentioned previously, the points on the streamline are represented as points in the unit cube
coordinate system for each of the cells through which the streamline traces. If the point needs
to be output for visualization, it is transformed back into the real coordinate system for the
corner point grid.
Stop criteria
The tracing continues until one of the following stop criteria is reached:
1 An active well is positioned in the current cell. The streamline is traced to the center of the
cell and terminated.
2 The streamline exits through a boundary. This may be either an open boundary defined by
pressure/flux (PSIDE, FLUXSIDE) or an aquifer connected to this cell face.
For compressible flow we have two more criteria to consider:
1 Sink/source in grid cells not containing wells. In this case either all the faces in a grid cell
have flow rates into the cell (sink) or they have only flow rates out from the cell (source).
Any cell in the grid can act as a sink/source in compressible cases, but they are most likely
to be close to the closed boundaries of the grid. If the difference between the total inflow
and outflow in the model is large, many streamlines are likely to have one endpoint in this
type of cell.
2 Low flow. This is very similar to the situation for the sink/source cells. The flow rate
calculated along the streamline reaches a predefined minimum close to zero, and the
streamline tracing is terminated. This minimum flow rate can be scaled by the user,
keyword TUNEFSSA (option 7).
Flow rate and compressibility

The start point for the streamline tracing is allocated a total flow rate at reservoir conditions.
The flow rate needs to be defined at all points in the streamline. If the model has incompressible
data (PVT+ROCK), the flow rates are constant for the streamline. If the model has compressible
data, the flow rate will most likely change along the streamline. FrontSim calculates the change
of this flow rate consistent with the change of flow rate in the underlying grid.
142 Streamline Tracing FrontSim Technical Description

Introduction
IOR Tracer Logic Guide
Chapter 17
Introduction
The FrontSim IOR tracer logic is a tool designed to provide an efficient workflow for history
matching, predicting and optimizing Water Alternating Gas (WAG) injection processes for
improved oil recovery (IOR) at the field operation scale. IOR WAG injection is a complex
multiphase process influenced by complex physical processes. Complicated injection
procedures, such as optimizing lean gas and solvent injections in producing fields also add to
the complexity. A predictive tool such as the FrontSim IOR tracer logic allows practising
reservoir engineers to design and to manage quantified IOR projects at the IOR injector/
producer pattern level. The FrontSim IOR tracer model is built on existing production
knowledge, and on geologic and petrologic understanding of trapped IOR oil targets.
The dynamic modeling of the IOR WAG process typically requires fine scale 3D fully-
compositional models that can handle fast-changing gas dynamics and viscous fingering, driven
by a large number of injectors or complex horizontal wells. The fundamental idea of the
FrontSim IOR tracer logic is to use tracer logic to mechanistically quantify solvent gas injection
and displacement processes with an upscaled 2D and two-phase (oil and water) streamline
model. In this manner, the high resolution model is preserved due to the high resolution of the
streamline simulator, yet the model can still be in a reasonable time on account of the numerical
efficiency of the simulator.
This guide illustrates important aspects of the IOR tracer logic tool. Background material is
provided as needed. The aim is for users to understand the basic IOR tracer logic concepts, and
to effectively use this option. This guide treats the following elements of the IOR tracer logic:
"The workflow of building the IOR tracer and truth model" on page 145.
"IOR tracer logic concepts" on page 151. Includes the IOR tracer logic itself, the
mobilization curve, the solvent allocation logic, and the logic taking into account
limitations in the production facilities.
"Keywords and parameters for the IOR tracer model" on page 165. Includes usage
examples.
"Scaling the model to match the field IOR mechanisms" on page 176.
FrontSim Technical Description IOR Tracer Logic Guide 143

Introduction
"The IOR model simulation output" on page 185.
144 IOR Tracer Logic Guide FrontSim Technical Description

Introduction
The workflow of building the IOR tracer and truth model
The essence of the IOR workflow is to use FrontSim, with some add-on functionality called the
tracer logic, to model complex Water-Alternating-Gas (WAG) mechanisms.
In the IOR workflow, four different kinds of model may be considered:
1 A full field, 3D simulation model exists, capable of modeling the field mechanisms prior
to the IOR process being started. This model could be a standard black-oil model, to be used
with ECLIPSE 100 or FrontSim.
2 A series of 2D or 3D sector models is constructed from the full field model. These models
will be subjected to IOR processes, and need to be simulated with a simulator capable of
accurate compositional simulation, for example ECLIPSE compositional.
3 An IOR tracer model is constructed by history-matching the tracer logic to mimic the
results of the sector models simulated by the ECLIPSE compositional simulator.
4 Additional models may be used in the intermediate steps before arriving at the full field
IOR tracer model. Examples of such models are injector/producer pair sector models,
simulated as 1D or 2D IOR tracer models.
A major challenge associated with using the IOR tracer logic is the construction and validation
of the FrontSim 2D layered and two-phase field tracer model. This model is vertically averaged
from the original fine scale, 3D geological or simulation model.
Some elements of this workflow are performed outside the IOR option itself. It is beyond the
scope of this guide to address these.
In the following sections, an overview of the workflow involved with obtaining the up-scaled
IOR tracer model is provided The starting point is to define the concept of IOR oil, and to
discuss how the IOR recovery is modeled in practice.
The high level workflow for arriving at a history matched, 2D full field tracer model is
illustrated in Figure 17.1. Yellow boxes correspond to the produced data, which may be
parameters or models, whereas green boxes correspond to an activity or process.

Figure 17.1 Possible workflow for constructing the FrontSim IOR Tracer Model

Modeling the IOR recovery
The truth model is designed to capture and to quantify the IOR oil recovery process through the
modeling of WAG solvent and lean gas injection. The IOR oil is the amount of oil that is
recovered after the water flood oil recovery, where such a process is typically called a tertiary
recovery. Throughout this user guide, the terms solvent and miscible indicant (MI) are used
interchangeably.
Consider a base curve showing the cumulative water flood oil recovered in a field over time
(Figure 17.2). If by applying an MWAG (miscible water alternating gas) process to the field,
increased oil recovery should be achieved. A curve of incremental oil may be seen at some point
in time. The difference between the MWAG recovery and the water flood recovery is defined as
the IOR.
Figure 17.2 Illustrates the incremental recovery of IOR oil with MWAG
A Truth Model is used as a starting point for the modeling of the IOR recovery in the field. This
is a finite difference model, most probably a sector of a larger model, and is assumed to
represent the ideal IOR recovery. This Truth model incorporates the complete physics of the
process. The simulator is capable of solving for fully compositional phase behavior, three-phase
relative permeability, explicit shale treatment, etc. The truth model represents a best guess on
how the WAG process will actually perform without the complications of numerical artifacts
and pseudo representations.
The IOR tracer logic workflow models complex 3D IOR displacement processes by combining
two types of models. The first type is the truth model, and the second type is an up-scaled two-
phase, 2D layered IOR tracer model.
Building the IOR tracer model

The IOR tracer logic requires that the original fine scale compositional model be upscaled to a
1D or 2D, two-phase streamline simulation model. The purpose is to approximate the complex
compositional physics in the reservoir, by using the fast streamline simulator and taking
advantage of the uniquely designed tracer logic. This logic quantifies the IOR trapped oil
displacement, by using the analogy of injected solvent along streamlines.
It is expected that a finite difference simulation model exists at the stage of developing the IOR
WAG injection project. The upscaling of the original fine scale reservoir simulation model to
the IOR field tracer model is a case-dependent, and often time-laborious, workflow with the
following tasks:

1 Convert the grid, and associated properties to an upscaled model
2 Read the model into FrontSim and check the pore volumes
3 Input PVT data and check fluid in place
4 Input relative permeability data and well locations
5 Input well rates in the schedule section.
The validation of the up-scaled streamline simulation model is closely related to, or dependent
on the original fine scale reservoir simulation model. The objective is to match the prediction
of the up-scaled model to the original model, with regard to the production well rates, pressure
and saturation distributions. The upscaled simulation model must be validated by comparing the
production well rates, the pressure and saturation distributions to the original model.
Building the IOR truth model

The truth model must have a fine grid in order to produce an accurate representation of the WAG
IOR process. It is most likely to be a small sector model of the reservoir, where the focus is to
model the communication between particular injector/producer pairs.
A typical workflow is to first up-scale this Truth model so as to convert it to an IOR tracer
model. This IOR tracer model is then history matched using the constraints of the truth model.
The properties associated with the streamline bundles that interconnect the injector/producer
pairs in this model are then applied to a full-field IOR tracer model.
2D truth model and 2D field tracer model

1 Construct a 2D finite difference truth model of a typical injector-producer pair. The relevant
injector/producer pairs may be identified through simulation of the reservoir using
FrontSim the streamline patterns will readily identify the communication patterns
between injectors and producers. A kite-shaped model can be used for vertical wells to
capture the converging-diverging nature of the flow. For horizontal wells, a rectangular
model can be used. Figure 17.3 shows a cut-away view of a triangular-shaped Truth Model.
Figure 17.3 2D vertical cross-section of a finite difference MWAG truth model
2 Vertically average the reservoir properties, and run a 1D FrontSim model in which the IOR
tracer parameters are tuned in order to match the IOR production to that of the ECLIPSE
compositional Truth model. Figure 17.4 illustrates the corresponding 1D FrontSim model.

Figure 17.4 1D Up-scaled MWAG truth model used in FrontSim
3 Combine a series of these sector models in order to model the full field using a single 2D,
IOR tracer model. An example of the full field tracer model is shown in Figure 17.5. It also
illustrates how the 1D sector IOR model relates to this 2D field model.
Figure 17.5 Illustration of a 2D full field FrontSim tracer model.
3D truth model and 2D field tracer model

As computers become faster, it becomes more feasible to run 3D truth models. However,
significant effort and time would be required to construct and to validate a 3D truth model.
Unlike 2D models, 3D models capture lateral heterogeneities. For example, the presence of
shale coverage impedes vertical gas movements and can be a key feature that impacts MWAG
performance. A 3D truth model can describe gas migrating around shale, and should provide a
better prediction of IOR performance.
1 Construct a 3D finite difference truth model of a typical injector/producer pair. Figure 17.6
is an example of two vertical wells for the simple box sector model.
Figure 17.6 3D Finite Difference MWAG truth model.
2 Vertically average the reservoir properties and run a 2D IOR FrontSim model in which the
IOR tracer parameters are tuned to match the IOR production to that of the finite difference
truth model. Figure 17.7 illustrates the corresponding 2D FrontSim model.

Figure 17.7 2D Up-scaled MWAG truth model in FrontSim.
As in the previous workflow, the tracer parameters represent the production from a single,
vertically averaged, streamline bundle which connects the injector and producer. The
parameters used in this model may be translated to the full field IOR tracer model, as with
previous workflow (Figure 17.5 above).
Although only two specific workflows and relationships between the Truth model and the up-
scaled IOR model have been described here, we may see a variety of combinations of models
in the future; for example, the Truth model may be a 3D compositional streamline model rather
than a finite difference model, and the up-scaled IOR model may also be a 3D model. These
possible workflows will not be treated here.

IOR tracer logic concepts
Modeling IOR dynamics with tracers

The streamline-tracer model is a modified version of the FrontSim simulator. Highly complex,
faulted grids can be modeled, and large time-steps can be taken with minimal numerical
dispersion. As well rates change, front locations are mapped from one streamline to another.
Hence, historical well injection and production can be honored.
MWAG and IWAG IOR (miscible and immiscible water alternating gas improved oil recovery)
and lean gas trapping processes in the field are modeled by defining a tracer analogy to the
problem, where both the injectant and the IOR oil are modeled as tracers. The model does not
contain any inherent MWAG/IWAG physics. Rather, the mechanism is represented along the
streamlines by an empirical model. This model approximates the response of finite-difference
truth models to solvent injection. It is used solely as a convenient transport model which has the
following essential characteristics:
1 It conserves the mass of the transported components;
2 It allows components to be trapped;
3 It allows components to be mobilized;
4 It can be quickly solved along streamlines;
5 The breakthrough timing can be easily adjusted.
The tracer movement is easily computed, because the transport equation for adsorbing/
desorbing tracers has a known solution that is very similar to the Buckly-Leverett solution.
Key components of this technology are the definition of an appropriate adsorption mechanism
for quantifying the volumetrics of the IOR oil mobilization, and the definition of a propagation
mechanism along the streamlines termed accessible pore volume (APV), which is used to adjust
the breakthrough timing of the IOR tracers.
This concept has an obvious advantage over a full field mixed-parameter-based compositional
simulation in that this effectively simplifies the book-keeping needed for tracking the IOR
recovery process. Furthermore, the IOR tracer model only requires one single run to calculate
the spatial distribution of variables of unique interest to the IOR WAG process. The ease of
directly working with the various IOR variables allows for additional flexibility when history
matching, and for managing an IOR project in a complex reservoir. The FrontSim IOR tracer
logic also offers advantages in the post processing and in the interpretation of results.
The IOR logic provides a series of tracer parameters that can be tuned, in order to match the
performance of the up-scaled streamline model to that of the Truth model. These parameters
will be treated in the following sections, where the core technology components of the IOR
tracer logic are described.
The IOR tracer logic also has functionality for optimizing the WAG process. The solvent
allocation logic and water/gas handling logic are field level tools which assist in the allocation
of the Miscible Injectant (MI) to competing injectors, constrained both by the limited MI
resources and by the facility limitations of the injectors.

The FrontSim IOR tracer simulation model can thus be used in predictive mode, in order to
guide solvent utilization over an entire field which could contain thousands of wells, and
hundreds of injector/producer patterns that could be configured dynamically over time. The
IOR tracer model can be effectively used to identify IOR recovery targets, and to allocate MI
solvent based on the injector/producer dynamic patterns.

The IOR tracer is simply an ordinary FrontSim tracer whose behavior is restricted by the IOR
tracer logic. The logic computes spatial distributions of injected solvents and recovered trapped
IOR oil mechanistically, by using a set of tracers to account for IOR oil and recovered solvent
rates in producers. The logic does not, however, model the solvent physical processes in detail,
because the two-phase streamline simulator cannot model gas as a separate phase. Rather, the
IOR tracer logic was designed as a tool for fast hypothesis testing and screening of WAG
injection scenarios.
The IOR tracer logic consists of two independent displacement processes running in sequence
along each streamline.
1 The first process is a traditional waterflood simulation. The waterflood reduces the oil
saturation to a waterflood residual.
2 The second process is an MWAG or an IWAG process, which reduces the oil saturation
further. In this second process some of the lean gas or solvent will be trapped.
The IOR displacement is mimicked by the flow of the IOR-oil tracers. These tracers are not
associated with a particular phase, but simply flow along each streamline at a user-specified
factor of the Darcy velocity.
Tracer solvent analogy

Several types of tracers are used as analogs for the IOR MWAG and IWAG processes in the
reservoir. These are lean gas tracers, solvent tracers and IOR oil tracers, each designed to mimic
the actual propagation and trapping of solvents and IOR oil within the streamline bundles
extending from the injectors to the producers.
The solvent tracer represents the volume of solvent by MWAG injection. Only a portion of the
injected solvent tracer is effective in mobilizing IOR oil, and the injected solvent tracer is
numerically divided into effective solvent tracer and ineffective solvent tracer. The ineffective
solvent tracer is allowed to move to producers along the same paths as are swept by the effective
solvent tracers. The effective solvent tracer mobilizes the IOR oil tracer at a given ratio, usually
at 1, while it itself is adsorbed or trapped according to a specified adsorption isotherm table. The
ineffective solvent tracer obtained at the producer can be recycled as a new solvent tracer at
specified injectors. Most of the trapped/adsorbed solvent tracer comes from the effective
solvent; most of the produced solvent tracer comes from the ineffective solvent.
The IOR tracer logic is capable of modeling two different WAG processes, namely IWAG
before MWAG and IWAG after MWAG. Separate sets of logic are used to model IWAG lean
gas injection before MWAG, and IWAG lean gas injection after MWAG. In each case, IWAG
lean gas injectant is divided into effective and ineffective lean gas tracers. In the IWAG before
MWAG process, the effective lean gas tracer is partly adsorbed, a common field practice for the
purpose of creating localized gas caps. Trapped lean gas may again be mobilized by a

subsequent MWAG injection, when effective solvent tracers mobilize trapped lean gas tracers,
while simultaneously mobilizing trapped IOR oil (at a 1:1 volumetric ratio when possible). For
IWAG injection after MWAG injection, the effective lean gas tracer is partly adsorbed,
mobilizing the trapped, effective solvent tracer, which can then be produced and subsequently
recycled at the injectors.
A key concept of the tracer logic is the master-slave tracer pair. See Table 17.1.
Table 17.1 Master-slave tracer pairs
Master Slave Model Type

Injectant Trapped Reservoir Fluid MWAG
Solvent Trapped Lean Gas IWAG before MWAG
Lean Gas Trapped Solvent IWAG after MWAG
This allows the application of generic tracers to model all the IOR WAG mechanisms along
streamlines, and to compute the concentration for the master tracers and the slave tracers.
Figure 17.8 The effective solvent and IOR oil have a master-slave relationship
On the left, Figure 17.8 shows IOR oil initialized at Sorw at some point along a streamline. On
the right, it shows how subsequent trapping of solvent causes an equal volume of IOR oil to be
mobilized. In this example, some IOR oil remains trapped.
In the IOR tracer model, each grid block is initialized with immobile IOR oil equal to the
residual oil saturation after water flooding. Typically, Sorw is not zero in the grid block. Any
effective solvent tracer entering into this block is trapped as it mobilizes an equal volume of
IOR-oil. The trapping of effective solvent is an irreversible process with respect to the IOR oil,
and it is modeled by an adsorption/desorption mechanism. An adsorption isotherm table is
assigned for the (master) tracers. It is used to compute the amount of adsorbed solvent in the
cells traversed by the streamline. Only the trapped master or effective solvent is able to displace
IOR oil present in this cell.
The tracer concentration along streamlines provides a spatial distribution of tracer movements
from injectors to producers. These distributions allow the visualization and quantification of the
effectiveness of WAG injection. A similar description can also be given for the IWAG processes
before and after the MWAG process, by replacing the master and slave tracer pair with the
appropriate fluid types.
The IOR tracers

The IOR tracer logic can model 9 tracers, divided into 3 categories or sets, for the IOR WAG
processes:

Set 1 (Modeling MWAG)
Tracer 1: T1 = Effective Solvent tracer
Tracer 2: T2 = IOR Oil tracer (mobilized by tracer 1)
Tracer 3: T3 = Ineffective Solvent tracer (RMI or returned MI, compositionally equivalent)
Set 2 (Modeling IWAG before MWAG):

Tracer 4: T4 = Effective Lean Gas Before Solvent tracer
Tracer 5: T5 = Returned Trapped Lean Gas tracer (adsorbed tracer 4 mobilized by tracer 1)
Tracer 6: T6 = Ineffective Lean Gas Before Solvent tracer
Set 3 (Modeling IWAG after MWAG):

Tracer 7: T7 = Effective Lean Gas After Solvent tracer
Tracer 8: T8 = Returned Trapped MI tracer (adsorbed tracer 1 mobilized by tracer 7)
Tracer 9: T9 = Ineffective Lean Gas After Solvent tracer
Tracer names T1 to T9 are normally reserved for use only with the IOR logic. It is possible to
use T4 to T9 as ordinary tracers if these names are not used in the IOR logic. However, this
usage is discouraged, to avoid confusions within the context of IWAG IOR tracer logic
modeling.
Each tracer is initialized with a particular concentration value in the grid cell. The following
variables, with units of TPV (Total Pore Volume) fraction within the reference grid cell, are
defined as follows:
Fluid in solution
C1 = effective solvent in solution
C2 = IOR oil in solution
C3 = ineffective solvent in solution
C4 = effective lean gas in solution before solvent
C5 = return trapped solvent in solution
C6 = ineffective lean gas in solution before solvent
C7 = effective lean gas in solution after solvent
C8 = return trapped lean gas in solution
C9 = ineffective lean gas in solution after solvent
Fluid adsorbed
A1 = effective solvent adsorbed
A2 = IOR oil adsorbed
A3 = ineffective solvent adsorbed
A4 = effective lean gas adsorbed before solvent
A5 = return trapped solvent adsorbed

A6 = ineffective lean gas adsorbed after solvent
A7 = effective lean gas adsorbed before solvent
A8 = return trapped lean gas adsorbed
A9 = ineffective lean gas adsorbed after solvent
An assumption used is that any re-mobilized gas cannot be trapped again, so A5 = A8 = 0.
In the MWAG after IWAG logic, trapped lean gas may be mobilized by solvent during the
MWAG injection. Tracer T5 is used to identify mobilized lean gas that has been trapped, and
the same mobilization truth model for the release of lean gas and oil is normally used.
In IWAG after MWAG, trapped solvent may be present after the MWAG process. This solvent
may be mobilized by lean gas injected during the IWAG process. Tracer T8 is used to identify
mobilized solvent that has previously been trapped. A different mobilization truth model is
required to describe the lean gas sweeping process (IWAG) as a function of cumulative gas
injected. T8 may not be used to mobilize IOR oil until it is re-cycled to the injector. This is part
of the IWAG after MWAG logic.
To summarize, the IOR tracer logic will allow both for solvent trapping and for subsequent
mobilization of trapped IOR oil and trapped lean gas (MWAG after IWAG). It also allows for
the trapping of lean gas and the subsequent mobilization of trapped solvent (IWAG after
MWAG).
Relationship between saturation and concentration

The IOR tracer logic handles only water and oil phases, and it does not model the flow of solvent
gas in the streamlines. A simpler approach is adopted trapped phases (solvent, lean gas and
IOR oil) are modeled by adsorbed tracers, whereas mobile phases (solvent, lean gas and IOR
oil) are modeled as tracer concentrations in the solution. Mobilization of IOR oil by solvent is
simply modeled as the desorption of IOR tracer in the presence of solvent tracer.
The volume of solvent and IOR oil is expressed in terms of concentrations rather than
saturations. The concentration is defined as the volume of a component divided by the pore
volume (PV). For example,
Mobile IOR Oil Concentration = Mobile IOR Oil Volume-

----------------------------------------------------------
PV
Trapped IOR Oil Concentration = Trapped IOR Oil Volume

-------------------------------------------------------------
PV
By specifying concentrations, rather than saturations, a concept of total phase tracer is

established, in the sense that the IOR WAG process is defined independently of individual
phases. This seemingly unusual step is necessary to allow solvent and lean gas tracer to
propagate quickly but separately from the reservoir fluids to the producing well. Thus, within a
grid cell or along a streamline, the total oil concentration is
Oil Volume- = WF
--------------------------- Oil + IOR Oil ( Mobile + Trapped )- ,
--------------------------------------------------------------------------------------------
PV PV
where
WF Oil = oil produced as a result of water flooding.
The total solvent concentration is:
Solvent Effective Solvent ( Mobile + Trapped ) + Ineffective Solvent ( Mobile + Trapped )-
------------------ = --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
PV PV

Key aspects of modeled WAG solvent and lean
gas processes
The FrontSim IOR tracer logic defines a fast and simple means to capture the following four
key aspects of the WAG solvent and lean gas processes:
"Solvent mobilizes water flood residual oil and lean gas" on page 156
"Solvent efficiency decreases with solvent slug size" on page 156
"Some solvent remains trapped in the reservoir" on page 157
"Solvent and lean gas travel rapidly through the reservoir" on page 158.
Solvent mobilizes water flood residual oil and lean gas

The mobilization of trapped waterflood residual oil by the IOR tracer is made possible by the
presence of the effective solvent tracer T1 during MWAG, or by recycling of the RMI tracer T8
to the injector during IWAG after MWAG. The solvent tracer T1 is also able to mobilize trapped
lean gas tracer T4 within each grid cell it visits. For practical purposes, such mobilization
processes occur at the solvent fronts along the respective streamlines.
Solvent efficiency decreases with solvent slug size

A key concept in the streamlinetracer model is that only a portion of the injected solvent is
effective in mobilizing IOR oil. The ineffective portion of the solvent simply moves to the
producing well through zones that have already been swept by solvent tracer. In the IOR tracer
model, the slope of the IOR mobilization curve represents the efficiency of a solvent slug. The
value of this slope is used on the fly in the simulator in order to partition an injected solvent
slug into effective and ineffective portions:
Solvent = Effective Solvent + Ineffective Solvent
Mobilizes IOR Oil Cannot mobilize IOR Oil
The IOR mobilization curve has a characteristic shape, shown in Figure 17.9. The initial solvent
slugs contain mostly effective solvent, while the final slugs contain mostly ineffective solvent.
In a typical model, most of the trapped solvent is effective solvent, whereas most of the
produced solvent is ineffective solvent. The partitioning of injected solvent into effective and
ineffective portions is transparent to you, who simply needs to enter the total amount of solvent
injected. The partitioning based on the mobilization curve is accomplished internally in the
simulator.

Figure 17.9 The slope of the mobilization curve reflects the solvent efficiency
Initial slugs are more efficient than later slugs. The overall process efficiency is the slope of the
line from the origin to the final point. The incremental efficiency of each injected slug is the
slope of the IOR Mobilization curve as shown in Figure 17.9.
The mobilization curve can be used to partition injected slug type (lean gas and water, or solvent
and water) for use with the tracer logic. You specify the pore volume of the injected slug and
the injected slug type (lean gas, solvent, or water).
The ineffective solvent concentration, C 3 , is the remaining portion of the injected slug:
C3 = 1 C1 .
The above concentrations are normalized in the sense that C 1 + C 3 = 1 . When solvent is not
injected, both the effective and ineffective solvent concentrations should be defaulted to zero at
the injector for the current simulator time step. Because injection occurs in discrete time steps,
the above concentrations are, in fact, averaged efficiency levels during the current time step,
(change in sweep between time steps) -
with the ratio of: ---------------------------------------------------------------------------------------------------------
(change in gas injection between time steps)
.
For lean gas injection, a similar efficiency level is defined by the lean gas sweep curve slope (or
lean gas efficiency) as a function of the cumulative lean gas injection slug. In general, the lean
gas sweep is less effective than the solvent sweep because solvent tends to be more viscous:
eff
Q lg
- = 4, 7 = slope of lean gas sweep curve
C 4, 7 = -------------
total
Q lg
The ineffective lean gas ( C 6, C 9 ) is the remaining portion of the injected slug:
C 6, 9 = 1 C 4, 7
Both effective and ineffective lean gas concentration is zero in the event of no lean gas injection.
Some solvent remains trapped in the reservoir

The trapping of solvent tracer when mobilizing IOR oil is quantified by an irreversible
adsorption process. The details of the IOR adsorption and desorption mechanisms are discussed
in the section "The tracer adsorbing/desorbing mechanism" on page 160.

Solvent and lean gas travel rapidly through the reservoir
FrontSim enables this feature by defining the IOR tracer as a total phase tracer traveling along
the same streamline distribution as the reservoir fluids, at the Darcy velocity. This speed factor
is an important history matching parameter available to you. This is described in detail in
section "The accessible pore volume (APV) factor" on page 162 and "Solvent and IOR oil
breakthrough/IOR production curve tuning" on page 171.
Determining the IOR tracer spatial distribution

Formulation of tracer propagation along a streamline
We adopt a simple one-dimensional adsorbtion model to describe the tracer movement along a
streamline:
( C i + A i ) V ( X s ) C i
------------------------ + -------------- -------- = 0
T ( X s ) X s
where C i is the tracer concentration, A i is the absorbed concentration, V ( X5 ) is the given Darcy
velocity at streamline coordinate X 5 , i ( X 5 ) is the accessible pore volume factor (APV) at X 5 ,
and T is the simulated time period. All these quantities are defined for a particular tracer.
The IOR mobilization curve and solvent efficiency

Prior to running the streamline-tracer model, one must determine how much IOR oil is
mobilized in a streamline for a given amount of injected solvent. This information is captured
in the mobilization curve, which is obtained by running a series of fine-scale, finite-difference,
injector-producer Truth models with a representative geological heterogeneity. Models with
varied slug sizes and injection rates have to be run. The mobilization curve is used to determine
the amount of IOR oil that is mobilized along a streamline extending from an injector to a
producer.
A separate mobilization curve is required for each geologically distinct portion of the field. In
addition, separate mobilization curves are required if multiple solvent types are used. The
mobilization curves are obtained when Recovery Fraction is plotted vs. slug size and injection
rates; these curves are then normalized.
The IOR oil recovery as a function of the injected, normalized slug size and injection rates. The
slope of the mobilization curve represents the efficiency of IOR mobilization. The slope is
computed on the fly in the simulator in order to partition the injected solvent tracer slug into
effective and ineffective portions. Numerically, this slope converges to zero as the solvent slug
size increases. This implies that the initial solvent slugs contain mostly effective solvent tracer,
while the final solvent slug contains mostly ineffective solvent.

Figure 17.10 IOR mobilization curve construction from Truth Model simulations
The IOR mobilization curve is typically constructed from constant-floodrate, finite-difference,

Truth Model simulations of an injector-producer pair (Figure 17.10). Each MWAG simulation
generates one point on the mobilization curve.
Solvent sweep-out, and hence the mobilization curve, is also a function of floodrate. Increasing
the floodrate increases the viscous-to-gravity ratio and improves the sweep. Thus, FrontSim
allows the mobilization curve to be floodrate-dependent, as illustrated below.
Figure 17.11 IOR mobilization curve and floodrate
The IOR mobilization curve depends on the floodrate. This dependency is obtained by running
the finite-difference truth model at various floodrates.
Each solvent injector in the tracer-streamline model has an associated mobilization curve that
dictates the dynamic solvent displacement efficiency of all streamlines connected to that
injector. The mobilization curve contains no information on the timing of solvent or IOR oil
production. Timing is handled by the accessible pore volume factors that are discussed later.
In order to use the mobilization curve efficiently in the simulator, the curve needs to be
parameterized and fitted to the following equation.
IOR V solv
ER = --------------------------------------
- [EQ 17.1]
1- + A ( V
--- )
B
C solv
where E R IOR is the produced IOR oil ( VREF fraction), Vsolv is the solvent slugsize ( VREF
fraction) and A , B and C are curve fitting parameters.
The floodrate-dependent mobilization curve also needs to be parameterized and fitted to the
following equation:
ER
IOR Q
= -------------------------
- [EQ 17.2]
1
--- D ( Q )
+
E
F

where ER IOR is the produced IOR oil ( VREF fraction), Q is the flood rate (TPV fraction) and D ,
E and F are curve fitting parameters. All the parameters A , B , C , D , E and F have to be input
into the simulation data deck, and hence you are responsible for fitting the mobilization curves
to the above equations.
The mobilization curve can be accurately applied to injector-producer pairs in a field only when
the conditions used to generate the mobilization curve are the same as the conditions in the field.
Strictly speaking, therefore, any change in, for example, injector-producer distance, reservoir
geology, WAG ratio, WAG cycle length, reservoir pressure, or initial saturations, requires a
separate mobilization curve. This approach can create an unwieldy number of mobilization
curves, and may require much CPU time. Therefore, it may be instructive to divide a
heterogeneous reservoir into regions that are dissimilar, and derive separate mobilization curves
only for these regions. The mobilization curves obtained may then be re-applied to reservoir
regions which have similarities to one of the regions for which a mobilization curve already
exists.
Note that it is generally assumed that the WAG cycle length does not impact the mobilization
curve, but only the timing of the solvent production. In addition, there is some evidence that the
WAG ratio has very little impact on the mobilization curve. The impact of the initial saturation
and injector-producer distance is somewhat stronger, and separate mobilization curves should
be generated for each significant change in initial saturation and injector-producer distance.
The tracer adsorbing/desorbing mechanism

An important IOR tracer logic mechanism is the determination of adsorption/ desorption levels
for the injected tracer traveling along the streamline. At a given time step, the amount of tracer
adsorption and desorption is determined and accounted for prior to advancing these tracers
along the streamline. The IOR tracer logic requires that the adsorption is an irreversible process,
namely that a given adsorption/desorption process may not be reversed by the same WAG
injection process. Desorption of a tracer that has previously been adsorbed is possible only with
a different WAG mechanism. We define three such mechanisms; these are respectively the
IWAG before MWAG, MWAG, and IWAG after MWAG mechanisms. At a given time, only one
mechanism can be active. It is most likely that the adsorption/desorption occurs only at the
tracer front in a streamline. Spatial distribution of tracer concentrations are reported at the end
of the simulation time steps.
Trapped solvent
max max
The IOR tracer logic uses a linear adsorption isotherm, with S solvent, trap and S gas, trap to represent
the maximum linear trapping weights. These are parameters chosen by you, and it is possible to
use other types of adsorption isotherms.
The MWAG mechanism mobilizes IOR oil by trapping the injected solvents along fronts that
propagate in the streamlines. The amount of incremental solvent concentration trapped, At1+ 1 ,
at the next time step is always positive.
t+1 t max t
A1 = max ( C 1S solvent, trap , A 1)
t+1 t+1 t t max t t

A 1 A1 A 1 = max ( C1S solvent, trap , A 1 ) A1

Mobilized IOR Oil
The amount of mobilized IOR oil is limited by a minimum function in order to ensure that no
more IOR oil can be mobilized than is present. If this minimum function has to be used, this
corresponds to the case when the injected solvent volume is higher than the volume of mobilized
IOR oil, which leads to a net solvent requirement larger than unity:
t t+1
IOR Oil Mobilized = min ( A 2, A 1 )
t+1 t
A1 = A2 + IOR Oil Mobilized
t+1 t
C1 = C 2 + IOR Oil Mobilized .
The master in the MWAG mechanism is the solvent tracer, whereas the slave is the mobilized
IOR oil.
Trapped lean gas

Both the IWAG before MWAG and the IWAG after MWAG processes include the adsorption or
trapping of injected lean gas. The maximum operators ensure that the concentration of trapped
lean gas is equal to or higher than the concentration at the previous time step. This is done in
order to avoid the process becoming reversible.
t+1 t Max t
A4, 7 = max ( C 4, 7,S gas, trap , A 4, 7 )
t+1 t+1 t t Max t t

A4, 7 = A 4, 7 A4, 7 = max ( C 4, 7,S gas, trap , A 4, 7 ) A 4, 7
Lean Gas and RTLG

For the IWAG before MWAG mechanism, desorption of trapped lean gas only occurs in the
MWAG process, through the trapping of solvent tracer. The solvent trapping mobilizes the same
amount/concentration of trapped lean gas tracer and IOR oil. The returned trapped lean gas
(RTLG) is considered ineffective lean gas that can no longer be trapped. The master is still the
solvent tracer and the slave is the RTLG tracer. The same mobilization curve is used as for the
MWAG process for obtaining the portion of effective and ineffective lean gas tracers.
t t+1
Lean Gas Mobilized = min ( A 4, A 1 )
t+1 t
A4 = A 4 Lean Gas Mobilized
t+1 t
C5 = C 5 + Lean Gas Mobilized
RTMI/ Mobilized Solvent

For the IWAG after MWAG process, the desorption of trapped solvent occurs only in the IWAG
process. In this case, the master is the injected lean gas tracer and the slave is the returned
trapped miscible injectant (RTMI) or mobilized solvent. The recycled portion of the produced
RTMI tracer to may be re-injected for a renewed MWAG process at selected injectors:
t t+1
Solvent Mobilized = min ( A 1, A 7 )
t+1 t
A1 = A 1 Solvent Mobilized

t+1 t
C8 = C 8 + Solvent Mobilized
In this case, a different mobilization curve from the one used in the MWAG process is typically
used in order to obtain the portion of effective and the portion of ineffective lean gas tracer.
The adsorption values are entered using the TAD, TADE and TBLK keywords in FrontSim.
The accessible pore volume (APV) factor

In MWAG and IWAG processes, solvent and lean gas will typically flow rapidly to the producer
either by viscous fingering or high permeability streaks. Thus, the solvent will not traverse all
of the pore volume available in the truth model. This is not explicitly modeled in the IOR tracer
simulation model. Rather, the reduced pore volume swept by the solvent and lean gas is
accounted for by an accessible pore volume (APV) parameter for each tracer. The APV is the
ratio of the pore volume traversed by the tracer to the actual pore volume within the swept area.
If the APV equals to one, the tracer front traverses the entire pore volume available, and does
not travel faster than the Darcy velocity in the streamline. If the APV is given by a constant ,
where 0 1 , then the tracer samples or sees a proportion of the pore volume equal to
multiplied by the total pore volume. This results in a tracer breakthrough --1- times faster than if
the tracer traverses the entire available pore volume. you can specify a global APV factor for
each IOR tracer, but it is also possible to specify a tracer-specific APV factor in each grid cell.
The APV factors impact only the velocity of the IOR tracers, and are independent of the
volumetrics of the IOR tracer model.
Recall that for the MWAG process, the solvent is viewed as being composed of two parts
effective solvent and ineffective solvent. The ineffective solvent tracer is that portion of the
solvent that flows rapidly from the injector to the producer through previously swept zones. The
solvent breakthrough time is normally controlled by the APV of the ineffective solvent rather
than the effective solvent. Typical APV values of ineffective solvent lie in the range from 0.02
to 0.20. Note that the adsorption of ineffective solvent can also delay the solvent breakthrough
time.
Notes
1 In trying to match the timing of returned solvent (RTMI) with field data, reducing APV for
ineffective solvent tracer can lead to earlier breakthrough of (ineffective) solvent tracer.
2 Similarly, the APV for IOR oil determines the IOR oil breakthrough. Reducing the IOR oil
tracer APV can cause earlier breakthrough.
3 The APV for effective solvent tracer also impacts the shape of the IOR production curve.
Increasing the APV can cause the delay of IOR oil breakthrough or cause the oil recovery
to take place at a reduced rate. Reducing the APV for IOR oil can cause earlier IOR oil
breakthrough.
In general, the shape or the timing of the IOR tracer breakthrough curve can be adjusted by
modifying APV values.
The APV values are currently entered using the TPFA and TPFV keywords in FrontSim.

The IOR solvent allocation and facility limit logic
The FrontSim IOR tracer logic includes solvent allocation logic and water/gas handling logic.
The solvent allocation logic allows you to specify a yearly solvent supply rate, target slug size
(normalized by VREF ), and WAG ratio. The simulator then distributes this solvent to injection
wells based on the efficiency of the IOR process. This efficiency is defined by the slope of the
IOR mobilization curve vs. cumulative solvent slug size. The water/gas handling logic allows
you to specify a maximum water and gas handling rate for the field. When these rates are
exceeded, the simulator shuts-in producing wells based on a GOR and WOR ranking of wells.
The solvent allocation logic

Solvent utilization is commonly defined as the ratio of injected solvent tracer to the IOR oil
produced within an injector/producer pair or cluster pattern. This ratio is sometimes referred to
as MI utilization, MI Efficiency, volumetric sweep efficiency and gross solvent utilization. For
the tracer model, it is equivalent to consider the solvent efficiency, which is the inverse of
solvent utilization. Hence, high solvent efficiency is desirable for a WAG process.
The FrontSim solvent allocation logic is designed with the target of optimizing the efficiency of
each injected slug at each time step. Based on a daily field rate of available solvent, the solvent
allocation logic routine compiles a prioritized efficiency list. This efficiency is quantified by the
solvent efficiency. The solvent efficiency is implicitly given in the mobilization curve as a
function of slug size, where it is seen that the initial solvent injection is more efficient than any
subsequent solvent injection.
Through adjustment of the WAG ratio, the volume ratio of water and gas injection, another
practical way of adjusting the WAG solvent efficiency is given. Field IOR projects often aim to
use a low level of solvent injection for obtaining a high-efficiency IOR recovery process. The
solvent allocation logic accounts for this by using variable WAG ratios, in the sense that the
WAG ratios for solvent injection can decrease with increased cumulative solvent slug sizes.
This is advantageous compared with using a constant WAG ratio when optimizing the solvent
allocation to injectors, which could lead to the situation that solvent is allocated to inefficient
patterns, while not enough solvent is allocated to efficient patterns.
Solvent is distributed to the injector efficiency list, whilst honoring slug size and WAG ratio
constraints. Both these parameters are allocated minimum and maximum values. The IOR
solvent allocation logic can be applied to favor new injector-producer patterns, or to encourage
the continuation of mature patterns. There are also constraints related to financial expenditure,
as the expansion of solvent injection to a new pattern requires new investments. In the IOR
solvent logic, this may be addressed through appropriate choice of the optimization logic; the
solvent allocation logic can be made to favor mature patterns, or it can be made to favor the most
efficient patterns. This latter option implicitly means that the solvent allocation logic favors new
patterns, as these are in general more efficient than mature patterns.
Water and gas handling limit logic

The IOR water and gas limit handling logic presets maximum limits for the water and gas
production rates in the field. During simulation, the simulated production rates from all
producers are summed, and the overall production rates are compared with the maximum
handling limits. If the handling limits have been reached, all producers are ranked by the WOR
and the GOR ratio in two different tables. The logic first consults the WOR list, and shuts in the

high WOR wells in accordance with this table. The overall production rates are re-computed
after each well elimination, and the process of shutting in wells continues until the water
production rate maximum limit is adhered to. If the maximum gas production rate is now
adhered to, the process can stop, whereas if the gas production rate still exceeds the gas
production limit, the logic proceeds by shutting in wells in accordance with the GOR ranking.
The logic also updates the IOR tracer model when these limits are reached. This facility limit
logic can be used independently of the solvent allocation logic.

Keywords and parameters for the IOR tracer model
The set of keyword definitions to be used with the IOR tracer models is given in the "FrontSim
User Guide". However, the usage of these keywords is also exemplified in the following
sections with the purpose of further illustrating possible IOR simulation workflows.
The available keywords are broadly classified into three different categories:
1 Definition of the tracer logic and setting up the initial tracer model
Keywords TREFFIC, TPAIRS, TPVT, TBLK, TIADS, TPFA, TPFV, TAD, TADE.
2 Definition of solvent and lean gas historical injection rates
Keywords WCONINJE, WSOLVENT, WTRACER.
3 Definition of solvent allocation logic and facility limit
Keywords MISUPPLY, RANKING, RANKWELL, SOLVSLUG, PRODLIM.
Notes
1 Gravity must be switched off in the IOR tracer model: set TUNEFSSA item 1 to 0. It is also
possible to use NOGRAV, but for 2D models only.
2 The TRACER keyword defines an ordinary tracer that does not involve tracer logic.
3 The UNIFOUT keyword offers a different way to output the .SUMMRY file, which could be
of importance to some third-party post-processing tools.
Most of the IOR tracer model keywords have to be used in the SCHEDULE section of the
simulator input data deck. Exceptions are found for those keywords used for setting up the tracer
logic and the tracer initial conditions.
Entering keyword parameters

Setting up the IOR tracer model
To set up a tracer model for IOR simulation:
1 Set up the type of IOR logic (tracer master-slave relationship) using the TPAIRS keyword.
2 Determine the tracer formation volume factor (PVT data) for reporting with the TPVT
keyword.
3 Specify the truth model to activate the tracer logic mechanism with the TREFFIC keyword.
See "The IOR mobilization curve and solvent efficiency" on page 158.
4 Specify the initial tracer concentration with the TBLK and TIADS keywords. Initial tracer
concentration is specified for each cell and for each tracer using the TBLK keyword, and
the adsorbed tracer concentration is specified for each cell and for each tracer using the
TIADS keyword. For an IOR tracer model, all the initial concentration and adsorbed
concentration values are normally defaulted to 0.0, except for the initial trapped IOR oil
target. Trapped or adsorbed IOR target is specified with the TADET2 parameter (keyword
TADE for tracer T2), or for each cell using the TIADS keyword. (See "The IOR tracers" on
page 153 where reserved tracer names are described.)

Note Note that it is possible to specify 0.0 trapped IOR targets in an aquifer layer or zone
using the TIADS keyword, which overrides the defaulted non-zero IOR adsorbed
concentration defined by the TADET2 parameter.
5 Specify the adsorption and propagation mechanisms with the TAD, TADE, TPFA and TPFV
keywords.
The APV (accessible pore volume) values are entered for each tracer with TPFA.
APV values for each cell and for each tracer can be specified by using the TPFV keyword.
Use TAD and TIADS for specifying tracer adsorption. The IOR tracer logic supports the
specification of the adsorption isotherm definition by tracer only.
The IOR tracer model in history mode

The solvent and lean gas injection rates are specified using the WTRACER and WSOLVENT
keywords, whereas the selected method of scaling the truth model is specified using the
RANKING and RANKWELL keywords in addition to the TREFFIC keyword. Please refer to
section "Scaling the model to match the field IOR mechanisms" on page 176 for a discussion
on scaling the truth model.
Computing Injected Solvent and Lean Gas Concentration in history mode

The IOR tracer model includes only the water and oil phase. This requires a conversion of
injected solvent and lean gas volume into tracer concentration, in order to account for both the
injected and produced volume.
In the case of injection, you must convert the volume of solvent injected into reservoir barrels,
compute the concentration in the injection stream, and then assign this concentration on the
injection well. Once in the reservoir, the tracer volumes are not associated with any phase, and
thus they are free to move ahead of any injected water on the same streamline with defined
factors of the Darcy velocity. At the producer, the produced solvent and lean gas tracer
concentration must be converted to equivalent water volume, and then to surface gas units by
using the proper tracer formation volume factor (FVF).
The concept of using water as a swing variable to account for solvent, lean gas tracer, as well as
the produced IOR oil is shown in Figure 17.12. The left sketch shows all 3 phases present in the
actual field, and the right sketch shows how the IOR tracer option models these phases, by
combining the gas and water phases into a single phase at injection. Gas is then traced as part
of water.
Figure 17.12 Using water as a swing variable to account for solvent, lean gas tracer and produced IOR oil

The produced IOR oil is treated in a similar fashion it must be converted to surface units using
B o , and its production is subtracted from the total water production since water is the swing
variable. The assumption in the model is that there is enough water produced in a WAG process
to act as the swing variable. Adjustments would have to be made to the model, for example,
to simulate either continuous gas injection or gas injection into a reservoir that had not been
previously water- flooded, since these cases would not have enough water to act as the swing
variable.
There are two possible ways of supporting solvent and lean gas injection volumes:
1 Obtain and specify the injection concentration along with the water injection rates using the
WTRACER keyword
2 Directly specify the injection volume and have FrontSim convert the injection rates into
concentration using the WSOLVENT keyword.
In each case, first use keyword WCONINJE to define the control data.
Controlling the tracer injectors using the RANKWELL keyword

The RANKWELL keyword provides control parameters for each tracer injector. In the history
mode, RANKWELL selects and re-scales the truth model by overriding the default set with the
TREFFIC keyword. In the predictive mode, RANKWELL specifies an additional switch. This
switch determines whether the injector participates in the solvent allocation logic or not. This
allows you to have an option to continue solvent injection at specified injection rates or allow
this injector to participate in the solvent allocation logic. Parameter controls are provided in
order to influence the timing and the amount of solvent allocated to this injector.
The combined use of RANKING, TREFFIC and RANKWELL enables you to select the
perforation thickness scaling mode, with reference to the truth model.
Note Horizontal injection wells are not supported for all thickness scaling modes.
You choose the truth model volume scaling methods. The scaling methods available are
dimensional scaling and dimensionless scaling. This type of scaling must not be confused with
the thickness scaling mentioned below. It is possible to have multiple RANKWELL listings for
the same well, with the purpose of specifying the parameters of the different perforations. This
is useful when a well spans multiple layers. However, this does not work for horizontal wells,
or with the injector layered model scaling (compare the RANKING keyword).
The mobilization curves are required to have separate names if multiple RANKWELL entries are
used for the same well. This means that the three curve names for each of the three WAG
processes need to be different for any two RANKWELL listings of the same well. Perforation
information is not used in predictive mode or with solvent allocation logic. In these cases, only
the last listing of the RANKWELL keyword is meaningful. This limitation is due to the fact that
solvent allocation in predictive mode is well based, not perforation based.
Solvent allocation and scaling with the RANKING keyword

RANKING is a SCHEDULE keyword that determines the mode of solvent allocation, and the
scaling method used globally in relation to the truth model for the current time step.
The IOR tracer model has been extended from the single-layer 2D model to multiple-layer 3D
models by using the scaling by layer option. Scaling by perforation is suitable for a 3D layered
tracer field model. You should bear this in mind before investing efforts in extending IOR tracer
models to 3D.

Scaling of injection solvent volume with THKRATIO
The FrontSim IOR tracer logic provides a number of ways for scaling the input solvent injection
volume. This could have an impact on the reference defined by the mobilization curve when
obtaining solvent efficiency. These scaling options are mentioned in the RANKING and
TREFFIC keyword descriptions. "Scaling the model to match the field IOR mechanisms" on
page 176 provides a detailed discussion on the use of VREF, the reference volume. Here we
focus on the THKRATIO variable, which is defined in the ALMODE option of the RANKING
keyword.
The IOR tracer logic uses the following equation to calculate the normalized solvent slug with
the THKRATIO variable:
INJ
Solv_Inj ( RVB )
Tracer_Slug = -------------------------------------------------------------------
-
VREF ( RVB ) THKRATIO
These variables are defined as follows:
1 You can choose not to scale the VREF defined either globally in TREFFIC for the truth
model, or locally for the injector in the RANKWELL keyword. This is possible by defaulting
THKRATIO = 1, and by specifying the THK in the truth model to be zero. See "Example
2" on page 346 of TREFFIC keyword.
2 you can choose to define the THKRATIO as the ratio of perforation thickness to that of the
truth model:
THK PERF
THKRATIO = ------------------------------------------------
-
THK TRUTH_MODEL
This is possible by specify ALMODE=0,1 in the RANKING keyword.
3 In a 2D layered model, THKRATIO is the ratio of the total layer thickness to that of the
truth model. This is the model that also supports horizontal injection well:
THKLAYER
THKRATIO = ------------------------------------------------
-
THK TRUTH_MODEL
This is possible by specifying ALMODE=2,3 in the RANKING keyword.
4 In a 2D layered model, THKRATIO is the ratio of current perforation thickness to the total
active perforation thickness:
THK PERF
THKRATIO = ------------------------------------------
-
THK TOTAL_PERF
This is possible by specifying ALMODE=4,5 in the RANKING keyword
You are advised to refer to the solvent allocation logic in "IOR tracer model in predictive mode"
on page 168 for discussion on the controls and behaviors of solvent allocation logic in the
predictive mode.
IOR tracer model in predictive mode

The solvent allocation logic (MWAG only) is activated by specifying the available solvent
supply using the MISUPPLY and SOLVSLUG keywords and by specifying eligible solvent
injectors using the keyword. The facility limit logic is available in both the predictive and the
historical modes using the PRODLIM keyword. It is possible to mix uses of predictive and
historical modes. In this case, you can specify injectors with fixed injection rates and injectors
whose rates are determined by the solvent allocation logic. The switch for this is set in the
RANKWELL keyword for each injector.

History matching a field tracer model
Matching historical field IOR production rates is a complex issue that is beyond the objective
of any user guide. However, it is important to point out some history matching workflows that
effectively utilize injector and producer streamline patterns, a concept native only to streamline
simulators. In the following, we discuss tuning options available within the IOR tracer model.
Mobilization curve and initial trapped IOR oil

Although the field engineer will normally have available a set of tracer parameters to use in a
simulation, it is sometimes necessary to tweak these parameters to match field performance.
We discuss below some of the most effective parameters that can be adjusted to alter the
production behavior of FrontSim. Large adjustments to the Truth Model values probably
indicate that something more fundamental is wrong. Users should double check the geology,
production data, and other assumptions before large adjustments to Truth Model parameters are
made.
The two most dominant factors impacting the amount of IOR oil produced are the IOR
mobilization curve and the initial trapped IOR oil value. Typically, the initial trapped IOR oil is
set to Sorw , the residual oil saturation after water-flooding, so there is not much room for
adjustment there. However, there are many parameters that impact the IOR mobilization curve,
whose equation is given again below. The parameters A , B and C are parameters determined
by you, and the objective is to obtain the best fit to the numerically obtained mobilization curve.
In history matching the model, it is recommended that users adjust the A parameter in order to
raise and lower the mobilization curve, and that the remaining parameters are left alone.
Decreasing A will raise the mobilization curve. The mobilization curve equation used in
FrontSim is
IOR V solv
ER = ---------------------------------
-
1
---- + A ( V solv )
B
C
For reference, the value of C is the initial slope of the curve, whereas the B parameter controls
the shape of the curve.
Figure 17.13 Decreasing the A parameter raises the mobilization curve.
In this example, B = 1.06 and C = 1.0 for all cases.

The mobilization curve can also be impacted by the floodrate. In many cases, however, this
option is turned off. In general, when trying to match the FrontSim simulation data to the field
production data, it is frequently desirable to turn off various simulation mechanisms in order to
help identify the variables that have a dominant effect on the production of solvent and IOR oil.
Some possibilities follow.
Turning off rate dependence

The IOR mobilization curve affects the total amount of IOR oil produced as well as the trapping
of the effective solvent. If the rate dependence of the IOR mobilization curve is incorrect, then
anomalous IOR production values can occur. The rate dependence of the IOR mobilization
curve can be turned off by setting D = 1 , E = 1 and F = 10 6 .
Turning off solvent trapping

If the FrontSim simulation model produces less solvent than is seen in the actual field, it is
sometimes helpful to turn off the solvent trapping completely so that the maximum amount of
solvent is produced. If FrontSim still does not produce enough solvent, then the streamline
distribution is probably wrong (in other words, the geology is incorrect). The Solvent trapping
can be turned off by setting the maximum adsorption value for the effective and ineffective
solvent to 0.0.
Turning off IOR oil mobilization

The produced IOR oil is typically mobilized by injected solvent. It may be desirable, for the
purpose of debugging, to make several FrontSim runs and selectively turn off the IOR
mobilization from all injectors except one. In this way, the contribution of IOR oil can be traced
back to individual injectors, and the cause of unusual IOR oil production can be more easily
determined. To use this technique, define a new mobilization curve with the parameters
A = 10 6 , B = 1 and C = 10 6 , and assign this curve to all injectors except the one under
investigation. These parameters set the IOR mobilization curve to a value close to zero. When
this technique is used, one should focus on the produced IOR oil and not the solvent, since
setting the adsorption curve to zero will also make the injected solvent 100% ineffective.
If it is desirable to eliminate the IOR oil mobilization for all injectors, but still maintain the
correct amount of solvent trapping, one can simply set the initial amount of IOR oil adsorbed to
0.0 in all grid cells, and leave the mobilization curve untouched.
Adsorption tuning and cumulative solvent production

The trapping of solvent is governed by the IOR mobilization curve and the end-point adsorption
values for the effective and ineffective solvent. In general, adjusting the IOR mobilization curve
to match solvent production is not recommended, since the IOR mobilization curve also impacts
IOR oil production. Likewise, the end-point adsorption value for effective solvent is generally
set to Sorw and should not be altered. Thus, it is best to adjust the adsorption of ineffective
solvent to control the amount of produced solvent. Lowering the end-point adsorption value will
increase the amount of solvent produced, since trapping will decrease. Note that if the
adsorption is set to zero and more solvent production is still needed, then there is probably
another phenomenon occurring in the model. Check if the field has a potential source of gas,
such as a gas cap, that is not being captured in the FrontSim model.

The cumulative solvent produced in a simulation run equals the cumulative solvent injected
minus the amount of trapped solvent. The trapping of solvent is mimicked by the tracer model
as adsorption of the effective and ineffective solvent. In the nomenclature of adsorbing/
desorbing tracers, an isotherm is the relationship between the amount of tracer adsorbed and
the total amount of tracer in the solution. In this case, the isotherm represents the amount of a
phase that is trapped as a function of the amount of phase that is flowing. Since phase trapping
is irreversible, the adsorption isotherms are specified to be irreversible, that is, once gas is
trapped it will remain trapped even when no flowing gas is present.
Solvent and IOR oil breakthrough/IOR production curve

tuning
In the truth model, solvent will typically flow rapidly to the producer either by viscous fingering
or high permeability streaks. Thus, the solvent will not traverse all of the pore volume in the
model. Recall, however, that the tracer model represents a vertically-averaged view of the
process. Hence, neither fingering nor high permeability streaks can be mechanistically
represented. To account for the reduced pore volume that is swept by the solvent, the tracer
model provides an accessible pore volume factor (APV) for each tracer. This value is the ratio
of the pore volume seen by the tracer to the actual pore volume. If the APV equals one, then the
tracer front is not accelerated. If the APV equals 0.25, then the tracer will see only a quarter of
the pore volume of the rock and, hence, breakthrough will occur four times more quickly. You
can also specify an APV for the IOR tracer. The APV is typically obtained by trial and error.
Thus, a 1D FrontSim model constructed from the truth model, and the APV for the tracers are
varied until the breakthrough timing matches the Truth Model. The concept is illustrated in
Figure 17.14 where breakthrough times are adjusted by adjusting the APV factors.
Figure 17.14 Adjusting breakthrough times by adjusting the APV factors as shown
Note In the tracer model, we view the solvent as being composed of two parts effective
solvent and ineffective solvent. The ineffective solvent is that portion of the solvent
that flows rapidly from injector to producer through previously swept zones. It is
therefore ineffective at recovering oil. Thus, the solvent breakthrough time is normally
controlled by the APV of the ineffective solvent rather than the effective solvent.
You can exert some control over the shape of the IOR oil production curve by adjusting the APV
value of the effective solvent. Increasing the APV of the effective solvent causes the IOR oil
production to occur more slowly. IOR oil production slow-down occurs because a large APV
means that the solvent advances more slowly through the reservoir, thus desorbing oil more
slowly. The TPFAT1 keyword is used to set the APV of effective solvent as described above.

Issues for gas handling and interpreting mass balance
error
Handling Gas
Because the underlying streamline model is a two-phase model, the impact of gas
compressibility on pressure cannot be accurately modeled. In cases with a gas-cap that provides
pressure support, but is not produced, it is possible to add a constant-pressure boundary
condition at the GOC to simulate the pressure impact of the gas cap. Errors in pressure will not
impact the displacement performance, since the IOR mobilization curve is entered directly in
the model and is not computed with pressure-dependent phase behavior and minimum
miscibility pressure (MMP). Hence, the predicted pressures have a minor impact on MWAG
performance relative to the streamline distribution and fluxes.
Gas production during fill-up or coning of gas from a gas-cap cannot be modeled. Thus, we do
not use bottom-hole pressure control on injection or production wells, since the two-phase tracer
model cannot account for the gas viscosity. In practice, MWAG floods with many patterns are
run at a fixed TPV/year floodrate fraction to maintain balanced patterns. Hence, BHP control is
less of an issue.
Material Balance Errors

One possible drawback of front-tracking models is that they can exhibit material balance errors.
Users should always check the material balance error in the simulation to ensure that it is within
reason. These errors can be particularly dangerous when two FrontSim scenarios are run and the
difference in cumulative oil produced is calculated. It is quite possible that the material balance
error will be larger than the difference in cumulative oil between the simulations particularly
when a small modification is made in a simulation containing many wells. It is frequently more
accurate to evaluate the situation where many wells are changed between scenarios, than to
assess the impact of changing a single well.
Field prediction using the IOR tracer model

Solvent allocation logic
The FrontSim IOR tracer logic supports two solvent allocation modes, defined by setting the
parameter SLMODE to 1 or 2 respectively. In both modes, you enter a list of eligible injectors
that are to be allocated solvent, and specifies the availability of the injector at the appropriate
time steps in the SCHEDULE section. This solvent availability in the field may change over
time. This reflects the fact that solvent facilities may not be available to all parts of the field.
Description of solvent allocation logic, SLMODE = 1

With SLMODE = 1 or constant WAG ratio logic, each injection well is allocated a certain target
slug size, where this target slug size is usually the same for all wells. The solvent is distributed
to wells in the order specified by you until the target slug size is reached. Excess solvent is then
distributed to remaining wells according to the solvent efficiency. More specifically, the
procedure works as follows:

Prior to reaching target slug size
You determine which eligible injectors are to be included in the solvent allocation logic in the
SCHEDULE section. The solvent allocation logic subsequently distributes solvent to all wells
injecting less than the target slug size. The injectors at the top of the list will always get priority,
because the sequence of solvent allocation is determined at the outset. This strategy favors the
development of patterns in sequence rather than in parallel: an injector will not lose priority as
it approaches its target slug size.
After reaching the target slug size

Any excess solvent is distributed to remaining injectors based on the solvent efficiency table,
with the most efficient injector receiving the highest priority. This approach is the same as the
one used in the SLMODE=2 logic, which employs this strategy once the minimum slug size is
reached, rather than target slugsize.
Handling of excess solvent

Solvent is initially distributed at the target WAG ratio to available injection wells. Once these
injection wells are allocated solvent, any excess solvent is redistributed to injection wells in
order to maximize the utilization of solvent. This distribution will lower the WAG ratio of the
injectors. A user-specified minimum WAG ratio is used to set a lower bound on allowable WAG
ratios.
Description of solvent allocation logic, SLMODE = 2

With SLMODE = 2, each injection well is allocated a certain target slug size which can vary
from well to well. The allocation logic first distributes solvent to new wells and then to those
that have had only a small amount of solvent allocated. You can specify the fraction of solvent
available for new wells using the RANKING keyword, which can be changed over time. The
remaining solvent is then distributed to the rest of the wells in accordance with the solvent
efficiency table. The procedure works in the following manner:
Prior to reaching minimum slug size

The eligible injectors are ranked at each time step in ascending order of volume of injected
solvent. Solvent is distributed using this ranked well list for all wells whose solvent injection is
less than a minimum value specified by you. This approach favors immature patterns over
mature patterns. For example, a well at the top of the ranked-well list will have only a small
amount of solvent injected. However, once this well receives solvent, its ranking will fall in the
list and a less mature well will take its place. The net effect will be to even out the injection
levels of all available patterns; maturing patterns will be slowed down and immature ones will
be sped up.
After reaching minimum slug size

Once all wells have received their minimum slug size, excess solvent is distributed to injectors
based on the injector's solvent efficiency. The most-efficient injectors receives the highest
priority. This approach will also tend to even out the injection levels of all available patterns
since less mature patterns have high efficiency. Thus patterns will tend to mature in parallel
rather than in sequence.

Handling of excess solvent
Solvent is distributed to all injection wells at the prescribed WAG ratio. This is defined by
record 2 in the SOLVSLUG keyword. Once these injection wells have been allocated solvent,
any excess solvent is not used. However, you can tune the amount of unused solvent by
adjusting the WAG ratio with the TARGWAG parameter. You can also adjust the amount of
utilized solvent by changing the number of entries in record 2 in the SOLVSLUG keyword
described in the section "IOR tracer model in predictive mode" on page 168.
Keyword parameters for the solvent allocation logic

The list of allocation keyword parameters for each RANKWELL injector is shown below in Table
17.2. The solvent allocation logic keywords are used in the SCHEDULE section, and are
specified at the time step when the events occur. You specify the amount of available solvent
with the MISUPPLY keyword at the time of initiating the allocation logic, and the control
parameters are set either globally using RANKING and SOLVSLUG, or individually for each
injector using RANKWELL. Specific differences between the two solvent allocation modes are
listed in the table.
Table 17.2 List of solvent allocation keyword parameters for the RANKWELL
injectors
Keyword parameters Notes

ALMODE=1 ALMODE=2 Allocation Logic mode is specified in RANKING
TARGSSZ Target slug size is specify by RANKWELL for each injector, or
Globally by SOLVSLUG
TARGWAG Target WAG ratio is set globally by SOLVSLUG, record 1
MINWAG Minimum WAG ratio is set globally by SOLVSLUG, record 1
MAXSSZ Maximum slug size is specify by RANKWELL for each injector,
or globally by SOLVSLUG
MIRCYCLE MIRCYCLE Fraction of MI recycle is set globally by SOLVSLUG, for
fraction of produced available for recycle.
MINSSZ Minimum slug size is specify by RANKWELL for each injector,
or globally by SOLVSLUG
MIFRAC Available MI fraction at given WAG ratio table (for solvent
allocation) is set globally by SOLVSLUG keyword.
The water and gas handling limit logic

PRODLIM is the keyword used with the facility limit logic. The water and gas handling logic is
called at each simulator time step. The WOR and GOR of all the wells for the previous time step
are implemented as follows:
1 Obtain the number of wells and identify the producers.
2 Obtain the total production rate at reservoir conditions for each well.
3 Obtain the PVT properties.
4 Obtain the oil, water, and gas rates at surface conditions.
5 Obtain the produced tracer concentrations for each well and convert to reservoir barrels.

6 Decrease the water production rate of each well to allow for tracer production (water is the
swing variable).
7 Calculate the total gas production rate by converting the produced tracer to standard
conditions (MMSCF/D) and add the solution gas to it.
8 Compute the producing GOR and WOR for each well.
If the water handling limit is reached, then rank all wells by WOR. Remove producing wells
based on the WOR ranking. The highest WOR wells are shut in first, until the water handling
limit is reached. If the gas handling limit is reached, then rank all wells by GOR. Remove
producing wells based on the GOR ranking. The highest GOR wells are shut in first until the
gas handling limit is reached.
Results of both the solvent allocation logic and the facility logic are output to a file with a
.FacilityOut suffix. The same content is also present in the .PRT file.

Scaling the model to match the field IOR mechanisms
This section is written for technology providers who must recommend a suite of tracer
parameters to be used in the IOR tracer model.
Determining the tracer parameters from the truth

model
The IOR oil production is captured by the IOR mobilization curve. The mobilization curve is a
three-dimensional surface of mobilized IOR oil, and is a function of solvent slug size and
injection rate. The curve is obtained by running two sets of truth model simulations. In one set,
the slug size is varied, whereas the injection rate is fixed. In the other set, the injection rate is
varied and the slug size is fixed. Based on these simulations, we interpolate other points on the
surface.
Matching the produced IOR Oil: Solvent slug size effect

The aim is to capture the impact of solvent slug size on produced IOR oil as modeled in a bundle
of streamlines connecting an injector/producer pair. An example of a truth model can be a 2D,
vertical cross-section, finite-difference compositional simulation model. We run a series of
simulations at a fixed flood rate and plot recovery vs. solvent slug size as shown in Figure 17.15.
The curve obtained is the IOR mobilization curve. In this case, the axes are normalized by the
hydrocarbon pore volume (HCPV). The HCPV is defined as 1 Swi , where S wi is the initial
water saturation. We define this normalization volume as the reference volume, VREF. Thus, in
this case, VREF = HCPV or HPV. In principle, any reference volume can be used for this
normalization, where an alternative the displaceable IOR pore volume (DEPV).
Note You should be consistent in normalizing injection and production rates with VREF, and
the same reference volume should be used throughout the same tracer simulation
model.
Figure 17.15 Mobilization curve as a function of slug size

Each point on this curve represents a complete simulation.
In order to efficiently use this curve in the simulator, the curve is fitted by a parameterized
equation:
IOR V solv
ER = --------------------------------------
- [EQ 17.3]
1
---- + A ( V solv )
B
C
where E RIOR is the produced IOR oil (VREF fraction), Vsolv is the solvent slug size (VREF
fraction) and A , B and C are curve fitting parameters.
Matching produced IOR oil: Flood rate effect

To capture the impact of flood-rate on produced IOR oil in a streamline bundle, a series of truth
model simulations are run at fixed slug size and varying flood rate. The recovery versus flood
rate is then plotted, as shown in Figure 17.16.
Figure 17.16 Mobilization curve as a function of injection rate
Each point on this curve represents a complete simulation.

The flood rate dependent mobilization curve also needs to be parameterized and fitted to the
following equation:
ER
IOR Q
= ------------------------------
- [EQ 17.4]
1
--- + D ( Q )
E
F
where E RIOR is the produced IOR oil (VREF fraction), Q is the flood rate (TPV fraction) and D ,
E and F are curve fitting parameters.
All the parameters A , B , C , D , E and F have to input into the simulation data deck, and hence
you are responsible for fitting the mobilization curves to the above equations.
The above equation forces the IOR recovery to be zero as the flood rate approaches zero.
However, even at low flood rates, a finite amount of oil is likely to be mobilized in practice.
Thus, the IOR curve is extrapolated backwards based on the slope of 0.03 TPV/year.

Scaling options for the truth model
The objective of scaling is to take results that were generated under one set of conditions and
apply them successfully to another set of conditions. This scaling may be applied to the
mobilization curves.
You should be careful about over-generalizing the IOR mobilization curve. It is tempting to
normalize a mobilization curve, say to HCPV, and then blindly apply it to all patterns in the
streamline tracer model, regardless of injector-producer distance or variations in the residual oil
saturation after water flooding. However, a balance must be struck between generating a
separate mobilization curve for each pattern in the streamline tracer model, and scaling a single
mobilization curve to all patterns in the field tracer model. It is not recommended to scale the
mobilization curve to field streamline patterns that are drastically different from the truth model.
To illustrate the concept of scaling, consider the incremental oil produced from the simulation
of a typical injector/producer pair in the field. Table 17.3 shows the raw data given in units of
MMRVB followed by the same data normalized by HCPV, HCPV after WF, and DEPV where
HCPV = TPV ( 1 S wi ) , HCPV after WF = TPV S orw and DEPV = TPV ( S orw S orm ) . Here,
S orm is the residual oil after miscible flood. In this case
the TPV of the model is 10 MMRVB

the injector-producer distance is 1800 feet
reservoir thickness = 175 feet
S oi = 0.753
S orw = 0.342
S orm = 0.153.
Table 17.3 Incremental oil recovery from a typical injector/producer pair
MI IOR
MI IOR Oil MI IOR MI
HPV HPV
MMRVB MMRVB HPV HPV DEPV
after WF after WF
0.00 0.00 0% 0% 0% 0% 0%
0.20 0.13 3% 2% 6% 4% 11%
0.50 0.28 7% 4% 15% 8% 27%
1.00 0.44 13% 6% 29% 13% 53%
1.50 0.53 20% 7% 44% 16% 80%
2.00 0.59 27% 8% 59% 17% 106%
2.5% 0.63 33% 8% 73% 18% 133%
3.00 0.65 40% 9% 88% 19% 159%
3.50 0.67 46% 9% 102% 19% 186%
4.00 0.67 53% 9% 117% 20% 212%

The problem that the FrontSim IOR tracer logic aims to answer is how to use the above data to
predict the RVB of IOR oil recovered for each RVB of solvent injected in the field? The answer
is straightforward if the TPV, injector/producer distance and the parameters S oi , S orw , and Sorm
are identical between the patterns in the field streamline tracer model and the truth model.
However, in real applications, there will never be an exact match and thus FrontSim must make
assumptions on how to scale the truth model results.
As an example, consider a case in which the streamline tracer and truth models have the same
TPV (10 MMRVB), but different S oi and S orw . The field has Soi = 0.5 and Sorw = 0.2 . The
results for three different scaling approaches are shown in Table 17.4 and Table 17.6. Here, 1
MMRVB of solvent is injected (0.1 TPV). As shown, different amounts of IOR oil are mobilized
depending on which basis is used for the scaling. The streamline tracer model and the truth
model have the same TPV (10 MMRVB), but different S oi and S orw .
Table 17.4 Different approaches for scaling truth model results
Truth model Streamline tracer model

Soi 0.753 0.50
Sorw 0.342 0.20
TPV (MMRVB) 10 10
Table 17.5 Scaling approaches
IOR
Scaling basis MI injected IOR (MMRVB)
(Based on above table)
HCPV_field 1/(10*0.50)=20% HCPV 7% HCPV_field 0.07*10*0.50=0.350
HCPV_field after 1/(10*0.2)=50% HCPV after WF (water 16.3% HCPV_field after WF 0.163*10*0.20=0.326
WF flood)
Dimensional 1 MMRVB 0.44 MMRVB 0.44

scaling

Consider another case (Table 17.6) in which Soi and Sorw are the same in the streamline tracer
model and the truth model, whereas the injector/producer distance in the streamline tracer
model is larger than that used in the truth model, with a resulting TPV of 20 MMRVB. The
differing IOR oil results are shown for the same 1 MMRVB of solvent injected.
Table 17.6 Example:
Truth model Streamline tracer model

Soi 0.753 0.753
11Sorw 0.342 0.342
TPV (MMRVB) 10 20
Table 17.7 Example
IOR
Scaling Basis MI injected IOR (MMRVB)
(Based on above table)
HCPV_field 1/(20*0.753)=6.64% HCPV 3.66% HCPV_field 0.0366*20*0.753=0.551
Dimensional 1 MMRVB 0.44 MMRVB 0.44

Scaling
These two examples show that FrontSim will predict different results depending on the scaling
basis. Since only a handful of truth models are developed in most reservoir studies, FrontSim
will typically have to do some scaling of the mobilization curves to field conditions even when
multiple mobilization curves are entered. Thus, you must tell FrontSim which scaling basis to
use. The rationale behind the various scaling assumptions is discussed below.
The reference volume VREF

The IOR mobilization curve is always entered into FrontSim on a dimensionless basis along
with the reference volume (VREF) used for normalization.
The value used for VREF can be the TPV, HCPV, or any other relevant volume that you desire.
FrontSim computes the RVB of solvent injected during a time-step, normalizes this value by
VREF, and then computes the slope of the dimensionless IOR mobilization curve. The slope
represents the efficiency of the injected slug ( RVB IOR oil mobilized-
------------------------------------------------------------- ). It is this efficiency
RVB of solvent injected
that ultimately determines the amount of IOR oil mobilized by the solvent slug. You may choose
to use dimensional scaling or dimensionless scaling.
1 For dimensional scaling, the actual basis for VREF is irrelevant as long as the basis is the
same as was used to create the dimensionless mobilization curve. For example, some users
may prefer to use the displaceable IOR pore volume (DEPV) as the reference volume
VREF. Other users may want to convert to HCPV since it is a more-accepted petroleum
engineering term. In general, dimensional scaling is appropriate for flows dominated by
gravity, as discussed later.

2 For dimensionless scaling, however, the basis for VREF can make a difference in the
computations. This point was illustrated in the tables above and is discussed further below.
In addition, dimensionless scaling requires that you specify injector/producer sweep-out
volumes a-priori. In this sense, the use of dimensionless scaling requires more work on your
part. However, for viscous dominated flows, the results may be more physical.
A small complication arises when the truth model is a partial pattern model, because how to
scale the partial-model volumetrics to the full-injector-pattern volumetrics must be addressed.
The key point is that the mobilization curve should always be normalized (that is, when
determining the A, B, and C parameters) based on the actual volumetrics of the truth model.
Suppose TPV is used as the reference basis. Then, injection of 1 MMRVB into a pattern
having a TPV of 10MMRVB would be 0.1 TPV. If the Truth Model were changed to a full-
pattern model, then injection of 1 MMRVB into the full 40 MMRVB would give 0.025 TPV of
solvent injected. In this way the A,B, and C parameters always reflect the actual volumetrics of
the Truth Model.
Dimensional scaling with VREF from the truth model

Dimensional scaling means that a given RVB of solvent will mobilize the same RVB of IOR oil
regardless of the injector/producer distance and initial field saturations. Thus, we assume that
the gross solvent utilization (RVB of solvent injected/ RVB of mobilized IOR oil) is
independent of pattern size and saturations. These assumptions are further based on the flood
rate (TPV/yr. fraction) being the same in the truth model and in the streamline tracer model, and
that the streamline tracer model and the truth model have the same reservoir thickness (see later
discussion for adjustments made by FrontSim when the flood rate or thickness varies).
Obviously, though, more IOR oil may not be produced than is initially in the pattern.
Dimensional scaling assumes that gravity segregation creates a solvent bulb around each
injector and that IOR oil is mobilized only in this bulb. Solvent that is injected after the bulb has
formed, is cycled to the producing well along gas tongues. Any additional recovery in these
tongues is assumed to be small. The solvent bulb may exist as a single large bulb in the case of
a high ratio of vertical permeability to horizontal permeability (kv/kh), or as a series of bulbs
underlying shale streaks.
The VREF, TPV, and THK parameters are set on the TREFFIC keyword for each mobilization
curve.
These parameters are discussed below.
VREF volume scaling

For dimensional scaling, the value of VREF depends on the angle-open-to-flow of both the truth
model injector and the streamline tracer model injector. Consider the case where 1 MMRVB of
solvent is injected into a pattern truth model, and we want to apply the resulting mobilization
curve to a full five-spot in the streamline tracer model. Using dimensional scaling, without
correcting VREF, FrontSim would compute the IOR displacement efficiency based on the front
location in blue (truth model) and use this efficiency for the front location in red (streamline
tracer model), since both have the same amount of solvent injected. Realistically, the
displacement efficiency between the two models should be the same when the front locations
are the same. To align front locations, we should set VREF = 4 VREF TRUTH_MODEL (Figure
17.17).

Figure 17.17 Aligning front locations
Generalizing the above argument, the angle-open-to flow (AOF) should be used to set the VREF
parameter on the TREFFIC keyword as follows:
VREF = VREF TRUTH_MODEL
AOF FIELD
= ---------------------------------------------
-
AOFTRUTH_MODEL
Although one would expect most field injectors to be full injectors, an example of a injector
is an injector that backs up to a sealing fault. In this case, the injected fluid only contacts 180
degrees of the area around the well. Another example is when FrontSim is run to tune the tracer
parameters. If the original finite-difference truth model is a pattern, then one would create a
-pattern, vertically-up-scaled FrontSim version of that model. In that case, = 1 since both
injectors have a 90-degree angle open to flow.
A similar argument holds for entering TPV in TREFFIC:
TPV = TPV TRUTH_MODEL
The TPV value is used for impacting the flood rate on recovery, and is discussed later. FrontSim
uses the following equation to convert injected solvent volumes to dimensionless basis before
computing the efficiency. Dimensionless solvent injected into injector INJ is
INJ
Solv_Inj ( RVB )
Tracer_Slug = -----------------------------------------------------------------------------------
-
THK FIELD
VREF ( RVB ) ---------------------------------------------
-
THK TRUTH_MODEL
Since the truth model volumetrics are used in this equation, the scaling is equivalent to a
dimensional scaling of the truth model results to the streamline tracer model.

Thickness scaling with THK
For dimensional scaling, a special adjustment is used in FrontSim when the reservoir thickness
is different from the value used in the truth model. Consider the truth model below, in which
1MMRVB of solvent has been injected. Using dimensional scaling, without correcting THK,
FrontSim would compute the IOR displacement efficiency based on the front location in blue
(Truth Model) and use this efficiency for the front location in red (streamline tracer model),
since both have the same amount of solvent injected. Realistically, the displacement efficiency
between the two models should be the same when the front locations are the same.
Figure 17.18 Example of aligning front locations with the THK parameter
To align front locations, FrontSim internally scales VREF by the ratio of the reservoir thickness
at the injector in the streamline tracer model to the reservoir thickness at the injector in the truth
model. While FrontSim knows the reservoir thickness at each injector in the streamline tracer
model, the thickness of the truth model must be supplied as the THK parameter in the TREFFIC
keyword.
RANKWELL parameters for dimensional Scaling

There are also TPV, VREF and THK values that appear in the RANKWELL keyword for each
injector. For dimensional scaling, it is important that the default values are chosen for these, as
shown below. The default, global values are those set in the TREFFIC keyword.
Summary of dimensional scaling

The mobilization curve is always entered in dimensionless form. The normalizing volume for
the mobilization curve is VREF TRUTH_MODEL, which can be HCPV, TPV or any other basis.
For dimensional scaling, the basis is irrelevant so long as the same basis is used for specifying
VREF in the TREFFIC keyword. VREF and VREF TRUTH_MODEL are related by the ratio of
angles-open-to flow ( ). FrontSim internally adjusts VREF for differences between the truth
model and the streamline tracer model in reservoir thickness at the injector locations. The key
parameters are set with TREFFIC.
The corresponding TPV , VREF , and THK parameters in the RANKWELL keyword should be
simply defaulted as discussed previously.

Dimensionless scaling with user-determined VREF
Dimensionless scaling follows the traditional type of curve approach used in throughput-based
tools. To use this approach, one must decide if the mobilization curve is to be scaled on the basis
of HCPV, TPV, DEPV, or on some other basis. The choice is entered in the VREF parameter.
Once the dimensionless mobilization curve is created, the truth model values for VREF are not
used again. As before, the default, global values are those set in the TREFFIC keyword.
FrontSim computes the dimensionless solvent injected based on the streamline tracer model
values of VREF entered by you, where the dimensionless solvent injected into injector INJ is
given by
INJ
Solv_Inj ( RVB )
Tracer_Slug = --------------------------------------------------------------------------------------------------
-
INJ THK FIELD
VREF FIELD ( RVB ) ----------------------------------------------
THKTRUTH_MODEL
INJ
Here, VREFFIELD and THK FIELD values are entered in the RANKWELL keyword for every injector
in the field. TPVFIELD values are also entered so that FrontSim can convert flood rates to the
fractional TPV/year.

The IOR model simulation output
IOR rates
The IOR tracer model is a two-phase model, the simulations of which predict water flood oil
recovery using traditional techniques, that is relative permeability curves. The IOR tracer logic
superimposes tracer flow along the streamlines that were generated by water flood calculations.
These tracers represent the flow of IOR oil, solvent and lean-gas. Thus, the concentration of
these produced tracers must be converted to flow rates using the appropriate tracer formation
volume factors with the TPVT keyword. Note, converting these tracers to volumetric quantities
means that their volumes must be subtracted-out from the water flood calculations in order to
conserve mass. Thus, we treat water as the swing variable and subtract the produced tracer
volumes from this water in order to compute the actual water production rate. Formulas given
in this section are valid only for volume definitions for the reserved IOR logic tracers T1
through T9. A description of the key parameters and concepts as related to the IOR tracer logic
is given in the following sections.
OOIP
OOIP in IOR tracer model is no different from any other two-phase models, although the initial
trapped IOR oil is in the form of the adsorbed IOR tracer T2. This is initialized by default using
the TADE keyword, or explicitly by using the TIADST2 keyword.
Pore Volume (PV) and Reference Volume (VREF)

Pore volume is used to normalize the tracer slug injection, which is then converted into injected
tracer concentration. PV can normally be either HCPV or DEPV. You are advised to be
consistent in using the type of normalization volume. HCPV is a variable linked to a given
injector and producer pattern. The HCPV value can be found in the ALLOC file output, and can
be defined using the RANKWELL keyword for the injector. VREF is the volume for referencing
the mobilization curve efficiency. This volume can also be chosen to be the hydrocarbon pore
volume (HCPV), the displaceable EOR/IOR pore volume (DEPV) or the total pore volume
(TPV). We note that the TPV is also a referencing volume associated with the truth model when
determining changes due to throughput rates.
Using water as swing variable to convert tracer

rates to water, oil and gas rates
The following rate conversion explanation assumes an MWAG process in which the field unit
is used. The general IWAG and MWAG case is an extension of the same rate reporting method.
A complete description of the reporting variables are listed in the tables given in "IOR
Reporting Rates" on page 187.
Injection rates
In order to use water as a swing variable, the volume of MI solvent gas injection is converted
into equivalent water volume, which is added to the total water injection ( rvb
-------- ):
d

( WWIR B w + WSIR B_T1_I )
WWIR = --------------------------------------------------------------------------------
-
Bw
WWIR is the true water injection rate and WSIR is the rate of MI solvent injected. Injected MI
solvent is then split into effective and ineffective portions, whose concentrations are defined as
WTCTi = (------------------------------------------
WSIR B_ Ti_I )-
WWIR B w
with I = 1 or 3.
Hence the MI solvent injection rate (Mscf/d) is:
WTCT1 ------------------- ( WWIR B w )

+ WTCT3
-------------------
B_T1_I B_T3_I
This is the MI injection volume equivalent to water (swing variable).
Production Rates
We first define the well total liquid production rate as
WVPR = WOPR Bo + WWPR B w
This is the total amount of oil and water produced.

Thus, the actual water production rate (stb/d) is
WWPRCORR = WWPR ( WTCT1 + WTCT2 + WTCT3 ) WVPR ,

-------------------------------------------------------------------------------------------------------------------------
Bw
obtained by removing the tracer production rate (stb/d) (------------------------------------------------------------------------------------------------------

WTCT1 + WTCT2 + WTCT3 ) WVPR
B w
from WWPR .
The solvent production rate, both effective and ineffective, in gas units (Mscf/d), is given by
-------------------- WTCT3- WVPR .

WTCT1 --------------------
B_T1_P- + B_T3_P
By using water as the swing variable, it is possible that the produced water rate becomes
negative if a large amount of tracer is produced compared with the produced water volume. This
is solved by thresholding negative values of water production to zero. However, in this case, the
water material balance will not be correct when integrated over the life of the process.
The volume of produced IOR tracers is expressed as a fraction of the total RVB rate. The IOR
oil production rate (stb/d) is
WTCT2 WVPR- .
WOPRIOR = -----------------------------------------
B_T2_P
FrontSim uses B w to convert all tracer volumes to standard conditions. The cumulative oil
produced (stb) is
WTPTT2 B w
WOPT + ----------------------------------- ,
B_T2_P

where WTPTT2 is the IOR production rates in equivalent water volumes. The term WTPTT2 Bw
WTPTT2 B w
converts this volume back to RVB, and the term ------------------------------------
B_T2_P
- converts this to oil rate using
FVF. Similarly, the cumulative solvent produced (Mscf) is given by
WTPTT1 ----------------------- B w .
- + WTPTT3
----------------------
B_T1_P B_T1_P
You may choose to compute additional IOR variables by adopting the above methods, and by
using the existing reporting variables listed the tables given in "IOR Reporting Rates" on
page 187.
IOR Reporting Rates

The IOR tracer simulation model outputs report variables in four categories. The first is the
general rates for injectors and producers in the summary file, the second is the report of solvent
allocation logic for injectors in the files with .FacilityOut and .PRT suffix, the third is the
report of facility logic for producers in the .FacilityOut and .PRT files, and finally the
fourth is the report of cell variables in the RESTART files. A subset of well rates reports is
available for the Group and Field variables.
Table 17.8 Rates reported in the SUMMARY file at the specified time steps
Variable Description Unit

WTCTi Well Tracer Concentration of tracer i (i = 1, 2,... up to 9.) none
WTPTi Well Tracer Initial In Place Tracer Number Ti SM3/D - STB/D
WTITTi Well Tracer Cumulative Injection for Tracer Number Ti SM3/D - STB/D
WTPTTi Well Tracer Cumulative Production for Tracer Number Ti SM3/D - STB/D
Note Variables in Red are treated as primary variables in the IOR formulas. Rates in Bold
(or Bold) are reporting in the group and field levels. PVT properties in Blue are IOR
only and read in through the TPVT keyword.
PVT properties are read in from the input data. You should be aware that using small values for
the B_T#_I and B_T#_P formation volume factors might lead to inconsistencies in mass
balance calculations.
Table 17.9 PVT properties are also treated as input variables
Variable Description Unit Info

Bo Oil Formation Volume Factor for Water Flood Oil RM3/SM3 - RVB/STB Defined in PVTO
Bw Water Formation Volume Factor RM3/SM3 - RVB/STB Defined in PVTW
Rs Solution-Gas/Oil Ratio from Water Flood Oil SM3/SM3 - MSCF/STB Defined in RSCONSTT

Table 17.9 PVT properties are also treated as input variables (Continued)
Variable Description Unit Info

B_T#_P Formation Volume Factor for tracer T# when produced RM3/SM3 - RVB/MSCF Defined in TPVT
B_T#_I Formation Volume Factor for tracer T# when injected RM3/SM3 - RVB/MSCF Defined in TPVT
RS_T# Solution-Gas/Oil Ratio for tracer T# (only required for IOR SM3/SM3 - MSCF/STB Defined in TPVT
oil tracer T2)
Table 17.10 Formulae to be used for computing the total well rates of the IOR tracer variables
TOTAL RATES
Variable Description Units
WWPR Well Water Production Rate SM3/D - STB/D
WWIR* Well Water Injection Rate at reservoir RM3/D - RVB/D
conditions
WVPR = ( WOPR B o ) + ( WWPR B w ) Well Volume Production Rate at reservoir RM3/D - RVB/D
conditions (Oil + Water)
WVIR Well Volume Injection Rate at reservoir RM3/D - RVB/D
conditions (Oil + Water)
Table 17.11 Formulae to be used for computing the oil well rates of the IOR tracer variables
OIL RATES
WOPR Well Oil Production Rate from Waterflood SM3/D - STB/D
Oil
WOPR IOR = WTC T2 WVPR ( B_T2_P ) Well Oil Production Rate from IOR Oil SM3/D - STB/D
WOPR TO = WOPR + WOPR IOR Well Oil Production Rate from all Sources of SM3/D - STB/D
Oil
Table 17.12 Formulae to be used for computing the gas well rates of the IOR tracer variables
GAS RATES
WGPR Well Gas Production Rate from Solution Gas SM3/D - MSCF/D
from Waterflood Oil.
WGPRIOR = WOPRIOR RS_T2 Well Gas Production Rate from Solution Gas SM3/D - MSCF/D
from IOR Oil
WGPRRTS = ( WTCT8 WVPR ) B_T8_P Well Gas Production Rate from Returned- SM3/D - MSCF/D
Trapped-Solvent

Table 17.12 Formulae to be used for computing the gas well rates of the IOR tracer variables (Continued)
GAS RATES
WGPRES = ( WTCT1 WVPR ) B_T1_P Well Gas Production Rate from Effective- SM3/D - MSCF/D
Solvent
WGPRIES = ( WTCT3 WVPR ) B_T3_P Well Gas Production Rate from Ineffective- SM3/D - MSCF/D
Solvent
WGPRTS = WGPRRTS + WGPRES Well Gas Production Rate from All Sources SM3/D - MSCF/D
+ WGPRIES of Solvent
WGPRRTLG = ( WTCT5 WVPR ) B_T5_P Well Gas Production Rate from Returned- SM3/D - MSCF/D
Trapped-Lean-Gas
WGPRELG = ( WTCT4 B_T4_P + WTCT 7 Well Gas Production Rate from Effective- SM3/D - MSCF/D
B_T7_P ) WQR Lean-Gas
WGPRIELG = ( WTCT6 B_T6_P + WTCT9 Well Gas Production Rate from Ineffective- SM3/D - MSCF/D
B_T9_P ) WQR Lean-gas
WGPRTLG = WGPRRTLG + WGPRELG + Well Gas Production Rate from All Sources SM3/D - MSCF/D
WGPRIELG of Lean Gas
WGPRTG = WGPR + WGPRIOR + WGPRTS + Well Gas Production Rate from All Sources SM3/D - MSCF/D
WGPRTLG of Gas
WGIRES = WTCT1 WWIR BW B_T1_I Well Gas Injection Rate from Effective- SM3/D - MSCF/D
Solvent
WGIRIES = WTCT3 WWIR BW B_T3_I Well Gas Injection Rate from Ineffective- SM3/D - MSCF/D
Solvent
WGIRTS = WGIRES + WGIRIES Well Gas Injection Rate from All Sources of SM3/D - MSCF/D
Solvent
WGIRELG = ( WTCT4 B_T4_I + WTCT7 Well Gas Injection Rate from Effective-Lean- SM3/D - MSCF/D
BT_T7_I ) WWIR BW Gas
WGIRIELG = ( ( WTCT6 ) B_T6_I + ( WTCT9 ) Well Gas Injection Rate from Ineffective- SM3/D - MSCF/D
B_T9_I ) WWIR BW Lean-Gas
WGIRTLG = WGIRELG + WGIRIELG Well Gas Injection Rate from All Sources of SM3/D - MSCF/D
Lean Gas
WGIRTG = WGIRTS + WGIRTLG Well Gas Injection Rate from All Sources of SM3/D - MSCF/D
Gas
Table 17.13 Formulae to be used for computing the water well rates of the IOR tracer variables.
WATER RATES
Variable Description
WWPRCORR = WWPR WVPR Well Water Production Rate Corrected for SM3/D - STB/D
( WTCT1 + WTCT2 + ...WTCT9 ) BW Tracer Production
WWIRCORR = WWIR ( 1 W TCT1 Well Water Injection Rate Corrected for SM3/D - STB/D
W TCT2 WTCT9 ) Tracer Injection

Table 17.14 lists reports in the FacilityOut and PRT files for each eligible solvent injector.
Table 17.14 Reporting variables for IOR solvent logic allocation

Well Well name of Eligible Solvent Injector in the
RANKWELL list
HPV Injector HCPV Volume RM3/D - RVB/D
HPVI_Past Cumulative MI Solvent Slug Injection HPV Fraction
MiRate = WVIR WTCT1 Allocated MI Solvent Injection Rate RM3/D - RVB/D

TotRate = WVIR Well Water and Solvent Injection Rate RM3/D - RVB/D
Ratio of Injected Water Rate and Solvent
WAG = (---------------------------------------------------
TotRate MiRate -)
MiRate Rate. Defaults to 999 when Solvent Rate is
0.0
conc1 Injector solvent efficiency, conc1/conc3 are Ratio
Eff = ------------------------------------------
-
( conc1 + conc3 ) well concentrations for tracer 1/3. Initial Eff
= 1.0; Eff does not change with zero well
concentration.
Mi_Past Flag to indicate previous time MI solvent
injection
Mi_Now Flag to indicate current time MI solvent
injection
Status Injector Solvent Allocation Reporting Status
In Table 17.15 variable reports are for the FacilityOut and PRT files, for each eligible
producer. The list includes all producers and could be used to analyze IOR recovery
performance.
Table 17.15 Reporting variables for the facility limit logic
IOR Facility Limit Logic Reporting Variable

Name Well name for active producer
Total = WVPR Total Well Liquid Production Rate (oil and RM3/D - RVB/D
water)
Wat = WVPR BW Water Production Rate RM3/D - RVB/D
WF_Oil ( RES ) = WOPR BO Water Flood Oil Production Rate RM3/D - RVB/D
IOR_OIL ( RES ) = WVPR WTCT2 IOR Oil Production Rate RM3/D - RVB/D
EffMi ( RES ) = WVPR WTCT1 Effective Solvent Production Rate RM3/D - RVB/D
InefMi ( RES ) = WVPR WTCT3 Ineffective Solvent Production Rate RM3/D - RVB/D
EffLeanGas or EffLg = WVPR ( WTCT4 + WTCT7 ) Effective Lean Gas Production Rate RM3/D - RVB/D
InEffLeanGas or InEfLg = WVPR ( WTCT6 + WTCT9 ) Ineffective Lean Gas Production Rate RM3/D - RVB/D
Rtn Lean GAS IWAG or IWGas = WVPR WTCT5 Returned Trapped Lean Gas Rate RM3/D - RVB/D
Rtn Solv IWAG or IWMi = WVPR WTCT7 Returned Trapped Solvent Rate RM3/D - RVB/D

Table 17.15 Reporting variables for the facility limit logic (Continued)
IOR Facility Limit Logic Reporting Variable

C1 , C2 , C3 or WTCT1 , WTCT2 , WTCT3 Concentration for Effective MI (conc1), IOR no unit
Oil (conc2), and ineffective MI (conc3)
Wat_Adj ( RES ) = WWPR WVPR SUM ( WTCTi ) , Water Rate after Adjusting for Tracer RM3/D - RVB/D
for i=1,2,3, up to 9 Production
WF_Oil = WOPR Water Flood Oil Production Rate SM3/D - STB/D

IOR Oil = WVPR WTCT2 BO IOR Oil Production Rate SM3/D - STB/D
EffMi = WVPR WTCT1 ( B_T1_P ) Effective Solvent Production Rate SM3/D - MSCF/D
InEfMi = WVPR WTCT1 B_T3_P Ineffective Lean Gas Production Rate SM3/D - MSCF/D
WF_SolnGas = WOPR RS_T2 Water Flood Oil Solution Gas Rate SM3/D - MSCF/D
IOR_SolnGas = ( WVPR WTCT2 BO ) IOR Oil Solution Gas Rate SM3/D - MSCF/D
RS_T2
WatAdj = ( WWPR WVPR SUM ( WTCTi ) ) ,

BW Water Rate after Adjusting for Tracer SM3/D - STB/D
for i=1,2,3, up to 9 Production
Tot_Oil = WOPR + WVPR WTCT2 BO Total Water Production Rate SM3/D - STB/D
Tot_GAS = WF_SolnGas + EOR_SolnGas Total Gas Production Rate SM3/D - STB/D
+ EffMi + InefMi + EffLg
+ Ing ( efL ) + IWGas + IWMi
WOR = ( WWPR ) ( Tot_Oil ) Water Oil Ratio Ratio

GOR = Tot_GAS Tol_Oil Gas Oil Ratio Ratio - MSCF/STB
Table 17.16 Reporting variables in each cell at specified reporting time steps
Variables reporting in each cell/streamline

Variable Description Note
Ti_CONC Cell Concentration, for (i= 1, 2, ... up Available to view with
to 9.) streamline
Ti_ADS Cell Absorbed Concentration, for (i = 1, 2,...
up to 9.)
Ti_SUMC = Ti_CONC + Ti_ADS Cell Total Concentration, for (i = 1, 2, ... up
to 9.)
Working with the output

You may benefit from running a sample input data set, for example, named tracer.data. To gain
better understanding of the IOR tracer model, the following steps are suggested:
1 Open tracer.data and look through tracer keywords and well specifications.
2 Run tracer.data

3 Open GridSim and view trapped solvent saturation and IOR oil saturation with time.
4 Open Graphs and view cumulative IOR oil production.
5 Rerun simulation and double solvent slug-size.
6 Open both cases in GridSim and see if cumulative IOR oil has doubled.
7 Rerun simulation and double rate.
8 Open this and original case in GridSim and look at rate impact.
9 Rerun simulation and change WAG ratio.
10 Open this and original case in GridSim and look at impact on timing.
Hint You can use ECLIPSE Office as an alternative to GridSim while working with the
output.
Quality-checking results
Material balance errors
A source of mass balance error may originate from a fast traveling tracer. This can occur when
small APV values are used, resulting in the IOR tracer travelling from the injectors to producers
within a very short space in time. It is possible that the tracer could travel from the injectors to
the producers within one time step. You may choose to use smaller time step in order to reduce
this type of error.
Tracer Compressibility
IOR tracers were originally designed to work with incompressible FrontSim IOR tracer models.
However, most of recent runs are based on IOR tracer models that is compressible. This use may
cause errors in the tracer mass balance, when large compressibility is used.

Tensor Permeability
Chapter 18
Introduction
Full tensor permeabilities are often required to describe complex reservoirs. Given a detailed
ECLIPSE 100
x ECLIPSE 300
heterogeneous reservoir description at the geological scale, upscaling is normally carried out to
SPECIAL reduce the model size to one suitable for reservoir simulation. These upscaling procedures will
x FRONTSIM generally create full tensor permeabilities, even if the permeabilities in the fine geological grid
are not represented as tensors. Full tensor permeabilities also arise in complex cross-bedded
systems where the dip directions will not in general coincide with a local coordinate direction.
A further case for full tensor permeabilities is in the modeling of fractured systems.
Conventionally, reservoir simulators ignore the full tensor nature of the absolute permeability
and assume the permeability can be represented by a diagonal tensor whose principal axes
coincide with the local coordinate axes. This allows the construction of the usual 5 point
discretization in 2D or 7 point in 3D which can be solved efficiently in the simulator.
Introduction of a full tensor permeability extends the stencil of the discretization scheme to 9
points in 2D and either 19 or 27 points in 3D.
FrontSim allows a full tensor description of the absolute permeability. The permeability tensor
may either be supplied by a pre-processor by upscaling the properties on the geological model,
or else it may be entered by keywords PERMXX, PERMYY, PERMZZ (which describe the
diagonal components) and PERMXY, PERMYZ, PERMZX to describe the off-diagonal
components.
Only positive definite symmetric tensors are allowed in the simulator. The principal directions
of the tensor must also be supplied. At present, the options are
1 the directions for the components of the tensor are aligned with the Cartesian axes.
The permeability tensor can be expressed as
k xx k xy k xz
K = k yx k yy k yz [EQ 18.1]
k zx k zy k zz
where by symmetry
FrontSim Technical Description Tensor Permeability 193

Introduction
k yx = k xy , k zy = k yz , k zx = k xz . [EQ 18.2]
In FrontSim, the coefficients are entered as

k xx =PERMXX, k yy =PERMYY, k zz =PERMZZ, k xy =PERMXY, k yz =PERMYZ and k zx =PERMZX.
Note FrontSim also accepts non-symmetric tensors although this might not be physical. The
user can supply a PERMYX different from PERMXY. If only PERMXY is entered,
FrontSim will assume symmetry by setting PERMYX=PERMXY.
The flow equations arising from the permeability tensor description are constructed using a
Multipoint Flux Approximation (MPFA). The transmissibilities are calculated by the control
volume discretization due to Aavatsmark et al. - see [Ref. 31] for details. The MPFA can only
be used in corner point geometry, not block centered geometry.
The discretization scheme is selected by the FDM9PNT keyword. The MPFA is a rigorous
treatment of both cell non-orthogonality and tensor permeability. Even for a diagonal isotropic
tensor, the MPFA will generally lead to a 9-point discretization in 2D in order to remove the bias
of grid non-orthogonality and grid orientation effects.
194 Tensor Permeability FrontSim Technical Description

Introduction
Discretization
Figure 18.1 Stencil for MPFA flow in 2D between cells (i,j) and (i+1,j)
C (i,j+1) D (i+1,j+1)
(i-1,j+1)
A B
(i-1,j) (i,j) (i+1,j)
E F
(i-1,j-1) (i,j-1) (i+1,j-1)
The standard two-point flow between cells A=(i,j) and B=(i+1,j) for the corner point grid in
Figure 18.1 can be written for a component c embedded in a phase p ( P = o, w, g ) as
c c
F pAB = T AB M pAB dP pAB [EQ 18.3]
where
TAB is the two-point transmissibility between cells A and B
c
M pAB is the generalized mobility of component c in phase p
and
dPpAB is the potential difference of phase p between cells A and B, given by
dPpAB = PA P B pAB G ( D A D B )
and where
Pcp is the capillary pressure for phase p
p is the mass density of phase p

G is the acceleration due to gravity
D is the cell centre depth.
c
Alternatively, the MPFA constructs the flow F pAB which depends on steering terms from the
neighboring cells C, D, E and F in Figure 18.1 as

Discretization
c c
F pAB = M pAB T AB dP pAB +
TAS dPAS [EQ 18.4]
S
where the summation is over steering transmissibilities S between cells AC, AD, AE and SF.
c
The mobility M pAB is evaluated in the upstream cell (A or B) according to the direction of flow
in [EQ 18.4].
The steering potential differences dPAS are evaluated using pressures and capillary pressures
for cells A and S but using the density term AB for the primary flow coefficient, so that
dPpAS = PA P S pAB G ( D A D S ) [EQ 18.5]
The transmissibilities T AB and T AS are calculated following the procedure described in [Ref. 31]
when the permeability K is a full tensor.
Note that the flows between adjacent cells depend on steering terms from adjacent cells.
Similarly in 3D, the flow between any two cells may depend on up to 16 steering
transmissibilities and this leads to a 19 or 27 point scheme.
In the present version of FRONTSIM, the MPFA transmissibilities are not calculated across
faults, but the two-point connections are used instead (see "Transmissibility Calculations" on
page 249).
If the FDM9PNT keyword is used without supplying off diagonal tensor permeabilities PERMXY,
PERMYZ and PERMZX, these terms are taken to be zero and the MPFA scheme is applied with
the diagonal tensor K =diag(PERMX,PERMY,PERMZ) in the specified basis.

Discretization
Orthogonality error
The MPFA or nine point discretization reduces to a standard two point flux scheme (that is, a
five-point scheme in 2D or a seven-point scheme in 3D) if the grid is sufficiently orthogonal.
For example, the MPFA discretization reduces to 5 or 7 points when both
1 the grid system is orthogonal and
2 the permeability tensor K is diagonal.
In general, when the grid is either non-orthogonal or K is a full tensor then a 9-point (2D) or 27
point (3D) discretization results. It is possible to control the application of the MPFA scheme
based on a cell orthogonality error indicator. Essentially for grids which are nearly orthogonal
it is desirable to apply the MPFA discretization only in regions of high non-orthogonality to
reduce the CPU cost. In the context of a full tensor permeability, an orthogonality indicator can
be defined as follows:
Figure 18.2 K-orthogonality error indicator
a2
K1 A K2
a1
Q
Consider an interface PQ between two cells 1 and 2. The permeabilities in each cells are K 1 and
K2 . The directed area normal on the interface is denoted by A . Let a 1 and a 2 be the vectors
joining the midpoints of opposite faces of the cells. We call a 1 and a2 the covariant basis
vectors. Define the contravariant basis vectors a1 and a 2 with the condition that
j
a i a = ij
where ij is the Kronecker delta.

Now consider a potential gradient in cell 1,
j a
j
=
j=1
The flux through PQ from cell 1 is therefore
2
j
f = A K = j A K a
j=1
where accounts for the mobility.

Orthogonality error
Since this expression can be used for arbitrary values of j , it follows that if A K is parallel
2
to a1 , such that AKa = 0 , then the flux depends only on the gradient in the covariant
direction a 1 and implies that a two point discretization can be employed.
The grid is said to be K-orthogonal (see [Ref. 30] and [Ref. 31]) when A K is parallel to a1 .
A convenient measure of orthogonality error for an interface is therefore
[ ( A K ) a 1 ]a 1
= A K -------------------------------------- AK
a1 a1
This is evaluated separately for each of the two cells adjoining the interface A . The maximum
of these two values provides a measure of the departure from orthogonality for the interface,
that is, the departure from a two point flux approximation for this interface.

Orthogonality error
The Oil/Water Front Tracking
Saturation Solver Chapter 19
The Front-Tracking Method

For two-phase cases the front-tracking method is the default method for solving the saturations
ECLIPSE 100
ECLIPSE 300
in FrontSim.
SPECIAL This method originated in the theory for one-dimensional scalar conservation laws. A general
x FRONTSIM
description of this topic can be found in Smoller [Ref. 14]. The method used in FrontSim was
first proposed by Dafermos[Ref. 15] and developed for reservoir simulation in the 1980s
(Bratvedt et al. [Ref. 1], [Ref. 2].). This method allows for general initial values and boundary
terms. In addition, there are no timestep length limitations. All physical shocks can be computed
exactly without numerical smearing in one dimension.
This method fits very well into the streamline concept where the numerical methods used to
solve for the saturations are applied in 1D along the streamlines/gravity lines. Due to its speed
and lack of numerical dispersion it is very well suited for two phase simulation models.
The saturation equation for two phases reads:
( i S i )
- + ( i Fi ) = 0
------------------- [EQ 19.1]
t
i is the density of phase i
Si is the saturation of phase i
is the porosity
To account for the gravity, we need to rewrite the equation slightly by separating the gravity and
convective terms. For incompressible flow we can then rewrite the equation as:
( S ) + ( F ) + ( G ) = 0 [EQ 19.2]
t i i i
where the two-flux terms are defined by
Fi = fi vt [EQ 19.3]
FrontSim Technical Description The Oil/Water Front Tracking Saturation Solver 199
G i = fi i Ddg [EQ 19.4]
fi is the fractional flow of phase i
vt is the total Darcy velocity
i is the mobility of phase i
D is the change in depth
d is the density difference between the phases
g is the gravity vector
We can now use the operator splitting concept (Bratvedt et al. [Ref. 16]) for the following
equations:
S 1
-------i + --- ( F i ) = 0 [EQ 19.5]
t
S 1
-------i + --- ( G i ) = 0 [EQ 19.6]
t
[EQ 19.5] models the convective flow without gravity and is solved by the front-tracking
method as described below. [EQ 19.6] models the gravity segregation of the fluids. The gravity
vector in [EQ 19.4] is of course constant and known, so the counter-parts to the streamlines, the
gravity lines, always are defined. [EQ 19.6]can also be solved using the front-tracking method.
Assumptions
Piece-wise constant initial saturation.
One of the assumptions for the front-tracking method is that the initial saturation must be piece-
wise constant. This is always the case in FrontSim where the initial condition is saturations that
are constant for each grid cell.
Piece-wise linear flow-function.

The flow-function (F and G) must be piece-wise linear. In FrontSim the flow-function is
computed for a set of saturation points and assumed linear between these points. For a water-oil
case this means that the user-defined water saturation values in the relative permeability
functions are taken to be the sampling points for the flow-function. Any saturation between
these points will be linearly interpolated.
Streamline solution
Let us first show two examples on how the front-tracking algorithm works.
The first example is for the flow-function along a streamline while the second is for a gravity
segregation step on a gravity line.
On a streamline the flow-function will basically be the fractional flow function. For a water-oil
case the fractional flow ( f w )is defined as:
200 The Oil/Water Front Tracking Saturation Solver FrontSim Technical Description
fw = w ( w + o )
w = k rw w, o = k ro o
[EQ 19.7]
k ri is the relative permeability of phase i
i is the viscosity of phase i
Figure 19.1 Fractional flow function approximated by a continuous piece-wise linear function
V4-
V34
f V4 f
V23
V3-or
V12
Vfront
Vwc-1 V2-or
V1-or
Swc S1 S2 S3 S4 Sor Sw Swc S1 S2 S3 S4 Sor Sw
In Figure 19.1, the fractional flow function is the blue dotted line. Five linear segments have
approximated this function as piece-wise linear. The relative permeability is defined in six
points (Swc, S1, etc.). This approximation yields a piece-wise constant saturation function, the
red line in the figure.
Figure 19.2 Initial saturation at time t1 Figure 19.3 Saturation at time t2 with flow from left to right
S S
Sor
Time = t2
Vt
S4
V4
S3
Time = t1
Vfront
X Swc X
For example, given the initial saturation as shown in Figure 19.2 and the fractional flow-
function shown in Figure 19.1, the saturation profile along a streamline would look like the one
in Figure 19.3 after a given time, if the flow direction (Vt) is from left to right.
Figure 19.4 Saturation at time t3 with flow direction from Figure 19.5 Saturation at time t4 with flow direction from
right to left right to left
S S
Sor
Time = t3 Sor
Time = t4
V1-or
S4 Vt S3 Vt
V34
S3 V23
V23
S2 S2
V12 V12
S1 S1
Vwc-1 Vwc-1
Swc X Swc X
If the flow direction (vt) changes at time t3 the saturation profile is shown in Figure 19.4. In this
case, the lower envelope decides the size of the saturation fronts and their velocity. Initially,
after the change of direction, the saturation profile breaks into fronts with the front between S2
and S3 moving with highest velocity. When this front catches up with the front between S3 and
S4 they merge into a saturation front between S2 and S4, but with a slower velocity than the S1
to S2 saturation front. Eventually the S2 to S4 front and the S1 to S2 front merge into a front
between S1 and S4, which moves faster than the Swc to S1 saturation front. This situation is
shown in Figure 19.7 at time t6.
Figure 19.6 Saturation at time t5 with flow direction from Figure 19.7 Saturation at time t6 with flow direction from
right to left right to left
S S
Sor
Time = t5 Sor
Time = t6
Vt V1-or Vt
V2-or
S2
S1
V12
S1 Vwc-1
Vwc-1
Swc X Swc X
From these examples, we can see that the shape of the fractional-flow function determines the
shape of the saturation profile over time. The concept can use any type of fractional-flow
function.
The approximation points on the continuous piece-wise linear approximation function can, of
course, be varied to suit the accuracy required. The smooth parts of the saturation distribution
can also be modeled with many small physical shocks, if needed.
Gravity line solution
For the gravity segregation problem, that is, along the gravity lines, the equation for oil water
segregation reads:
S w
--------- + G w = 0
t
where G is defined as:
G w = fw ( o w ) o g
Figure 19.8 Water above oil
w
g
Let us assume we have a initial situation where water sits on top of the oil (Figure 19.8). We
want to see how this situation will evolve using the front tracking method.
Figure 19.9 Linear relative permeability curves Figure 19.10 Linear flow function
kw ko fw
1.0 1.0
Viscosity of oil &
water = 1.0
Sw Sw
1.0 1.0
Figure 19.11 Linear flow function multiplied by linear oil relative permeability and negative density difference
Gw
1.0
Sw
1.0
-0.5
For simplicity, let us use the linear relative permeability curves shown in Figure 19.9, and
assume viscosities at 1.0 for both oil and water, which result in the flow function shown in
Figure 19.10. If we then assume the water density is 1.0 and the oil density is 0.5 the difference
is -0.5. Multiplying the linear flow function with the linear oil relative permeability and the
negative density difference will result in the gravity flow function seen in Figure 19.11.
Figure 19.12 Gravity flow function with negative density Figure 19.13 Gravity flow function with negative density
difference: initial fronts difference: after front collisions
Gw Gw
V06 V06
S1 S2 S3 S4 S1 S2 S3 S4
Sw Sw
1.0 1.0
-0.5 -0.5
V1 V5
V2 V03
V3 V4 V51 V52
V04
Initial fronts are shown in red New fronts after front collisions
are shown in blue
For the example we have divided the saturations into five equally spaced parts. As before, we
find the velocities for each saturation front.
Initial fronts are shown in red in Figure 19.12, and new fronts after front collisions in blue in
Figure 19.13. The X-axis is positive in the direction of gravity.
Figure 19.14 Gravity flow saturation, Figure 19.15 Gravity flow saturation, Figure 19.16 Gravity flow saturation,
distribution, initial distribution, snapshot after time t1 distribution, snapshot after time t2
Sw Sw Sw
1.0 1.0 V5 1.0 V51
S4 S4 V4 S4 V4
S3 S3 S3
S2 S2 V2 S2 V2
V04
S1 S1 V1 S1
X X X
Figure 19.17 Gravity flow saturation Figure 19.18 Gravity flow saturation Figure 19.19 Gravity flow saturation
distribution, initial distribution, snapshot after time t1 distribution, snapshot after time t2
Sw Sw Sw
1.0 V52 1.0 V52 1.0
S4 S4 S4
S3 S3 S3
S2 S2 S2
V03 V04
S1 S1 S1
X X X
When water starts moving up and oil down, there are fronts moving in both directions. In Figure
19.14 we can see the initial situation, water to the left (on top) and oil to the right of the initial
front. In Figure 19.15, a snapshot after time t1, the fronts are moving upwards and downwards
according to the gravity flow function in Figure 19.12 and Figure 19.13. When the first front
(V1 / V5) hits the no flow boundaries at the top and bottom, a front reflects back from the
boundary.
In Figure 19.17 we see a snapshot at the left when fronts V4 and V04 have collided and formed
the front V03. In Figure 19.18 is a new snapshot before the two main fronts collide, and in Figure
19.19 the oil is on top and the water is on the bottom.
If we have higher resolution of points on the saturation function, the saturation distribution will
be smoother.
Front events
The FrontSim two-phase front tracker can handle any initial saturation distribution and is not
restricted to the number of fronts or the number of points on the saturation function. Increasing
the number of points on the saturation function (relative permeability) might slow down the
simulation. During a timestep the front-tracking algorithm will handle a large number of events
of collisions of fronts and fronts hitting the wells. Each event can either increase or decrease the
number of fronts. The timing of these events is continuous through the timestep, and the solver
will continue until there are no more events for the remainder of the simulation timestep.
The Pressure Equation
Chapter 20
Introduction
FrontSim is an IMPES (IMplicit Pressure Explicit Saturation) simulator. That is, we solve a
ECLIPSE 100
ECLIPSE 300
pressure equation in which all the terms that depend on saturation are evaluated at the initial
SPECIAL saturation and where the spatial derivatives of the pressure are evaluated using the pressure at
x FRONTSIM the end of the time step.Although IMPES is potentially unstable, it may be used on easy
problems such as history matching applications where the timesteps are usually small.
The Implicit pressure is a non-linear equation and is solved using a Newton Raphson method.
The Newton Raphson itself results in a system of linear equations which are solved using
Algebraic Multi-Grid equation solver.
FrontSim Technical Description The Pressure Equation 207

Introduction
Pressure Equation
The pressure equation that FrontSim solves is given below.
P
f ( P ) = t + c o o P + c w w P + c g g P + Q C T ------ [EQ 20.1]
t
where
1 dB ( B g R v B o ) d R
c o = ------ --------o- + ---------------------------- --------s ,
B o dP ( 1 R v R s ) dP
1 dB ( B o R s B g )- d R
c g = ------ --------g- + --------------------------- --------v ,
B g dP ( 1 R v R s ) dP
1- d---------
c w = ------
Bw
- ,
B w dP
and
t = o + + g ,
and where for each phase p (that is, for subscripts o, w and g):
p = p ( P p g d ) and
kkrp
p = ---------
-
p
where:
k is the permeability of the rock
k rp is the relative permeability of phase p
p is the viscosity of phase p
p is the density of phase p
Bp is the formation volume factor of phase p
Rs and Rv are respectively the dissolved gas and vaporized oil
P is the oil phase pressure
is the porosity
CT is the rock compressibility
and
Q consists of the source and sink terms arising from wells.
208 The Pressure Equation FrontSim Technical Description

Pressure Equation
Equation Solution Method
Newton Raphson Method

The pressure equation above is non-linear as many of the coefficients depend on the value of
the pressure we are trying to calculate.
The solution we require is given by f ( P ) = 0 . We obtain this using the Newton Raphson method.
This is an iterative technique, where the (n+1)th estimate of the pressure is obtained from the
nth estimate by the following equation:
f(P) -
Pn = P n + 1 ---------------------- [EQ 20.2]
df ( P ) dP
since we have one pressure value for each cell and each cell is coupled to its neighbor by the
flow, the gradient of the function df ( P ) dP is a n n matrix where n is the number of active
cells in the model, and P and f ( P ) are vectors of length n .
Multigrid linear solver.

The Newton Raphson method described above allows us to swap a set of n non-linear equations
for a set of n linear equations.
The linear solver for the pressure equations is based on the SAMG solver developed by the
Fraunhofer Institute of Algorithms and Scientific Computing (SCAI). It is a Krylov subspace
method (conjugate gradient, GMRES, or Bi-CGSTAB) preconditioned by an algebraic
multigrid method. Algebraic multigrid works by combining two basic processes with
complementary properties. The first process smoothing is achieved by applying a classical
iterative scheme, such as Gauss-Seidel or incomplete LU factorization, to the system of
equations. The second process coarse grid correction is implemented by solving the defect
equation for a subset of the unknowns, and then interpolating the error to the full set of
unknowns. If the initial error was already smooth this process is highly effective. In fact the
combination of both processes yields a convergence rate independent of the number of
equations and is optimally efficient. The algorithm is implemented recursively, with the reduced
set of equations itself being solved by smoothing and coarse grid correction.
In SAMG the definition of the required sequence of reduced unknown sets, and the operators to
transfer data between them, are all generated automatically. These are based on the coefficients
of the original matrix, represented in sparse compressed-row format.
Convergence Criteria
The convergence criteria for both the linear and the non-linear solver are controlled by the
keyword TUNEFSPR. These controls fall into two categories.
First, the user can set a maximum number of iterations for both the linear and the non-linear
solver beyond which FrontSim will accept the solution. Care should be taken when accepting
un-converged solutions, as the results may not be accurate.
FrontSim Technical Description The Pressure Equation 209

The second set of controls is based on how quickly the solution is changing. The linear norm is
given by
L = ( 100 Abs ( p ) ) ( p )
where p is the sum of the absolute changes in the pressure estimate as a result of the current
linear iteration, divided by the sum of the current estimate of the pressure.
The non-linear norm is given by
NL = ( 100 Abs ( P ) ) ( P )
where P is the sum of the absolute changes in the pressure estimate as a result of the current
non-linear iteration, divided by the sum of the pressure at the beginning of the time step.
210 The Pressure Equation FrontSim Technical Description

Multicore Parallel Option
Chapter 21
Introduction
This chapter describes the Parallel Multicore option, which is a separately licensed extension to
ECLIPSE 100
ECLIPSE 300
FrontSim.
SPECIAL
x FRONTSIM
Note From the 2008.1 version of FrontSim the following modifications to parallel multicore
licensing is in place:
A new keyword GEOFLOFS for conducting incompressible simulations using parallel
multicore without requiring parallel multicore licenses is available. For all other
parallel simulations on more than 2 cores require additional parallel multicore licenses.
The base FrontSim license will automatically support up to 2 cores in parallel.
The Parallel Multicore option allows the simulation of a single data set to be explicitly split up
into multiple threads on a single shared memory parallel architecture computer with multiple
processors and/or cores. This implies that all the processors access the same physical memory.
Typically, such machines include the new multicore laptop computers, desktop PCs and high
performance workstations. The availability of 64-bit operating systems and large amounts of
installed memory means that fairly high resolution models can be simulated on simple personal
computing hardware.
Note The parallel multicore option is by design not available for cluster computing using
multiple processes and process interconnect.
In contrast to ECLIPSE, there is no decomposition of the model into separate processes.

The FrontSim Parallel Multicore option allows large high resolution models to be simulated
much faster than is possible with the standard simulator. The streamline solution is naturally
parallel as each individual streamline can be solved independently on a separate processor. At
least for the streamline solution portion the scalability is linear.
FrontSim Technical Description Multicore Parallel Option 211

Introduction
Currently, the saturation solver is multithreaded and the option is supported only on Windows
PC platforms. Parallel Multicore option is only compatible with the EXPL solver, which is the
default for 3-phase problems. For 2-phase problems, the use of the EXPL solver must be
explicitly set using the keyword TUNEFS1D. Future versions of the parallel multicore option
will support Linux and the front tracking solver.
Note One consequence of multithreading is that there will be minor differences in results
between serial and parallel runs.
The Multicore Parallel option is easy to use and requires a single keyword THREADFS in the
RUNSPEC section. The user needs to specify the number of threads to be used. Corresponding
number of parallel multicore licenses must be available.
Note The run stops if the required number of licenses is not available.
Ideally, the number of threads specified should equal the number of physical processor cores for
best performance. For further improvements in speed the recommended tuning options for serial
runs is still relevant. In particular, the sensitivity of the solution to number of streamlines used
should be analyzed using the TUNEFSSA keyword.
During the simulation streamlines will be distributed to the available cores for parallel
processing. Load balancing is automatic and no user interaction is required.
You may change the number of processors during a restart run.
Note The keyword is not currently supported via the GUI in Petrel and has to be introduced
via the keyword editor.
212 Multicore Parallel Option FrontSim Technical Description

Introduction
Scalability
The scalability with number of cores is dependent on the type of model.
The total CPU time for a FrontSim simulation is broadly divisible into two parts a) the pressure
solution and b) the saturation solution. Below is an extract from the FrontSim PRT file showing
a detailed reporting of the time spent in the various modules.

CPU Saturation : StGen 0.2 StSolve 52.5 STGrav 1.8 Tot 54.5
Depending on the nature of the problem the proportion of time spent on either of the solvers will
differ. In the example report above, the cumulative time spent on the pressure solution is 17.4
seconds while the saturation solution takes about 1000 seconds. Here time for saturation
solution includes the time to solve streamlines and gravity lines. The time taken to generate
streamlines should not be counted. Thus, about 98% of the total CPU time is taken by the
saturation solver. Such a model will benefit tremendously from using multicore parallel
processing. For example, a dual socket quad core workstation with a total of 8 CPUs will run
this problem in about 145 seconds (17.4+1000/8).
High resolution models often require a large number of streamlines so they make a perfect
candidate for parallel multicore processing. Fractured dual porosity models are another
candidate. The high throughput along streamlines passing through fracture cells require shorter
time steps due to stability considerations resulting in longer computation times for the saturation
solver.
FrontSim Technical Description Multicore Parallel Option 213

Scalability
214 Multicore Parallel Option FrontSim Technical Description
Scalability
Pattern Flood Management
Chapter 22
Introduction
Streamline simulation is being increasingly used for managing waterflood operations in some
ECLIPSE 100
ECLIPSE 300
of the largest fields in the world (SPE 54616, SPE 63152, SPE 105393). Underpinning the
SPECIAL analyses of a waterflood is the relationship between injection and production wells. This
x FRONTSIM relationship can be directly and fully quantified on reservoir models through streamline
simulation as is clear from Figure 22.1. This ability of streamline simulation is unique. In the
past, engineers have used time consuming trial and error methods to optimize waterflood
simulations using streamline data. In this chapter we discuss the use of the Pattern Flood
Management (PFM) option which is a separately licensed extension to FrontSim. This option
provides an automated way of optimizing streamline waterflood simulations. The techniques
currently used are standard reservoir engineering methods and not black box optimization.
Figure 22.1 Comparison of water flood simulations.
Figure 22.1 shows on the left: waterflood simulation with finite difference method. And on the
right - same simulation using FrontSim streamline solution using the front tracking method.
FrontSim Technical Description Pattern Flood Management 215

Introduction
FrontSim PFM uses streamline simulation properties to determine how much water to allocate
to injectors in order to enhance the performance of a waterflood. Given a history matched
reservoir simulation model, a set of active wells and an overall injection limit, the FrontSim
PFM option recommends well by well injection and production rate schedule for the waterflood.
These rate schedules help to manage the reservoir in such a way that oil rate decline is arrested,
water breakthrough delayed or water production suppressed, and volumetric efficiency and
ultimate recovery are increased. Thus, field redevelopment, modification of flood pattern and
similar waterflood design and planning studies can be undertaken efficiently. FrontSim PFM is
highly suited for fields with large number of wells and high resolution reservoir models.
Multiple field development options can be studied quickly and the impact of uncertainty can be
analyses through rapid screening of multiple realization of equi-probable geology.
Figure 22.2 Example of improved reservoir performance with PFM
Problem solving
PFM can be used to solve the following problems:
Balancing voidage and recovery across the field

Areas/zones with higher voidage are automatically detected and allocated more injection.
Alternatively, higher injection is allocated to areas with relatively higher quantities of remaining
mobile oil; and lower injection rates for patterns that are almost flooded out.
Reduce water recycling

Injection water can breakthrough at adjacent producers and result in water recycling. The water
cut associated with an injector producer pair indicates the amount of recycling and is used to
adjust the injection. (Figure 22.2 above shows an example simulation.)
216 Pattern Flood Management FrontSim Technical Description

Introduction
Reduce injection loss to aquifer
Injectors close to aquifers can be injecting large amounts of water into the aquifer. Water lost to
the aquifer in this way can be accounted for and the overall injection rate reduced or the excess
water can be redistributed to better performing injectors.
Using PFM
PFM is easy to use and is triggered by a single keyword, WCONPAT. There are various output
summary vectors associated with this option that allow analysis of the simulation (see Table
5.23 and Table 5.24 in the"FrontSim User Guide").
PFM is compatible with 3-phase black oil systems. If only oil-water slightly compressible
simulation is required then advantage can be taken of the front tracking solver. This solver is
much faster and introduces very little numerical dispersion so that sharp flood fronts are
maintained during the simulation.
FrontSim optimizes the allocation of water injection at every time step or after user-defined
intervals of time during the course of the simulation. Individual well constraints, economic
limits are taken into account during the allocation process. The option is compatible with well
workover logic.
FrontSim PFM and high speed simulation, with the new parallel multicore option, makes it
possible to think of high resolution waterflood simulation on a daily basis for reservoir
surveillance.

Introduction
Workflow
You can choose from three different rate allocation strategies. For a successful waterflood one
can envisage three distinct phases as shown in Figure 22.3.
Figure 22.3 Typical Successful Waterflood Performance.
(Adapted from Ganesh Thakur, Integrated Waterflood Asset Management, SPE Applied
Technology Seminar, Mumbai, 2005)
A 'fill-up' phase followed by an oil rate 'incline' phase before breakthrough and finally a 'decline'
phase after breakthrough. Corresponding to these three phases of 'fillup', incline and decline one
can specify in WCONPAT either the VREP, RECOV and INJEFF allocation criteria, respectively.
There is, however, no restriction on the sequence of use for these different allocation strategies.
Note When getting started almost all the parameters of the WCONPAT keyword can be set to
default except for the allocation strategy.
To start the pattern management feature the wells in the reservoir model must have an initial set
of operating rates. Therefore, the use of WCONPAT should always be preceded by well rate
assignments using WCONPROD/ WCONHIST/ WCONINJE and/or group allocation controls
GCONPROD and GCONINJE. The run with pattern management could be a restart run from an
earlier history match run. First a time step, as explained above, is required in the schedule
section of the restart run to set initial well rates. In the next step the WCONPAT keyword is
introduced to begin the optimized rate allocation strategy. The history match could be either an
ECLIPSE or a FrontSim run.
For large number of injectors it is best to use the WLIST keyword to group injectors. The list
name is then directly used in the WCONPAT keyword. It is therefore possible to apply PFM to a
portion of a field, e.g. a pilot project.

Workflow
For green field or facility up gradation studies it is best to run PFM with minimal constraints to
gauge field capacity for all existing and planned wells. For capacity constrained simulations
care should be taken when formulating schedule sections that seek to combine general well
management target and constraints with PFM control. (Please review the rules for combining
PFM with standard well management towards the end of this chapter).
It is recommended to use well economic limits to remove very low rate producers (WECON) and
injectors (WECONINJ) as they can interfere negatively with the optimization exercise.
Injection capacity limit can be applied to each list of injectors. Optimization allocation
computations are done at every step.
For the application of pattern flood management to the real reservoir, both the data driven
methods (OFM, Decide!) and the model based simulation method (FrontSim PFM) are required
in a closed loop monitoring system. Field inter-well measurements, for example, tracer tests,
interference tests, logging, etc. are required to verify computed (data-driven or model based)
allocation factors. When there is a match, then the model based system can be used to prescribe
production and injection rates for field implementation.
The FrontSim simulation model must be updated continuously and history matched prior to
using it as a surveillance model for prescribing rates for field implementation.

Workflow
Waterflood Patterns
Classical methods for waterflood design employ some standard well patterns, for example, line
drive, 5-spot, 9-spot or inverted 5-spot.
Figure 22.4 Repeated 5-spot waterflood pattern. P wells are producers and I wells are injectors
Patterns are also conceived for the purpose of water flood monitoring. Patterns are thus groups
of well identified by the user and can be based on the original waterflood design, e.g. 5-spot, or
wells in close proximity, reservoir blocks/compartments or even reservoir history. Figure 22.4
shows a repeated 5-spot pattern of wells in a homogeneous permeability field. Patterns can also
be considered as fixed volumes of the reservoir containing a group of wells. For each well in a
pattern, it is recognized that only a fraction of its production or injection could be allocated to
that pattern. In Figure 22.4, producer P5 would contribute to the production of 4 different
patterns.
Allocation factors are difficult to measure or estimate independently but they form the basis of
all pattern based waterflood analyses. If the 'actual' pattern of wells were known to the user then
geometrical methods could be used to estimate the allocation factors. For example, in Figure
22.4 well P5 could have an allocation factor of 0.25 for each of the 4 patterns.
There are data-driven production data based polynomial fitting methods, for example neural
networks, for both identifying connected wells as well as estimating allocation factors.

Waterflood Patterns
FrontSim Patterns
In reality, well patterns can be far from perfectly symmetrical shapes. This is because wells are
not often drilled in perfect patterns, the geology is not homogeneous and well rates are not in
proportion relative to the pattern or that some wells are simply shut in.
Figure 22.5 Same model as Figure 22.4 but with a heterogeneous permeability field
Observe complete change in patterns. Plot on the right shows dynamic injector based patterns
Figure 22.5shows how the introduction of channel geology to the model in Figure 22.4 can
completely change the flooding patterns. This picture is more real than what we see in Figure
22.4. However, now the computation of well relationships and allocation factors becomes
extremely complicated. Correspondingly, allocation of injection water based on erroneous/
simplistic allocation factors could be very risky.
FrontSim is able to identify well patterns and generate allocation factors for any given geology,
well locations and rates. The pattern of connected wells in FrontSim also changes with every
time step during the simulation. Therefore, we refer to patterns identified by FrontSim as being
'dynamic' and those specified by the user (Figure 22.4) as 'static' or 'user-defined'.
FrontSim goes a step further than commonly used data driven methods that can detect
relationships and total allocation factors. FrontSim can define allocation factors for individual
fluid phases. For example, 40% of the oil production from a producer could be attributed to a
particular pattern, while the allocation of water production to the same pattern could be 60%.
It is normal in FrontSim to identify patterns of producers by their connection to an injector. Such
patterns are called injector based patterns. Patterns can also be identified as a set of injectors
influencing a producer. Such patterns are called producer-based patterns. Thus patterns in
FrontSim are normally associated with a single producer or injector. It is possible to identify
producers or injectors with associated streamline bundles that do not start or end in any other
well. This commonly happens when fluids are produced from or injected into aquifers,
depletion/expansion processes and compression of fluids.
Single phase or total allocation factors produced by FrontSim can be loaded into Oilfield
Manager (OFM) using a custom interface. Use the RPTSCHED and RPTALLOC keywords to
output separate files containing allocation factor information.

FrontSim Patterns
Note Note that FrontSim supports the use of the WCONINJP keyword for user defined
injector based patterns. Injection leakage outside the user defined pattern can be
reported using the summary vector WPLEAKUD.

FrontSim Patterns
Allocation Strategy
In FrontSim, the bundle of streamlines not only indicate which injector is connected to which
producer but also provide a wealth of other information, for example phase injection/production
flow rates in the bundle, bundle pore volumes, phase volumes such as mobile oil volumes,
pressures, etc.
Figure 22.6 Injector-producer pair streamline bundles
Figure 22.6 shows 5 separate bundles of streamlines connecting one injector (I24) to 5 different
producers. Such information is used by the Pattern Flood Management option together with a
chosen recovery strategy to allocate new injection and production rates according.
Strategies
There are currently three strategies available to choose from.
Pattern voidage Replacement (VREP)

The voidage occurring in the regions around an injector are tracked continuously using the
streamline bundles emanating from injectors. The injection rate for the injector is then adjusted
to achieve the voidage replacement ratio (VRR) requested by the user.

Allocation Strategy
Pattern recovery balancing (RECOV)
First, the rate at which the remaining mobile oil in each bundle of streamlines connecting an
injector producer pair is computed. Next, all the bundles for all the injectors are normalized and
ranked. Then the overall injection available is allocated to these bundles based on an input
weighting scheme. In principle, injector-producer pairs with higher remaining mobile oil and
higher sweep rate are rewarded with more injection. The production rate for each bundle is
adjusted to maintain the original pattern of streamline bundles within engineering accuracy. The
bundle rates are aggregated to achieve well injection and production rates.
Reducing water recycling (INJEFF)

The oil cut at reservoir condition for each bundle of streamlines connecting an injector-producer
pair is computed. The overall injection available is then allocated to these bundles based on an
input weighting scheme. In principle, injector-producer pairs with higher oil cut are rewarded
with more injection. The production rate for each bundle is adjusted to maintain the original
pattern of streamline bundles within engineering accuracy. The bundle rates are aggregated to
achieve well injection and production rates.
Weighting Scheme
The weighting scheme to determine the bundle allocation is based on published work by Thiele
et. al. (SPE84080). The following needs to be read in conjunction with the WCONPAT keyword
and its data items.
The basic rate change formula is
New Bundle Rate = Weight * Old Bundle Rate

New Well Rate = Sum of Bundle rates assigned to well
The general formulae used to calculate the weights for each injector-producer pair i are as
follows:
Alpha
W i = 1.0 + W lim Beta
If Beta1 > Betaavg then

W lim = W max (item 7)
Beta = Min ( ( 1.0, ( Beta i Beta avg ) ) ( Beta max Beta avg ) )
If Betai < Betaavg then

W lim = W min (item 6)
Beta = Min ( ( 1.0, ( Beta avg Beta i ) ) ( Beta max Beta avg ) )
Beta is a bundle parameter value that relates to the control strategy (item 2),that is oil cut if
reduce recycling is chosen or rate of flooding of remaining mobile oil if recovery balancing is
chosen. The parameter values at the end of the previous time step are used in the allocation
process for the current time step. In order for the allocation process to be meaningful, FrontSim
tries to ensure that the bundle configurations or patterns do not significantly change across time
steps.
Beta avg is the local average over all the bundles representing the list of injector wells
participating in the optimization. This is computed by FrontSim at run time.

Allocation Strategy
defines the parameter range (item 4) within which to apply proportional
[ Beta min, Beta max ]
weighting. Betamin and Beta max are not directly input, instead the range is input (item 4) and
Beta min and Beta max are calculated. The computation of Beta min and Beta max is controlled by
item 5. If item 5 is set to 0 (default) then Betamin and Beta max straddles Beta avg , else if item 5 is
set to 1 then Betamin and Betamax is fixed around a Betaavg = 0.5 .
Alpha (item 3) can be used to control the distribution of weights. If Alpha is set to 1, then the
relationship between bundle property and the weights is linear. This means bundles are assigned
weights in proportion to the difference of the bundle parameter value from the average. If Alpha
is set to 2, then the relationship is non-linear and bundles with values close to the average bundle
value will be less affected (Wi ~ 1.0) while the outlier bundles will see higher changes.
The final injector rates are scaled to meet total injection capacity or the total injection rate from
the previous time step.

Allocation Strategy
Example showing computation of weights
Figure 22.7 Showing computed weights a) picture on the left is for alpha=1 and b) picture on the right is for alpha=2.
The above graphs showing weights for range of Beta values were computed using the following
input in the WCONPAT keyword:
Alpha = 1, 2 (Item 3)
Range for Beta = 0.75 (Item 4)
Method to compute Beta Limits = 0 (Default for Item 5)
WMIN = -1.0 (Item 6)
WMAX = 1.0 (Item 7)
Beta min and Beta max were computed using the default formula (Item 5) for the given range.
= 0.45 (Either average oil cut or average recovery efficiency as requested by item 2 will
Beta avg
be computed by FrontSim).
For weighting schemes in both graphs above, it can be observed that injectors with oil cuts or
recovery efficiency at the extremities are affected the most by the rate adjustment. Weights
above 1 imply the injection rate is increased and weights below 1 imply the injection rate will
be decreased. If alpha is 1 then the rate increase or decrease is proportional to the variance of
beta around the average value. If alpha is 2 then injectors around the average beta value remain
relatively unaffected as the weights are close to 1.
The effect of choosing a range < 1 can cause the worst offending injectors to shut in (for
example above weight = 0 for beta < 0.1) while capping the injection rate for the best injectors.
There is considerable flexibility in designing a specific weighting scheme for a specific region.
The WCONPAT keyword accepts multiple record entries such that multiple 'lists' of injectors
with different weighting strategies can be operated upon simultaneously. It is also where the
feature is different from a regular optimization problem as engineering is required to produce a
strategy that gives the maximum benefit for a particular reservoir.
If Beta is changing rapidly at any time during the simulation then it may be advisable to use
shorter time steps for the optimization exercise to produce quality results.
Debug output that details the calculations can be produced by using OPTIONFS (51) = 1.

Example showing computation of weights
Aquifers
Bundle of streamlines connecting an aquifer to a producer is automatically accounted for in the
above strategy. However, bundles of streamlines connecting an injector to a aquifer represents
how much water or oil could be lost to the aquifer. The injection to the aquifer is cut back
arbitrarily as specified by the user (Item 10). The amount of injection cut back can be reallocated
among other injectors or the overall injection reduced (Item 11).

Aquifers
Multi-zone Waterfloods
FrontSim PFM supports multi-zone waterfloods. This requires that zones be identified by
lumping simulation layers together. The COMPLUMP keyword is used to describe zone
completions in wells. This indicates to FrontSim that a multi-zone waterflood is being modeled.
All allocation calculation will now be done at the completion level. Economic limits can be set
at the completion level with workover action to shut in connections for producers (CECON).
Injection wells can be worked over on the basis of completion injection efficiency when the
CECONINJ keyword is used. A separate set of summary vectors at the completion level can be
produced, for example,. COPRL, CWPRL. Special summary vectors at the completion/zone level
for pattern flood management can also be reported (See Table 5.23 and Table 5.24 in the
"FrontSim User Guide").

Multi-zone Waterfloods
Combining Well Management and PFM Controls
PFM is essentially an allocation scheme similar to group allocation based on well potential.
Groups and wells defined in reservoir simulation models are essentially a pseudo representation
of the surface network. Similarly, streamline bundles are used to bundle wells into dynamic
patterns or groups. In a sense, the surface network and the sub-surface streamline bundles
represent two 'networks'. Balancing is required to simultaneously honor group and well
constraints when PFM allocation is exercised. This is quite a challenging task and in the current
version only limited functionality with respect to constraining the PFM allocation is available.
Limitations and rules
Note It is recommended, wherever possible, to start PFM with none or few well and group
constraints/limits and simple well schedules. Complex scheduling and application of
intricate well management routines together with PFM can be challenging and the user
is advised to contact the help desk before proceeding
Here are some of the implemented rules:

1 It is necessary to have at least one time step before PFM allocation begins to initialize
producer and injector well rates and generate initial set of pattern related parameters for the
allocation process. This is also required when performing a restart run.
2 The target rate for a list of injectors under PFM at any time step is taken to be equal to the
sum of the rates for the same list of injectors in the previous time step or user defined
injection capacity.
3 Injector lists can be modified explicitly using ADD, MOV or DEL options in WLIST. This
handled as follows
a If you add a new well in the current timestep it will be assigned a small arbitrary rate
while maintaining the injection target. It is recommended to introduce the injector
under individual or group control in the previous time step prior to including it under
PFM.
b If you add a well to the list that had a rate in the previous timestep, its rate will be added
to the target injection rate.
c If you remove a well, its rate will be subtracted from the target injection rate.
d It is recommended not to mix up producers and injectors in the same list.
4 More than one list of injectors with different allocation criteria can be applied at any time.
5 In contrast to normal group and well controls, currently PFM allocation is allowed to
violate individual and group rate limits.
6 Well BHP limits will be honored.
7 Well and group economic limits are applied as usual. Actions are always taken in the next
time step.
8 Injection wells under PFM control are automatically taken off group control.
a Injection rate is scaled down to meet injection capacity limits.

9 Production wells impacted by PFM are automatically taken off group control. The wells not
impacted by PFM remain under group control.
a Production rate is also scaled down to meet production limits in GCONPROD. The
workover procedure RATE must be set. This is only applicable when all producers
affected by PFM belong to the same group.
10 It is possible to switch back from PFM to Group or individual well control during a run
using the WCONPEND keyword.
Please refer to the install directory for sample data sets showing the use of PFM.

References
SPE16482 - "Optimizing Reservoir Surveillance by Using Streamlines and the Microcomputer",
1987. [Ref. 1]
SPE16957 - "An approach for the determination of economically optimum injection and
production rates in a large multi-pattern waterflood." 1987. [Ref. 2]
SPE29278 - "Guntong Field: Development and Management of a multiple reservoir offshore

waterflood", 1996. [Ref. 3]
SPE 54616 "Waterflood Pattern Allocations: Quantifying the injector to producer relationship
with streamline simulation", 1999. [Ref. 4]
SPE 63152 " Waterflood Management: A Case Study of the Northwest Fault Block Area of
PrudhoeBay,Alaska,UsingStreamlineSimulationandTraditionalWaterfloodAnalysis,2000.[Ref. 5]
SPE 84080 - "Using Streamline-Derived Injection Efficiencies for Improved Waterflood

Management", 2006. [Ref. 6]
SPE105393 - "Improving Injector Efficiencies Using Streamline Simulation: A Case Study in a

Giant Middle East Field", 2007. [Ref. 7]

References
References
Three-Phase Saturation Solver
Chapter 23
Introduction
Unlike the 2-phase case, it is not currently possible to solve streamlines by front tracking when
ECLIPSE 100
ECLIPSE 300
3 phases are present. In this case the streamlines are converted to 1-dimensional finite volume
SPECIAL models and solved using standard finite volume simulation techniques.
x FRONTSIM
The 1-dimensional streamlines are then solved by one of four techniques that you can specify,
and the results mapped back onto the grid.
Operator splitting is used to incorporate gravity segregation effects. After the streamline
solution is mapped to the underlying grid we construct vertical gravity streamlines which are
also solved as a series of 1-dimensional finite volume models.
FrontSim Technical Description Three-Phase Saturation Solver 233

Introduction
Streamline solution
Refer to "1D grids" on page 135, which describes how the 1D finite difference grid is
constructed from a streamline. Having constructed these 1-dimensional models we then solve
them using standard finite volume techniques. There are four choices available; these are
controlled using the TUNEFS1D keyword. The four options are
1 IMPLICIT
2 AIM
3 IMPES
4 EXPLICIT.
The first three of these use, essentially, a cut-down version of ECLIPSE 300 to solve the
streamlines. In each of these cases streamlines are bundled together in groups containing
approximately 1000 cells (although this can be controlled by the user), with each streamline
separated from the next by a zero transmissibility, no flow barrier. They are then solved using
a standard finite volume technique. The solutions are solved using mini-timestepping, that is to
say intermediate timesteps are used to solve the streamlines, and the solution is marched
forward to the end of the timestep used in FrontSim. During each mini-timestep, pressure is
recalculated along the streamline as well as the saturations or molar densities. This means that
at the end of the timestep we may end up with a pressure along the streamline which is different
from that used to calculate the original streamline. At the end of the timestep, the solution is
mapped back to the original user grid.
The parameters IMPLICIT, IMPES and AIM indicate the method of solving these
1-dimensional streamlines. They respectively represent a fully implicit solution, an IMPES
(IMplicit Pressure, Explicit Saturation), and an adaptive implicit solution of each mini-timestep.
The limits on the length of the mini-timestep and the number of Newton iterations per mini-
timestep are controlled using the TUNEFS1D keyword.
The fully implicit method

This option is the default method for compositional models.
The fully implicit method solves the residual equation using the saturations at the end of the
timestep t + dt .
M t + dt M t
- + F (P t + dt , S t + dt ) + Q (P t + dt , S t + dt )
R = -------------------------
dt
This means that we need to solve Ncell*Ncomp simultaneous equations where Ncell is the
number of cells and Ncomp is the number of components (compositional) or phases (blackoil)
in the model. The number of calculations required to do this varies linearly with Ncell and with
the 3rd power of Ncomp. Using the fully implicit method for large numbers of components can
therefore be quite slow.
For compositional runs where there are often too many components to be able to use the fully
implicit method efficiently, the AIM method may be a better and quicker option.
234 Three-Phase Saturation Solver FrontSim Technical Description

Streamline solution
IMPES
The IMPES (IMplicit Pressures Explicit Saturations) residual is similar to the fully-implicit
residual, except that all flow and well terms are computed using saturations (or R s , R v ) in a black
oil run; or molar densities in a compositional run at the beginning of each timestep.
M t + dt M t
- + F (P t + dt , S t ) + Q (P t + dt , S t )
R = ------------------------- [EQ 23.1]
dt
The mass terms M t + dt are evaluated using both pressures and saturations at the end of the
timestep. This makes the non-linear residual equation, R = 0 , much easier to solve because
there are now no nonlinear values arising from relative permeabilities that remain fixed
throughout the timestep. However, to solve the IMPES equations correctly it is still necessary
to iterate until all residuals have been reduced to a sufficiently small value.
The linear equations arising from Newtons method are also much easier to solve in the IMPES
case because derivatives of flows with respect to saturations are zero. The linear equations are
solved sequentially, first for pressure and subsequently for saturation changes. This contrasts
with the fully implicit method where the linear equations must be solved simultaneously. The
IMPES formulation is strictly an IMPEM (IMplicit Pressure Explicit Mobility) method. The
mass terms M t + dt are evaluated using both pressures and molar densities at the end of the
timestep. The flow terms between cells are evaluated assuming the saturations, generalized
mobilities and reservoir density terms are all fixed at the previous timestep.
AIM
The Adaptive IMplicit method (AIM) is a compromise between the fully implicit and IMPES
procedures. Cells with a high throughput ratio are chosen to be implicit for stability and to
obtain large timesteps, while the majority of cells can still be treated as IMPES where the
solution may be changing little. All completions are treated implicitly.
More details of these can be found in "Formulation of the Equations" in the "ECLIPSE
Technical Description".
Explicit
This is (2005A) the default method for three-phase black oil models.
The explicit option is a explicit upstream finite volume saturation update along the streamline.
This is much faster than the other 3 solution techniques, but will might require that the full field
pressure equation be solved more frequently.

Streamline solution
Gravity Line Solution
Clearly if we have 3 phases flowing along the streamlines we have to take account of gravity
segregation of the phase. The effect of gravity is incorporated by operator splitting and the use
of vertical gravity streamlines. In fact the gravity lines are made up of columns of cells in the
Z direction of the model.
These vertical streamlines are then solved using the same method as the original streamlines.

Gravity Line Solution
Mapping the solution between streamlines and the grid
A key part of the 3 phase solution process is the way we map the solution variables between the
streamlines and the underlying grid. Clearly there can never be one-to-one mapping between
cells in the streamlines and cells in the grid, except in some very exceptional circumstances. We
therefore require a method of relating the properties in the cells on the grid to those of the
streamline.
We need to re-map the fluids twice for each timestep. We first do this when we construct the
properties of the streamlines from the grid cell properties. We then have to perform a second
mapping when we need to determine the grid cell properties from the streamline cells.
Mapping properties to streamlines.

Each streamline cell is made up of one or more segments of a grid cell.
The pore volume occupied by the streamline cell is given by
V sl = Vi
where V sl is the volume of the streamline cell and Vi is the volume of grid cell i that also forms
part of the streamline cell. Most of the properties of the streamline cell are then calculated using
the pore volume weighted average of the property
Vi Xi
X sl = ----------------- .
V sl
In the case of the amount of each fluid in the cells we use the specific volumes, that is surface
volumes per unit reservoir volume for black oil cases and molar densities for compositional
cases. In the case of pressures, the user has two alternative methods of calculating the pressure.
The default method is to calculate the pressure at which the fluid exactly fills the cell. This
should conserve volume. Alternatively the user can optionally use the pore volume weighted
average of the pressure. In this case the volume of fluid in the cell is adjusted so that the
saturation of water is preserved, and also the ratio of surface gas to surface oil in black oil cases.
In compositional cases the moles of the components are simply scaled so that the fluid occupies
the entire cell. This latter technique introduces a material balance error; however, if the fluids
are fairly incompressible, the material balance error should be small and the initial pressure will
tend to be smooth.
The choice of initial pressure is controlled by item 7 of the OPTIONFS keyword.
Mapping properties back to the Grid.

This is essentially the same as the method used in mapping to the streamlines, with one
exception. It is possible that an individual grid cell is not occupied entirely by streamlines, so
that
V gr = Vj + Vnsl
where
V gr is the volume of the grid cell,
V nsl is the volume of the grid cell which is not contained in a streamline,

Vj is the volume of the cell contained in the j th streamline.
The cell fluid abundances are again calculated by taking volume-weighted averages of specific
volumes, or molar densities, depending on whether the model is a black oil model or a
compositional model. The volume not contained in the streamline is accounted for by adding in
the fluid contained in that fraction of the cell at the beginning of the timestep. This helps to
prevent material balance errors.
As in the case of mapping to the streamlines we have a number of ways of determining the
pressure in the cell. As before we can choose the pressure so that the fluid in the cell exactly fills
the cell. Also as before it is possible to take a pore-volume weighted average of the streamline
pressure. The third possibility is to use the pressure distribution that we initially calculated in
order to trace the streamlines. In the latter two cases we adjust the amount of fluid in the cell so
that the fluid exactly fills the cell. This is done in such a way that the water saturation remains
constant and the ratio of surface oil and surface gas in the cell also remains constant. The user
can choose the method using item 7 of OPTIONFS and item 6 of TUNEFS1D. Methods 2 and
3 will introduce material balance errors, but may be useful in situations where the fluid is highly
incompressible. If the fluids are incompressible, if we use method 1 any small material balance
errors in the solution for an individual streamline, or even inconsistencies between neighboring
streamlines, may result in a pressure distribution that is not very smooth. This can lead to
problems solving subsequent pressure steps. Using method 3 the pressure field will be smooth,
and any error due to scaling the fluids-in-place in individual cells so that they fit the cell will be
small.
Numerical Dispersion
The mapping process can be very dispersive.
Figure 23.1 Numerical dispersion through the mapping process
Sg=1
So=1
Take the case above where we have 2 grid cells, one above and one below the gas oil contact,
and with 100% gas above the contact and 100% oil below. If we then have a streamline cell
(indicated by the dotted line) which straddles the contact, then the streamline cell will contain
50% gas and 50% oil. If we now map the fluids back to the grid, the upper cell will have 75%
gas and 25% oil. This is without moving any fluids.
The user should therefore be aware that while shortening timesteps will generally improve the
quality of the solution along the streamline, any improvement may be more than offset by the
increase in numerical dispersion.

Tuning
3-phase data sets frequently need tuning. The most common problems are simulations stopping
due to high material balance errors or unphysical solution values. These can often be solved by
one of the following.
1 Increasing the number of Newton iterations that can be used in each mini-timestep in the
saturation solver - item 12 of TUNEFS1D. Values above 12 rarely provide any benefit.
2 Decreasing the minimum size of the mini-timestep allowed in the saturation solver. This is
controlled using item 4 of keyword TUNEFS1D; it is a multiple of the actual timestep. It is
unlikely that a value which corresponds to a mini-timestep of less than 0.5 days will help.
3 Decreasing the timestep may help with problems.
4 Ensuring that the initial pressure solve has converged also can overcome problems with 3-
phase simulations. This can often be done by increasing the number of Newton iterations
in the pressure solver. This is controlled by item 5 of keyword TUNEFSSA.
In each case there is a cost in terms of the simulator performance. The user can however apply
the change just before the point at which the problem occurs. It is worth noting that problems
often only appear 1 or 2 timesteps after the actual problem has occurred, so it is can be effective
to apply these tuning changes 3 or 4 timesteps before the observed problem.

Tuning
Keywords
There are 2 keywords that provide control over the 3-phase saturation solver:
TUNEFS1D is the main keyword for controlling the 3-phase saturation solver.
OPTIONFS primarily provides back compatibility with previous code versions, but allows
some tuning of the 3-phase solution method.

Keywords
Total Compressibility Checks
Chapter 24
Introduction
In black oil models, FrontSim checks for positive compressibility of each single reservoir fluid
x ECLIPSE 100
x ECLIPSE 300
as the PVT data is read (the formation volume factor must be a monotonically decreasing
SPECIAL function of pressure assuming all other variables are held fixed).
x FRONTSIM
However, FrontSim also checks that oil-gas mixtures have a positive total compressibility even
when there is mass transfer between the two phases. For example, it is well known that oil
sometimes swells when the pressure increases, apparently in violation of physical principles.
This swelling occurs because gas is dissolving in the oil. Provided that the reduction in the
volume of gas is greater than the increase in the volume of oil, the total volume of the oil-gas
mixture reduces as the pressure increases, and the paradox is resolved.
It is possible to calculate a value for the total compressibility of a hydrocarbon system where
mass exchange may occur between the reservoir liquid and vapor phases. Consider a volume Vg
of separator gas and a volume Vo of stock tank oil at surface conditions. Compress the mixture
to pressure P, volume V and assume that a two-phase equilibrium state is formed. The material
balance equations for the oil and gas components are
V S V Rs So
Vg = ------------g- + ---------------------
- [EQ 24.1]
Bg Bo
V S V Rv Sg
Vo = ------------o- + ----------------------
-. [EQ 24.2]
Bo Bg
[EQ 24.1] and [EQ 24.2] allow the mixture volume V and gas saturation Sg to be computed. If
the pressure of the system is increased, the volume occupied by the liquid-vapor system must
decrease for physically well-defined fluids. The total compressibility of the system,
C t = ( 1 V ) ( dV dP ) , can be shown to be given by the following expression
S dB dR B o R s B g S o dB o dR s B g R v B o
C t = -----g- --------g- + --------v -----------------------
- + ------ --------- + -------- ------------------------ [EQ 24.3]
Bg dP dP 1 R s R v B o dP dP 1 R s R v
where the pressure derivatives are taken along the saturation curve.
FrontSim Technical Description Total Compressibility Checks 241

Introduction
This can also be written as
C t = S g C t, gas + S o C t, oil [EQ 24.4]
which splits the total compressibility into gas and oil dependent terms.
To derive this expression, we assume without loss of generality that
So + Sg = 1 [EQ 24.5]
and note that

dVo dp = dV g dp = 0 [EQ 24.6]
since the volumes of stock tank oil and separator gas are fixed.
Solving for S o and S g gives
Rv Vg Vo Bo
- -------------------
S o = ----------------------- - [EQ 24.7]
V Rs Rv 1
and
Rs Vo Vg Bg
S g = ----------------------- -------------------
- [EQ 24.8]
V Rs Rv 1
And since S o + Sg = 1 we have
1
V = ------------------------- ( V o ( R s Bg B o ) + V g ( R v B o Bg ) ) [EQ 24.9]
( Rs Rv 1 )
Hence
1 dV
C t = --- ------ [EQ 24.10]
V dp
( R s dRv dp + R v dR s dp )
= -----------------------------------------------------------
-
( Rs Rv 1 )
dBg dR s dB dB o dR v dB
Vo R s --------- + B g --------- --------o- + V g Rv --------- + B o --------- --------g-
dp dp dp dp dp dp
+ ---------------------------------------------------------------------------------------------------------------------------------------------
Vo ( Rs Bg Bo ) + Vg ( Rv Bo Bg )
which after some manipulation, and substitution for Vo and Vg using the above relations, leads
to the desired expression for C t .
Some simple limiting cases may be derived from [EQ 24.3].
If R s = Rv = 0 then
S dB S dB
C t = -----g- --------g- -----o- --------o- > 0 [EQ 24.11]
B g dP B o dP
since the formation volume factor pressure derivatives are < 0.

If Rs > 0 and Rv = 0 then
242 Total Compressibility Checks FrontSim Technical Description

Introduction
S dB S dB dR
C t = -----g- --------g- -----o- --------o- B g --------s [EQ 24.12]
Bg d P B o d P dP
so that C t < 0 if dBo dP > B g dR s dP and S g is sufficiently small.

FrontSim checks the total compressibility of the hydrocarbon PVT data as it is read from the
input data file. For each PVT region in the simulation grid a pressure range is selected from the
corresponding oil and gas PVT data tables to span the complete range of pressure data in the
two tables. This pressure range is then subdivided into 30 equally spaced pressure nodes for the
evaluation of the total hydrocarbon compressibility using [EQ 24.3].
The sample pressure range is the maximum of the oil pressure (maximum bubble point pressure
in PVTO or maximum pressure specified in PVDO) and the gas pressure (maximum dew point
pressure specified in PVTG or maximum gas pressure specified in PVDG).
At each pressure node two limiting compressibility values are calculated corresponding to
S g = 0 and S g = 1 in [EQ 24.3]. If either or both values should be negative, a warning message
will be issued indicating the offending pressure value and the gas saturation range for which the
compressibility is negative. It should then be possible using [EQ 24.3] to determine how to
change the saturated gas/oil PVT data to ensure the total compressibility remains positive for all
pressures.
If the range of sample pressures extends above the maximum bubble point specified in the PVTO
table or above the maximum dew point specified in the PVTG table, then FrontSim will be
forced to extrapolate above the highest entered bubble point or dew point. This extrapolation is
linear in 1 B o etc. (see the PVTO keyword). In this case, it is not unlikely that negative
compressibilities could occur as a result of extrapolation.
In some cases, if the pressure is extrapolated severely, then the linearly-extrapolated formation
volume factors may become unphysical. It is recommended that the highest bubble point nodes
in the PVTO table are constructed so avoid extrapolations above the highest entered Rs in the
PVTO table during the simulation (similarly, in a run with vaporized oil present, it is
recommended that the highest dew point nodes in the PVTG table are constructed to avoid
extrapolations above the maximum entered Pdew during the simulation).
Note The effect of a negative total compressibility is usually to cause the simulator to
experience numerical difficulties (convergence failures and/or erratic changes in the
solution) in regions where the total compressibility is negative.
FrontSim Technical Description Total Compressibility Checks 243

Introduction
244 Total Compressibility Checks FrontSim Technical Description
Introduction
Tracer Tracking
Chapter 25
Introduction
The Tracer Tracking option is a general facility to follow the movement of marked fluid
ECLIPSE 100
ECLIPSE 300
elements during a simulation run.
SPECIAL The Tracer Tracking option has a wide variety of reservoir modeling applications. In the case
x FRONTSIM
of tracers defined to exist in the water phase, it may be used, for example, to determine the
movement within the reservoir of water injected into any number of injection wells or to predict
the variations in salinity or concentration of other chemical species in the water produced from
the reservoir
Tracers may also be defined to exist in the oil phase.
The tracer concentrations can be initialized on a grid cell basis to trace fluids from certain areas
of the reservoir.
The current Tracer Tracking option assumes that the presence of tracers does not affect the PVT
properties of the phases in which they are embedded. The tracers are thus to be regarded as
passive. The tracer equations are a set of conservation equations for each tracer species.
The current implementation can only be combined with the two-phase front tracking saturation
solver and can not be used with three phase models.
FrontSim Technical Description Tracer Tracking 245

Introduction
The Tracer Equation
Tracers, or polymers, may be added to the injected phase to investigate reservoir properties as
well as for defining flow patterns and inter-well connections. Due to physical and chemical
interaction between added species (tracers) and the porous medium, adsorption takes place. The
most important effects are due to ion exchange, ion pairing and hydrophobic bonding
mechanisms. The relative importance of these effects depend highly on the tracer as well as the
porous medium. Most minerals in reservoirs have a negative electric potential (although some
clays have positive). Thus, to minimize electrostatic effects most non-neutral tracers are
negative ions. Also the pH value is critical for the adsorption. In general, decreased pH value
(fewer H+ ions in the solute) allows more positive potential on the rock surface, and thereby
increases adsorption of a negative tracer species.
Due to the numerous combined effects, the adsorption function may have different shapes, even
non-convex. However, for most purposes a relatively simple mathematical model for adsorption
is used, the Langmuir model.
The underlying assumption for this model is a reversible exchange of tracer at the rock surface.
The following mathematical model is used:
a(c) = k c(A a(c ) ) k a( c) [EQ 25.1]
t 1 2
Here:
c = concentration in fluid phase
a(c) = adsorbed amount of tracer
A = maximum adsorbed amount of tracer
k1 = reaction coefficient for adsorption
k2 = reaction coefficient for de-adsorption
Several options are possible for the units for the adsorbed amount. Mass of tracer per mass of
rock is frequently used.
If we assume that the time scale for the adsorption process is short compared to the time scales
of interest in reservoir simulation, we may assume that equilibrium is established
instantaneously. Thus, the above equation gives:
k 1 Ac
a ( c ) = ----------------------
- [EQ 25.2]
k 1 + k 2 Ac
which is the Langmuir model for adsorption.
In Figure 25.1 we see a typical shape of the function.
246 Tracer Tracking FrontSim Technical Description

The Tracer Equation
Figure 25.1 Langmuir model
a(c)
For adsorption processes, hysteresis is also an important effect. Anything between no hysteresis
and complete irreversible adsorption may occur, and may complicate the modeling to some
extent.
For the one-phase tracer model in <ProductName>FrontSim, the adsorption is used explicitly
to compute the tracer shock speed. The conservation law for the tracer is:
( c + a ( c ) ) + ( vc ) = 0 [EQ 25.3]
t
where v is the flow velocity. Thus, the shock speed of a tracer shock (separating cL and cR ) is
given by
cR cL
= ------------------------------------------------------
-v [EQ 25.4]
cR + a ( cR ) cL a ( cL )
In the present version of the code, hysteresis is accounted for by assuming that if present, the
adsorption is irreversible. Thus, in the above expression, in case of irreversibility
(IRREVERSIBLE), the immobile concentrations a ( cL ) and a ( cR ) are determined not by the
actual floating concentrations, but by the maximum value ever obtained at the actual location.
The adsorbed tracer distribution is updated globally after each time step.
FrontSim Technical Description Tracer Tracking 247

The Tracer Equation
248 Tracer Tracking FrontSim Technical Description
The Tracer Equation
Transmissibility Calculations
Chapter 26
Introduction
This chapter describes the expressions used by FrontSim to calculate transmissibility values,
x ECLIPSE 100
x ECLIPSE 300
between cells in the grid, and between cells and numerical aquifers.
SPECIAL The transmissibility calculations for each type of geometry are detailed in the next section. In
x FRONTSIM
the corner point case, transmissibility values between cells that are not neighbors in the basic
indexing grid may be calculated on the same basis as those for neighboring cells. In both cases,
the mutual interface area is calculated, and this may be non-zero for non-neighboring cells at
faults.
Cell ordering and geometry

The basic grid indexing system is by natural order. Cells may be identified by their (i ,j, k)
indices in the cartesian indexing grid, and in natural ordering, the i index changes most quickly,
the k index most slowly. Internally, cells are held by active order, with any inactive cells (that
is, those with zero pore volume) not requiring any storage.
Details of cell geometry are entered using the COORD and ZCORN keywords. The data
associated with these keywords is usually prepared using the FloGrid or GRID pre-processors,
and entered from an included file. The cell is assumed to have edges defined as straight lines
between the corner points, and the cell faces may be bilinear surfaces. Pore volumes may be
calculated exactly for such a shape.
There is one transmissibility calculation available in FrontSim.
It is based upon the use of cell corner points, which are available to FrontSim when the COORD/
ZCORN form of grid definition is used. It is possible to distinguish unambiguously between cell
dip and fault displacement, and fault transmissibilities are generated automatically.
FrontSim Technical Description Transmissibility Calculations 249

Introduction
Corner point transmissibility calculations
In this case, the transmissibility values are calculated from the X-,Y- and Z-projections of the
mutual interface area of the two cells.
An inner product is then taken with the vector distance from the cell center to the center of the
cell face, so that a dip correction is automatically incorporated.
X- transmissibility
The X-transmissibility is given by the expression:
CDARCY TMLTX
TRANXi = ---------------------------------------------------i [EQ 26.1]
1 + ----
---- 1
Ti Tj
where
AD
T i = PERMX i RNTG i ---------------i-
Di Di
with
( A D i ) = A X D iX + A Y D iY + A Z D iZ
and
2 2 2
( D i D i ) = D iX + D iY + D iZ .
AX , AY and A Z are the X-,Y- and Z- projections of the mutual interface area of cell i and cell j
(which need not be neighbors in the cartesian indexing grid), and DiX , DiY and DiZ are the X-,
Y- and Z-components of the distance between the center of cell i and the center of the relevant
face of cell i, these centres being obtained as the appropriate average.
The expression for T j is analogous.
Y- and Z- transmissibility
The Y- and Z-transmissibility expressions are similar, the net to gross ratio being absent from
the Z expression.
The calculation is illustrated by the following figure (where PERMX is represented by Kx):
250 Transmissibility Calculations FrontSim Technical Description

Introduction
Figure 26.1 Y- and Z- transmissibility expressions
Kxi- Kxi+
Dxi
A Dxj
Kxj- Kxj+
FrontSim Technical Description Transmissibility Calculations 251

Introduction
252 Transmissibility Calculations FrontSim Technical Description
Introduction
Well Inflow Performance
Chapter 27
Introduction
This chapter outlines the relationships that FrontSim uses to calculate well inflow performance.
x ECLIPSE 100
x ECLIPSE 300 We define the flow path between the well bore and a single reservoir grid block as a
SPECIAL connection.
x FRONTSIM
The total flow rate (oil + water + gas) at reservoir conditions across a connection is given by the
Inflow Performance Relationship.
FrontSim Technical Description Well Inflow Performance 253

Introduction
Inflow Performance Relationship
In FrontSim the inflow performance relationship is written in terms of the total volumetric
production rate at reservoir conditions:
qj = Tw ( Pj Pw Hwj ) [EQ 27.1]
where
qj is the total volumetric flow rate in connection j at reservoir conditions. The flow is taken as
positive from the formation into the well, and negative from the well into the formation.
Twj is the connection transmissibility factor, defined below.
Pj is the pressure in the grid block containing the connection.
Pw is the bottom hole pressure of the well.
Hwj is the well bore pressure head between the connection and the well's bottom hole datum
depth.
The calculation of the terms in this relationship is described in the following sections of this
chapter.
254 Well Inflow Performance FrontSim Technical Description

Inflow Performance Relationship
The connection transmissibility factor (Cartesian grids)
For brevity, we refer to this quantity as the "connection factor". It depends on the geometry of
the connecting grid block, the well bore radius, and the rock permeability. Its value may be
specified directly by the engineer, or it can be calculated by the program using one of the
formulae below.
FrontSim uses the relationship
Tw = ( c q Kh ) ( ln ( ro rw ) + S ) [EQ 27.2]
where
c is a unit conversion factor (0.001127 in field units and 0.008527 in metric units).
q is the angle of the segment connecting with the well, in radians. In a Cartesian grid its
value is 6.2832 (= 2 ), as the connection is assumed to be in the center of the grid block.
For wells located on an edge (or a corner) of a grid block, use keyword WPIMULT after
COMPDAT to scale the resulting connection factors by 0.5 (or 0.25).
Kh is the effective permeability, multiplied by the net thickness of the connection. For a
vertical well the permeability used here is the geometric mean of the x- and y-direction
permeabilities, K = ( Kx K y ) 1 2
ro is the "pressure equivalent radius" of the grid block, defined below.
rw is the well bore radius.

S is the skin factor.
The pressure equivalent radius of the grid block is defined as the distance from the well at which
the local pressure is equal to the nodal average pressure of the block. For a Cartesian grid
Peaceman's formula is used, which is applicable to rectangular grid blocks in which the
permeability may be anisotropic. The well is assumed to penetrate the full thickness of the
block, through its center, perpendicularly to two of its faces.
2 12 2 12 12
[ Dx ( Ky Kx ) + Dy ( Kx Ky ) ]
ro = 0.28 ----------------------------------------------------------------------------------------
14 14
- [EQ 27.3]
( Ky Kx ) + ( Kx Ky )
where Dx and Dy are the x- and y- dimensions of the grid block, and Kx and K y are the x- and
y- direction permeabilities.
[EQ 27.2] and [EQ 27.3] are intended for vertical wells. Horizontal wells may penetrate the
block in either the x- or y- direction, or the appropriate components of permeability and block
dimensions are substituted in these equations. For a well penetrating in the x-direction, for
example, the quantities K y , K z , Dy , Dz will be used in [EQ 27.2] and [EQ 27.3].
A net-to-gross ratio applied to a grid block containing a horizontal well will not affect the Kh
product, but will still affect the equivalent radius ro through the reduction in the value D z .
FrontSim Technical Description Well Inflow Performance 255

The connection transmissibility factor (Cartesian grids)
The productivity index
Engineers have traditionally used the "productivity index" to define the degree of
communication between a well and the reservoir. Unlike the connection factor, it is a quantity
that can be obtained directly from field measurements. But whereas the connection factor
remains constant over the lifetime of the well (unless the skin factor changes because of silting
or stimulation, for example), the productivity index will vary with the fluid mobilities at the
well.
The steady-state productivity index is defined as the total production rate divided by the
drawdown. The drawdown here is the difference between the well's bottom hole pressure and
the pressure in the reservoir at the edge of the well's zone of influence. The extent of the well's
influence is known as the "drainage radius", r d . Thus the productivity index, J , is defined as
J = Qr ( P d P w ) [EQ 27.4]
where
Qr is the total production rate at reservoir conditions, and
Pd is the pressure at the drainage radius.
The simulator calculates the productivity index of each well from this expression, and can
optionally print it out at each well report.
The reservoir pressure at the drainage radius could be obtained from a representative grid block,
or the average pressure of the field or a suitable fluid-in-place region could be used.
256 Well Inflow Performance FrontSim Technical Description

The productivity index
Well Modeling Facilities
Chapter 28
Well completions
Multiple connections
Each well can be completed in several layers of the reservoir. A communication between the
x ECLIPSE 100
x ECLIPSE 300 well bore and a single grid block is defined as a connection. A given well may have any number
SPECIAL of connections.
x FRONTSIM
The connections belonging to a particular well need not all lie in the same vertical column of
grid blocks, so it is possible to model highly deviated wells. Moreover, a well can be completed
in several grid blocks within the same layer, enabling the simulator to model horizontal wells.
Inflow performance
The flow rate of a phase (oil, water or gas) through a connection is proportional to the product
of three quantities:
1 the transmissibility between the grid block and the well bore
2 the mobility of the phase in the grid block at the perforations
3 the pressure drawdown between the grid block and the well bore.
In certain situations the drawdown in one layer may have the opposite sign to the drawdown in
the other completed layers. The simulator will then allow crossflow to take place between the
reservoir layers through the well bore. The crossflow facility can be turned off if the engineer
does not wish this to occur, using a switch in the keyword WELSPECS.
FrontSim Technical Description Well Modeling Facilities 257

Well completions
Relative permeabilities in well connections
The relative permeability of a phase in a well connection is a function of the saturations in the
grid block containing the connection. The relative permeabilities will be calculated using the
Saturation Function tables associated with the grid block containing the connection.
258 Well Modeling Facilities FrontSim Technical Description

Well completions
Well controls and limits
Well control options

Individual wells can operate at a target value of any of the following quantities:
1 Oil flow rate
2 Water flow rate
3 Gas flow rate
4 Liquid flow rate (oil and water)
5 Reservoir fluid volume (or voidage) rate
6 Bottom hole pressure
One of these quantities is selected as the main control target, while limiting values can be
supplied for any of the remaining quantities. The limiting flow rates are also treated as upper
limits. The pressure limits are treated as lower limits in production wells and upper limits in
injectors. The well will automatically change its mode of control whenever the existing control
mode would violate one of these limits. The target quantity in the old control mode will then
become a limit in the new control mode.
For example, consider a production well operating at a target oil flow rate of 1000 stb/day, with
a lower limit of 3000 PSIA on the bottom hole pressure. The well will produce 1000 stb/day of
oil until the bottom hole pressure falls below 3000 PSIA. The wells control mode will then
change automatically to maintain a constant bottom hole pressure of 3000 PSIA, and the oil
production rate will decline. If subsequently the oil production rate were ever to exceed 1000
stb/day (resulting for example from stimulation of the well, or the opening of an extra
connection), then the control mode will automatically switch back to the original target oil
production rate.
An alternative method of control can be applied to wells during the history matching process,
when their observed oil, water and gas production rates are known. The observed rates are
entered with the WCONHIST keyword. A well can be made to produce at a rate that matches one
of the phases, or at the equivalent liquid or reservoir volume rate of the observed production.
The latter option is useful for making the well produce the correct amount of total fluid from the
reservoir before the mobility ratios are fully matched. Thus the rate of pressure decline should
be approximately correct. The observed rates and production ratios are written to the summary
file, for graphical comparison with the calculated rates. Similarly, for injection wells the
keyword WCONINJH can be used to enter observed historical injection rates.
Economic limits
There is an additional class of limits that can be applied to production wells. The engineer can
specify values of the oil or gas production rate, the water cut, the gas-oil ratio and the water-gas
ratio which represent the limits of economic operation of the well. The violation of one of these
limits will result in the well, or one or more of its connections, being automatically closed. The
economic limit options are:
1 Lower limits for the oil, gas and liquid production rates for each well. The well is closed if
any of these limits are broken.

2 Upper limits for the water cut, the gas-oil ratio, the gas-liquid ratio and the water-gas ratio
of each well. If a well violates one of these limits the well is closed.
Keyword WECON is used to set the limiting values and define the choice of workover action.
There is a choice of actions to be taken if a well violates one of these limits:
1 The worst-offending connection (that is the connection with the highest water cut, gas-oil
ratio or water-gas ratio) in the well is closed.
2 The worst-offending connection and all connections below it in the well are closed. Here,
"below" is interpreted as "further from the wellhead according to the connection ordering".
The connection ordering may be specified in the COMPORD keyword.
3 The well itself is closed.
The economic limits are checked at the beginning of the time step, and the appropriate action is
taken if any limits are violated. The action is taken before the new production data is read for
the this time step. Thus a well may produce uneconomically for one time step before remedial
action is taken. This behavior is different from ECLIPSE in fully implicit mode.
Well controls and limits/Efficiency factors

Wells can be given efficiency factors to take account of regular downtime (see keyword
WEFAC). For example, if a well is down for 10 percent of the time, its efficiency factor will be
0.9.
The well rates and pressures given in the well reports describe the state of the flowing well. The
full rates are also used in the well economic limit checks. The efficiency factors are applied
when updating the cumulative well and connection flows.
The efficiency factors are also applied when summing the well rates to obtain the group and
field flow rates. Thus the group and field flow rates represent the average rates over the time
step, rather than the full rates reached when all the wells are operating.
Vertical flow performance

Calculations involving tubing head pressure are handled using Vertical Flow Performance
(VFP) tables, which are supplied as input data. These tables relate the bottom hole pressure of
a well to the tubing head pressure at various sets of flowing conditions.
There are two types of VFP table:
1 Injector tables, which describe the vertical flow performance of injection wells, entered
with keyword VFPINJ.
These are tables of bottom hole pressure versus:
injection rate
tubing head pressure.
2 Producer tables, which describe the vertical flow performance of production wells, entered
with keyword VFPPROD.

These are tables of bottom hole pressure versus:
production rate of oil, liquid or gas
tubing head pressure
water-oil ratio, water cut, or water-gas ratio
gas-oil ratio, gas-liquid ratio, or oil-gas ratio
artificial lift quantity
Note There are three different ways of defining the flow rate, water fraction and gas fraction
in producer VFP tables. You should select the most appropriate definitions for the type
of well being modeled. For example, if it is an oil well which eventually waters out, a
VFP table defined in terms of the liquid rate, water cut and gas-liquid ratio would be
suitable. For gas wells, the VFP table should be defined in terms of the gas rate, water-
gas ratio and oil-gas ratio.
The artificial lift quantity (ALQ) is a fifth variable that can be used to incorporate an additional
look-up parameter, such as the level of artificial lift. For example, if gas lift is being applied, the
artificial lift quantity could refer to the injection rate of lift gas into the well bore.

Group and field control facilities
The multi-level grouping hierarchy

Each well must belong to a particular group, which is named when the well is first declared with
keyword WELSPECS. Rate targets and limits, and economic limits, can be applied to each group
and to the whole field. This provides a standard three-level (well - group - field) control
hierarchy, where controls and limits can be specified independently at each level.
Figure 28.1 Two-level group hierarchy
FIELD
GR1 GR2 GR3
Group production rate targets - guide rate control

Both at group and field level, the groups can be made to produce at a target value of any one of
the following quantities:
1 Oil production rate
2 Water production rate
3 Gas production rate
4 Liquid (oil + water) production rate
5 Reservoir fluid volume rate.
The control target is set using keyword GCONPROD. By default, the group's target rate is
apportioned between the individual wells in proportion to each well's guide rate. The guide rate
is set at the beginning of each time step to a value that depends on the well's production
potential. The production potential is defined as the instantaneous production rate that the well
would initially have in the absence of any constraints on flow rate, at the current grid block
conditions By default, the well's guide rate is set equal to its production potential of the phase
under group control. Pre-2006.1 versions of FrontSim used the productivity indices to apportion
group targets among individual wells. The OPTIONFS(21) switch can be set to 1 for backward
compatibility.

The individual wells can be subject to their own pressure constraints. For example, if a well
would violate its bottom hole pressure limit when producing its full share of the group's
production target, the well will operate at its bottom hole pressure limit. The production rates of
the other wells will increase in proportion to their guide rates (or potentials) to meet the group's
target, as long as they do not violate any of their own flow or pressure limits. A well that is
producing its full share of the group's production target is said to be under group control, while
a well constrained by its own pressure limits is said to be under individual control.
Economic limits
The set of economic limits described earlier for wells can also be applied to the overall
production of groups, and of the field as a whole. If the oil or gas production rate of the group
(or field) falls below a minimum value, all its production wells are closed. If the group (or field)
water cut, gas-oil ratio or water-gas ratio exceeds a maximum value, then the worst-offending
connections or wells in the group (or field) will be shut down. The economic limit values are set
using keyword GECON.
Group production control options/Group

production rate limits
The engineer can impose upper limits on any of the quantities listed above, for selected groups
and/or the field, using keyword GCONPROD. These limits can be imposed whether or not the
group or field has a production target to maintain. If a group's production rate exceeds one of
these limits, there is a choice of actions to follow:
1 The worst-offending connections in the worst-offending wells will be closed successively
until the rate limit is honored. The 'worst-offending' well or connection here is the one that
has the highest ratio of the production rate of the phase violating the limit to the production
rate of the well's preferred phase.
2 As 1 above, except that all connections below the worst-offending one in the well will also
be closed.
3 The worst-offending wells will be closed successively until the rate limit is honored.
4 The group will be made to produce the offending phase at its maximum allowed rate,
according to the group control facilities described in "Group production rate targets - guide
rate control" on page 262. If the group was previously meeting a target rate for another
phase, that target will no longer be met but will act as an upper limit for the production rate
of that phase. The violated limit in effect becomes the new target.
If a reservoir fluid volume rate limit is exceeded, only action 4 is performed.
As an example consider a group of oil wells experiencing water breakthrough, such that the
liquid rate is approaching its maximum limit. If action 1, 2, or 3 is selected, the wells or
connections with the highest liquid-oil ratio (that is the highest water cut) will be successively
closed. If the group is operating at a target oil rate, this target will continue to be met until there
are no wells remaining under group control. If however action 4 is selected, the group control
facility will be applied to make the group produce liquid at the maximum liquid rate. The oil
rate will decline steadily as the group's water cut increases.

The Wellbore Friction Option
Chapter 29
Introduction
The Wellbore Friction option models the effects of pressure loss due to friction in the well
x ECLIPSE 100
ECLIPSE 300
tubing along the perforated length, and between the perforations and the bottom hole reference
x SPECIAL point of the well. The facility is primarily intended for use with horizontal wells, in which
frictional pressure losses may be significant over the horizontal section of the well-bore and in
the branches.
In the standard well model, frictional pressure losses between the well connections and the
bottom hole reference point are neglected entirely. The difference between the pressure at the
connections and the bottom hole pressure is purely the hydrostatic head of the fluid mixture in
the wellbore acting over the difference in true vertical depth between these locations. In wells
completed vertically through the formation, the frictional pressure drop acting over the
relatively short length of the perforated section is generally negligible.
In horizontal wells, however, the perforated section may extend over many hundreds of feet.
The frictional pressure drop over this length may have a significant effect on the behavior of the
well. The pressure in the well-bore towards the far end of the perforations (that is, away from
the wellhead) will be higher than the pressure at the near end, so the drawdown will vary over
the perforated length. This may cause the productivity per unit length of perforations to fall off
towards the far end. Furthermore, the lower wellbore pressure at the near end of the perforations
may cause localized water or gas coning to occur in this region, thus reducing the effectiveness
of the horizontal well in overcoming coning problems. It is therefore important to consider the
effects of frictional pressure losses when deciding on the optimum length and diameter of a
horizontal well.
FrontSim Technical Description The Wellbore Friction Option 265

Introduction
Calculating the frictional pressure loss
The frictional pressure drop over a length L of tubing is
L 2
P f = 2f ---- v [EQ 29.1]
D
where
f is the Fanning friction factor
D is the tubing inner diameter
is the fluid density
v is the fluid velocity
Transforming the flow velocity into the local volumetric flow rate Q (in rb/day or m3/day) and
taking into account the unit conversion factors, the pressure drop becomes
2
Cf f L Q
P f = -----------------------------------
- [EQ 29.2]
5
D
where
Cf = 2.956E-12 in FIELD units (L and D in ft., in lb/ft.3, Q in rb/day)
= 4.343E-15 in METRIC units (L and D in m, in kg/m3, Q in rm3/day)
= 2.469E-13 in LAB units (L and D in cm, in g/cm3, Q in rcc/hr)

The Fanning friction factor depends upon the Reynolds number Re . For laminar flow
( Re < 2000 ),
16-
f = ----- [EQ 29.3]
Re
For Re > 4000 we use Haalands formula ([Ref. 28]),
e 10 9
--1- = 3.6 log10 6.9
------- + ------------ [EQ 29.4]
f Re 3.7D
where
e is the absolute roughness of the tubing in the same units as D
In the uncertain region (2000 < Re < 4000) we use a linear interpolation between the values
at Re = 2000 and Re = 4000. The above scheme has the advantage of providing a direct
calculation for values of f that are continuous in Re and are in reasonable agreement with the
friction factor chart (see [Ref. 29], for example). It should be noted, however, that these
formulae do not take account of fluid inflow through the perforations. Its influence on the
effective roughness of the tubing is largely unknown at present, and the engineer is advised to
vary the roughness to gauge the sensitivity of the results to this parameter.
The Reynolds number is
Re = vD
---------- [EQ 29.5]

where
266 The Wellbore Friction Option FrontSim Technical Description

is the viscosity of the fluid.
Converting v to the volumetric flow rate Q and including the unit conversion factors, this
becomes
C r Q
Re = ---------------
- [EQ 29.6]
D
where
Cr = 0.1231 in FIELD units ( in lb/ft.3, Q in rb/day, D in ft., in cP
= 0.01474 in METRIC units ( in kg/m3, Q in rm3/day, D in m, in cP)
= 0.03537 in LAB units ( in g/cm3, Q in rcc/hr, D in cm, in cP)

If there is more than one free phase flowing in the well, we assume the flow along the perforated
length is homogeneous (that is, no slip between the phases). The homogeneous mixture density
(mass flow rate / Q) is used in the equations for Re and Pf , and the viscosity is the volumetric
flow weighted average of the phase viscosities.
Wellbore friction is included in FrontSim by adding the frictional pressure losses to the
hydrostatic term that illustrates the pressure drop between each pair of adjacent connections.

Using the wellbore friction option
You can designate one or more wells to be friction wells, with the keyword WFRICTN. This
keyword also sets the data required by the friction calculation, for example, the tubing diameter
and roughness, and the locations of the start and end of perforations within each connection. The
WFRICTN keyword can only be used on one well at a time, so the keyword must be specified
more than once if there is more than one friction well. Other frictionless wells can also exist
in the run.
Friction wells can have the same set of controls and limits as ordinary wells.

Units
Chapter 31
The unit conventions

There are two unit conventions currently used:
x ECLIPSE 100
x ECLIPSE 300 METRIC units
SPECIAL
x FRONTSIM FIELD units
The units for each data quantity are given in Table 31.1.
Table 31.1 Table of the units used for two conventions
Quantity Metric Field

Length, depth, radius m ft
Time day day
Density kg/m 3 lbm/ft3
Pressure (absolute) Barsa Psia
Pressure (difference) Bars Psi
Temperature (absolute) K R
Temperature (difference) C F
Compressibility 1/Bars 1/Psi
Viscosity cpoise cpoise
Permeability MDarcy MDarcy
Liquid surface volume sm3 stb
Gas surface volume sm3 Mscf
Reservoir volume rm3 RB
Liquid surface volume rate sm3/day stb/day
Gas surface volume rate sm3/day MScf/day
FrontSim Technical Description Units 271

Table 31.1 Table of the units used for two conventions (Continued)

Reservoir volume rate rm3/day RB/day
Formation volume factor (liquid) rm3/sm3 RB/stb
Formation volume factor (gas) rm3/sm3 RB/Mscf
Gas-oil ratio sm3/sm3 Mscf/RB
Oil-gas ratio sm3/sm3 RB/Mscf
Transmissibility cp.m3/day/Bar cP.RB/day/Psi
Constants
Table 31.2 gives the values of some principal constants in the two unit conventions.
Table 31.2 Constants used in the two unit conventions

Gravity constant 0.0000980665 0.00694444
Darcy constant 0.00852702 0.00112712
Atmospheric pressure 1.01325 14.6959
Density of air 1.2232 0.076362
Density of water 999.014 62.3664
Gas constant, R 0.083143 10.732
Standard conditions are taken as one atmosphere and 60F.
272 Units FrontSim Technical Description

Conversion factors
Table 31.3 gives some useful conversion factors between the unit systems.
Table 31.3 Some useful conversion factors

Length 1m =3.28084 ft
0.3048 m =1 ft
Volume 1m 3 =35.31466 cf
=1 cf
0.02831685 m3
Mass 1 kg = 2.204623 lb
0.45359237 kg =1 lb
Density 1 kg/m 3 =0.06242797 lb/ft3
16.01846 kg/m3 =1 lb/ft3
Pressure 1 bar =14.50377 psi
0.06894757 bar =1 psi
Gas-liquid ratio 1 m3/m3 = 5.614583 10 3 mcf/Mscf
178.1076 m3/m3 =1 mcf/bbl
Temperatures T K = ( T 1.8 ) R
API gravity
API gravity = (141.5 / liquid gravity) - 131.5
Conversion for an ideal gas (Z=1)

For an ideal gas Z-factor of unity, we can use the ideal gas equation:
PV = nRT [EQ 31.1]
where:
P is pressure
V is volume
n is number of moles
R is the gas constant
T is temperature
Using [EQ 31.1], we can calculate the following:
When P = 14.7psia and T = 519.67R ,
the volume occupied by one mole of gas is:
V molar = 379.39445ft 3 [EQ 31.2]
FrontSim Technical Description Units 273

Conversion factors
the number of moles in unit volume is:
n moles = 0.00263578 mol [EQ 31.3]
When P = 1.013Bar and T = 288.15K ,

the volume occupied by one mole of gas is:
V molar = 23.650203 10 6 m 3 [EQ 31.4]
the number of moles in unit volume is:

n moles = 0.04228293 mol [EQ 31.5]
274 Units FrontSim Technical Description

Conversion factors
Index
Appendix A
Restrictions. . . . . . . . 56
A Specific Facilities . . . 55
Transmissibility Calculations52,
G
Aquifer Modeling. . . . . . . .29 54 GEOFLOFS
Carter-Tracy . . . . . . . .31 Using . . . . . . . . . . . . 80
Constant Flux . . . . . . .35 GEOFLOFS simulation . . . 81
Fetkovich . . . . . . . . . .33
Numerical . . . . . . . . .30 E Geologic Model Screening. 73
End Point Scaling

LGRs . . . . . . . . . . . . 96
B Equations of State . . . . . . . 59 H
Hydrocarbon Mixtures 64 Horizontal Well. . . . . . . . 265
Boundary Conditions . . . . .78 Three Parameter . . . . 63
Hydrocarbon Mixtures
Two parameter . . . . . 59
Equations Of State . . . 64
Equilibration
Hydrostatic Equilibration
C Algorithm . . . . . . . . . 88
Initial conditions . . . . 89
Basic . . . . . . . . . . . . 88
Carter-Tracy Aquifer . . . . .31 EXPL solver. . . . . . . . . . 212

Connection
Well . . . . . . . . . . . . .257 L
Constant Flux Aquifers . . . .35
Crossflow . . . . . . . . . . . .257
F Licenses . . . . . . . . . . . . . . 24
Local Grid Refinement . . . 93
Fetkovich Aquifers . . . . . . 33
Block Sizes . . . . . . . . 95
File Handling . . . . . . . . . . 67 Cartesian. . . . . . . . . . 94
D File internal format . . . . . . 69

Flash Calculations. . . . . . . 62
End Point Scaling . . . 96
Example . . . . . . . . . 101
Data Requirements . . . . . . .86 Grid Data . . . . . . . . . 98
Fluid In Place
Pore Volume . . . . . . . 98
Default Reports . . . . . . . . .82 Accurate Calculation . 90
Restrictions . . . . . . . . 97
Dual Porosity . . . . . . . . 51, 73 Frictional Pressure Loss . 265 Rock Properties . . . . . 96
Keyword summary . . .57 FrontSim Transmissibility . . . . . 98
Recovery Mechanisms.54 Features . . . . . . . . . . 15 Well . . . . . . . . . . 94, 97
FrontSim Technical Description Index 275

Consistency requirements 249
M 117
Gas saturation properties .
Corner Point . . . . . . 250
Dual Porosity . . . . 52, 54
Multi-phase Flow Simulation . 110
78 Oil saturation properties. .
111
Multi-segment Wells . . . . . 23
Table end points . . . . 116
Three phase oil relative
U
permeability Units . . . . . . . . . . . . . . . 271
N models. . . . 113
Constants. . . . . . . . . 272
Conventions. . . . . . . 271
109 Conversion factors . . 273
Numerical Aquifers . . . . . . 30
Saturation Table Scaling . . 119
125
P Example. . . . . . . . . .126 V
Miscellaneous points .124
Parallel Multicore . . . . . . 211 Scaling of relative permea- Viscosity Evaluation . . . . . 62
Pattern Flood Management 215 bility functions .
121
Phase States . . . . . . . . . . . 66
Simulation . . . . . . . . . . . . .77
Pore Volume
Steady State . . . . . . . . . . . .77
W
LGRs . . . . . . . . . . . . 98
Well
Pressure
Connection . . . . . . . 257
Frictional Loss. . . . . 265
Control . . . . . . . . . . 259
T Crossflow . . . . . . . . 257
Economic Limit . . . . 259
Tensor Permeability . . . . .193
R Discretization . . . . . .195
Horizontal . . . . . . . . 265
Limit. . . . . . . . . . . . 259
Recovery Mechanisms. . . . 54 Time Stepping . . . . . . . . . .79 Treatment in Local Grids
Timesteps . . . . . . . . . . . . .97 97
Reporting . . . . . . . . . . . . . 79
Total Compressibility Checks . Well Modeling Facilities . 257
Restarts . . . . . . . . . . . . . 105
241 Group and Field Controls
Restrictions . . . . . . . . . . . 82 262
Tracer Tracking . . . . . . . .245
Local Grid Refinement 97 Well Completions. . . 257
Tracking
Well Controls and Limits
Tracer . . . . . . . . . . .245 259
Transmissibility Wellbore Friction. . . . . . . 265
S Calculations . . . . . . . .96
Wells
LGRs . . . . . . . . . . . . .98
Saturation Functions . . . . 107 Multi-segment . . . . . . 23
Transmissibility Calculations. .
276 Index FrontSim Technical Description

Post 901 1275120003.ipb

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Post 901 1275120003.ipb

Загружено:

Авторское право:

Доступные форматы

FrontSim

Service mark information

Standard buttons in interactive programs

FrontSim Technical Description 3

4 FrontSim Technical Description

Chapter 1 - Introduction ................................................................................................................. 13

Chapter 2 - Allocation Factors....................................................................................................... 25

Chapter 3 - Aquifer Modeling Facilities ........................................................................................ 29

Chapter 4 - Time stepping control................................................................................................. 37

Chapter 5 - Dual Porosity ............................................................................................................... 51

Chapter 6 - Equations of State ...................................................................................................... 59

Chapter 7 - File Handling in FrontSim........................................................................................... 67

Chapter 8 - Geologic Model Screening ......................................................................................... 73

FrontSim Technical Description 5

Chapter 9 - Initializing the Study ................................................................................................... 85

Chapter 10 - Local Grid Refinement.............................................................................................. 93

Chapter 12 - Restarts.................................................................................................................... 105

Chapter 13 - Saturation Functions .............................................................................................. 107

Chapter 14 - Saturation Table Scaling .........................................................................................119

Chapter 15 - The Streamline Concept ......................................................................................... 129

Chapter 16 - Streamline Tracing .................................................................................................. 139

Chapter 17 - IOR Tracer Logic Guide .......................................................................................... 143

Chapter 18 - Tensor Permeability ................................................................................................ 193

6 FrontSim Technical Description

Chapter 20 - The Pressure Equation ........................................................................................... 207

Chapter 21 - Multicore Parallel Option........................................................................................ 211

Chapter 22 - Pattern Flood Management .................................................................................... 215

Chapter 23 - Three-Phase Saturation Solver.............................................................................. 233

Chapter 24 - Total Compressibility Checks ................................................................................ 241

Chapter 25 - Tracer Tracking........................................................................................................ 245

Chapter 26 - Transmissibility Calculations................................................................................. 249

Chapter 27 - Well Inflow Performance ........................................................................................ 253

Chapter 28 - Well Modeling Facilities.......................................................................................... 257

FrontSim Technical Description 7

Chapter 31 - Units ......................................................................................................................... 271

Appendix A - Index ....................................................................................................................... 275

8 FrontSim Technical Description

FrontSim Technical Description 9

10 FrontSim Technical Description

FrontSim Technical Description 11

The ECLIPSE simulator suite

About this manual

FrontSim Technical Description Introduction 13

14 Introduction FrontSim Technical Description

Free format input

FrontSim Technical Description Introduction 15

Saturation table scaling

Individual well controls

16 Introduction FrontSim Technical Description

Group and field production controls

Crossflow and co-mingling in wells

Highly deviated and horizontal wells

Fine grid equilibration

FrontSim Technical Description Introduction 17

18 Introduction FrontSim Technical Description

Note GRAF does not support .SLNxxxx file formats.

FrontSim Technical Description Introduction 19

20 Introduction FrontSim Technical Description

FrontSim Technical Description Introduction 21

22 Introduction FrontSim Technical Description

FrontSim Technical Description Introduction 23

24 Introduction FrontSim Technical Description

Determine allocation factors