Front Sim Technical Description

FrontSim
Version 2017.2
Technical Description
FrontSim Technical Description
Copyright Notice
Copyright © 2017 Schlumberger. All rights reserved.
This work contains the confidential and proprietary trade secrets of Schlumberger and
may not be copied or stored in an information retrieval system, transferred, used,
distributed, translated or retransmitted in any form or by any means, electronic or
mechanical, in whole or in part, without the express written permission of the copyright
owner.
Trademarks & Service Marks
Schlumberger, the Schlumberger logotype, and other words or symbols used to identify
the products and services described herein are either trademarks, trade names or
service marks of Schlumberger and its licensors, or are the property of their respective
owners. These marks may not be copied, imitated or used, in whole or in part, without
the express prior written permission of Schlumberger. In addition, covers, page headers,
custom graphics, icons, and other design elements may be service marks, trademarks,
and/or trade dress of Schlumberger, and may not be copied, imitated, or used, in whole
or in part, without the express prior written permission of Schlumberger. Other company,
product, and service names are the properties of their respective owners.
An asterisk (*) is used throughout this document to designate other marks of

Schlumberger.
Security Notice
The software described herein is configured to operate with at least the minimum
specifications set out by Schlumberger. You are advised that such minimum
specifications are merely recommendations and not intended to be limiting to
configurations that may be used to operate the software. Similarly, you are advised that
the software should be operated in a secure environment whether such software is
operated across a network, on a single system and/or on a plurality of systems. It is up
to you to configure and maintain your networks and/or system(s) in a secure manner. If
you have further questions as to recommendations regarding recommended
specifications or security, please feel free to contact your local Schlumberger
representative.
Table of Contents
1 Introduction .................................................................................................. 1
FrontSim features ............................................................................................................. 1
Additional programs ......................................................................................................... 4
Licenses ............................................................................................................................. 6
2 Allocation factors ......................................................................................... 7

Allocation factor reports .................................................................................................. 7
3 Aquifer modeling facilities ........................................................................ 12

Numerical aquifer ............................................................................................................ 12
Carter-Tracy aquifer ........................................................................................................ 13
Fetkovich aquifer ............................................................................................................ 15
Constant flux aquifer ...................................................................................................... 17
5 Dual porosity .............................................................................................. 30

Transmissibility calculations ......................................................................................... 30
Recovery mechanisms ................................................................................................... 32
Facilities specific to dual porosity runs ........................................................................ 32
Restrictions on dual porosity runs ................................................................................ 33
Summary of keywords .................................................................................................... 33
6 Equations of state ...................................................................................... 34

Flash calculations ........................................................................................................... 36
Three-parameter equations of state .............................................................................. 37
Use of the equation of state for hydrocarbon mixtures .............................................. 38
Calculation of phase states ............................................................................................ 40
7 File handling in FrontSim .......................................................................... 41

File internal format .......................................................................................................... 42
Graphics post-processors ............................................................................................. 43
8 Geologic model screening ........................................................................ 44

Theory .............................................................................................................................. 45
Steady State Single Phase Tracer Flow Simulation ..................................................... 47
How to use GEOFLOFS .................................................................................................. 49
9 Initializing the study .................................................................................. 54

Data requirements ........................................................................................................... 54
i
The equilibration algorithm ............................................................................................ 55

Calculating the initial conditions ................................................................................... 56
10 Licenses ...................................................................................................... 59
Special cases ................................................................................................................... 60
11 Local grid refinement ................................................................................ 62

Local grid refinements .................................................................................................... 62
Geometry and grid data in LGRs ................................................................................... 66
12 Restarts ....................................................................................................... 70
Requesting RESTART files in FrontSim ....................................................................... 70
Notes on RESTARTS in FrontSim ................................................................................. 71
13 Saturation functions .................................................................................. 72

Water saturation properties ........................................................................................... 73
Gas saturation properties .............................................................................................. 74
Oil saturation properties ................................................................................................ 74
Three-phase oil relative permeability models .............................................................. 75
Table end–points ............................................................................................................. 78
Consistency requirements ............................................................................................. 78
14 Saturation table scaling ............................................................................ 81

Scaling of relative permeability functions .................................................................... 82
Miscellaneous points ...................................................................................................... 85
Consistency requirements ............................................................................................. 86
Example of end–point scaling ....................................................................................... 86
15 The streamline concept ............................................................................. 89

The governing equations ............................................................................................... 89
The solution strategy ...................................................................................................... 91
16 Streamline tracing ...................................................................................... 96

Streamline parameters ................................................................................................... 96
17 IOR tracer logic guide .............................................................................. 100

The workflow of building the IOR tracer and truth model ......................................... 100
Modeling IOR dynamics with tracers .......................................................................... 106
Keywords and parameters for the IOR tracer model ................................................. 118
Scaling the model to match the field IOR mechanisms ............................................ 128
The IOR model simulation output ................................................................................ 136
18 Tensor permeability ................................................................................. 144

Discretization ................................................................................................................. 145
ii
Orthogonality error ....................................................................................................... 146
19 The Oil/Water Front Tracking Saturation Solver ................................... 148

The front-tracking method ........................................................................................... 148
20 The pressure equation ............................................................................ 155

Pressure equation ......................................................................................................... 155
Equation solution method ............................................................................................ 156
21 Parallel multicore option ......................................................................... 158

Scalability ...................................................................................................................... 159
22 Pattern flood management ...................................................................... 161

Problem solving ............................................................................................................ 162
Using PFM ...................................................................................................................... 163
Workflow ........................................................................................................................ 163
Waterflood patterns ...................................................................................................... 164
FrontSim patterns ......................................................................................................... 165
Allocation Strategy ....................................................................................................... 167
Example showing computation of weights ................................................................ 169
Aquifers .......................................................................................................................... 170
Multi-zone waterfloods ................................................................................................. 170
Combining well management and PFM controls ....................................................... 170
Exporting PFM rates to a separate include file .......................................................... 172
23 Solvent model .......................................................................................... 173

Implementation .............................................................................................................. 174
Applications ................................................................................................................... 174
Model formulation ......................................................................................................... 175
Using the Solvent model .............................................................................................. 181
Summary of keywords .................................................................................................. 183
Example problem .......................................................................................................... 185
Solvent pattern flood management - solvent allocation ........................................... 189
24 Three-phase saturation solver ................................................................ 198

Streamline solution ....................................................................................................... 198
Gravity line solution ...................................................................................................... 200
Mapping the solution between streamlines and the grid .......................................... 200
Tuning ............................................................................................................................ 202
Keywords ....................................................................................................................... 202
25 Total compressibility checks .................................................................. 203
iii
26 Tracer tracking ......................................................................................... 206

The tracer equation ....................................................................................................... 206
27 Transmissibility calculations .................................................................. 209

Corner point transmissibility calculations ................................................................. 209
28 Well inflow performance ......................................................................... 211

Inflow performance relationship .................................................................................. 211
The connection transmissibility factor (Cartesian grids) .......................................... 212
The productivity index .................................................................................................. 213
29 Well Modeling Facilities .......................................................................... 214

30 The wellbore friction option .................................................................... 219
Calculating the frictional pressure loss ...................................................................... 219
31 Units .......................................................................................................... 222

Conversion factors ....................................................................................................... 223
A FrontSim development history ............................................................... 225

Developments for 2016.1 and 2016.2 .......................................................................... 225
Developments in 2008.1 and 2008.2 ............................................................................ 241
New developments for 2007.1 and 2007.2 .................................................................. 247
B Bibliography ............................................................................................. 251
iv
1
Introduction
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 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.
Introduction
1
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. PETREL can be used
to prepare corner-point data for FrontSim or ECLIPSE. PETREL may also 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" 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 data set. Space is saved by not storing unnecessary data for inactive
cells.
PVT and rock data
FrontSim honors the user-specified pressure and saturation function data precisely. 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" 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" for further information.
Introduction
2
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.
See "Well controls and limits" 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 group’s 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" 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:
a. The transmissibility between the grid block and the well bore.
b. The mobility of the phase in the grid block at the perforations
c. The pressure drawdown between the grid block and the well bore.
FrontSim takes full account of all three quantities when apportioning a well’s 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
Introduction
3
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 well’s
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.
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" 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, and so on, of each
aquifer cell may be specified separately, giving you complete flexibility in defining each aquifer.
See "Aquifer Modeling Facilities" for further information.
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.
Introduction
4
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
zigzagged. 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.
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 streamlines. The
program contains a host of new options to allow easier visual interpretation of the grid and its
results.
PlanOpt
PlanOpt is an interactive tool to assist you in choosing the potential locations of vertical
production wells during development. PlanOpt applies predefined 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 VFP i.
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 three-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.
Introduction
5
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 Multisegment Well Model. It can read data
describing casing, liner and tubing characteristics and locations of chokes, packers and inflow
control valves.
Licenses
To run FrontSim, and 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 data set 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.
Introduction
6
2
Allocation factors
If the mnemonic in the RPTSCHED keyword is set, FrontSim will generate allocation reports in the .prt
ECLIPSE 100 file or a separate .alloc file in ASCII-format. If the ALLOC mnemonic is set to 1 - a simple report is
ECLIPSE 300 generated including allocation factors and pore volumes (drainage area) for wells and for injector-producer
x FRONTSIM 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.
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 (surface volumes are volumes in the bundle, not
total production volumes).
• Pore Volume. The pore volume represented by the bundle or well.
• Allocation factor. Bundle rate divided by well rate.
Allocation factors
7
• I-edge. Injection not represented by an injector - which is the boundary conditions (PSIDE and other
boundary keywords).
• P-edge. Production not represented by a producer - which is the boundary conditions (PSIDE and
other boundary keywords).
• The total pore volume not visited by any streamline and the total pore volume for the reservoir are also
reported.
Examples
Example 1
Using RPTSCHED, ALLOC=3 for complete output.
Allocation factors
8
Allocation factors
9
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.
Allocation information to OFM or MS EXCEL

Using the controls in the RPTALLOC keyword formatted output of allocation/bundle information are
exported to the .ALN file. The data on this file can easily be imported to OFM or MS EXCEL.
The contents of the file are described in the tables below:
Properties Description
Pattern Set "FS_PRODUCER_BASED" or "FS_INJECTOR_BASED"
Start Bundle Well id number
End Bundle Well id number
Date Time format: dd.mm.yyyy
Oil Production Floating point value
Water Production Floating point value
Water Injection Floating point value
Bundle Pressure Floating point value
Pattern Average Pressure Floating point value
Injection Efficiency Floating point value
Allocation factors
10
Properties Description
Pore Volume Floating point value
Table 2.1: Contents of ALN file - Well level
Properties Description/Example
Start Pattern Well Well id number
Oil Production for Pattern Floating point value
Water Production for Pattern Floating point value
Water Injection for Pattern Floating point value
Table 2.2: Contents of ALN file - Well pattern level
Properties Description/Example
Start Completion Bundle Well id number
End Completion Bundle Well id number
Oil Production Floating point value
Water Production Floating point value
Water Injection Floating point value
Table 2.3: Contents of ALN file - Zone (completion) level
Allocation factors
11
3
Aquifer modeling facilities
This chapter describes the aquifer models available in FrontSim. These are:
x ECLIPSE 100
• Numerical aquifers
x ECLIPSE 300
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.
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

12
2 ⋅ PERMX i ⋅ XSECT i
Ti =
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 center 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.
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):
μw φCt ro2
Tc = Eq. 3.2
ka c 1
where
ka is the aquifer permeability
φ is the aquifer porosity
μw is the viscosity of water in the aquifer

13
Ct is the total (rock + water) compressibility
ro is the outer radius of the reservoir (or inner radius of the aquifer)
c 1 is 0.008527 (METRIC); 0.006328 (FIELD);
and the aquifer influx constant (with the dimension of total influx per unit pressure drop)
β = c 2 hθφCt ro2 Eq. 3.3
where
h is the aquifer thickness
θ is the angle astounded by the aquifer boundary from the center of the reservoir, in degrees divided by
360
c 2 is 6.283 (METRIC); 1.1191 (FIELD).
The time constant Tc is used to convert time t into dimensionless time tD 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 PI D by
Qa
p a 0 − p̄ = PI D ( t D ) Eq. 3.5
β
where
Qa is the aquifer inflow rate
pa 0 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 p i (t + Δ t ) - p i (t ) } Eq. 3.6
where
βΔp ai - W a (t)(PI D ′ ) (t + Δt ) D
a =
1
Tc { PI D (t + Δt ) D -t D PI D ′ (t + Δ t ) D } Eq. 3.7
and

14
β
b = Eq. 3.8
T c PI D (t + Δt ) D -t D PI D ′ (t + Δ t ) D
where
Δ pai is the pressure drop pa 0 + ρg (di -da ) - pi ( t + Δt )
PI D ′ is the derivative of PI D with respect to tD
αi is the area fraction for each connection.
Here, the area fraction for each connection is given by:

mi Ai
αi =
Σm i A i
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 equation 3.6 contribute the residual for the implicit equations
solved by FrontSim at time t . The cumulative aquifer influx W a (t ) used in equation 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 equation 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. 7].
Fetkovich aquifer
The Fetkovich aquifer model uses a simplified approach based on a pseudo steady-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:

15
d
Q ai = W = Jα i p a -p i + ρg ( d i -d a ) Eq. 3.9
d t ( ai )
where
Qai is the inflow rate from the aquifer to the connecting grid block i
Wai 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
Σm i A i
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 Ai 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
W a = C t V w 0( p a 0-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
Vw 0 is the initial volume of water in the aquifer
pa 0 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.

16
The aquifer performance essentially depends on two parameters, the aquifer time constant and the
productivity index. The aquifer time constant is given by
Ct Vw 0
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
equations 3.9 and 3.11, the average influx rate over the time interval Δt is expressed as
(-Δt / T c )
Q¯ai = α i J ( p a -p i + ρg ( d i -d a )) ( 1-e
Δt / T c ) Eq. 3.13
which is the form used by FrontSim to compute the influx rates.

At the end of each timestep, the aquifer’s cumulative total influx is incremented and its pressure is updated
using equation 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 Ct Vw 0 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 equation 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. 16].
Constant flux aquifer

The water influx rate for a constant flux aquifer is user-specified instead of being calculated by an analytic
aquifer model. But, for the purpose of dimensioning, and other operations, 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
Qai is the inflow rate from the aquifer to the connecting grid block i
Fa is the user-specified aquifer flux
Ai is the area of the connecting face of grid block i, which is calculated directly from the cell geometry

17
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 using the keyword AQUANCON. To
achieve time-dependency, the flux may be modified during simulation by reentering 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.

18
4
Timestepping control
FrontSim supplies user timestepping control keywords to determine timestep size at run time. These
ECLIPSE 100 keywords are in following three categories:
ECLIPSE 300
1. DATES or TSTEP
x FRONTSIM
2. NEXTSTEP, MINSTEP, MAXSTEP
3. TSCRITFS.
The FrontSim timestepping 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 subdivide 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 timestepping 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 timestepping controller chooses the smallest autostep among user-activated methods.
FrontSim can internally determine a half reporting step when the selected timestep (from the timestep
controller) is more than 50% of the current remaining reporting step. This Half Reporting step is made to
facilitate SUMMARY section reporting needs.
Timestepping control methods

Reporting steps
DATES and TSTEP are the standard keywords to specify reporting steps. Reporting steps define the
primary target dates honored during run time.
Timestepping 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 timestep
controller can compute appropriate manual and automatic steps suitable for the model.
19
Manual timestepping control

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

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

The fluid volume step limits the maximum phase fluid volume change δV Resv
Phase to MXFVCHG fraction of
total pore volume PV N
Total :
MXFVCHG × PV N
Δt N
FV = MIN { δV Resv /
Total
Phase δt
} Eq. 4.1
where:
N is the estimated fluid volume step at the current timestep N (days). The MIN is defined as the
Δt FV
minimum of oil, water and gas phases fluid volume timesteps present.
MXFVCHG is the user-input fraction limit (dimensionless); this ratio is the mnemonic “ MXFVCHG ” in
keyword TSCRITFS.
PV N
Total
is the total fluid volume in reservoir condition at the current timestep.
δV Resv
Phase δt/is the estimated phase fluid volume throughput rate,
Resv Resv Resv

δV Phase / |
δt = V InFlux − V OutFlux | Phase / δt
Where
Resv is the influx volume which includes wells and boundary influx, and
VInFlux
Resv is the outflux volume which includes wells and boundary outflux.
VOutFlux
20
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 timestep.
Pore volume timestep control

Pore volume step is based on limiting the maximum convection throughput, which is MXTHRUPT × PV N
within one pore volume timestep:
MXTHRUPT × PV N
Total
Δt N
PV =
Eq. 4.2
MAX( δV Inj / δt, δV Prod / δt)
where:
N is the estimated pore volume autostep for the current step N (DAYS),
Δt PV
MXTHRUPT is the user-input parameter to set the model pore volume fraction change
limit. This is the mnemonic “ MXTHRUPT ” in keyword TSCRITFS.
PV N
Total
is the phase pore volume sum at timestep N,
MAX ( δV Inj / δt , δV Prod / δt ) is the estimated maximum of total volume injection and total volume
production throughput rate at the timestep N (in reservoir conditions).
Pressure change timestep control

¯
Pressure timestep control estimates a pressure rate of change (dP / dt ) Est within timestep N, to limit the
maximum change of average pressure change to MXDELPA × P¯ N within one pressure step:
MXDELPA × P¯ N
Δt N
Pressure = Eq. 4.3
¯
(dP / dt ) Est
where:
Δt N
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 is the model average pressure at timestep N,

P
¯
(dP / dt ) Est is the estimated average pressure rate of change during current timestep N.
A pressure timestep can be used to limit pressure change during each run timestep. 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 timestep may be modified when the actual pressure change within a timestep 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 timestep does not alternate from a very large step size to a very small step size.
21
Large variations among timesteps 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 timestep control

Flux timestep control determines a flux autostep by comparing the averaged flux change between two
previous timesteps, and by computing a flux step based on this change:
ΔT N
Remain
Δt N = Eq. 4.4
Flux M
Δt N
Flux
is the estimated flux autostep for the current step N,
ΔT N
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
Composite
M = Eq. 4.5
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 δFlux N and pore volume throughput change δPV N for the current
timestep N.
This scales the difference in measure between model average cell flux and model pore volume throughput:
ΔΦ N |
Composite = δPV
N
− δFlux N | Eq. 4.6
where:
δPV N is the relative pore volume change over two previous timesteps,
δFlux N is the relative model cell flux change over two previous timesteps,
N −1
( )
δPV N
|
= 1.0 −
MAX PV Throughput
N
MAX(PV Throughput ) | Eq. 4.7
MAX PV N
( -1
Throughput
is pore volume throughput in the previous timestep N-1, computed max. throughput
)
as described in the Pore Volume timestep control.
22
MAX PV N
( Throughput
is pore volume throughput in the current timestep N, computed in the same manner
)
as described in the Pore Volume timestep control.
Note that pore volumes are in reservoir conditions.

where:
N − 1
|
δFlux N 1.0 −
F cell
N
F cell | Eq. 4.8
N -1 is the cell flux measure in the previous timestep N-1,

Fcell
N is the cell flux measure in the current timestep N.

Fcell
where:
Cell flux measure Fcell has multiple modes.
The flux timestep 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 timestep control is based on computing flux changes ΔΦ N Composite between two previous
timesteps, flux timestep is only computed/enforced one timestep after it is activated. Other timestepping
facilities are enforced on the same timestep as they are activated.
Flux timestep control may internally compute a control flux step with averaged flux timesteps 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 timestep, and
to improve pressure solve convergence speed. Slower convergence can occur due to use of uneven flux
autosteps.
Flux timestep control is a second-order timestepping mechanism whose usage often increases when some
type of flux anomaly or instability occurs. Flux timestep control makes an effort to resolve this type of
difficulty and to help continue the current run.
Pressure solver convergence timestep control

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

The FrontSim timestepping controller enforces two sweeps in each timestep in order to calculate the proper
timestep.
Sweep one is prior to the pressure update; the timestep is computed by enforcing the following three
priorities:
23
DATES or TSTEP defines report steps
NEXTSTEP, MINSTEP and define user-set manual timestepping limits

MAXSTEP
TSCRITFS defines the smallest auto timestep computed by all activated

automatic timestepping facilities.
The FrontSim timestep controller computes a maximum timestep 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 timestep reason will become Updated Reason. The
REDO event may happen many times during one timestep; this typically signals certain kinds of difficulties
or instabilities at run time.
When a model runs into difficulty at run time, the timestep control can issue various reasons such as
PRESSURE, FluxStep, MINSTEP or HalfRep.
Note: A simple converged model should not lead to complex auto timestepping decisions like those
described above.
Timestepping 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 five-day timestep.
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 timestep control limits the change of saturation in the cell in one timestep, by 5%
in the example above.
• Pore volume throughput timestep control limits the amount of mass one can inject/produce from this
cell in one timestep, by 10% in the example above.
• Pressure change timestep control limits the maximum change of pressure in the cell, currently as a
fraction of the current average pressure.
24
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
25
@ 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
26
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
27

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
28

Saving : FSTIMESTP_C1_MOBILITY.X0001
29
5
Dual porosity
This chapter describes the fractured reservoir option. The implementation uses a special three-phase
x ECLIPSE 100 compressible, dual porosity formulation suitable for streamline simulation as published in [Ref. 31].
x ECLIPSE 300
In a dual porosity reservoir, fluids exist in two interconnected systems:
x FRONTSIM
• 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.
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 LENGTH-2, to account for the matrix/fracture interface area per unit
volume, that is the size of the blocks in the matrix volume.
Dual porosity
30
Kazemi [Ref. 24] has proposed the following form for σ :

1 1 1
σ =4
( lx 2
+
ly 2
+
lz 2 ) Eq. 5.2
where
lx, ly and lz are typical X, Y and Z dimensions of the blocks of material making up the matrix volume. (lx , ly
and lz 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.
Figure 5.1. A simple, dual porosity, dual permeability system.
Dual porosity
31
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.
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.
Dual porosity
32
Partially fractured reservoirs

In a dual porosity single-permeability run, the simulation model may be specified to be dual porosity only
in part of the reservoir, using the keyword DPNUM. FrontSim treats the rest of the reservoir as in a
conventional single porosity run. In this case, the single porosity cells are taken to be matrix cells for input
purposes, and any data input for fracture cells in the single porosity region is ignored.
Since for Dual Porosity models in FrontSim the streamline tracing is only done in the fracture cells,
FrontSim will copy the contents of the matrix cell into the fracture cell and then remove the matrix cell.
This is different behavior than ECLIPSE 100 and ECLIPSE 300 where the fracture cell is removed.
Note: Whenever completions and aquifer contacts are input; any such contacts in the matrix will be ignored
by FrontSim.
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.
Summary of keywords
The following table shows a summary of 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 box.
required
DPGRID Optional You use this 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.
Table 5.1: Dual porosity keywords
Dual porosity
33
6
Equations of state
Two-parameter equations of state

ECLIPSE 100
Note: FrontSim uses ECLIPSE 300 software for all equation of state calculations.
x ECLIPSE 300
x FRONTSIM
ECLIPSE 300 incorporates four equations of state and two additional variations to the Peng-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 Martin’s equation, [Ref. 28] and [Ref.
10].
The generalized form of such an equation of state is:
Z 3 + E2Z 2 + E1Z + E0 = 0 Eq. 6.1
with:
E 2 = (m 1 + m 2-1) B - 1 Eq. 6.2
E 1 = A - m 1 + m 2-m 1m 2 B 2 - (m 1 + m 2) B
( )
E 0 = - AB + m 1 m 2 B 2(B + 1) Eq. 6.3
The coefficients m 1 and m 2 depend upon the equation used. Refer to the table below for details.
Equations of state
34
Equation of State m1 m2
Redlich-Kwong 0 1
Soave-Redlich-Kwong 0 1
Zudkevitch-Joffe 0 1
Peng-Robinson 1 + 2 1- 2
Table 6.1: Coefficients m1 and m2: variation with the equation of state
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:
2Σ i B i Z + m 2B Bi
ln ( f i / ( px i )) = - ln (Z -B ) +
A
(
( m 1-m 2)B A B
- )(ln
Z + m 1B)+
B
(Z -1) Eq. 6.4
where:
Σ i = Σ A ij x j
j
n n
A = Σ Σ x j x k A jk
j = 1 k = 1
n
B = Σ xj Bj
j = 1
1
A jk = (1-δ jk ) ( A j A k ) 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
A j = Ω a (T , j ) Eq. 6.5
T rj2
P rj
B j = Ω b (T , j ) Eq. 6.6
T rj
Ω a (T , j ) and Ω b (T , j ) are functions of the acentric factor wj and the reduced temperature Trj .
• For Redlich-Kwong:
1
-
Ω a (T , j ) = Ω a T rj 2 Eq. 6.7
o
Ω b (T , j ) = Ω b Eq. 6.8
o
• For Soave-Redlich-Kwong:
Equations of state
35
Ω a (T , j ) = Ω a 1+ (0.48 + 1.574w j − 0.176w j 2) 1 − T rj1/2

( )2 Eq. 6.9
o
Ω b (T , j ) = Ω b Eq. 6.10
o
• For Zudkevitch-Joffe:
Ω a (T , j ) = Ω a F aj (T )T rj−1/2 Eq. 6.11

o
Ω b (T , j ) = Ω b F bj (T ) Eq. 6.12
o
• For Peng-Robinson:
Ω a (T , j ) = Ω a 1+ 0.37464+ 1.54226w j − 0.26992w j2 1 − T rj1/2

( )( )2 Eq. 6.13
o
Ω b (T , j ) = Ω b Eq. 6.14
o
1
As Tr = T / Tc , the SRK and PR forms for Ωa and Ωb may be expanded as a polynomial in 1 / T 2
, for
example,
1
Eq. 6.15
Ω a (T , j ) = A + B ⋅ T 2
+ CT
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
wj > 0.49. This correction is invoked by use of the PRCORR keyword.
Ω a and Ω b are constants depending upon the equation of state, as shown in the table below.
0 0
Equation of state Ωa Ωb
0 0
RK, SRK, ZJ 0.4274802 0.08664035

PR 0.457235529 0.07796074
Table 6.2: The dependence of Ωa0 and Ωb0 on the equation of state
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 F bj (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:
Equations of state
36
fiL = fiV Eq. 6.16
As described above, the fugacities are functions of temperature, pressure and composition:
fi = fi (T , p , xi ) Eq. 6.17
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:
yi
Ki = Eq. 6.18
xi
The mole fractions of each component in the liquid and vapor phases are given as:
zi
xi = Eq. 6.19
1 + ( K i − 1)V
Ki zi
yi = Eq. 6.20
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.
Three-parameter equations of state

The traditional weakness of the two-parameter equations of state (EoS), such as the Peng-Robinson,
Redlich-Kwong, and so on 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 ZcVdW = 0.375, ZcRK = 0.333 and Zcpr = 0.307. But hydrocarbons are known to have
Zc < 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 V mol,p is given by:
N
EoS
V mol,p = V mol , p - Σ z i c i Eq. 6.21
i = 1
where
p = (liquid, vapor) represents the phase of the system
EoS is the molar volume of the phase predicted by the traditional two-parameter EoS
V mol , p
zi = (xi , yi ) are the liquid and vapor mole compositions
Equations of state
37
ci constitute a set of volume corrections.
The component corrections are usually related to set of dimensionless shift parameters si , by:
ci
si = Eq. 6.22
bi
where:
Ωb ,i RTci
bi =
pci
The shift parameters are entered in the dimensionless form using the keyword SSHIFT.
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 A
P = - Eq. 6.23
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 Tc , Pc , Vc or Zc , ω , Ω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
PVT i program.
Determining equilibrium conditions

The calculation process determines 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, Ki , are assigned to each component, i, from the previous iteration, or, if none exist, from
Wilson’s formula, stated below:
Equations of state
38
e
5.37(1-ω i ) 1-
( T ri ) Eq. 6.24
Ki =
P ri
Then, given zi and Ki , ECLIPSE 300 solves the Flash Equation for the molar fraction of vapor, V. Details
of this Flash Equation are shown overleaf.
N comps z i ( K i -1)
g (V ) = Σ =0 Eq. 6.25
i = 1
1 + V( K 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 comps Eq. 6.26
y i = ( K i z i ) / 1 + V ( K i -1) , i = 1, 2, ……N comps Eq. 6.27
PV
The compressibility factor is defined as Z = . As a result, the Peng-Robinson equation of state can be
RT
expressed in terms of Z:
Z 3-Z 2(1-b ) + Z ( a -3b 2 - 2b ) − ( ab - b 2 - b 3) = 0 Eq. 6.28
where
AP
a =
R 2T 2
BP
b =
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,
fLi = fVi .
A convergence criteria is then used to determine if a grid block is in equilibrium (if ε is very small),
nc f iL 2
Σ
i = 1
( )
f iV
-1 <ε Eq. 6.29
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:
f iL
K iNEW = K iOLD ⋅ Eq. 6.30
f iV
After equilibrium is achieved, ECLIPSE 300 begins the next non-linear iteration.
Equations of state
39
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. 29]. 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 nontrivial 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.
• Newton’s method involves order N3 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.
14]. 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. 12].
Equations of state
40
7
File handling in FrontSim
A number of files may be produced by FrontSim for each simulation run.
x ECLIPSE 100
These are:
x ECLIPSE 300
x FRONTSIM
File Function Keywords
PRT file Main printer output RPTSCHED and RPTPRINT
keywords
GRID file Grid geometry file GRIDFILE keyword
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 the WRFTPLT
wellbore or the connecting grid blocks at selected
times in the run.
RSM file RSM (Run Summary) report in either EXCEL OPTIONFS
format, XML format or ECLIPSE format.
Table 7.1: FrontSim Files
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.

41
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
you 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.
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 eight-character keyword which identifies the data in the block.
• A four-byte integer containing the number of elements (NEL) in the block.
• A four-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

42
’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, 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.

43
8
Geologic model screening
This chapter describes the application of the GEOFLOFS keyword.
ECLIPSE 100
The GEOFLOFS keyword encapsulates the functionality required to perform multiphase fluid flow
ECLIPSE 300
simulation using an incompressible rock and fluid model. The transport phenomena modeled is limited to
x FRONTSIM
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
multimillion 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 is 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.
If you are an experienced FrontSim user, you can 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 in 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 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 are available to provide the
maximum power when working with multimillion 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.

44
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 center of a stream tube. It is inefficient to compute stream tubes for 3D problems. However, it is easier
to construct streamlines in 3D and associate them to stream tubes in an implicit manner. Thus, we can
assign pore volumes to streamlines. This property of streamlines allows us to analyze easily 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 to a sink/producer. Mathematically, it is defined as:
φ
τ = ∫
0
s
ut
ds Eq. 8.1
where
τ time of flight
φ porosity
ut Darcy velocity
s distance along the streamline
PV i = Q i ⋅ τ i Eq. 8.2
where
Q flow rate in streamline i
τi TOF attend 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". 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 the following equation:

45
∇ • (-λ t ∇p ) = q i Eq. 8.3
where
λt total mobility
∇ p pressure drop
qi n0
total flow rate = Σ q j
j −1
A difference form of equation 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
kj
λj =
μj
kj effective permeability to phase j
μj viscosity of phase j
and
k j = k ⋅ k rj
k permeability of porous medium
krj 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.

46
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, that is equal to 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 an 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 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 compare fine-scale models with their upscaled versions.
Multiphase 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

47
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 8.1. However, you 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 multiphase 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 equations 8.3 and 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. You 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, for example gas phase, more pressure updates will be required. In
addition, pressure field needs to be recalculated 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 input using GEOFLOFS controls
how subsequent input data and output are handled. There are currently five types of simulations:
• Simulations using wells to control flow behavior (Type 1 and 2).
• Simulations using pressure boundary conditions at the edges of the model (Type 3, 4 and 5).
Type 1 simulations enable the use of auto-generated source/sink well patterns (see DEFWPAT). If
DEFWPAT is not specified, default values will be used. All auto-generated wells are controlled by BHP
where the value can be set by the user (same value for all injectors and respectively producers).
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.

48
It is possible to override the default injection controls in the GEOFLOFS keyword and opt to use controls
defined in the SCHEDULE section. You must 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, 4 and 5 simulations do not use wells and instead use constant pressure boundary conditions at
opposite edges of the grid. The simulations are restricted to two phases (oil-water) only. In general, type
3-5 simulations are more restrictive than type 1 and 2 simulations.
Type 3 refers to a pressure gradient being applied from the left side of the grid towards the right side, Type
4 to a pressure gradient from back to front and type 5 to a pressure gradient from the top to the bottom. 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-5 simulations are strictly limited to one
timestep and it is not possible to change the pressure boundary conditions during a run.
Type 3-5 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.
Timestepping and reporting

FrontSim performs a pressure calculation at every user-defined timestep 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 timesteps. For a steady-state, single-
phase flow simulation - only one step is required.
When variations in mobility and gravity are introduced, more pressure computation steps will be required
to maintain sufficient accuracy. The saturation solver timesteps 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 three phases; oil, gas and water, are supported it is primarily intended to cover

49
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.
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 may be required in order to define the source/sink points, modify historical
production control and well control adjustments to maintain incompressibility conditions.
Type 3-5 simulations are intended to assist primarily 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-5 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 using the inverse of
TOF versus streamline number for the fine and coarse models. FrontSim sorts all the streamlines based on
descending velocity (1/TOF) and bin them into bundles with equally bundled Pore Volumes (Total PV/
Number Of Bins). This implies that the first bin consists of fewer streamlines than the last ones. FrontSim
then reports the bundled (accumulated) Streamline Flow Rate for each bin. This report is produced by
default only for type 3-5 simulations and has the file extension _TOF.TXT, but it can also be generated for
other types of FrontSim runs. For more information, see the RPTFSGEO keyword.
###Example of _TOF.TXT #####

#iBin SLBundlePV SLBundleFlwRate
1 3.3331e+006 1.1162e+002
2 3.3331e+006 4.0332e+001
3 3.3331e+006 3.0195e+001
4 3.3331e+006 2.4059e+001
5 3.3331e+006 2.0268e+001
6 3.3331e+006 1.7952e+001
.........................
95 3.3331e+006 6.3393e-001
96 3.3331e+006 5.3279e-001
97 3.3331e+006 4.0649e-001
98 3.3331e+006 3.0569e-001
99 3.3331e+006 1.9170e-001
100 3.3331e+006 6.1523e-002
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.

50
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
Type 3, 4 and 5 simulations
The process to set up a single GEOFLOFS simulation of type 3-5 is as follows:
1. In Petrel, create grid and populate with porosity and permeability.
a. Add faults and fault properties 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.
Enter 3, 4 or 5 as the first parameter of the first record to define the type of simulation.
6. Run the simulation.
FrontSim executes a type 3, 4 or 5 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.
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.

51
Type 1 simulations
Setting up a type 1 simulation is similar to type 2 except that the keyword editor is needed to insert
DEFWPAT to define wells and well controls (can be defaulted). No regular schedule keywords are allowed
to define/control wells for a type 1 run.
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.
Default reports
GEOFLOFS runs produce default output for line graphs. Other types of output (grid cell displays,
streamline display) 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.
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:
Data file Keywords/features supported Keywords/features ignored or not accepted

section (error)
Run type = 1,2 Run type = Run type = 1,2 Run type =
3,4 3,4
RUNSPEC All except NOGRAV All NOGRAV replaced X
GRID/EDIT All All except as X Aquifers,
noted JFUNC/
JFUNCR
PROPS All saturation functions, None PVT, Tracer, Temperature All
end point scaling, modeling
aquifers
REGIONS Saturation, fluid in place None PVT and rock All
SOLUTION Equilibration (multiple None Depth variation, tracers and All
regions), enumeration, restart (which will terminate
aquifer with an error message)
SUMMARY All relevant keyword All relevant No change in behavior from
keywords normal runs

52
Data file Keywords/features supported Keywords/features ignored or not accepted

section (error)
Run type = 1,2 Run type = Run type = 1,2 Run type =
3,4 3,4
SCHEDULE All except as noted Tuning Historical controls, VFP All except
under ignored category. keywords tables, temperature, tracer. tuning
For a type 1 run only only GCONINJE will be ignored keywords
reporting and tuning if target is specified in
keywords are allowed GEOFLOFS. For a type 1 run
all well definition and
control keywords are
ignored.
Table 8.1: FrontSim behavior when GEOFLOFS is operational
Note: Some of these restrictions will be lifted in future versions of FrontSim.
Type 2 runs
Combining GEOFLOFS Injection Scheduling with GCONINJE for type 2 runs.
Record/option
GEOFLOFS Record 2 Set Set Set Set Set Set
Parameter 2: HCPV Fraction
GEOFLOFS Record 2 Parameter 3 Simulation Set Set Set Set Set Set
Duration
SCHEDULE Section: GCONINJE Set Set Set Set Set Set
SCHEDULE Section: TSTEP Set Set Set Set Set Set
Error Error Error OK Error OK Error OK OK
Table 8.2: Combining GEOFLOFS injection scheduling with GCONINJE

53
9
Initializing the study
The initial reservoir conditions can be defined in one of three ways:
x ECLIPSE 100
• They can be read from a RESTART file generated by an earlier run (see keyword RESTART).
x ECLIPSE 300
x FRONTSIM • They can be set directly in each grid block, using the keywords PRESSURE, SWAT, SGAS, RS or
PBUB, and RV or PDEW.
• 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.
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 undersaturated 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,

54
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 nonexistent oil phase. However, 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. The following methods
exist for setting up the initial composition variation, which is usually with depth:
• 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.
• 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.
• 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
honor 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 inter block flows are zero.
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

55
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.
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.

56
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
P cow ( S w ) = P o -P w Eq. 9.1
If Po -Pw 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 Po -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
P cog ( 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 Pg -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 Rs 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 Rs value is reset 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 Sg = 0 below the gas transition zone), and the
highest gas saturation in this table should be 1–Swmin (so that So = 0 above the gas transition zone). The
lowest water saturation value in the SWFN or SWOF table should be the connate value (so that Sw = Swco
above the water transition zone), and the highest water saturation in this table should be 1.0 (so that Sw =
1.0 below the water transition zone). The consistency requirements between saturation tables are detailed in
"Saturation functions".
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 (Sw > Swmin ) and the gas saturation (Sg = Sgmax ) 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
P cow ( S w ) + P cog ( S g = 1-S w ) = P g -P w Eq. 9.3
Note: If the saturation tables contain values of Pcow 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 except for dual porosity systems where the capillary pressure is
used to solve the imbibition mechanism. An option to set SWCR based on the initial saturation is available
in item 37 of OPTIONFS

57
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.

58
10
Licenses
To run FrontSim, and to run any of the additional FrontSim options, you need to obtain an appropriate
x ECLIPSE 100 FLEX license.
x ECLIPSE 300
The FLEX license checking procedure checks for the availability of an appropriate license for a FrontSim
x FRONTSIM
option when a keyword activating the feature is encountered. In most cases, these are encountered at the
beginning of the RUNSPEC section, and so are encountered at the beginning of the run.
Activating keywords for some features, however, may not be encountered until the SCHEDULE section,
and perhaps even part way through a run.
If an appropriate license is not available when a particular feature is activated, the run stops.
A DATACHECK license is available, which allows FrontSim to run a data set in NOSIM mode to check for
data errors without taking up a full license.
This chapter provides information about the licenses that are available for FrontSim and a description of the
keywords required to invoke these features.
There are a number of special cases, which will be dealt with separately:
• Multicore (Parallel) Option
• Multiple Realization (MR).
Keywords that invoke additional license features

In most cases, the licenses being used by the simulators are quite straight forward to work out. A base
frontsim(Frontsim Black Oil) license is checked out and, depending on other factors, additional
licenses may also be used.
Primarily it is the keywords in the data set that determine which licenses are required. Standard usage is
described below.
The following table shows the feature names, the keywords that invoke the functionality and the license
key name. Where two license names appear, FrontSim will attempt to checkout the first one and if this fails
it will attempt to checkout the second.
Licenses
59
License Feature Name Keywords License Key

Compositional COMPS compositional
Datacheck NOSIM datacheck
Multiple Realization MULTREAL is generated by a pre- multiple_realisation parallel
processor
Pattern Optimalization WCONPAT fs_patternbalance
Shared Memory Parallel THREADFS fs_multicore
Table 10.1: Feature names, keywords that invoke the functionality and the license key name
Special cases
Parallel multicore option
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.
One single license for FrontSim MultiCore includes four threads — but as part of the
frontsim(Frontsim Black Oil) license, four Shared Memory Parallel (SMP) licenses are
provided. This forces FrontSim to run on four different threads. It is the default option.
To increase the number of threads the number in the THREADFS keywords needs to be increased to a
number higher than 4. FrontSim then checks whether there are enough SMP licenses available. As an
example if the number in THREADFS is set to 8, one additional SMP license are checked out.
Multiple realization
Multiple Realization (MR) licensing was implemented as a way to lower the cost of running multiple
similar versions of the same model.
Programs, for example Petrel and MEPO generate MR data sets. Do not attempt to create them as they
cannot be made by hand. The data set differs from a standard data set in that it includes the MULTREAL
keyword.
Following the MULTREAL keyword is a UID (Unique Identifier), which is a long string of numbers, and a
word (‘Yes’ or ‘No’). All MR data sets generated from the same base case at the same time will have the
same UID. The word, Yes or No, tells FrontSim whether to continue if MR licenses are not available. This
is however not yet implemented in the generating applications.
When the first of a group with a single UID starts running, the standard set of licenses that would be
required for that job is checked out. In addition, an MR license or, if not available, a parallel license, is
checked out as well. When the second and subsequent jobs from the same group start, they each only
checkout an MR license, or if not available, a parallel license. Even if the first job finishes, the standard set
of licenses are kept checked out until all running jobs from that group finish.
The example in illustrated below shows 6 MR jobs running through a system that can handle 3 jobs at a
time.
Licenses
60
Figure 10.1. Example shows 6 MR jobs running through a system that can handle 3 jobs at a time
Licenses
61
11
Local grid refinement
The local grid refinement option allows enhanced grid definition near wells. The local models are 3D
x ECLIPSE 100 Cartesian. Local models may have more layers than the global model. Transmissibilities between the local
x ECLIPSE 300 models and the global model are computed automatically by FrontSim. The properties of the cells in the
x FRONTSIM local grid can be inherited from the Global grid or specified explicitly for the refined cells.
Local grid refinements

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 11.1 (in the areal direction).

62
Figure 11.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.
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:

63
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

64
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 item 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

• Partially overlapping LGRs are not allowed.
• Aquifers cannot be attached to local grids. FrontSim ignores any aquifer connections to refined cells.
• 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
well’s 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 unrefined 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.

65
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. Please 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.
Keyword Description
ACTNUM Identifies active grid blocks.
ADD Adds specified constants to specified arrays in the current box.
BOX Redefines 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.
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 Redefines 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.

66
Keyword Description
MULTX / MULTY / Transmissibility multipliers
MULTZMULTX- /
MULTY- / MULTZ-
NTG Grid block net-to-gross ratios for the current box.
NXFIN, NYFIN, NZFIN Sets the number of local cells in each global cell of a local grid refinement
PERMX, PERMY, PERMZ Specifies the permeability in the X, Y or Z direction for the current box.
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 /
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 /

67
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 /
SOLUTION
SOLUTION
EQUIL
2000 300 2150 /
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 /

68
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 /
TSTEP
730 /

69
12
Restarts
A run can be restarted by supplying a complete data file, and taking the initial solution from the RESTART
x ECLIPSE 100 file. It is possible to restart a run with, for example, altered permeability data; but in general such changes
x ECLIPSE 300 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 timestepping 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.
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 argument ‘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.
Restarts
70
2. A RESTART file can also be generated at time 0.0 days, containing the initial solution, by setting the
argument ‘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, TUNEFSSA and WRFTPLT.
• Other keywords that need to specified: VFPPROD, VFPINJ, WELLSTRE, WINJGAS, WPIMULT,
WTMULT, WSOLVENT and WCONINJP.
Notes on RESTARTS in FrontSim

• The following data cannot be changed at a restart:
• The grid dimensions NDIVIX, NDIVIY, NDIVIZ, and the number of active cells.
• The unit convention.
• The type of well model for existing wells.
• The number of LGRs and their definitions must be consistent between the base and the restart run
• 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.
Restarts
71
13
Saturation functions
Relative permeabilities are entered as tables (keywords SWFN, SGFN, SOF2 and SOF3 or the alternative
x ECLIPSE 100 family SWOF and SGOF). Saturation values need not be specified at equal intervals, and are used in the
x ECLIPSE 300 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" 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 two or three-phase systems with both water
and oil.
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 two or three-phase systems
with both gas and oil.
72
Family (ii)
SWFN sets water relative permeability and capillary pressure as a function of water saturation. This is
required for two or three-phase systems with water.
SGFN sets gas relative permeability and capillary pressure as a function of gas saturation. This is required
for two or three-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 three-phase systems.
SOF2 sets oil relative permeability as a function of oil saturation. This is required for two-phase systems
with oil.
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:
Swcr 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 krw
= 0). In the example above, Swcr = 0.22.
Swco 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, Swco is the connate water saturation. In the example shown
above, Swco = Swcr. 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 Swcr = 0.22, the table
should begin with the lines
.20 .0 7.0
.22 .0 7.0
.3 .07 4.0
etc.
73
Sw The maximum water saturation value in the table. The Equilibration calculation sets the water
max saturation to this value in grid blocks that lie below the water transition zone. In the example
shown above, Sw 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 = Pg -Po ).
Three saturation values in the table are of special interest:
Sgcr 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.
Sgco The 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.
Sg 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
Sg max = 1.0-Swco , as in the example above, with Swco = 0.22 as in the first SWFN table example in
this chapter.
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 two-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 - Sg .
An example data table for keyword SOF3 is given below. If family (i) were being used, the krowdata would
be included in keyword SWOF and the krog data would be included in keyword SGOF.
74
-- 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:
Soco The minimum oil saturation value in the table. This is the connate oil saturation. Normally, Soco =
0.0, as in the example above.
Socr 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, Socr =0.20.
Sorw 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 krow = 0). In the example above,
Sorw = 0.20.
Sorg 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 (So at which krog = 0). In the example above, Sorg
= 0.38.
So max The maximum oil saturation value in the table. This should be equal to 1 - Swco as determined
from the SWFN table. The two oil relative permeabilities should be the same at So max (both
represent a case with So = So max, Sw = Swco and Sg = 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 three-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 three-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. 3].
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, So, 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,
75
Swco. The full breakdown, assuming the block average saturations are So, Sw and Sg (with So + Sw + Sg = 1)
is as follows:
In a fraction Sg / (Sg + Sw -Swco ) of the cell (the gas zone),
• the oil saturation is So
• the water saturation is Swco
• the gas saturation is Sg + Sw -Swco
In a fraction (Sw -Swco ) / (Sg + Sw -Swco ) of the cell (the water zone),
• the oil saturation is So
• the water saturation is Sg + Sw
• the gas saturation is 0

The oil relative permeability is then given by
Sg krog + (Sw -Swco )krow
kro = Eq. 13.1
Sg + Sw -Swco
where
krog is the oil relative permeability for a system with oil, gas and connate water (tabulated as a function
of So )
krow is the oil relative permeability for a system with oil and water only (also tabulated as a function of
So )
Figure 13.1. The default three-phase oil relative permeability model assumed by FrontSim
76
Stone’s 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. 37] and is available with keyword
STONE1 in the PROPS section. The formula is
kro = krocw SSo Fw Fg Eq. 13.2
where
krocw 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 So > 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 Sw > Swco
SS g = S g / (1-S wco - S om )
In these formulae
So , Sw and Sg denote block averaged values for the oil, water and gas saturations in a grid cell.
krog 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.
krocw denotes the oil relative permeability in the presence of connate water only.
Som 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 , Sogcr ).
Stone’s 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. 36]. The formula is
k row k rog
k ro = k rocw ( k rocw
+ k rw )( k rocw )
+ k rg -k rw - k rg Eq. 13.3
where
77
krog denotes the oil relative permeability for a system with oil, gas and connate water;
krow 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.
krocw 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 Stone’s 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
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.
• Sg max must not exceed 1 – Swco
78
Normally, if there is no oil in the gas cap, Sg max = 1 – Swco.
• Sgco must not exceed 1 – Sw max
Normally, there is no initial free gas below the gas cap, and the water zone is fully saturated with
water, thus Sgco = 0 and Sw max = 1.
• So max must equal 1 – Swco
• krow(So max) must equal krog(So max
• 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:
• Sowcr + Swcr < 1
• Sogcr + Sgcr + Swco < 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, Krw would be scaled between Swcr and 1 – Sowcr that is
a null range if the first condition is not satisfied.
Also, the following relationships are forced by the simulator:
• Sgu must not exceed 1.0 - Swl. If this condition is violated, the gas saturation in the gas cap is reset to
1.0 - Swl to prevent a negative oil saturation. Normally, if there is no oil in the gas cap, Sgu = 1.0 - Swl.
• Sgl must not exceed 1.0 - Swu. If this condition is violated, the gas saturation in the water zone is reset
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
79
Figure 13.3. Ternary diagram showing mobile fluid end-points
80
14
The FrontSim saturation table end-point scaling option allows you to redefine values for the connate,
x ECLIPSE 100 critical and maximum saturations in the saturation tables describing the flow of the reservoir fluids. The
x ECLIPSE 300 scaling facility is useful for modeling reservoirs, which contain an initial depth variation of either the
x FRONTSIM 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
rescaling 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.
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.

81
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 lookup in the unscaled table.
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 three-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 two-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 → Sw 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 Swcr , scaled and
unscaled oil-in-water critical saturations are SOWCR and Sowcr , scaled and unscaled connate gas
saturations are SGL and Sgco , and scaled and unscaled maximum water saturations are SWU and Swmax .
With the two point scaling method, the water relative permeability Krw ( SW ) is then evaluated in the input
saturation table at the new saturation SW ′ , where

82
(SW - SWCR)( S wmax -S wcr )

SW ′ = S wcr + Eq. 14.1
SWU - SWCR
so that Krw 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 Krw ( SW ) = Krwmax ( 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
Sr = 1-Sowcr - Sgco in water/oil or gas/oil/water runs
Sr = 1-Sgcr in gas/water runs
The two cases are:

SWCR ≤ SW ≤ SR
(SW - SWCR)( S r -S wcr ) Eq. 14.2
SW ′ = S wcr +
SR - SWCR
SR ≤ SW ≤ SWU
(SW - SR)( S wmax -S r ) Eq. 14.3
SW ′ = S r +
SWU - SR
and also for SW ≤ SWCR then
Krw ( SW ) = 0 and for SW ≥ SWU then
Krw ( SW ) = Krwmax ( table ) Eq. 14.4
The two- and three-point scaling equations are similar for Krg , Krow and Krog 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.

83
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)
( K rw max (table) ) Eq. 14.5
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 Kr 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:
• SWCR ≤ SW ≤ SR
KRWR (grid block)
K rw ( S ) = K rw (S ′ ) Eq. 14.6
( K rw ( S r )) (table)
• SR ≤ SW ≤ SWU
( K rw (S ′ )(table)-K rw ( S r )(table)))
K rw (S ) = KRWR + (KRW - KRWR ) Eq. 14.7
( K rw max(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 shown here:
Figure 14.1. Two-point scaling
and the three-point scaling is shown here:

84
Figure 14.2. Three-point scaling
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 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.

85
Consistency requirements
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". The same requirements apply to the scaled endpoints.
• SGU must not exceed 1.0 - SWL
If this condition is violated, the gas saturation in the gas cap will be reset to 1.0 -SWL, to prevent a
negative oil saturation. Normally, if there is no oil in the gas cap, SGU = 1.0 - SWL.
• 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
SR = 1-SGCR(grid block) in gas/water runs (ECLIPSE 100, FrontSim)
In order to ensure that at least one fluid remains mobile in the three-phase ternary diagram, FrontSim also
checks for the following:
• SOWCR+SGU< 1.0
• 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, KRW would be scaled between SGU 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

86
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

87
1.0 1.0 0.0 /

REGIONS
SATNUM
50*1 50*2 /

88
15
The streamline concept
FrontSim is a three-phase, three-dimensional black-oil reservoir simulator where the solution mechanism is
ECLIPSE 100 based on a streamline concept. This chapter briefly describes this concept in general and, more specifically,
ECLIPSE 300 how it is implemented in FrontSim. The objective is to describe the process for a single timestep and some
x FRONTSIM 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. 4], [Ref. 5], [Ref. 6] and [Ref. 25].
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.
The governing equations

The black-oil formulation for conservation of each fluid phase reads:
∂ →
φb S + ∇ ⋅ ( b w v w ) = q w
∂t ( w w)
∂ → →
φ b S + R v b g S g )) + ∇ ⋅ ( b o v o + R v b g v g ) = q o Eq. 15.1
∂t ( ( o o
∂ → →
φ b S + R s b o S o )) + ∇ ⋅ ( b g v g + R s b o v o ) = q g
∂t ( ( g g
where the velocities vi (Darcy’s law) are defined as:
→ →
vo = -λo ( ∇ Pw - ρo G V D )
→ →
v w = -λ w (∇ P o - ρ w G V D )
→ →
v g = -λ g (∇ P g - ρ g G V D )

89
ki
λi = K 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
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
+
( Σ
i = o , w , g
v i ci
) ⋅ ∇p Eq. 15.3
The total Darcy velocity vt is defined by (Pc=0)

→ → →
v t = -λt ∇ Po + (∑ j λj ρj ) g Eq. 15.4
Equations 15.3 and 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 ) → →
- + ∇ ⋅ (ρn F n ) = 0 Eq. 15.5
∂t
with F defined by equation 15.2.

90
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 cannot 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.
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 dependent 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, equations 15.3 and 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 and porosities net-to-gross. 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".
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 user-defined flux boundaries. 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.

91
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".
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 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 equations, equations 15.3 and 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 three-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 start points

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.

92
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. You can alter the method to be used for streamline distribution using
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. If you are an experienced FrontSim user you can use the streamline
density multiplier available in keyword TUNEFSSA to speed up the calculations by setting it to a number
less than 1.0.
FrontSim also has new methods to remove automatically 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

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. You can scale this minimum flow rate using keyword
TUNEFSSA, parameter 7.
There are more details on this process in "Streamline tracing".
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.

93
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".
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

94
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".
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 timestep.
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 SWj in a grid cell number j is:
SW j = Σ( PV str × SW str ) / PV j
The sum is taken over all segments in all streamlines going through cell number j.

95
16
Streamline tracing
Tracing the streamline is the process whereby we create the unique streamline passing through a specified
ECLIPSE 100 point in 3D space. From this starting point, the streamline is traced backward and forward to create the
ECLIPSE 300 complete streamline. The algorithm is iterative and rests on calculating the exit point in a grid cell given an
x FRONTSIM 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.
The following figure shows how points and segments are defined with respect to the grid.
Streamline tracing
96
Figure 16.1. Streamline tracing through grid, showing points and segments between the points
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:
PVi = dTOFi × Qi
where
dTOF is delta TOF
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. 31].
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 vt is defined by
→ → →
vt = -λ t ∇ Po + (∑ j λj ρj ) g Eq. 16.1
Pollock’s algorithm is based on three assumptions within one grid cell:
Streamline tracing
97
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]).
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. 35] 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 x 0 + m x ( x -x 0)
Eq. 16.2
m x = ( v x 1-v x 0) / ( x 1-x 0)
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
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
16.2, the dt (or delta TOF) can be expressed as
dt x = ln (( v x 0 + m x ( x b − x x 0)) / ( v x 0 + m x ( x a − x x 0))) / 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.
Streamline tracing
98
( m x dt ) − v
(
x b = x x 0 + v xa e 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 equation
above.
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:
• An active well is positioned in the current cell. The streamline is traced to the center of the cell and
terminated.
• 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:
• 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.
• 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.
You can scale this minimum flow rate using 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.
Streamline tracing
99
17
IOR tracer logic guide
The FrontSim IOR tracer logic is a tool designed to provide an efficient workflow for history matching,
ECLIPSE 100 predicting and optimizing Water Alternating Gas (WAG) injection processes for improved oil recovery
ECLIPSE 300 (IOR) at the field operation scale. IOR WAG injection is a complex multiphase process influenced by
x FRONTSIM 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 practicing 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 quantify mechanistically 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. These show the basic IOR tracer logic concepts, and the effective use this option. This guide treats
the following elements of the IOR tracer logic:
• "The workflow of building the IOR tracer and truth model".
• "Modeling IOR dynamics with tracers". 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". Includes examples.
• "Scaling the model to match the field IOR mechanisms".
• "The IOR model simulation output".
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.

100
In the IOR workflow, four different kinds of model may be considered:

• 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.
• 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.
• 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.
• 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 the
following figure. Yellow boxes correspond to the produced data, which may be parameters or models,
whereas green boxes correspond to an activity or process.

101
Figure 17.1. Possible workflow for constructing the FrontSim IOR tracer model

102
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

103
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 upscale this Truth model 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. The following figure 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. The following figure illustrates the corresponding 1D FrontSim model.

104
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 the following figure. 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. The following figure 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. The
following figure illustrates the corresponding 2D FrontSim model.

105
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.
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 timesteps 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:
• It conserves the mass of the transported components;
• It allows components to be trapped;
• It allows components to be mobilized;
• It can be quickly solved along streamlines;
• 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 bookkeeping needed for tracking the IOR recovery process. Furthermore,

106
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.
IOR tracer logic concepts

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.

107
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 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:
Master Slave Model Type

Injectant Trapped Reservoir Fluid MWAG
Solvent Trapped Lean Gas IWAG before MWAG
Lean Gas Trapped Solvent IWAG after MWAG
Table 17.1: Master-slave tracer pairs
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.

108
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) Set 2 (Modeling IWAG before Set 3 (Modeling IWAG after
MWAG) MWAG)
Tracer 1: T1 = Effective Solvent Tracer 4: T4 = Effective Lean Tracer 7: T7 = Effective Lean
tracer Gas Before Solvent tracer Gas After Solvent tracer
Tracer 2: T2 = IOR Oil tracer Tracer 5: T5 = Returned Trapped Tracer 8: T8 = Returned Trapped
(mobilized by tracer 1) Lean Gas tracer (adsorbed tracer MI tracer (adsorbed tracer 1
4 mobilized by tracer 1) mobilized by tracer 7)
Tracer 3: T3 = Ineffective Solvent Tracer 6: T6 = Ineffective Lean Tracer 9: T9 = Ineffective Lean
tracer (RMI or returned MI, Gas Before Solvent tracer Gas After Solvent tracer
compositionally equivalent)
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 Fluid adsorbed

C1 = effective solvent in solution A1 = effective solvent adsorbed
C2 = IOR oil in solution A2 = IOR oil adsorbed
C3 = ineffective solvent in solution A3 = ineffective solvent adsorbed
C4 = effective lean gas in solution before solvent A4 = effective lean gas adsorbed before solvent
C5 = return trapped solvent in solution A5 = return trapped solvent adsorbed
C6 = ineffective lean gas in solution before solvent A6 = ineffective lean gas adsorbed after solvent
C7 = effective lean gas in solution after solvent A7 = effective lean gas adsorbed before solvent
C8 = return trapped lean gas in solution A8 = return trapped lean gas adsorbed
C9 = ineffective lean gas in solution after solvent A9 = ineffective lean gas adsorbed after solvent
An assumption used is that any remobilized 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 recycled 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).

109
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 Volume
Mobile IOR Oil Concentration =
PV
Trapped IOR Oil Volume
Trapped IOR Oil Concentration =
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"
• "Solvent efficiency decreases with solvent slug size"
• "Some solvent remains trapped in the reservoir"
• "Solvent and lean gas travel rapidly through the reservoir".
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.

110
Solvent efficiency decreases with solvent slug size

A key concept in the streamline–tracer 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:
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, as
you simply need 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, C3, is the remaining portion of the
injected slug:
C3 =1 - C1.
The above concentrations are normalized in the sense that C1 + C3 =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 timestep. Because injection occurs in discrete timesteps, the above concentrations are, in
fact, averaged efficiency levels during the current timestep, with the ratio of:
(change in sweep between timesteps)
.
(change in gas injection between timesteps)

111
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:
Qlgeff
C 4,7 = = η 4,7 = slope of lean gas sweep curve
Qlgtotal
The ineffective lean gas (C6, C9) is the remaining portion of the injected slug:
C6,9 = 1 – C4,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".
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" and "Solvent and IOR oil breakthrough/IOR production curve tuning".
Determining the IOR tracer spatial distribution

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

112
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 versus 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

113
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.
V solv
E RIOR = Eq. 17.1
1
+ A( V solv ) B
C
where
ERIOR is the produced IOR oil ( VREF fraction),
Vsolv is the solvent slugsize ( VREF fraction)
A , B and C are curve fitting parameters.
The floodrate-dependent mobilization curve also needs to be parameterized and fitted to the following
equation:
Q
ERIOR =
1 Eq. 17.2
+ D(Q ) E
F
where
ERIOR is the produced IOR oil ( VREF fraction),
Q is the flood rate (TPV fraction)
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
reapplied 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

114
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 timestep, 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 is reported at the end of the
simulation timesteps.
Trapped solvent
max max
The IOR tracer logic uses a linear adsorption isotherm, with Ssolvent ,trap and Sgas ,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, ΔA 1t +1,
at the next timestep is always positive.
A 1t +1 = max C 1t Ssolvent
( max
,trap , A 1
t
)
ΔA 1t +1 ≡ A 1t +1-A 1t = max C 1t S solvent
( max t
)
,trap , A 1 - A 1
t
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:
IOR Oil Mobilized = min A 2t , ΔA 1t +1

( )
A 1t +1 = A 2t + IOR Oil Mobilized
C 1t +1 = C 2t + 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 timestep. This is done in
order to avoid the process becoming reversible.
t +1 t Max t
A 4,7 (
= max C 4,7 , Sgas ,trap , A 4,7 )
t +1 t +1 t t Max t t
ΔA 4,7 = A 4,7 -A 4,7 (
= max C 4,7 , S gas )
,trap , A 4,7 - A 4,7

115
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.
Lean Gas Mobilized = min A 4t , ΔA 1t +1

( )
A 4t +1 = A 4t -Lean Gas Mobilized
C 5t +1 = C 5t + 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 reinjected for a renewed MWAG process at selected injectors:
Solvent Mobilized = min A 1t , ΔA 7t +1

( )
A 1t +1 = A 1 t -Solvent Mobilized
C 8t +1 = C 8t + 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
1
ϕ multiplied by the total pore volume. This results in a tracer breakthrough 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.

116
Notes
• 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.
• Similarly, the APV for IOR oil determines the IOR oil breakthrough. Reducing the IOR oil
tracer APV can cause earlier breakthrough.
• 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 timestep. 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

117
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 recalculated 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:
• Definition of the tracer logic and setting up the initial tracer model
Keywords TREFFIC, TPAIRS, TPVT, TBLK, TIADS, TPFA, TPFV, TAD, TADE.
• Definition of solvent and lean gas historical injection rates
Keywords WCONINJE, WSOLVENT, WTRACER.
• Definition of solvent allocation logic and facility limit
Keywords MISUPPLY, RANKING, RANKWELL, SOLVSLUG, PRODLIM.
Notes
• 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.
• The TRACER keyword defines an ordinary tracer that does not involve tracer logic.
• 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.

118
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".
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" 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" 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).

119
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 three 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
Bo , 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:
• Obtain and specify the injection concentration along with the water injection rates using the
WTRACER keyword
• 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

120
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 timestep.
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"
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:
Solv_InjINJ(RVB)
Tracer_Slug =
VREF(RVB) × THKRATIO
These variables are defined as follows:
• 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
in the TREFFIC keyword.
• 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.

• 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:
THK LAYER
THKRATIO =
THK TRUTH _MODEL

121
This is possible by specifying ALMODE=2,3 in the RANKING keyword.

• 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"
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 which is beyond the scope of this guide.
The following sections provide examples of tuning options available within the IOR tracer model which
show some history matching workflows that effectively use injector and producer streamline patterns.
These can only be done with streamline simulators.
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. Some of the most effective
parameters that can be adjusted to alter the production behavior of FrontSim are described here. Large
adjustments to the truth model values probably indicate that something more fundamental is wrong. In this
case, 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 you 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
Vsolv
ERIOR =
1
+ A(Vsolv ) B
C
For reference, the value of is the initial slope of the curve, whereas the B parameter controls the shape of
the curve.

122
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 flood rate. 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 = 106.
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 = 106,
B =1 and C = 106, 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.

123
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, the solvent is treated as being of two parts – the effective solvent and ineffective
solvent. The ineffective solvent is that portion of the solvent that flows rapidly from injector to producer

124
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, the
simulator does 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 flood rate 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.
You 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 timesteps 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

125
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 timestep 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".

126
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 timestep
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.
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
Table 17.2: List of solvent allocation keyword parameters for the RANKWELL injectors
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 timestep. The WOR and GOR of all the wells for the previous timestep 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, and 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

127
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 versus 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 Swi 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.

128
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:
V solv
E RIOR = Eq. 17.3
1
+ A( V solv ) B
C
where
ERIOR is the produced IOR oil (VREF fraction),
Vsolv is the solvent slug size (VREF fraction)
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 the figure below.

129
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:
Q
ERIOR =
1 Eq. 17.4
+ D(Q ) E
F
where
ERIOR is the produced IOR oil (VREF fraction),
Q is the flood rate (TPV fraction)
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.

130
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 × Sorw and DEPV = TPV × ( S orw -S orm ). Here, Sorm 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
• Soi = 0.753
• Sorw = 0.342
• Sorm = 0.153.
MI IOR Oil MI IOR MI IOR MI

MMRVB MMRVB HPV HPV 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%
Table 17.3: Incremental oil recovery from a typical injector/producer pair
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 Soi, Sorw 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 Soi and Sorw. The field has Soi = 0.2 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

131
scaling. The streamline tracer model and the truth model have the same TPV (10 MMRVB), but different
Soi and Sorw.
Truth model Streamline tracer model

Soi 0.753 0.50
Sorw 0.342 0.20
TPV (MMRVB) 10 10
Table 17.4: Different approaches for scaling truth model results
Scaling basis MI injected IOR IOR (MMRVB)

(Based on the table
above)
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 16.3% HCPV_field after 0.163*10*0.20=0.326
WF WF (water flood) WF
Dimensional scaling 1 MMRVB 0.44 MMRVB 0.44
Table 17.5: Scaling approaches
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.
Truth model Streamline tracer model

Soi 0.753 0.753
11 Sorw 0.342 0.342
TPV (MMRVB) 10 20
Table 17.6: Approaches for scaling truth model results
Scaling basis MI injected IOR IOR (MMRVB)

(Based on the table
above)
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
Table 17.7: Example: scaling approaches
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.

132
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 timestep, normalizes this value by VREF, and then
computes the slope of the dimensionless IOR mobilization curve. The slope represents the efficiency of the
RVB IOR oil mobilized
injected slug ( ). It is this efficiency that ultimately determines the amount of IOR
RVB of solvent injected
oil mobilized by the solvent slug. You may choose to use dimensional scaling or dimensionless scaling.
• 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, you may prefer to use the
displaceable IOR pore volume (DEPV) as the reference volume VREF. Others 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.
• 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.

133
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
α =
AOF TRUTH_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

134
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
Solv_Inj 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.

135
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
Solv_Inj INJ (RVB)

Tracer_Slug =
THK FIELD
VREF INJ
FIELD (RVB) × THK
TRUTH_MODEL
INJ
Here, VREF FIELD 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.

136
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. Complete descriptions
of the reporting variables are listed in the tables given in "IOR reporting rates".
Injection rates
In order to use water as a swing variable, the volume of MI solvent gas injection is converted into
rvb
equivalent water volume, which is added to the total water injection ( ):
d
(WWIR′ × Bw + 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
(WSIR × B_Ti_I)
WTCTi =
WWIR × Bw
with I = 1 or 3.
Hence the MI solvent injection rate (Mscf/d) is:
( WTCT1
B_T1_I
+
WTCT3
B_T3_I ) (
× WWIR × B ) w
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 × Bw
This is the total amount of oil and water produced.

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

137
(WTCT1 + WTCT2 + WTCT3) × WVPR

obtained by removing the tracer production rate (stb/d) from
Bw
WWPR .
The solvent production rate, both effective and ineffective, in gas units (Mscf/d), is given by
WTCT1 WTCT3
( B_T1_P +
B_T3_P )
× WVPR.
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 Bw to convert all tracer volumes to standard conditions. The cumulative oil produced (stb) is
WTPTT2 × Bw
WOPT + ,
B_T2_P
where WTPTT 2 is the IOR production rates in equivalent water volumes. The term WTPTT 2 × Bw converts
WTPTT2 × Bw
this volume back to RVB, and the term converts this to oil rate using FVF. Similarly, the
B_T2_P
cumulative solvent produced (Mscf) is given by
( WTPTT1
B_T1_P
+
WTPTT3
B_T1_P )
×B . w
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".
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.
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
Table 17.8: Rates reported in the SUMMARY file at the specified timesteps

138
Note: Variables in Red are treated as primary variables in the IOR formulas. Rates in Bold (that is red and
bold or blue and 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.
Variable Description Unit Info

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

Oil
B _T #_P Formation Volume Factor for tracer T# RM3/SM3 - RVB/MSCF Defined in TPVT
when produced
B _T #_I Formation Volume Factor for tracer T# RM3/SM3 - RVB/MSCF Defined in TPVT
when injected
RS _T # Solution-Gas/Oil Ratio for tracer T# (only SM3/SM3- MSCF/STB Defined in TPVT
required for IOR oil tracer T2)
Table 17.9: PVT properties are also treated as input 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.10: Formulae to be used for computing the total well rates of the IOR tracer variables
OIL RATES
WOPR Well Oil Production Rate from SM3/D - STB/D
Waterflood Oil
WOPR IOR = WTC T 2 × WVPR / ( B _T 2_P ) Well Oil Production Rate from IOR Oil SM3/D - STB/D
WOPR TO = WOPR + WOPR IOR Well Oil Production Rate from all SM3/D - STB/D
Sources of Oil
Table 17.11: Formulae to be used for computing the oil well rates of the IOR tracer variables

139
GAS RATES
WGPR Well Gas Production Rate from SM3/D - MSCF/D
Solution Gas from Waterflood
Oil.
WGPRIOR = WOPRIOR × RS_T2 Well Gas Production Rate from SM3/D - MSCF/D
Solution Gas from IOR Oil
WGPRRTS = (WTCT 8 × WVPR ) / B_T8_P Well Gas Production Rate from SM3/D - MSCF/D
Returned-Trapped-Solvent
WGPRES = (WTCT 1 × WVPR ) / B_T1_P Well Gas Production Rate from SM3/D - MSCF/D
Effective-Solvent
WGPRIES = (WTCT 3 × WVPR ) / B_T3_P Well Gas Production Rate from SM3/D - MSCF/D
Ineffective-Solvent
WGPRTS = WGPRRTS + WGPRES Well Gas Production Rate from SM3/D - MSCF/D
+WGPRIES All Sources of Solvent
WGPRRTLG = (WTCT 5 × WVPR ) / B_T5_P Well Gas Production Rate from SM3/D - MSCF/D
Returned-Trapped-Lean-Gas
WGPRELG = (WTCT 4 / B_T4_P + WTCT 7 / Well Gas Production Rate from SM3/D - MSCF/D
B_T7_P) × WQR Effective-Lean-Gas
WGPRIELG = (WTCT 6 / B_T6_P + WTCT 9 / Well Gas Production Rate from SM3/D - MSCF/D
B_T9_P) × WQR Ineffective-Lean-gas
WGPRTLG = WGPRRTLG + WGPRELG + Well Gas Production Rate from SM3/D - MSCF/D
WGPRIELG All Sources of Lean Gas
WGPRTG = WGPR + WGPRIOR + WGPRTS + Well Gas Production Rate from SM3/D - MSCF/D
WGPRTLG All Sources of Gas
WGIRES = WTCT 1 × WWIR × BW / B_T1_I Well Gas Injection Rate from SM3/D - MSCF/D
Effective-Solvent
WGIRIES = WTCT 3 × WWIR × BW / B_T3_I Well Gas Injection Rate from SM3/D - MSCF/D
Ineffective-Solvent
WGIRTS = WGIRES + WGIRIES Well Gas Injection Rate from All SM3/D - MSCF/D
Sources of Solvent
WGIRELG = (WTCT 4 / B_T4_I + WTCT 7 / Well Gas Injection Rate from SM3/D - MSCF/D
BT_T7_I) × WWIR × BW Effective-Lean-Gas
WGIRIELG = ((WTCT 6) / B_T6_I + (WTCT 9) / Well Gas Injection Rate from SM3/D - MSCF/D
B_T9_I) × WWIR × BW Ineffective-Lean-Gas
WGIRTLG = WGIRELG + WGIRIELG Well Gas Injection Rate from All SM3/D - MSCF/D
Sources of Lean Gas
WGIRTG = WGIRTS + WGIRTLG Well Gas Injection Rate from All SM3/D - MSCF/D
Sources of Gas
Table 17.12: Formulae to be used for computing the gas well rates of the IOR tracer variables

140
WATER RATES
WWPRCORR = WWPR ⋅ WVPR × Well Water Production Rate Corrected for SM3/D - STB/D
(WTCT 1 + WTCT 2 + ...WTCT 9) / BW Tracer Production
WWIRCORR = WWIR × (1-W TCT 1 − Well Water Injection Rate Corrected for SM3/D - STB/D
W TCT 2-…WTCT 9) Tracer Injection
Table 17.13: Formulae to be used for computing the water well rates of the IOR tracer variables.
The following table lists reports in the FacilityOut and PRT files for each eligible solvent injector.

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 × WTCT 1 Allocated MI Solvent Injection Rate RM3/D - RVB/D
TotRate = WVIR Well Water and Solvent Injection Rate RM3/D - RVB/D
(TotRate - MiRate) Ratio of Injected Water Rate and Solvent Rate. Defaults
WAG =
MiRate to 999 when Solvent Rate is 0.0
conc1 Injector solvent efficiency, conc1/conc3 are well Ratio
Eff =
(conc1 + conc3) 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
Table 17.14: Reporting variables for IOR solvent logic allocation
In the following table, the 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.
IOR Facility Limit Logic Reporting Variable

Name Well name for active producer
Total = WVPR Total Well Liquid Production Rate RM3/D - RVB/D
(oil and 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 × WTCT 2 IOR Oil Production Rate RM3/D - RVB/D
EffMi (RES ) = WVPR × WTCT 1 Effective Solvent Production Rate RM3/D - RVB/D
InefMi (RES ) = WVPR × WTCT 3 Ineffective Solvent Production Rate RM3/D - RVB/D

141
IOR Facility Limit Logic Reporting Variable

EffLeanGas or Eff Lg = Effective Lean Gas Production Rate RM3/D - RVB/D

WVPR × (WTCT 4 + WTCT 7)
IneffLeanGas or Inef Lg = Ineffective Lean Gas Production RM3/D - RVB/D
Rate
WVPR × (WTCT 6 + WTCT 9)
Rtn Lean Gas IWAG or IWGas = Returned Trapped Lean Gas Rate RM3/D - RVB/D

WVPR × WTCT 5
Rtn Solv IWAG or IWMi = Returned Trapped Solvent Rate RM3/D - RVB/D

WVPR × WTCT 7
C 1, C 2, C 3 or Concentration for Effective MI no unit
(conc1), IOR Oil (conc2), and
WTCT 1, WTCT 2, WTCT 3 ineffective MI (conc3)
Wat _Adj (RES ) = Water Rate after Adjusting for RM3/D - RVB/D
Tracer Production
WWPR - WVPR × SUM (WTCTi )
for i=1,2,3, …up to 9
WF _Oil = WOPR Water Flood Oil Production Rate SM3/D - STB/D
IOR Oil = WVPR × WTCT 2 / BO IOR Oil Production Rate SM3/D - STB/D
EffMi = WVPR × WTCT 1 / (B _T 1_P ) Effective Solvent Production Rate SM3/D - MSCF/D
InEfMi = WVPR × WTCT 1 / B _T 3_P Ineffective Lean Gas Production SM3/D - MSCF/D
Rate
WF _So lnGas = WOPR × RS _T 2 Water Flood Oil Solution Gas Rate SM3/D - MSCF/D
IOR _So lnGas = IOR Oil Solution Gas Rate SM3/D - MSCF/D
(WVPR × WTCT 2 / BO ) × RS _T 2
WatAdj = Water Rate after Adjusting for SM3/D - STB/D
Tracer Production
(WWPR - WVPR × SUM (WTCTi )) / BW
for i=1,2,3, …up to 9
Tot_Oil = WOPR + WVPR × WTCT 2 / BO Total Water Production Rate SM3/D - STB/D
Tot_GAS = WF _Sol nGas + EOR _Sol nGas 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.15: Reporting variables for the facility limit logic
Variables reporting in each cell/streamline

Variable Description Note
Ti _CONC Cell Concentration, for (i= 1, 2, ... up to 9.) Available to view
with streamline

142
Variables reporting in each cell/streamline

Variable Description Note
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.)
Table 17.16: Reporting variables in each cell at specified reporting timesteps
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 the tracer keywords and well specifications.
2. Run tracer.data
3. Use a 3D viewer to look at the trapped solvent saturation and the IOR oil saturation with time.
4. Use a summary plot viewer to look at the cumulative IOR oil production.
5. Rerun the simulation and double solvent slug-size.
6. Look at the summary plots and see if the cumulative IOR oil has doubled.
7. Rerun the simulation and double the rate.
8. Look at the results and look at the rate impact.
9. Rerun the simulation and change the WAG ratio.
10. Study this and the original case to look at the impact on timing.
Tip: Both Petrel RE and ECLIPSE Office can be used to view the output of the simulations.
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
timestep. You may choose to use smaller timestep 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.

143
18
Tensor permeability
Full tensor permeabilities are often required to describe complex reservoirs. Given a detailed heterogeneous
ECLIPSE 100 reservoir description at the geological scale, upscaling is normally carried out to reduce the model size to
x ECLIPSE 300 one suitable for reservoir simulation. These upscaling procedures will generally create full tensor
x FRONTSIM 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
k yx = k xy , k zy = k yz , k zx = k xz Eq. 18.2
In FrontSim, the coefficients are entered as

kxx = PERMXX, kyy = PERMYY, kzz = PERMZZ, kxy = PERMXY, kyz = PERMYZ and kzx = PERMZX.
Tensor permeability
144
Note: FrontSim also accepts non-symmetric tensors although this might not be physical. You 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. 1] 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.
Discretization
Figure 18.1. Stencil for MPFA flow in 2D between cells (i,j) and (i+1,j)
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 is the generalized mobility of component c in phase p

M pAB
Tensor permeability
145
dPpAB is the potential difference of phase p between cells A and B, given by

dP pAB = P A -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
c c
F pAB = M pAB T AB dP pAB + Σ T AS dP AS
( S ) Eq. 18.4
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 equation
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
dP pAS = P A -P S - ρ pAB G ( D A -D S ) Eq. 18.5
The transmissibilities TAB and TAS are calculated following the procedure described in [Ref. 1] 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").
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.
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
• the grid system is orthogonal and
• the permeability tensor K is diagonal.
¯
Tensor permeability
146
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
Consider an interface PQ between two cells 1 and 2. The permeabilities in each cells are K 1 and K 2. 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 a 2 the covariant basis vectors. Define the contravariant basis
¯ ¯
vectors a 1 and a 2 with the condition that
¯ ¯
a i • a j = δ ij
¯ ¯
where δij is the Kronecker delta.
Now consider a potential gradient in cell 1,

2
∇ φ = Σ αj a j
¯ j =1 ¯
The flux through PQ from cell 1 is therefore

2
f = λ ⋅ A ∙ K ∙ ∇φ = λ Σ α j A ∙ K ∙ a j
¯ ¯ j =1 ¯ ¯ ¯
where λ accounts for the mobility.

Since this expression can be used for arbitrary values of αj , it follows that if A ∙ K is parallel to a 1, such
¯ ¯ ¯
that A ∙ K ∙ a 2 = 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. 22] and [Ref. 1]) when A ∙ K is parallel to a 1.
¯ ¯ ¯
A convenient measure of orthogonality error for an interface is therefore
(A ∙ K ) ∙ a 1 a 1
ε = A ∙ K-
¯ ¯
¯ ¯
a1 ∙ a1
¯ ¯
¯ ¯
/ A ∙K
¯ ¯
This is evaluated separately for each of the two cells adjoining the interface A . The maximum of these two
¯ that is, the departure from a
values provides a measure of the departure from orthogonality for the interface,
two point flux approximation for this interface.
Tensor permeability
147
19
The Oil/Water Front Tracking
Saturation Solver
The front-tracking method

ECLIPSE 100
For two-phase cases, the front-tracking method is the default method for solving the saturations in
FrontSim. Although it is designed for typical water-oil floods, it can also be used for water-gas and gas-oil
ECLIPSE 300
(no variable Rs or Rv) floods unless the compressible effects are too large. Also, tracers can be applied
x FRONTSIM
using the front-tracking method (two-phase mode).
This method originated in the theory for one-dimensional scalar conservation laws. A general description of
this topic can be found in Smoller [Ref. 34]. The method used in FrontSim was first proposed by Dafermos
[Ref. 13] and developed for reservoir simulation in the 1980s (Bratvedt et al. [Ref. 4], [Ref. 5]). 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 i ) + ∇ ⋅ G i = 0
∂t ( i) ( ) Eq. 19.2
where the two-flux terms are defined by
The Oil/Water Front Tracking Saturation Solver

148
Fi = fi vt Eq. 19.3
→ →
Gi = fi λi ∇Ddρ g 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. 6]) for the following equations:
∂Si 1→
∂t
+
φ ( )
→
∇ ⋅ Fi = 0 Eq. 19.5
∂Si 1→
∂t
+
φ ( )
→
∇ ⋅ Gi = 0 Eq. 19.6
Equation 19.5 models the convective flow without gravity and is solved by the front-tracking method as
described below. Equation 19.6 models the gravity segregation of the fluids. The gravity vector in equation
19.4 is of course constant and known, so the counterparts to the streamlines, the gravity lines, always are
defined. Equation 19.6 can also be solved using the front-tracking method.
Assumptions
Piecewise constant initial saturation
One of the assumptions for the front-tracking method is that the initial saturation must be
piecewise constant. This is always the case in FrontSim where the initial condition is saturations
that are constant for each grid cell.
Piecewise linear flow-function
The flow-function (F and G) must be piecewise 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 (fw ) is defined as:

149
fw = λw / (λw + λo )
Eq. 19.7
λ w = k rw / μ w , λ o = k ro / μ o
kri is the relative permeability of phase i
μi is the viscosity of phase i
Figure 19.1. Fractional flow function approximated by a continuous piecewise linear function
In figure 19.1, the fractional flow function is the blue dotted line. Five linear segments have approximated
this function as piecewise linear. The relative permeability is defined in six points (Swc, S1, etc.). This
approximation yields a piecewise 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
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.

150
Figure 19.4. Saturation at time t3 with flow Figure 19.5. Saturation at time t4 with flow
direction from right to left direction from right to left
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 Figure 19.7. Saturation at time t6 with flow
direction from right to left direction from right to left
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 piecewise 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:

151
∂Sw ⇀ ⇀
+∇ ⋅ Gw = 0
∂t
where G is defined as:
⇀ ⇀
G w = f w ( ρ o -ρ w ) λ o ⋅ g
Let us assume we have an 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.8. Water above oil
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.
Figure 19.9. Linear relative permeability Figure 19.10. Linear flow function
curves
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.

152
Figure 19.11. Linear flow function multiplied by linear oil relative permeability and negative
density difference
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.12. Gravity flow function with

negative density difference: initial fronts Figure 19.13. Gravity flow function with
negative density difference: after front
collisions
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

153
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.
Figure 19.14. Gravity flow Figure 19.15. Gravity flow Figure 19.16. Gravity flow
saturation, distribution, initial saturation, distribution, saturation, distribution,
snapshot after time t1 snapshot after time t2
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.
Figure 19.17. Gravity flow Figure 19.18. Gravity flow Figure 19.19. Gravity flow
saturation distribution, initial saturation distribution, saturation distribution,
snapshot after time t1 snapshot after time t2
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.

154
20
The pressure equation
FrontSim is an IMPES (IMplicit Pressure Explicit Saturation) simulator. That is, we solve a pressure
ECLIPSE 100 equation in which all the terms that depend on saturation are evaluated at the initial saturation and where
ECLIPSE 300 the spatial derivatives of the pressure are evaluated using the pressure at the end of the timestep. Although
x FRONTSIM 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.
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
dB o ( B g -R v B o ) dR s
co =
1
Bo
- (
dP
+
(1-R v R s ) dP )
,
dB g ( B o -R s B g ) dR v
cg =
1
Bg
- (
dP
+
(1-R v R s ) dP )
,
1 dB w
cw = - ,
B w dP
and
νt = νo + ν + νg ,
and where for each phase p (that is, for subscripts o, w and g):
v p = − λ p (∇ • P − ρ p g ∇ d ) and
kkrp
λp =
μp

155
where:
k is the permeability of the rock
krp 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.
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)
P n = 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

156
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, you 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 unconverged solutions, as
the results may not be accurate.
The second set of controls is based on how quickly the solution is changing. The linear norm is given by
(100 × ΣAbs(Δp))
L =
(Σ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
(100 × ΣAbs(Δp))
NL =
(Σ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 timestep.

157
21
This chapter describes the parallel multicore option, which is a separately licensed extension to FrontSim.
ECLIPSE 100
ECLIPSE 300
Note: The keyword GEOFLOFS (added in 2008.1) can be used for conducting incompressible simulations
x FRONTSIM using parallel multicore without requiring parallel multicore licenses. All other parallel simulations on
more than four cores require additional parallel Shared Memory Parallel (SMP) licenses. The base
FrontSim license will automatically support up to four 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 (Windows
and Linux). 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.
The FrontSim multicore is based on three different threading strategies:
• Using a boost threading library for setting up the pressure equation system and for generating/solving
streamlines including computing gravity lines. The multicore option is supported for both two-phase
front tracker and three-phase black oil saturation solvers. For two-phase problems, the use of the
EXPL solver must be explicitly set using the TUNEFS1D keyword.
• Using OpenMP pragma directives to parallelize the linear pressure solver (algebraic multigrid solver)
• Optionally the pressure equation can be solved using GPU algebraic multigrid solver on single/
multiple graphics card; the FSSOLVE is used to enable this option. At least one high end graphics card
(with a computing capability 2.0 or higher) is required to utilize this solver, but if there are more than

158
one high end card available FrontSim will take advantage of this and run on multiple cards. If you set
the GPU option and no cards are available FrontSim will switch to the default linear solver (2).
For two-phase problems, the use of the EXPL solver must be explicitly set using the TUNEFS1D keyword.
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. You need to specify the number of threads to be used. Corresponding number of SMP 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 in the GUI in Petrel and has to be introduced using the
keyword editor.
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. The first block is describing the workload for the different threads
in the saturation solver. The number of streamlines processed by the different threads can differ — mainly
because of the streamlines are different (the number of segment could vary between the streamlines:
Workload for parallel threads (load-balancing):

Worker Thread : 0 Generation : 8915 Solving : 8581 Gravity : 4600
Total : Generation : 34797 Solving : 34797 Gravity : 18087
Total discarded : 0
The next block is an extract of the CPU Times for the pressure solver — the pressure solver setup is done
using multithreading, the linear pressure solve is either done in parallel using a parallel (OpenMP)
algebraic multigrid solver or optionally a GPU solver running one or multiple graphics card. The velocity
calculations are done as a serial task.
CPU Time Pressure Current TS : Accumulated :

Setting up pressure equation : 9.2 sec(s) 596.4 sec(s)
Solving pressure : 6.8 sec(s) 457.8 sec(s)

159
Computing total velocity : 1.4 sec(s) 137.5 sec(s)

Total : 17.4 sec(s) 1191.7 sec(s)
The last block is an extract of the CPU Times for the transport solver. Here time for saturation solution
includes the time generate streamline startpoints (only task done in serial), generate (trace) streamlines,
solve streamlines (transport) and also compute the gravity lines.
CPU Time Saturation Current TS : Accumulated :

Start points generated : 1.1 sec(s) 81.0 sec(s)
Streamlines generated : 3.1 sec(s) 261.7 sec(s)
Streamlines solved : 6.1 sec(s) 514.1 sec(s)
Gravitylines solved : 3.5 sec(s) 342.6 sec(s)
Other : 1.1 sec(s) 125.1 sec(s)
Total : 15.0 sec(s) 1324.6 sec(s)
Depending on the nature of the problem, the proportion of time spent on either of the solvers will differ. In
general the saturations solver is scaling better than the pressure solver so models and in serial mode is
spending most of the time in the saturation solver will benefit tremendously from using multicore parallel
processing. For the model above the pressure solver in serial model uses approximately 2200 seconds (less
than 2x speedup) seconds while the saturation solver uses 4200 seconds (more than 3.5x speedup) when
comparing with running with 4 threads on a 6x Dual Core machine.
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 timesteps due to stability considerations
resulting in longer computation times for the saturation solver.

160
22
Pattern flood management
Streamline simulation is being increasingly used for managing waterflood operations in some of the largest
ECLIPSE 100 fields in the world (SPE 54616, SPE 63152, SPE 105393). Underpinning the analyses of a waterflood is the
ECLIPSE 300 relationship between injection and production wells. This relationship can be directly and fully quantified
x FRONTSIM 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. The left image in figure 22.1
shows a waterflood simulation with finite difference method. The right image shows same simulation using
FrontSim streamline solution with the front tracking method.
Figure 22.1. Waterflood simulations.
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

161
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.)
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.

162
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 tables to in the "FrontSim User
Guide").
PFM is compatible with three-phase black oil systems. If only oil-water slightly compressible simulation is
required then advantage can be taken of the front tracking solver. The Front Tracker solver is faster and
introduces very little numerical dispersion while maintaining sharp flood fronts during the simulation.
FrontSim PFM optimizes the allocation of water injection at every timestep or user-defined intervals during
run time. Individual well constraints, economic limits are taken into account by the allocation process.
FrontSim PFM is compatible with well workover logic.
FrontSim PFM runs can be made with the parallel multicore option, this makes it possible to implement
high resolution waterflood simulation on a daily basis for reservoir surveillance.
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
Figure 22.3 is 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.

163
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 timestep, 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.
Often there are a large number of injectors and the WLIST keyword is used 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, for example a pilot project.
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 that you 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 tools (OFM,
Decide!) and the model based simulation tool (FrontSim PFM) are required in a closed loop monitoring
system. Field inter-well measurements, for example, tracer tests, interference tests, logging, and so on are
required to verify or to calibrate 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.
Waterflood patterns
Classical methods for waterflood design employ some standard well patterns, for example, line drive, 5-
spot, 9-spot or inverted 5-spot.

164
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 wells that
you identify and can be based on the original waterflood design, for example, 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 you know the 'actual' pattern of wells 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 many data-driven production data based polynomial fitting methods, for example neural
networks, for both identifying connected wells as well as estimating allocation factors.
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.

165
Figure 22.5. Repeated 5-spot waterflood pattern but with a heterogeneous permeability field
Observe complete change in patterns. Plot on the right shows dynamic injector based patterns
Figure 22.5 shows how the introduction of channel geology to the model in figure 22.4 can completely
change the flooding patterns. This picture is more realistic 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
risky.
FrontSim PFM can identify well patterns and generate allocation factors for any given geology, well
locations and rates. The pattern of connected wells in FrontSim are time-dependent. The patterns identified
by FrontSim are called 'dynamic' and those which you specify are called 'static' or 'user-defined'.
FrontSim goes one step further than alternative data driven methods that are applied to detect connected
well relationships and total allocation factors. FrontSim can further define allocation factors for individual
fluid phases. In this example, PFM indicated that 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 is as high as
60%.
FrontSim PFM can 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.
Note: 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 keyword
WPLEAKUD.

166
Allocation Strategy
In FrontSim, a bundle of streamlines not only indicates which injector is connected to which producer but
also provide a wealth of other information, for example phase injection/production flow rates, bundle pore
volumes, phase volumes such as mobile oil volumes, pressures, and so on within this bundle.
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) that you have specified.
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 injection and production
rates at well or zone level.

167
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 injection and production rates at well or
zone level.
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:
Wi = 1.0 + Wlim ∙ ΔBeta Alpha
If Beta 1 > Betaavg then
Wlim = Wmax (item 7)
ΔBeta = Min {1.0, ( Beta i -Betaavg ) / ( Beta max -Betaavg )}
If Beta i < Beta avg then
Wlim = Wmin (item 6)
ΔBeta = Min {(1.0, Beta avg -Betai ) / ( Beta max -Betaavg )}
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 timestep are used in the allocation process for the current
timestep. In order for the allocation process to be meaningful, FrontSim tries to ensure that the bundle
configurations or patterns do not significantly change across timesteps.
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.
Beta min , Beta max defines the parameter range (item 4) within which to apply proportional weighting.
Beta min 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 Beta min and Beta max straddles Beta avg , else if item 5 is set to 1 then Beta min and Beta max
is fixed around a Beta avg = 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

168
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 timestep.
Example showing computation of weights
Figure 22.7. Showing computed weights.
Figure 22.7 shows 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)
• Betamin and Betamax were calculated using the default formula (item 5) for the given range.
Betaavg = 0.45 (Either average oil cut or average recovery efficiency as requested by item 2 will 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.

169
If Beta is changing rapidly at any time during the simulation then it may be advisable to use shorter
timesteps for the optimization exercise to produce quality results.
Debug output that details the calculations can be produced by setting item 51 in OPTIONFS to = 1.
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 according to your
specification (item 10). The amount of injection cut back can be reallocated among other injectors or the
overall injection reduced (item 11).
Multi-zone waterfloods
FrontSim PFM supports multi-zone waterflooding. This requires that zones be identified by lumping
simulation layers together. The COMPLUMP keyword is used to describe zone completions in wells. To
activate multi-zone waterflood in FrontSim the switch for multi-zone in WCONPAT must be turned ON.
When multi-zone is selected, all allocation calculation will now be done at the completion level for the
injectors as opposed to well level as is the default algorithm. To account for the allocation at zone level the
target for each completion is set and solved as separate entities. To compute a consistent BHP for the wells
an extra constant pressure drop is calculated for each of the completions and added to the well equation for
each connection. See the chapter on well inflow for more.
The 2008.x versions of FrontSim cannot apply the completion target that the PFM algorithm calculates. In
these versions, the rates are accumulated to the well level even though the algorithm works on the
completion level. You can set backward compatibility using FrontSim 2009.1. See OPTIONFS parameter
61.
Also, an option is available to apply the targets at completion level for the producers connected to the
injectors affected by the PFM algorithm. The default in the PFM algorithm is to accumulate the completion
targets for the producers to well level. See OPTIONFS parameter 61.
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 tables to in the FrontSim User Guide).
FrontSim PFM also supports zone based rate allocations to directly honor lumped connections. Zone rate
based allocations to PFM wells that spans multiple layered geologic structure, where rate allocations can be
different for lumped connections to achieve good oil recovery, Through a new parameter in the WCONPAT
keyword you can decide whether to use zone based rate allocation for each connections, or to use
accumulated rates for the well.
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 subsurface streamline bundles represent two 'networks'. Balancing is required to
simultaneously honor group and well constraints when PFM allocation is exercised. This is quite a

170
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. Contact the help desk before proceeding.
Here are some of the implemented rules:

• It is necessary to have at least one timestep 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.
• The target rate for a list of injectors under PFM at any timestep is taken to be equal to the sum of the
rates for the same list of injectors in the previous timestep or user-defined injection capacity.
• Injector lists can be modified explicitly using ADD, MOV or DEL options in WLIST. This handled as
follows
• 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 timestep prior to including it under PFM.
• 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.
• If you remove a well, its rate will be subtracted from the target injection rate.
• It is recommended not to mix up producers and injectors in the same list.
• More than one list of injectors with different allocation criteria can be applied at any time.
• In contrast to normal group controls, currently PFM allocation is allowed to violate group rate limits.
Individual rate limits for PFM injectors (RATE and RESV) will be honored. This can be reverted
using item 57 in OPTIONFS. Individual limits for production wells that are affected by PFM are not
honored.
• Well BHP limits will be honored.
• Well and group economic limits are applied as usual. Actions are always taken in the next timestep.
• Injection wells under PFM control are automatically taken off group control.
• Injection rate is scaled down to meet injection capacity limits.
• Production wells impacted by PFM are automatically taken off group control. The wells not impacted
by PFM remain under group control.
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.
• It is possible to switch back from PFM to Group or individual well control during a run using the
WCONPEND keyword.
Refer to the install directory for sample data sets showing the use of PFM.

171
Exporting PFM rates to a separate include file

FrontSim PFM by default exports all well rates and limits to a separate include file (. PFM_SCHED) using
the keywords WCONPROD, WCONINJE and DATES. This can then be included in another data deck to be
rerun by either ECLIPSE or FrontSim.
Note: The control keywords included in the . PFM_SCHED file are only at the well control level. No group
control keywords are supported.
All wells are by default set to control at RESV target conditions but this can be changed to RATE injector
target and LRAT target for producers by using item 66 in OPTIONFS.

172
23
Solvent model
The solvent model in FrontSim is based on the ECLIPSE solvent model as described in the ECLIPSE
x ECLIPSE 100 Technical Description. The implementation in FrontSim is based on the streamline approach and some
ECLIPSE 300 differences with ECLIPSE are therefore expected.
x FRONTSIM
This chapter describes a four-component extension of the black-oil model. The aim of the extension is to
enable modeling of reservoir recovery mechanisms in which injected fluids are miscible with the
hydrocarbons in the reservoir.
An injected fluid sets up a miscible displacement if there is no phase boundary or interface between the
injected fluid and the reservoir oil. A miscible displacement has the advantage over immiscible
displacements such as water flooding, of enabling very high recoveries. An area swept by a miscible fluid
typically leaves a very small residual oil saturation.
In miscible gas injection processes, total displacement of the oil in the swept regions does not guarantee a
high overall recovery efficiency. This is because the high adverse mobility ratio inherent in gas injection
means that the flow is unstable and leads to the growth of viscous fingers that leave regions of by-passed
oil in the reservoir at gas breakthrough. Gravitational fingering may also be present as a result of the large
density differences between the injected gas and the in-place oil. The flow is unstable to finger formation at
mobility ratios greater than unity, or in places where a dense fluid overlies a less dense fluid, and the
fingers grow rapidly from small fluctuations in reservoir homogeneity. Reservoir simulation models must
account for the growth of fingers whenever they might arise in the reservoir.
A further feature of miscible fluid displacement to be included in a simulation model is the mixing of the
miscible components. Component mixing occurs on a microscopic scale and results from molecular
diffusion and fluid velocity variations within the porous medium on the scale of the pore size. The mixing
process is represented by a diffusion term in the component equations. Correct treatment of this mixing
effect within the simulation model is important since the mixing term exerts a considerable damping effect
on the growth of viscous and gravity fingers
The simulation of incompressible miscible displacement was initially based on a direct solution of the
convection-diffusion equations for the local concentration of each of the miscible components. However,
such models are unreliable unless the fine scale structure of the fingers can be resolved, otherwise mixing
cell effects will dampen the finger growth rates and produce optimistic oil recovery forecasts. The
numerical diffusion inherent in finite difference models also masks the true mixing of the miscible
components unless the grid is sufficiently fine. The number of grid cells required for accurate field-scale
study of miscible displacement is unacceptably high and the cost of computing time prohibitive.
Solvent model
173
Implementation
The model is optionally a four-component system consisting of water, oil, reservoir gas and an injected
solvent, or a three-component system of water, oil and solvent gas or an oil/solvent system.
In regions of the reservoir containing only solvent and reservoir oil (possibly containing dissolved gas), the
solvent and reservoir oil components are assumed to be miscible in all proportions and consequently only
one hydrocarbon phase exists in the reservoir. The relative permeability requirements of the model are
those for a two-phase system (water/hydrocarbon).
In regions of the reservoir containing only oil and reservoir gas, the gas and oil components will be
immiscible and will behave in a traditional black oil manner. In regions containing both dry gas and
solvent, an intermediate behavior is assumed to occur. The modeling of the immiscible/miscible transition
is described in subsequent sections.
The Todd-Longstaff model is an empirical treatment of the effects of physical dispersion between the
miscible components in the hydrocarbon phase. The model introduces an empirical parameter, ω , whose
value lies between 0 and 1, to represent the size of the dispersed zone in each grid cell. The value of ω thus
controls the degree of fluid mixing within each grid cell. A value of ω = 1 models the case where the size
of the dispersed zone is much greater than a typical grid cell size and the hydrocarbon components can be
considered to be fully mixed in each cell. In this case the miscible components have the same value for the
viscosity and density, as given by the appropriate mixing rule formulae. A value of ω = 0 models the effect
of a negligibly thin dispersed zone between the gas and oil components, and the miscible components
should then have the viscosity and density values of the pure components. In practical applications an
intermediate value of ω would be needed to model incomplete mixing of the miscible components. By
default the viscosity and density values will be calculated using the same mixing parameter, ω . However, if
the mixing parameter is being used as a history matching parameter, it is sometimes useful to specify two
separate mixing parameters, one for the viscosities and one for the densities.
Applications
There is a wide variety of secondary and tertiary recovery schemes in which the aim is to enhance the
reservoir sweep by using a miscible injection fluid.
Typically, the miscible injection fluid is expensive compared with traditional flooding fluids, such as dry
gas and water. Miscible fluids are often referred to as ‘solvents’; examples of solvent schemes are listed
below:
• High pressure dry gas processes, in which mass transfer effects at the gas-oil contact generate miscible
flow conditions between the gas and the oil.
• A solvent such as LPG or propane may be injected as a ‘slug’ to be followed by an extended period of
lean gas injection. The slug fluid is miscible with both the gas and oil, and the success of the method
depends upon maintenance of both the reservoir pressure and the solvent slug itself.
• Certain non-hydrocarbon gases such as carbon dioxide produce miscible displacement of oil at
pressures above a threshold value.
• All-liquid miscible displacements by fluids such as alcohol, normally injected as a slug between the
in-place oil and the injected chase water.
In many of the schemes, the cost of the solvent is such that the recovery scheme needs to be ‘engineered’ to
allow enough solvent to be injected to increase the total oil recovery while keeping the solvent costs low
enough to make the project economic.
Solvent model
174
In applications where the reservoir pressure falls below the bubble point, and in schemes where a solvent
slug is chased by a lean gas flood, there is a requirement to model four components within the reservoir
(water, oil, solvent and lean gas). The Solvent Model provides a simple method of modeling these recovery
mechanisms.
Model formulation
The solvent model is an extension of the standard three-phase, three-component model (water, oil, and gas),
whereby an extra conservation equation is solved for the solvent. Below we detail the modeling of the
different flow parts and the mixing rules used which are based on the empirical treatment suggested by M.
Todd and W. Longstaff in the appendix of [Ref. 40].
Relative permeability model: immiscible case

In regions of the reservoir where the saturation of solvent is small, for example in the region swept by lean
chase gas, the displacement is immiscible. In the usual black-oil model the relative permeabilities for the
three phases water, oil and gas are specified as follows:
k rw = k rw ( S w ) as a function of water saturation
k rg = k rg ( S g ) as a function of gas saturation
k ro = k ro ( S w , S g ) as a function of both water and gas saturations.
When two gas components are present, the assumption is made that the total relative permeability of the
gas phase is a function of the total gas saturation,
krgt = krg (Sg + Ss ) Eq. 23.1
where Ss is the solvent saturation.
This total relative permeability is obtained from the SGFN keyword. Then the relative permeability of each
gas component is taken as a function of the fraction of each gas component within the gas phase as:
Fraction of solvent:
Ss
Fsol = Eq. 23.2
Sg + Ss
Fraction of reservoir gas:

Sg
Fgas = Eq. 23.3
Sg + Ss
k rs = k rgt ⋅ k rfs ( F sol )

Eq. 23.4
k rg = k rgt ⋅ k rfg ( F gas )
Typically the functions krfs = krs / krgt and krfg = krg / krgt (Equation 23.4) are ‘straight line’ functions such
that
k rfs (0.0) = 0.0 k rfg (0.0) = 0.0
k rfs (1.0) = 1.0 k rfg (1.0) = 1.0
However, FrontSim allows you to specify these gas-solvent functions using the SSFN keyword.
Solvent model
175
Relative permeability model: miscible case

In regions where solvent is displacing oil, the hydrocarbon displacement is miscible. However, the two-
phase character of the water/hydrocarbon displacement needs to be taken into account. The relative
permeabilities are given by:
So
k ro = k rn ( S n ) Eq. 23.5
Sn
Ss + Sg
k rgt = k rn ( S n ) Eq. 23.6
Sn
where
Sn = Sg + Ss + So is the total hydrocarbon saturation,
krgt is the total relative permeability of the gas and solvent,
k rn ( S n ) is the relative permeability of hydrocarbon to water obtained from the SOF2 keyword.
Then, the gas and solvent component relative permeability are computed from krgt as above, equations 23.2
- 23.4. It is possible to modify the straight line miscible relative permeabilities, using the MSFN keyword to
supply multipliers Mkro and Mkrg . The oil and total gas relative permeabilities will then be:
So
k ro = M kro ( ) (
Sn
k rn S n ) Eq. 23.7
Ss + Sg
k rgt = M krg ( ) Sn
k rn ( S n ) Eq. 23.8
Note that saturations end-points are taken into account in the previous equations as explained below.
Transition between miscible and immiscible cases

The descriptions above are the treatments of the extremes when the displacement behavior is either fully
miscible or fully immiscible. In practice, there will be regions of transition where the displacement is
changing from miscible to immiscible in character. Typically, this occurs when a lean chase gas breaks
through the solvent slug. Todd and Longstaff recommend that the displacement will be miscible until the
solvent saturation becomes very small (of the order of 0.01). However, this transition is likely to vary from
case to case.
The transition is handled by a user-specified ‘Miscibility function’. This is a function of the solvent fraction
in the gas phase. The function is tabulated between 0 and 1, where 0 implies immiscible displacement and 1
implies miscible. The miscibility function is supplied using the MISC keyword.
The transition algorithm has two steps:
1. Scale the relative permeability end points by the miscibility function. The residual oil saturation is
S or = S orm M + S ori (1-M ) Eq. 23.9
where
Solvent model
176
Sorm is the miscible residual oil saturation (this is taken from SORWMIS, or defaulted to zero if
SORWMIS is not present)
Sori is the immiscible residual oil saturation (this is taken from Sogcr in the SOF3 table, or SOGCR
if entered)
M is the miscibility function entered using the MISC keyword
Similarly, for the solvent gas

S sgr = S sgrm M + S sgri (1-M ) Eq. 23.10
where
Ssgrm is the miscible residual solvent + gas saturation (taken from SGCWMIS or defaulted to zero)
Ssgri is the immiscible residual solvent + gas saturation (taken from Sgcr in the SGFN table, or
SGCR if entered)
2. Calculate the miscible and immiscible relative permeabilities at the scaled saturations using the new
end points. Then the relative permeability is again an interpolation between the two using the
miscibility function:
k r = k rm M + k ri (1-M ) Eq. 23.11
where
krm the scaled miscible relative permeability
kri is the scaled immiscible relative permeability
The formulae above, equations 23.5 to 23.8, are modified to take into account these new saturation
end points, so that:
S g + S s -S gc
k rgt = ( S n -S gc - S or ) k rn ( S n ) Eq. 23.12
S o -S or
k ro = ( S n -S gc - S or )k rn ( S n ) Eq. 23.13
Modifying the straight line miscible functions using the MSFN keyword will result in
S g + S s -S gc
k rgt = M krg ( S n -S gc - S or ) k rn ( S n ) Eq. 23.14
S o -S or
k ro = M kro ( S n -S gc - S or )k rn ( S n ) Eq. 23.15
where the Mkro and Mkrg functions are supplied with the MSFN keyword.
The saturations supplied in this keyword are normalized and honor the end-point supplied in the
SORWMIS and SGCWMIS keywords. The critical oil to water saturation Sor is entered with the
SORWMIS keyword and the critical oil to gas saturation Sgc is supplied with the SGCWMIS keyword as
Solvent model
177
a function of the water saturation and weighted as appropriate as explained above (1). See also the
"Effect of water saturation".
Pressure effect on relative permeability and capillary

pressure miscibility
In many miscible displacements, the solvent is only miscible with the reservoir oil at high pressure.
Typically the solvent/oil capillary pressure will reduce with increasing pressure, and only when it has
reduced to zero can the two fluids be considered to be miscible.
The pressure dependence can be modeled by using the PMISC keyword to supply a pressure dependent
miscibility function Mp . This is used to interpolate between the immiscible and miscible values of the PVT
and relative permeability. Here we described its usage with the relative permeability.
For the relative permeabilities and saturation end points, the effect of pressure miscibility is combined with
the solvent saturation MISC effects, so that the multiplier M coefficient in equations 23.9 to 23.11 is now
replaced by:
M T = MM p Eq. 23.16
Pressure miscibility is not taken into account when calculating capillary pressure in FrontSim.
Effect of water saturation

A feature of miscible gas injection processes that may also be modeled is the screening effect of high water
saturation which reduces the contact between the miscible gas and the oil in-place. The effective residual
oil saturation to a miscible gas drive is found to increase with increasing water saturation, and correct
modeling of the effect is important since it may reduce the efficiency of the miscible displacement. The
process is modeled by introducing an effective residual oil saturation, Sor , which depends on the water
saturation ( S or = S or ( S w )) and is input with the SORWMIS keyword. A mobile oil saturation is then
calculated by
S o* = MAX ( S o -S or , 0.0) Eq. 23.17
For completeness, a corresponding mobile gas saturation has been defined in which a critical gas saturation
( S gc = S gc ( S w )) is specified for the miscible flood and input with the SGCWMIS keyword. Then the
mobile gas saturation is taken as:
S g* = MAX ( S g -S gc , 0.0) Eq. 23.18
The mobile oil and gas saturations S o*, S g* are used to determine the miscible component relative
permeabilities and the effective viscosities and densities in each grid cell. When End-point Scaling is used
in conjunction with SORWMIS, then Sorm is replaced by the scaled value of the critical hydrocarbon to
water saturation taken from the SOF2 table (or keyword SOGCR if entered). When endpoint scaling is used
in conjunction with SGCWMIS, then Ssgrm is replaced by the scaled value of SGCR.
Viscosity model
The full three hydrocarbon components mixing calculation can be thought of as two separate miscible
displacements: gas/solvent and solvent/oil. The effective viscosities of the hydrocarbon components follow
the Todd and Longstaff model:
Solvent model
178
ω
μo eff = μ o1-ω ⋅ μ mos
μs eff = μ s 1-ω ⋅ μ mω Eq. 23.19

ω
μg eff = μ g1-ω ⋅ μ msg
where
μo , μs , μg are the component viscosities of oil, solvent and gas.
μmos is the fully mixed viscosity of oil + solvent
μmsg is the fully mixed viscosity of solvent + gas
μm is the fully mixed viscosity of oil + solvent + gas
ω is the Todd-Longstaff parameter.
The mixture viscosities μmos , μmsg and μm are defined using the 1/4th-power fluid mixing rule, as follows:
μo μs
μmos = 4
So Ss Eq. 23.20
( Sos
μs 1/4 +
Sos
μo1/4 )
μo μs μg
μm = 4
So Ss Sg Eq. 23.21
( Sn
μs 1/4μg1/4 +
Sn
μo1/4μg1/4 +
Sn
μo1/4μs 1/4 )
μs μg
μmsg = 4
Ss Sg Eq. 23.22
( Ssg
μg1/4 +
Ssg
μs 1/4 )
where Sn = So + Ss + Sg , Sos = So + Ss and S sg = S s + S g
These effective viscosities are also used to compute the effective densities as detailed below.
Density model
The treatment of effective oil, gas and solvent densities is based on the fourth power law for the effective
viscosities above. By default, the density calculation can be based on the same mixing parameter as the
viscosity, however a separate mixing parameter may be specified for the effective density calculation if
required.
The densities are computed by the following procedure. First, the effective viscosities are calculated using
equations 23.20 to 23.22 above. The value of each effective component viscosity is then used in turn in
equations 23.20 to 23.22 to yield an effective saturation fraction to be used in oil, gas and solvent density
calculations as:
So μ o1/4 μ o1/4
( eff - μ s
1/4
)
( )
Sn oe
=
μ o1/4
eff
1/4 1/4
( μ o - μ s )
Eq. 23.23
Solvent model
179
Sg μ s 1/4 μ g1/4 - μ g
( 1/4
)
( )
Sn ge
=
μ g1/4
eff (μs 1/4
−
eff
μ g1/4 )
Eq. 23.24
The solvent effective saturation fraction is computed as:
μo1/4μs 1/4μg1/4
Ss
( ) =
μo1/4μg1/4 -
( 1/4
μs eff )
+ μo1/4 μg1/4-μs 1/4 Sse
( ) Eq. 23.25
Sn se μs 1/4 μo1/4-μg1/4
( )
where
Ss
Sse =
Sn
The effective oil, gas and solvent densities (ρo eff, ρg eff, ρs eff) are now computed from the effective
saturation fractions in equations 23.23 to 23.25, and the pure component densities (ρo , ρg , ρs ) using the
following formulae
So So
ρo eff = ρo ( )
Sn oe
+ ρs 1- ( ) Sn oe
Eq. 23.26
Sg Sg
ρg eff = ρg ( )
Sn ge
+ ρs 1- ( ) Sn ge
Ss Ss
ρs eff = ρ s S se + ρ o ( ) Sn se
+ ρ g 1- ( )
Sn se
- S se
Note that equations 23.23 to 23.25 are singular for unit mobility ratio displacements. In that case, for
example where μo = μg , the effective densities are computed as follows. First, a mixture density is defined
as:
So Sg Ss
ρm = ρo ( ) ( ) ( )
Sn
+ ρg
Sn
+ ρs
Sn
Eq. 23.27
Then
ρo eff = (1-ω )ρ o + ωρ m Eq. 23.28
ρg eff = (1-ω )ρ g + ωρ m Eq. 23.29
ρs eff = (1-ω )ρ s + ωρ m
Where ω is the Todd and Longstaff parameter input with the TLMIXPAR keyword.
Pressure effect on viscosity and density miscibility

As for the relative permeability, the pressure dependence of the transition between the immiscible and the
miscible flow can be modeled for PVT data. This is achieved by using the PMISC keyword to supply a
pressure dependent miscibility function Mp . This is used to interpolate between the immiscible and
miscible values of the PVT as follows, with the gas component taken as an example:
Solvent model
180
1 1 1
= M + 1-M p )
Bg B gm p B gi ( Eq. 23.30
μ g = μ gm M p + μ gi (1-M p ) Eq. 23.31
where
Bg is the effective gas formation volume factor
Bgi is the immiscible gas formation volume factor
Bgm is the miscible gas formation volume factor
μg is the effective gas viscosity
μgi is the gas viscosity (immiscible)
μgm is the gas viscosity (miscible)
Mp is the pressure dependent miscibility function entered using the PMISC keyword.
Note that the above equation is different to the one used for ECLIPSE due to the difference in the way that
these parameters are stored in tables and interpolated in the simulators. ECLIPSE uses the reciprocal of
viscosity multiplied by the volume factor, however FrontSim interpolates on the viscosity.
Note that for the relative permeability the interpolation can be a combination of both MISC and PMISC
keywords.
Choice of the mixing parameter

The mixing-parameter model would be of limited use unless the mixing parameter could itself be modeled
over a wide range of operating conditions. A value of ω = 1 results in a piston-like displacement of oil by
the injected solvent. If ω = 0 the displacement is similar to an immiscible displacement (except for the
treatment of relative permeability). An intermediate value of ω results in a continuous solvent saturation
increase behind the solvent front. Todd and Longstaff accounted for the effects of viscous fingering in 2D
studies by setting ω = 2 / 3 independently of mobility ratio. For field-scale simulations they suggested
setting ω = 1 / 3. However, in general history matching applications, the mixing parameter may be
regarded as a useful history matching variable to account for any reservoir process inadequately modeled.
Using the Solvent model

Initiating the model
Two keywords in RUNSPEC control the solvent and miscible models:
SOLVENT Activates the separate solvent component
MISCIBLE Initiates the mixing calculation
Solvent model
181
If SOLVENT is specified, then the four-component model is used. The SOLVENT keyword should only be
used with the other three components/phases (water, oil, gas) present.
If the solvent model is run in immiscible mode, the mixing is not performed, and the four components take
their pure PVT properties. The relative permeabilities are calculated as for a traditional black oil case, with
the solvent and gas taking their respective fraction of the total ‘gas’ relative permeability.
PVT data
This consists of the following keywords:
SDENSITY Surface density of the solvent
PVDS Pressure dependent data for each PVT region (analogous to PVDG)
These PVT data can be used with the mixing parameter ω which is input in the PROPS section with the
keyword TLMIXPAR as described in the "Viscosity model" and "Density model". If the grid contains cells
whose MISCNUM region is zero, this mixing parameter is automatically set to zero in those cells. The
miscibility region numbers are specified using keyword MISCNUM in the REGIONS section. The first
argument NTMISC of the keyword MISCIBLE sets the maximum number of regions which can be defined
(not used by FrontSim).
Relative permeability data

The relative permeability data needs to be specified as follows:
SGFN For krg in immiscible regions (either MISCNUM =0 or Sg » 0)
SWFN For any case containing water.
SOF2 Three-component or miscible case: cases with MISCNUM=0 in at least one cell, SOF2 gives krog.
Four-component case: SOF2 gives krhc (kr of the miscible hydrocarbon phase to water).
SOF3 Three-component cases: Three-phase cases with MISCNUM=0 in at least one cell
Four-component cases: immiscible displacement regions
SSFN In immiscible or miscible four-component cases.
In four-component cases, the miscibility function needs to be defined to control the transition from miscible
to immiscible relative permeabilities. This is done using the MISC keyword in the PROPS section.
The miscible solvent-oil relative permeability curves can modified using the MSFN keyword. If the MSFN
keyword is omitted, straight line relative permeability curves will be used.
Transition between immiscibility and miscibility

The transition between an immiscible and a miscible displacement is controlled by the following keywords
MISC Tables of the miscibility function versus local solvent fraction (four-component)
Solvent model
182
PMISC Tables of the miscibility function versus oil pressure.
MISC is required for all four-component runs, but PMISC is optional. If PMISC is not specified, the
solvent/oil displacement is assumed to be miscible at all pressures.
Injecting solvent into the reservoir

Solvent can be injected by specifying a gas injection well. A separate keyword WSOLVENT can then be
used to specify the fraction of the gas flow as solvent.
It is also possible to initialize the model by enumeration and to include a Solvent saturation. This is
achieved using the SSOL keyword in the SOLUTION section.
Summary of keywords
RUNSPEC section
The keywords are:
Keyword Description
SOLVENT Activates the separate solvent component.
MISCIBLE Initiates the mixing calculation.
Table 23.1: RUNSPEC section
PROPS section
The keywords are:
Keyword Description
MISC Solvent fraction dependent miscibility tables.
MSFN Miscible gas/oil saturation functions.
PMISC Pressure dependent miscibility tables.
PVDS Pressure dependent PVT properties for solvent gas.
SDENSITY Solvent density at surface conditions.
SGCWMIS Miscible critical gas saturation tables versus water saturation.
SORWMIS Miscible residual oil saturation tables versus water saturation.
SSFN Gas/solvent relative permeability functions.
TLMIXPAR Todd-Longstaff mixing parameter.
Table 23.2: PROPS section
REGIONS section
The keywords are:
Solvent model
183
Keyword Description
MISCNUM Miscibility region numbers.
Table 23.3: REGIONS section
SOLUTION section
The keywords are:
Keyword Description
SSOL Initial solvent saturations.
Table 23.4: SOLUTION section
SUMMARY section
The following keywords control the output of data specific to the Solvent Model.
Field Group Well Information

FNPR GNPR WNPR Solvent Production Rate
FNPT GNPT WNPT Solvent Production Total
FNIR GNIR WPIR Solvent Injection Rate
FNIT GNIT WNIT Solvent Injection Total
FNIP Solvent In Place
Table 23.5: Solvent SUMMARY output controls
Note: As for ECLIPSE, FrontSim reports the field, group and well gas rates and totals for the total gas
phase, including the solvent gas. The total gas phase is also used when calculating the GOR. This was not
the case for version 2012.1.
The additional streamline based pattern quantity summary vectors are:
Field Pattern Well Information

FMISCF WPMISCF CPMISCFL Fraction of oil under miscible conditions (Solvent model only).
FMOIPS WPMOIPS CPMOIPSL Volume of oil that can be released by miscibility (Solvent).
FMOPOTS WPMOPOTS CPMOPOSL Fraction of oil volume that can be released by miscibility
(Solvent).
FMOEFFS WPMOEFFS CPMOEFSL Fraction of original MOPOT that has been released by miscibility
(Solvent).
FVIEFFS WPVIEFFS CPVIEFSL Solvent Injection Efficiency. Ratio of released oil due to
miscibility and injected/produced volume.
WPNIP CPNIPL Pattern solvent in-place volume.
WPNPR CPNPRL Pattern solvent production rate.
Solvent model
184
Field Pattern Well Information

WPNPT CPNPTL Pattern solvent cumulative production.
Table 23.6: Streamline based pattern quantity summary vectors
SCHEDULE section
The keywords are:
keyword Description
WSOLVENT Sets solvent concentrations for gas injection wells.
WCONPATS Manage the solvent allocation algorithm.
ALLPROPS SOL_DEN, SOL_VISC, 1OVERBS and SOLKR are output if the SOLVENT option is
active.
Table 23.7: SCHEDULE section
Example problem
RUNSPEC
RUNSPEC
TITLE
SPE Fifth Comparison Test Problem - Scenario 2 - 4 Phase
DIMENS
7 7 3 /
OIL
WATER
GAS
SOLVENT
FIELD
MISCIBLE
/
START
1 'JAN' 1986 /
GRID
GRID ==============================================================
DEPTHZ
64*8325 /
DXV
7*500 /
DYV
7*500 /
DZV
20 30 50 /
EQUALS
'PORO' 0.3 /
'PERMX' 500 /
'PERMZ' 50 /
'PERMX' 50 1 7 1 7 2 2 /
Solvent model
185
'PERMZ' 50 /
'PERMX' 200 1 7 1 7 3 3 /
'PERMZ' 25 /
/
COPY
'PERMX' 'PERMY' 1 7 1 7 1 3 /
/
PROPS
PROPS =============================================================
SWFN
0.20 0.0 45.00
0.2899 0.0022 19.03
0.3778 0.0180 10.07
0.4667 0.0607 4.90
0.5556 0.1438 1.80
0.6444 0.2809 0.50
0.7000 0.4089 0.05
0.7333 0.4855 0.01
0.8222 0.7709 0.00
0.9111 1.0000 0.00
1.0000 1.0000 0.00 /
SGFN
0.0000 0.0 0.0
0.0500 0.0 0.0
0.0889 0.001 0.0
0.1778 0.01 0.0
0.2667 0.03 0.001
0.3556 0.05 0.001
0.4444 0.1 0.03
0.5333 0.2 0.8
0.6222 0.35 3.0
0.6500 0.39 4.0
0.7111 0.56 8.0
0.8000 1.0 30.0 /
SOF2
0.0 0.0
0.0889 0.0
0.1778 0.0
0.2667 0.0
0.3000 0.0
0.3556 0.0123
0.4444 0.0835
0.5333 0.2178
0.6222 0.4153
0.7101 0.6769
0.8000 1.0000 /
SOF3
-- KROW KROG
0.0 0.0 0.0
0.0889 0.0 0.0
0.15 0.0 0.0
0.1778 0.0 0.0110
0.2667 0.0 0.0370
0.3000 0.0 0.05
0.3556 0.0123 0.0878
0.4444 0.0835 0.1715
0.5333 0.2178 0.2963
0.6222 0.4153 0.4705
0.7101 0.6769 0.7023
0.75 0.7 0.8800
0.8000 1.0000 1.0000 /
SSFN
-- KRG* KRS*
0 0.0 0.0
1.0 1.0 1.0
Solvent model
186
MISC
0.0 0.0
0.1 1.0
1.0 1.0 /
PVTW
4000.0 1.000 3.3D-6 0.70 0 /
ROCK
4000.0 5.0D-6 /
DENSITY
38.53 62.40 0.06867 /
SDENSITY
0.06243 /
TLMIXPAR
0.7 /
PVDG
14.7 211.4160 0.0107
500.0 5.9242 0.0127
1000.0 2.8506 0.0134
1200.0 2.3441 0.0138
1500.0 1.8457 0.0145
1800.0 1.5202 0.0153
2000.0 1.3602 0.0159
2302.3 1.1751 0.0170
2500.0 1.1025 0.0177
3000.0 0.9852 0.0195
3500.0 0.9116 0.0214
4000.0 0.8621 0.0232
4500.0 0.8224 0.0250
4800.0 0.8032 0.0261 /
PVDS
14.7 223.2140 0.011
500.0 5.6022 0.012
1000.0 2.5310 0.013
1200.0 2.0354 0.014
1500.0 1.5593 0.016
1800.0 1.2657 0.018
2000.0 1.1296 0.019
2302.3 0.9803 0.022
2500.0 0.9085 0.023
3000.0 0.7807 0.027
3500.0 0.6994 0.031
4000.0 0.6430 0.034
4500.0 0.6017 0.037
4800.0 0.5817 0.038 /
PVTO
0.0000 14.7 1.0348 0.310 /
0.1176 500.0 1.1017 0.295 /
0.2226 1000.0 1.1478 0.274 /
0.2677 1200.0 1.1677 0.264 /
0.3414 1500.0 1.1997 0.249 /
0.4215 1800.0 1.2350 0.234 /
0.4790 2000.0 1.2600 0.224 /
0.5728 2302.3 1.3010 0.208
3302.3 1.2988 0.235
4302.3 1.2966 0.260 /
0.6341 2500.0 1.3278 0.200 /
0.7893 3000.0 1.3956 0.187 /
0.9444 3500.0 1.4634 0.175 /
1.0995 4000.0 1.5312 0.167 /
1.2547 4500.0 1.5991 0.159 /
1.3478 4800.0 1.6398 0.155
5500.0 1.6305 0.168 /
/
Solvent model
187
SOLUTION
SOLUTION ============================================================
EQUIL
8400 4000 9900 0 1000 0 1 0 0 /
RSVD
8200 0.5728
8500 0.5728 /
SUMMARY
SUMMARY ============================================================
FOPR
FNPR
FGPR
SCHEDULE
SCHEDULE ============================================================
WELSPECS
'PRODUCER' 'G' 7 7 8400 'OIL' /
'INJ-G ' 'G' 1 1 8335 'GAS' /
'INJ-W ' 'G' 1 1 8335 'WAT' /
/
COMPDAT
'PRODUCER' 7 7 3 3 'OPEN' 0 -1 0.5 10000.0 /
'INJ-G ' 1 1 1 1 'OPEN' 0 -1 0.5 10000.0 /
'INJ-W ' 1 1 1 1 'OPEN' 0 -1 0.5 10000.0 /
/
WCONPROD
'PRODUCER' 'OPEN' 'ORAT' 12000 4* 3000 /
/
WECON
'PRODUCER' 1* 1* 5.0 10.0 1* 'WELL' 'YES' /
/
WCONINJE
'INJ-W' 'WAT' 'OPEN' 'RATE' 45000 1* 1* 1* 4500 /
'INJ-G' 'GAS' 'OPEN' 'RATE' 20000 1* 1* 1* 4500 /
/
WSOLVENT
'INJ-G' 1.0 /
/
MAXSTEP
5/
TUNEFS1D
1* 2* 2* 3* 10 100 1.0 1* /
-- YEAR 1 ------------------------------------------------------
INCLUDE
'CASE2.ONEYEAR' /
-- YEAR 2 ------------------------------------------------------
INCLUDE
'CASE2.ONEYEAR' /
END
Solvent model
188
Included file
-- INCLUDED FILE: CASE2.ONEYEAR
-- FIRST 3 MONTHS ------------------------------------------------
--*WATER*--
WELOPEN
'INJ-G' 'SHUT' /
'INJ-W' 'OPEN'/
/
TSTEP
91.25
/
-- SECOND 3 MONTHS -------------------------------------------------

--*GAS*--
WELOPEN
'INJ-W' 'SHUT' /
'INJ-G' 'OPEN' /
/
TSTEP
91.25
/
--THIRD 3 MONTHS --------------------------------------------------

--*WATER*--
WELOPEN
'INJ-G' 'SHUT' /
'INJ-W' 'OPEN' /
/
TSTEP
91.25
/
-- FOURTH 3 MONTHS ----------------------------------------------

--*GAS*--
WELOPEN
'INJ-W' 'SHUT' /
'INJ-G' 'OPEN' /
/
TSTEP
91.25
/
-----------------------------------------------------------------
Solvent pattern flood management - solvent

allocation
As for water floods (Pattern Flood Management) the data carried by streamlines can be used to effectively
manage the allocation of solvent among a group of injectors. For this purpose FrontSim has implemented
an algorithm for allocation of solvent managed by the keyword WCONPATS. The algorithm uses a mix of
Solvent model
189
the serial filling up of solvent into injector patterns followed by a solvent allocation strategy where the
injectors are ranked based on user-selected control criteria.
Solvent pattern quantities

The summary vectors for streamline based solvent quantities that are relevant for the solvent allocation
algorithm and for you to inspect the efficiency of the miscible injection process are listed in tables 23.5 and
23.6. This section provides more information on some of these vectors:
• WNIR and WNIT are the solvent injection rate and the accumulated injection
• WPNIP, WPNPR and WPNPT are the solvent in place, solvent production rate and solvent production
from the injector based pattern.
• In the following equations, the summation over ss refers to the streamline segments and the
summation over sl refers to the streamlines.
Sorw - is the residual oil in the water-oil system
Sor - is the current residual oil after solvent flood
Sors - is the minimum residual oil saturation after solvent flood and current pressure.
• WPVIEFFS
is a measure of how efficient the solvent injected into the pattern mobilizes the oil due to miscibility.
The calculation uses the change of the Sor over the timestep relative to the throughput. Throughput is
calculated as the average of the injection and production voidage rates.
∂
Σ (PV ⋅ (Sorw - Sor))
∂ t ss
VIEFFS =
Σ Qr
sl
where Qr is the throughput.
Beware that this can easily be a negative number.

• WPMISCF
is a measure of how much of the remaining oil volume is in the miscible condition. It is calculated as
the average miscibility fraction.
Σ (Vo ⋅ M(P, S))
ss
MISCF =
Σ Vo
ss
where M is the miscibility fraction at current pressure and solvent saturation and Vo is the oil volume.
• WPMOIPS
is a measure on how much oil can theoretically be mobilized by miscible injection in the pattern.
MOIPS = Σ ( PV ⋅ bo ⋅ ( Sor - Sors ))
ss
where bo is the inverse oil formation volume factor and PV the pore volume.
• WPMOPOTS
Solvent model
190
is the fraction of MOIPS versus oil volume

MOPOTS =MOIPS/OIP
• WPMOEFFS
is the fraction of the original MOIPS that has been mobilized by miscible flood.
Σ (PV ⋅ bo ⋅ (Sorw - Sor))
ss
MOEFFS =
Σ (PV ⋅ bo ⋅ (Sorw - Sors))
ss
where PV is the pore volume and bo is the inverse oil formation volume factor.
Note: The volumetric calculations for the streamlines can be limited by the TOF (time-of-flight) to the
producer along the streamline by setting a value for the maximum TOF in the WCONPATS keyword. Note
that this will impact all the solvent based pattern quantities that include a volumetric calculation along the
streamlines. Figure 23.1 shows an example of the different streamline volumes used for these calculations
when the maximum TOF was defaulted (left) and limited to 3650 days (right).
Figure 23.1. Effect of maximum TOF settings on streamline volume based calculations
The solvent allocation algorithm

The solvent allocation algorithm can be summarized as follows (for each timestep):
1. Prioritize the injectors
Rank the injectors based on their solvent slug size and their control criteria value. The solvent slug
size is calculated as
WNIT * Bs/ WPHCPV
where
WNIT is the total injected solvent for the injector until current time
Bs is the solvent formation volume factor calculated at the well block pressure
WPHCPV is the injector pattern hydrocarbon pore volume calculated by the streamlines for previous
timestep.
Solvent model
191
Note:
Note that WPHCPV varies over time due to changes in streamline pattern and will affect the calculation
of the slug size. Slug size can decrease if pattern volume is increasing.
You can select the control criteria used. Current options are:
• SINJEFF - Solvent injection efficiency. See the definition of WPVIEFFS in "Solvent pattern
quantities".
• SRECOV - Potential volume of extra oil that can be recovered by injecting the miscible solvent
into the injector pattern. See definition of WPMOPOTS in "Solvent pattern quantities".
All wells with a slug size less than the user-defined slug size limit for the fill-up phase are ranked first
and in same sequence as they were listed in the WLIST definition.
The remaining wells with a slug size larger than the slug size limit are ranked according to their
control criteria value.
2. Distribute the available solvent
The user-defined solvent rate capacity is distributed among the injectors. The injection rates are not
changed by this algorithm, only the target injection phase. You can directly set rates or they can be
calculated as part of PFM or group control. These rates are converted to the phase rates (solvent, gas
or water) that get allocated by this algorithm.
The distribution of the solvent is done in sequence down the ranked list as long as there is solvent
available (the solvent capacity).
The injectors that do not get solvent allocated will inject the other phase (reservoir gas or water) which
you specify in the WCONPATS keyword.
The last well in the list that gets allocated solvent might not get sufficient solvent for the full timestep.
If so, for the rest of the timestep it will then inject the other phase instead of solvent.
An example of how the injectors are ranked and allocated solvent is shown in table 23.8. The WLIST
keyword identifies that the injectors prioritized at the wells in the following sequence: 14, 15, 16, 17.
The minimum slug size was set to 0.10. Wells 14 and 17 were ranked first due the slug size being less
than the minimum slug size, with well 14 being prioritized before 17. Well 15 has higher value for the
control criteria and is ranked before 16. The solvent is allocated from the top of the list.
You can change the solvent capacity for each report timestep. For instance, a process where solvent is
injected followed by a period of water injection can be obtained by setting the solvent capacity to a
very low value (or 0.0) during the water injection period.
Rank Well Slug size Criteria value Rate (RESV) Solvent conc.
1 14 0.0428 1.0000 8.91 1.000
2 17 0.0578 0.8580 24.95 1.000
3 15 0.1717 0.9729 34.59 0.085
4 16 0.1526 0.6117 6.15 0.000
Table 23.8: Example ranking and solvent allocation
Solvent model
192
Injection rate allocation by using PFM

The actual injection rates can either be regular input that you specify or, preferably, be made by applying
PFM (Pattern Flood Management). If the rates are input directly through the WCONINJE or GCONINJE
keywords it is important to realize that the solvent allocation algorithm will apply the same reservoir rate
(RESV) based on this input and it will only set the phase and solvent concentration decided by the solvent
allocation algorithm.
To optimize the solvent flood it is often best to apply it on top of the regular PFM algorithm. The PFM
algorithm will first reallocate the injection rates based on which injectors are most effective to maximize oil
production. The criteria used to maximize oil production in PFM will also favor the most effective solvent
floods which inherently will increase the potential mobile oil (RECOV) and the oil cut (INJEFF) in the
pattern used by PFM. The solvent allocation will take place after the PFM algorithm is done and the rates
have been decided.
The injection of solvent does not have an immediate effect on oil rate in the patterns. There is a time lag
between when solvent is injected and the oil rate increase due to miscible effects. Therefore, when using
PFM for reallocation of injection rates, this needs to be considered when selecting the PFM control criteria
for maximizing oil production from the patterns. The INJEFF option in PFM will act on the current oil cut
and will not be the most effective criteria early in the solvent injection process due to the time lag. RECOV
and VREP are likely to be much better in the period when solvent is injected. However, later when oil rate
increases in the pattern due to the previously injected solvent, the INJEFF control criteria can help in
pushing out the released oil. This effect can be observed in figure 23.2.
Solvent model
193
Figure 23.2. Solvent injection and oil production
Solvent model
194
Using the WCONPATS keyword

The WCONPATS keyword is used in the SCHEDULE section of the data file to manage the solvent
The following example shows the SCHEDULE section of a data file with the solvent allocation being
specified using WCONPATS and with PFM being specified by WCONPAT. This example produced the plot
shown in figure 23.2.
WELSPECS
P1 A 8 8 1* LIQ 3* 1* 3* /
P2 A 24 8 1* LIQ 3* 1* 3* /
P3 A 40 8 1* LIQ 3* 1* 3* /
P4 A 8 24 1* LIQ 3* 1* 3* /
P5 A 24 24 1* LIQ 3* 1* 3* /
P6 A 40 24 1* LIQ 3* 1* 3* /
P7 A 8 40 1* LIQ 3* 1* 3* /
P8 A 24 40 1* LIQ 3* 1* 3* /
P9 A 40 40 1* LIQ 3* 1* 3* /
I1 INJ 16 16 1* WATER 3* 1* 3* /
I2 INJ 32 16 1* WATER 3* 1* 3* /
I3 INJ 16 32 1* WATER 3* 1* 3* /
I4 INJ 32 32 1* WATER 3* 1* 3* /
/
COMPDAT
P1 8 8 1 1 2* 1* 0.75 /
P2 24 8 1 1 2* 1* 0.75 /
P3 40 8 1 1 2* 1* 0.75 / -- horizontal well section
P3 40 7 1 1 2* 1* 0.75 /
P4 8 24 1 1 2* 1* 0.75 /
P5 24 24 1 1 2* 1* 0.75 /
P6 40 24 1 1 2* 1* 0.75 /
P7 8 40 1 1 2* 1* 0.75 /
P8 24 40 1 1 2* 1* 0.75 /
P9 40 40 1 1 2* 1* 0.75 / -- horizontal well section
P9 39 40 1 1 2* 1* 0.75 /
P9 38 40 1 1 2* 1* 0.75 /
P9 37 40 1 1 2* 1* 0.75 /
I1 16 16 1 1 2* 1* 0.75 /
I2 32 16 1 1 2* 1* 0.75 /
I3 16 32 1 1 2* 1* 0.75 /
I4 32 32 1 1 2* 1* 0.75 /
/
WLIST
'*PRI_PROD' NEW P1 P2 P4 P5 P6 /
'*SEC_PROD' NEW P3 P7 P8 P9 /
'*INJ' NEW I* /
/
GCONPROD
-- Cmode oil wat gas Liq Work 6* Resv
FIELD RESV 1* 1* 1* 1* 1* 6* 200.0 /
/
WCONPROD
P* OPEN GRUP 1* 1* 1* 1* 1* 700.0 /
/
WECON
P* 1.0 1* 0.97 1* 1* WELL /
/
TSTEP
1.0 6*91.25 / -- 1.5 years of depletion
GCONINJE
INJ WATER RESV 1* 400.0 /
/
WCONINJE
I* WATER OPEN GRUP 1* 1* 10000.0 /
Solvent model
195
/
TSTEP
1.0 4*91.25 / -- 1 year of fillup injecting at 2 times the total production
GCONPROD
-- Cmode oil wat gas Liq Work 6* Resv
FIELD RESV 1* 1* 1* 1* 1* 6* 400.0 /
/
TSTEP
1.0 28*91.25 / -- 6.5 years of incline + decline
-- End of history
WCONPAT
-- WELLS CITERIA ALPHA RANGE TYPE MIN. MAX Res Voidage Aquifer Aquifer Injection
-- WT WT erved Fraction Cutback Realloc Capacity
*INJ RECOV 1.0 1.0 0 -0.1 0.1 1* 1* 1* 0 400 /
/
TSTEP
60*91.25 /
TSTEP
60*91.25 /
-- Start Solvent WAG
WCONPAT
*INJ RECOV 1.0 1.0 0 -0.1 0.1 1* 1* 1* 0 400 /
/
-- Inject Solvent / Gas
WCONPATS
*INJ SRECOV 400 G 36500.0 0.12 /
/
TSTEP
10*90 /
-- Inject reservoir gas only

WCONPATS
*INJ SRECOV 0.0 G 36500.0 0.12 /
/
TSTEP
40*90 /
-- Inject Solvent / gas

WCONPATS
*INJ SINJEFF 200 G 36500.0 0.12 /
/
TSTEP
10*90 /
-- Inject Water only

WCONPATS
*INJ SINJEFF 0.0 W 36500.0 0.12 /
/
TSTEP
40*90 /
WCONPATS
-- *INJ SRECOV 200 W 36500.0 0.12 /
*INJ SINJEFF 200 W 36500.0 0.12 /
/
TSTEP
10*90 /
-- Inject reservoir gas
WCONPATS
*INJ SINJEFF 0.0 W 36500.0 0.12 /
/
TSTEP
40*90 /
WCONPAT
*INJ RECOV 1.0 1.0 0 -0.1 0.1 1* 1* 1* 0 400 /
Solvent model
196
/
-- Back on water only
WCONPATS
*INJ SINJEFF 0.0 W 36500.0 0.12 /
/
TSTEP
100*60 /
END
Solvent model
197
24
Three-phase saturation solver
Unlike the two-phase case, it is not currently possible to solve streamlines by front tracking when three
ECLIPSE 100 phases are present. In this case, the streamlines are converted to one-dimensional finite volume models and
ECLIPSE 300 solved using standard finite volume simulation techniques.
x FRONTSIM
The one-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 one-
dimensional finite volume models.
Streamline solution
Refer to "1D grids", which describes how the 1D finite difference grid is constructed from a streamline.
Having constructed these one-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
• IMPLICIT
• AIM
• IMPES
• 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 you can control this), 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 one-dimensional
streamlines. They respectively represent a fully implicit solution, an IMPES (IMplicit Pressure, Explicit

198
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
R = + F ( P t +dt , S t +dt ) + Q ( P t +dt , S t +dt )
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 (black oil) in the model. The number of
calculations required to do this varies linearly with Ncell and with the third 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.
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 Rs , Rv ) in a black oil run; or molar densities
in a compositional run at the beginning of each timestep.
M t +dt -M t
R = + F ( P t +dt , S t ) + Q ( P t +dt , S t ) Eq. 24.1
dt
The mass terms Mt +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 Newton’s 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.

199
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 an 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.
Gravity line solution

Clearly if we have three 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.
Mapping the solution between streamlines and

the grid
A key part of the three-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 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 = ΣV i
where
Vsl is the volume of the streamline cell and
Vi is the volume of grid cell i 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
ΣV i X i
X sl =
V sl

200
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, you have 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, you 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 = ΣV j + V nsl
where
Vgr is the volume of the grid cell,
Vnsl 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. You 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.

201
Figure 24.1. Numerical dispersion through the mapping process
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.
Please note 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
Three-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.
• 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.
• 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.
• Decreasing the timestep may help with problems.
• Ensuring that the initial pressure solve has converged also can overcome problems with three-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 TUNEFSPR.
In each case, there is a cost in terms of the simulator performance. You 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.
Keywords
There are two keywords that provide control over the three-phase saturation solver:
• TUNEFS1D is the main keyword for controlling the three-phase saturation solver.
• OPTIONFS primarily provides back compatibility with previous code versions, but allows some
tuning of the three-phase solution method.

202
25
Total compressibility checks
In black oil models, FrontSim checks for positive compressibility of each single reservoir fluid as the PVT
x ECLIPSE 100 data is read (the formation volume factor must be a monotonically decreasing function of pressure
x ECLIPSE 300 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 ⋅ Sg V ⋅ Rs ⋅ So
Vg = + Eq. 25.1
Bg Bo
V ⋅ So V ⋅ Rv ⋅ Sg
Vo = + Eq. 25.2
Bo Bg
Equations 25.1 and 25.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
Sg dB g dR v B o -R s B g So dB o dR s B g -R v B o
Ct =
Bg ( -
dP
+
dP
⋅
1-R s R v ) (
+
Bo
-
dP
+
dP
⋅
1-R s R v ) Eq. 25.3
where the pressure derivatives are taken along the saturation curve.
This can also be written as
Ct = Sg Ct ,gas + So Ct ,oil Eq. 25.4
which splits the total compressibility into gas and oil dependent terms.

203
To derive this expression, we assume without loss of generality that

So + Sg = 1 Eq. 25.5
and note that

dVo / dp = dVg / dp = 0 Eq. 25.6
since the volumes of stock tank oil and separator gas are fixed.
Solving for So and Sg gives
Rv Vg - Vo Bo
So = ⋅ Eq. 25.7
V Rs Rv - 1
and
R s V o - V g Bg
Sg = ⋅ Eq. 25.8
V Rs Rv - 1
And since So + Sg = 1 we have
1
V =
( s v - 1)
R R (
⋅ Vo (Rs Bg - Bo ) + Vg (Rv Bo - Bg )
) Eq. 25.9
Hence
1 dV
Ct = - ⋅
V dp
( R s dR v / dp + R v dR s / dp)
=-
( R s R v - 1) Eq. 25.10
dB g dR s dB o dB o dR v dB g
+
{ Vo Rs
dp
+ Bg
dp dp
- + Vg Rv
dp
+ Bo
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 Ct .
Some simple limiting cases may be derived from equation 25.3.

• If Rs = Rv = 0 then
Sg dB g So dB o
Ct = - ⋅ - ⋅ >0 Eq. 25.11
Bg dP Bo dP
since the formation volume factor pressure derivatives are < 0.

• If Rs > 0 and Rv = 0 then
Sg dB g So dB o dR s
Ct = -
Bg
⋅
dP
-
Bo
⋅ ( dP
-B g
dP ) Eq. 25.12
so that Ct < 0 if dB o / dP > B g dR s / dP and Sg 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

204
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 equation 25.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 Sg = 0 and
Sg = 1 in equation 25.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 equation 25.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 / Bo 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.

205
26
Tracer tracking
The tracer tracking option is a general facility to follow the movement of ‘marked’ fluid elements during a
x ECLIPSE 100 simulation run.
x ECLIPSE 300
The tracer tracking option has a wide variety of reservoir modeling applications. In the case of tracers
x FRONTSIM
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.
Tracer tracking for three-phase models was implemented in FrontSim 2012.1, but does not allow
adsorption functions for the tracers. Tracer tracking for the combination of dual porosity and two-phase
models is currently not available in FrontSim.
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 called the Langmuir model is
used for adsorption.
The underlying assumption for this model is a reversible exchange of tracer at the rock surface. The
following mathematical model is used:
Tracer tracking
206
∂
a c − k 1 c ( A − (c )) − k 2 a (c ) Eq. 26.1
∂t ( )
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. The 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 1Ac
a (c ) = Eq. 26.2
k 1 + k 2Ac
which is the Langmuir model for adsorption.

In figure 26.1 we see a typical shape of the function.
Figure 26.1. Langmuir model
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 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. 26.3
∂t
where v is the flow velocity.
Thus, the shock speed of a tracer shock (separating cL and cR ) is given by
c R -c L
σ = v Eq. 26.4
c R + a( c R ) - c L - a( c L )
Tracer tracking
207
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 ( c L ) and a ( c R ) 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 timestep.
Tracer tracking
208
27
This chapter describes the expressions used by FrontSim to calculate transmissibility values, between cells
x ECLIPSE 100 in the grid, and between cells and numerical aquifers.
x ECLIPSE 300
The transmissibility calculations for each type of geometry are detailed in the next section. In the corner
x FRONTSIM
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 pre-processor, 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.
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.
209
X- transmissibility
The X-transmissibility is given by the expression:
CDARCY ⋅ TMLTX i
TRANX i =
1 1 Eq. 27.1
+
Ti Tj
where
A ⋅ Di
T i = PERMX i ⋅ RNTG i ⋅
Di ⋅ D i
with
(A ⋅ D i ) = A X ⋅ D iX + A Y ⋅ D iY + A Z ⋅ D iZ
and
(Di ⋅ D i ) = D iX
2 2
+ D iY 2
+ D iZ
AX , AY and AZ 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 centers being obtained as the appropriate
average.
The expression for Tj 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):
Figure 27.1. Y- and Z- transmissibility expressions
210
28
Well inflow performance
This chapter outlines the relationships that FrontSim uses to calculate well inflow performance.
x ECLIPSE 100
We define the flow path between the well bore and a single reservoir grid block as a “connection”.
x ECLIPSE 300
x FRONTSIM The total flow rate (oil + water + gas) at reservoir conditions across a connection is given by the Inflow
Performance Relationship.
Inflow performance relationship

In FrontSim the inflow performance relationship is written in terms of the total volumetric production rate
at reservoir conditions:
qj = TwjMwj (Pj - Pw - Hwj ) Eq. 28.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.
Mwj is the total mobility for the grid block containing the connection. This mobility is used both for
injection and production wells.
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.

211
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. 28.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 Ky )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.
Dx2(Ky / Kx )1/2 + Dy2(Kx / Ky )1/2 1/2

ro = 0.28 Eq. 28.3
(Ky / Kx )1/4 + (Kx / Ky )1/4
where
Dx and Dy are the x- and y- dimensions of the grid block,
Kx and Ky are the x- and y- direction permeabilities.
Equations 28.2 and 28.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 Ky , Kz , Dy and Dz
will be used in equations 28.2 and 28.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 Dz .

212
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”, rd. Thus the productivity index, J, is defined as
J = Q r / ( P d − P w ) Eq. 28.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.

213
29
Well Modeling Facilities
Well completions
x ECLIPSE 100
x ECLIPSE 300
Multiple connections
x FRONTSIM Each well can be completed in several layers of the reservoir. A communication between the well bore and
a single grid block is defined as a connection. A given well may have any number of connections.
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:
• the transmissibility between the grid block and the well bore
• the mobility of the phase in the grid block at the perforations
• 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.
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.

214
Well controls and limits

Well control options
Individual wells can operate at a target value of any of the following quantities:
• Oil flow rate
• Water flow rate
• Gas flow rate
• Liquid flow rate (oil and water)
• Reservoir fluid volume (or voidage) rate
• 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 well’s 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:
• Lower limits for the oil, gas and liquid production rates for each well. The well is closed, if any of
these limits are broken.
• 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:

215
• 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.
• 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.
• The well itself is closed.
The economic limits are checked at the beginning of the timestep, 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 timestep. Thus a
well may produce ‘uneconomically’ for one timestep 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 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 timestep, 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:
• 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.
• 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

216
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 multilevel 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 29.1. Two-level group hierarchy
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:
• Oil production rate
• Water production rate
• Gas production rate
• Liquid (oil + water) production rate
• 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 timestep 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

217
productivity indices to apportion group targets among individual wells. The item 21 of OPTIONFS 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:
• 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.
• As above, except that all connections below the worst-offending one in the well will also be closed.
• The worst-offending wells will be closed successively until the rate limit is honored.
• 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. 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.

218
30
The wellbore friction option
The wellbore friction option models the effects of pressure loss due to friction in the well tubing along the
x ECLIPSE 100 perforated length, and between the perforations and the bottom hole reference point of the well. The facility
ECLIPSE 300 is primarily intended for use with horizontal wells, in which frictional pressure losses may be significant
x FRONTSIM over the horizontal section of the wellbore 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
wellbore 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.
Calculating the frictional pressure loss

The frictional pressure drop over a length L of tubing is
L
δP f = 2f ⋅ ⋅ρ ⋅v2 Eq. 30.1
D
where
f is the Fanning friction factor
D is the tubing inner diameter
ρ is the fluid density
v is the fluid velocity

219
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
Cf ⋅ f ⋅ L ⋅ ρ ⋅ Q 2
δP f = Eq. 30.2
D5
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)
The Fanning friction factor depends upon the Reynolds number, Re. For laminar flow (Re < 2000),
16
f = Eq. 30.3
Re
For Re > 4000 we use Haaland’s formula ([Ref. 23]),
1 10/9
f
= - 3.6 log10 ( 6.9 +
e
Re ( 3.7D ) )
Eq. 30.4
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. 41], 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
ρvD
Re = Eq. 30.5
μ
where
μ is the viscosity of the fluid.
Converting v to the volumetric flow rate Q and including the unit conversion factors, this becomes
Cr ρQ
Re = Eq. 30.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)

220
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.

221
31
Units
The unit conventions

x ECLIPSE 100
There are two unit conventions currently used:
x ECLIPSE 300 • METRIC units
x FRONTSIM
• FIELD units
The units for each data quantity are:
Quantity Metric Field

Length, depth, radius m ft
Time day day
Density kg/m3 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
Reservoir volume rate rm3/day RB/day
Formation volume factor (liquid) rm3/sm3 RB/stb
Units
222

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
Table 31.1: Table of the units used for two conventions
Constants
The following table gives the values of some principal constants 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
Table 31.2: Constants used in the two unit conventions
Standard conditions are taken as one atmosphere and 60 °F.
Conversion factors
The following table gives some useful conversion factors between the unit systems.

Length 1m =3.28084 ft
0.3048 m =1 ft
Volume 1 m3 =35.31466 ft3
0.02831685 m3 =1 ft3
Mass 1 kg = 2.204623 lb
0.45359237 kg =1 lb
Density 1 kg/m3 =0.06242797 lb/ft3
16.01846 kg/m3 =1 lb/ft3

Pressure 1 bar =14.50377 psi
0.06894757 bar =1 psi
Units
223

Gas-liquid ratio 1 m3/m3 = 5.614583 x 10 -3 mcf/bbl
178.1076 m3/m3 =1 mcf/bbl

Temperatures T °K = (T / 1.8) °R
Table 31.3: Some useful conversion factors
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 equation 31.1, we can calculate the following:

When P = 14.7 psia and T = 519.67 °R,
the volume occupied by one mole of gas is:
V molar = 379.39445 ft3 Eq. 31.2
the number of moles in unit volume is:

n moles = 0.00263578 mol Eq. 31.3
When P = 1.013 Bar and T = 288.15K,

the volume occupied by one mole of gas is:
V molar = 23.650203 × 10 - 6m3 Eq. 31.4
the number of moles in unit volume is:

n moles = 0.04228293 mol Eq. 31.5
Units
224
A
FrontSim development history
This appendix contains an extensive, detailed record of the developments to FrontSim.
Developments for 2016.1 and 2016.2

New Facilities
Reporting
• Summary Files: The SMSPEC file has been extended to contain a new INTEHEAD record (specified
in the File Formats Reference Manual). This record encodes the simulator and units convention used
in the simulation. To revert to the pre-2016.1 SMSPEC file structure, set item 75 of the OPTIONFS
keyword to 1.
Behavioral Changes
• MULTREGT is now supported in the GRID and EDIT sections. Item #6 is added (as ECLIPSE) to
support choice of region array: MULTNUM (M) or FLUXNUM (F) .
• The restriction on multiple equilibration regions when using GEOFLOFS is removed
• The MultiCore license model is changed to four threads included in the FrontSim Black Oil license
followed by one MultiCore license for each additional four threads.
• Summary report of aquifer rates The summary outputs of the analytical aquifer rates and totals in the
case of backflow from the reservoir to the aquifer have been changed in FrontSim 2015.2 to be
compatible with ECLIPSE. To be consistent with the ECLIPSE simulators FrontSim now only
account for the water flow when calculating a potential backflow to the analytical aquifer. Previously,
FrontSim used the total flow (all phases) at reservoir condition multiplied by the water volume factor
for this purpose. This change mainly results in different values for the summary vectors FAQR/
AAQR/FAQT/AAQT. This change has no effect when flow is strictly from the aquifer to the
reservoir. An option switch has been added in OPTIONFS (item 25) for backward compatibility.
• For the IOR scale-up option (9–tracer model) the solvent supply available for re-injection previously
did not account for the returned trapped solvent (tracer number 8). A backward compatibility switch
has been added to install previous behavior. See OPTIONFS switch 47.
Appendix A FrontSim development history

225
Altered Keywords
The following keywords have been changed:
• RPTRST — mnemonic FLOWTOT is redundant and thereby removed.

New Facilities
Geoscreening
A new item in the GEOFLOFS keyword allows you to run FrontSim in Geoscreening mode. Geoscreening
is a Petrel plug-in for use in subsurface uncertainty analysis workflows. See the Geoscreening User Guide
for further information (included with the plug-in).
Large Models
By introducing a new version of the Pressure Solver, FrontSim can run larger models than with previous
versions. FrontSim can now handle models with more than 250 million active cells without terminating
assuming that the required amount of free RAM is available for the process.
Behavioral Changes
For time-of-flight (TOF) reports:
• XXXX _ TOF. TXT
The number of bins (rows) for a time-of-flight data report (_ TOF. TXT) is increased to 100. This
value can be modified by using the RPTFSGEO keyword. Also, the binning has changed to hold equal
amount of pore volume for each bin instead of the equal amount of accumulated 1/TOF in previous
versions..
• Report in XXXX. PRT
The TOF report that was included by default for GEOFLOFS runs is now disabled. You can enable it
by setting OPTIONFS(56) to a value larger than zero.
• The summary outputs of the analytical aquifer rates and totals in the case of backflow from the
reservoir to the aquifer have been changed in FrontSim 2015.2 to be compatible with ECLIPSE. To be
consistent with the ECLIPSE simulators FrontSim now only account for the water flow when
calculating a potential backflow to the analytical aquifer. Previously, FrontSim used the total flow (all
phases) at reservoir condition multiplied by the water volume factor for this purpose. This change
mainly results in different values for the summary vectors FAQR/AAQR/FAQT/AAQT. This change
has no effect when flow is strictly from the aquifer to the reservoir. An option switch has been added
in OPTIONFS (item 25) for backward compatibility.

226
New Keywords
Schedule section
The new optional keyword FBHPDEF provides a default bottom hole pressure (BHP) target or limit to be
used where none is specified for a well. The keyword has two values, one for injection wells and one for
production wells.
Altered Keywords
• RPTRST — mnemonic FLOWTOT is redundant and thereby removed.

New Facilities
Performance Of Linear Pressure Solver
A new faster GPU algebraic multi-grid solver utilizing single/multiple graphics cards is available for
solving the pressure equation. The FSSOLVE keyword is used to enable this option. This solver is
recommended for bigger models (in the range of 0.5 to 3-4 million active cells – if more graphics cards are
supplied this upper range value could be extended accordingly). This linear solver can only utilize GPUs
with a high computing capability.
Skipping input keywords

A keyword skipping mechanism for FrontSim is supported in the same way as for ECLIPSE 100 and
ECLIPSE 300 using the keywords SKIP, SKIPFS and ENDSKIP. This will make it possible to ignore a
set of subsequent keywords starting with SKIP or SKIPFS until the ENDSKIP keyword is detected.

New facilities
Grid section — Saturation functions
• JFUNCR activates the Leverett J-Function option to scale capillary pressure according to rock porosity
and permeability on a per saturation region basis.
Summary section — Pattern-based solvent reports

A new set of SUMMARY output keywords for pattern-based solvent efficiency has been added. See
"SUMMARY Section" for information on the new keywords.

227
Schedule section — Pattern-based solvent allocation functionality

New functionality has been added to allocate solvent among a set of injectors defined by the user. This
functionality is managed by the new keyword WCONPATS. As well as the keyword description, there is
further information in "Solvent Pattern Flood Management - Solvent allocation" in the "FrontSim Technical
Description". Also a number of pattern-based summary vectors are available to support the solvent
Behavioral changes
Initialization — PVT data
The initialization of Rs/Pbub/Rv/Pdew in black-oil mode was slightly changed in FrontSim 2013.1.
Previously, for some cases, the initialization of for instance Rs for undersaturated oil, was not consistently
honored by the simulator. FrontSim should now consistently honor the input. For backward compatibility
parameter number 22 in the OPTIONFS keyword will revert back to pre-2013.1 behavior.
Summary reports
• For GEOFLOFS simulations, well reports (W***) are only generated by default for Type 2 runs.
• To be consistent with ECLIPSE the gas rates and totals now include the solvent.
New keywords
RUNSPEC section
The following keywords have been added:
Keyword Description
NOINSPEC Disables the initial index file output.
NORSSPEC Disables the restart index file output.
Table 32.1: New RUNSPEC keywords
GRID section
Keyword Description
JFUNCR Activates the Leverett J-function option per saturation table
Table 32.2: New GRID keywords
SOLUTION section

228
Keyword Description
SSOL Initial solvent saturations
Table 32.3: New SOLUTION keywords
SUMMARY section
The following keywords have been added:.
Keyword Description
WPNIP/CPNIPL Pattern in-place solvent volume
WPNPR/CPNPRL Pattern solvent production rate
WPNPT/CPNPTL Pattern solvent production total
*MISCF (*= F,WP,CP..L) Fraction of oil under miscible conditions (Solvent model only)
*MOIPS (*= F,WP,CP..L) Volume of oil that can be released by miscibility (Solvent)
*MOPOTS (*= Fraction of oil volume that can be released by miscibility (Solvent)
F,WP,CP..L)
*MOEFFS (*= Fraction of original MOPOT that has been released by miscibility
F,WP,CP..L) (Solvent)
*MVIEFFS (*= Solvent Injection Efficiency. Ratio of released oil due to miscibility
F,WP,CP..L) and injected/produced volume.
Table 32.4: New SUMMARY keywords
SCHEDULE section
Keyword Description
WCONPATS Solvent Injection Rate Allocation
Table 32.5: New SCHEDULE keywords
Altered keywords
Keyword Description
OPTIONFS Added a backward compatibility switch (parameter 22) for black-oil initialization.
OPTIONFS Removed item 2 and 3.
Table 32.6: Altered keywords

229

New facilities
Points data reports
The new keyword RPTFSGEO is added to control screening and ranking output of well points data to
FSCAT files and TOF data to _TOF.TXT files. These file are automatically generated (using default
values) when the keyword GEOFLOFS is used. If GEOFLOFS is not used, RPTFSGEO could be used to
generate these reports. The FSCAT files is extended to include discounted oil/water production and option
to include reports for inactive wells.
Water Flood Management

Using RATE as target control for PFM Injectors
RATE should now work as a target control type in the same way as RESV when running pattern
Flood Management.
Solvent model
The three-phase black-oil model in FrontSim has been extended with a solvent model. The
model is based on the one implemented in the ECLIPSE 100 Solvent model. The FrontSim
Technical Description has been extended with a new chapter on the details of the solvent model
and the keywords used.
Tracers
The three-phase black-oil model in FrontSim has been extended to include passive tracers. Prior
to 2012.1 tracers were only available for the two-phase front-tracking saturation solver.
Screening of geological models

A type 5 has been added to the GEOFLOFS keyword for flows from the top boundary to the bottom
boundary for the upscaling validation workflow.
Parallel linear solver

A parallel (multi-threaded) Algebraic MultiGrid Solver is included to speed up the pressure solve. This
solver is only used for datasets with compressible PVT data.

Behavioral changes in 2011.2
Reporting
In the 2011.2 release and beyond, FGIP / RGIP (in a 2 phase oil -water run) are reported as non-zero
values if RSCONSTT is set to a non-zero value.

230
Pattern Flood Management

In the 2011.2 release and beyond, the simulation results could potentially be altered if WCONINJE is set up
to use RATE control. This is due to resolving an issue with surface injection control when using PFM.
Altered keywords in 2011.2

Keyword Description
WLIST In the 2011.2 release and beyond, a well can be a member of multiple instances of a
well list. However, when using WCONPAT, we can have a well in multiple instances of
the WLIST, but only one instance of the list should be used in WCONPAT to avoid
having the same well in different WCONPAT definitions.
GEOFLOFS/ In the 2011.2 release and beyond, only the main points data report is generated for a
ZONEMAP GEOFLOFS Type 2 run (same as Type 1).
New facilities in 2011.1

New reports
The new mnemonic PAVPRESS in the RPTALLOC keyword supports the reporting of the pattern average
pressure (PAPressure) in the ALN files.

An option to calculate the injection capacity as a voidage replacement fraction has been implemented for
the WCONPAT keyword to be used with the RECOV and INJEFF options.
Grids and Models — Generic Simulation Grid (GSG)

The PETGRID keyword is extended to import global grid geometry (both linear and curved/truncated
pillars) and local grid geometry and properties from a Generic Simulation Grid (GSG) file. This file format
has to be imported from Petrel and the PETOPTS keyword (in RUNSPEC) supports this workflow.
The GSG file format can also include transmissibilities and pore volumes calculated and exported from
Petrel. FrontSim can initialize the transmissibilities and pore volumes directly, including non-neighbor
connections as well as LGR to global grid connections (see the PETOPTS keyword for more information).
Initializing transmissibilities directly from the GSG file offers more flexibility than the standard
initialization in FrontSim for the combination of LGRs and faulted connections.

Initialization – Pore volume multipliers in the EDIT section
To be compatible with ECLIPSE behavior, the pore volumes can now be modified in the EDIT section
even if the PORV keyword has not been explicitly used in the EDIT section.

231
Reporting
• Data for saturation function and saturation function endpoints for the .INIT file have been updated to
be compatible with ECLIPSE. This supports new functionality in Petrel RE.
• Generation of .GRID files is abandoned when PETGRID is used to import a GSG file. This is done to
be compatible with ECLIPSE 100/300. If the GRIDFILE keyword is specified to generate a .GRID
file, a warning is issued.
• The generation of .FSCAT files has been slow in previous releases (especially when the number of
zones/layers is high). The algorithm has been redesigned to be more efficient.
Well Management – Completions

If completions are only partly generated (using COMPLUMP) for a well, FrontSim will auto-generate a
separate completion and assign it to those without any completion id.
New keywords in 2011.1

RUNSPEC section
Keyword Description
PETOPT Options for Petrel runs
GRID section
Keyword Description
ADDREG Adds a constant to the specified array in either a flux region or MULTNUM region
COPYREG Copy by either FLUXNUM region or MULTNUM region
EQUALREG Sets an array to a constant value in a flux region or MULTNUM
MAXVALUE Apply a maximum limit to an array in the current box
MINVALUE Apply a minimum limit to an array in the current box
MULTIREG Multiplies an array by a constant in a given flux region or MULTNUM region
Table 32.9: New GRID keywords
EDIT section
Keyword Description
COPYREG Copy by either FLUXNUM region or MULTNUM region

232
Keyword Description
MAXVALUE Apply a maximum limit to an array in the current box
MINVALUE Apply a minimum limit to an array in the current box
Table 32.10: New EDIT keywords
PROPS section
Keyword Description
COPYREG Copies by either FLUXNUM region or MULTNUM region
MAXVALUE Applies a maximum limit to an array in the current box
MINVALUE Applies a minimum limit to an array in the current box
Table 32.11: New PROPS keywords
REGIONS section
Keyword Description
Table 32.12: New REGIONS keywords
SOLUTION section
Keyword Description
Table 32.13: New SOLUTION keywords

233
SUMMARY Section
Keyword Description
PERFORM Outputs a set of performance data vectors from the run to the summary files
Table 32.14: New SUMMARY keywords

Keyword Description
MULTPV The behavior of this keyword when used in the EDIT section has been changed to be
compatible with ECLIPSE 100. Backward compatibility is available through item 9 in
keyword OPTIONFS .
PETGRID This keyword can now also be used to import Generic Simulation Grids (GSG)
RPTALLOC A new mnemonic (PAVPRESS) is added to support reporting of pattern average pressure
(PAPressure)
WCONPAT The voidage fraction parameter can now be used to activate calculation of the injection
capacity for the RECOV and INJEFF options, based on the voidage replacement fraction.
OPTIONFS MULTPV backward compatibility (see above)

Behavioral changes for 2010.2
FrontSim 2010.2 is a maintenance release and focuses on corrections and quality improvements.
Grid Initialization
To be compatible with ECLIPSE, the TRANZ keyword has been changed so that it does not affect any
pinched grid connection in the Z-direction.
Pattern Flood Management (PFM)

The algorithm for honoring individual production limits (activated by using OPTIONFS(57) = 2) has been
improved in this release. However, for some runs, it has shown some differences in allocation compared
with previous releases. This algorithm is off by default.

234
New facilities in 2010.1

Screening Geologic Models
• The new keyword DEFWPAT is used to do the automatic generation of source/sink well patterns
(’pseudo’ vertical wells) for a GEOFLOFS Type 1 workflow (uncertainty quantification study).
• The GEOFLOFS output has been extended to be reported by zone (FSCAT files). The zones are
defined using the new keyword ZONEMAP (only valid for GEOFLOFS Type 1 and 2).

• FrontSim now honors individual production limits when running Pattern Field Management (PFM).
Even if the production targets are controlled by the injection efficiency (if they are “connected” to the
pattern injectors) a new algorithm will ensure that individual production limits are not violated.
OPTIONFS (57) = 2 will activate this option (production limits are off by default).
Grids and Models

• The transmissibility multipliers (keywords MULTX, MULTX-, MULTY, MULTY-, MULTZ, MULTZ-)
can now be used in the SCHEDULE section to change the transmissibility at specific time during
simulation.

Screening Geologic Models
• For GEOFLOFS type 3 and 4 simulations, the pressure boundary condition can now be consistently
applied to irregular boundaries. The pressure boundary condition is set for the first inactive cell at the
specified boundary. A backward compatibility switch is available in OPTIONFS (parameter 70).

• Production limits are honored.
• Injection RATE limits are honored.
• For the VREP option in WCONPAT, the calculation of the injection fluid rate has been slightly changed
to account for the difference in pressure at the producer side and the injector side of the connecting
streamline bundles. A backward compatibility switch is available in OPTIONFS (parameter 72).
Well Management
• NTG can be used when calculating KH for well blocks (only used for Z-penetrated well blocks).
• There is a new item 12 in the GCONINJE keyword.
• For the VREP option in GCONINJE and re-injection option in WCONINJ, the calculation of the
injection fluid rate has been slightly changed to account for the difference in pressure in the producers
and injectors. The new implementation is compatible with ECLIPSE (only field level is available in
the 2010.1 release). A backward compatibility switch is available in OPTIONFS (parameter 72).

235
• The value of the OPTIONFS(65) switch has been swapped. OPTIONFS(65)=1 in pre-2010 versions is
equal to OPTIONFS(65)=0 in 2010.1 and vice versa.
Performance developments in 2010.1

Multi Core Parallel Option
The process of setting up the equation system (assembler) is done in parallel using multi-threading.

REGIONS section
The following keywords have been added.
Keyword Description
ZONEMAP Generate zone maps for point data reports
Table 32.16: New REGIONS keywords
SCHEDULE section
The following vectors have been added:
Vector Description
DEFWPAT Auto-generation of source/sink well patterns
MULTX Transmissibility multipliers in the X-direction
MULTX- Transmissibility multipliers in the negative X-direction
MULTY Transmissibility multipliers in the Y-direction
MULTY- Transmissibility multipliers in the negative Y-direction
MULTZ Transmissibility multipliers in the Z-direction
MULTZ- Transmissibility multipliers in the negative Z-direction
Table 32.17: New SCHEDULE keywords

Keyword Description
OPTIONFS Activate special program options

236

Developments and updates for 2009.2
FrontSim 2009.2 was a maintenance release and focused on corrections and quality improvements. It
improved the usability of the geological screening and the pattern flood management facilities and made
improvements to well models, aquifers and reporting.
Behavioral changes
Performance enhancements
• FrontSim 2009.2 has an improved run time CPU performance in the three-phase explicit saturation
solver on Windows platforms, and this performance enhancement is particularly noticeable on the
Windows Vista 64 platform.
• The performance of FrontSim’s two-phase front tracker saturation solver has also been improved on
the Windows Vista 64 platform, in terms of CPU performance time. The front tracker solver is, in
general, five to six times faster than the explicit saturation solver.
• FrontSim 2009.2 should support a 10 to 12 million active cell two-phase problem using a standard
configuration Windows Vista 64 PC with 16GB or less core memory. It can also support a three-phase
Black Oil version of the same model on such a machine.
• You are encouraged to run multiple realizations using the GEOFLOFS facility in an uncertainty
workflow.
Pattern water flood management

• Pattern water flood management (PFM) messaging has been improved and simplified. The PFM
summary table is output only once until it is updated during the simulation. Excessive PFM messages
caused by pattern wells changing status or closing have been removed.
• A formatting issue with PFM rate schedule output file . PFM_SCHED has been fixed. FrontSim now
supports default BHP values in the PFM case from where this file is derived.
Geologic Ranking
• GEOFLOFS has default output options that include GRID and INIT files. Default reporting no
longer includes restart and streamline files. You need to request these files using RPTRST and
RPTSLN.
• Both RPTRST and RPTSLN are accepted (all mnemonics) in a GEOFLOFS run. Streamline allocation
data is available in a GEOFLOFS screening run.
Saturation Solver
• FrontSim supports streamline density output higher than 1.0 using the TUNEFSSA keyword.
• FrontSim has improved support of streamline outputs for visualization and bundle flow pattern
analysis through RPTSLN.
• Due to support of the multi-threading solvers, FrontSim no longer supports automatic streamline
density computation and SAVE streamlines during a simulation. These functions were previously

237
supported in items 2 and 6 of the TUNEFSSA keyword. The absence of the SAVE streamline function
can lead to higher CPU time, which can usually be made up using the multi-threading feature.
Input
• Default value interpolation represented by 1* is supported by both families of saturation table. The
first family of keywords are SWFN, SGFN, SOF2 and SOF3, and the second family of keywords are
SWOF and SGOF.
Well model
• The usability of the well model has been improved. The well model will now close a well if the
estimated rates could cause the pressure solver to fail.
• CECON with CWCT workover behavior is ECLIPSE compatible. It acts on average connection water
cuts instead of the maximum water cut amongst the qualified connections.
• GCONPROD now correctly supports maximum rate limits in item 7, in addition to the rate control
constraints in item 2.
Aquifer
• A known problem with numerical aquifers producing unreasonable aquifer rates in the presence of
gravity has been fixed.
Dual Porosity
• Block centered grids should work with dual porosity using the DXV/DYZ and DZV keywords.
Restarts
• A restart run will give an error and exit when a well has no rate control data at the restart time. This is
to ensure all wells have valid controls which are either inherited or updated at restart time.
Reporting
• An issue related to FLPR/FLPT reporting has been corrected.
• An issue with incorrect units for history fluid rates being given on SUMMARY mnemonics FOPTH,
FWPTH and FGPTH has been fixed.

PROPS section
The following new keywords have been added:.
Keyword Description
RSCONST Used to declare that dead oil contains a constant and uniform concentration of dissolved gas.
RVCONST Used to declare that dry gas contains a constant and uniform concentration of vaporized oil.


238
Keyword Description
GEOFLOFS Default reporting no longer includes restart and streamline files. You need to
request these files using RPTRST and RPTSLN.
Both RPTRST and RPTSLN are accepted (all mnemonics) in a GEOFLOFS run.
Streamline allocation data is available in a GEOFLOFS screening run.
TUNEFSSA Supports streamline densities higher than 1.0 for the Saturation Solver.
No longer supports automatic streamline computation and the SAVE streamlines
function during run time.
CECON This keyword with CWCT workover behavior is now ECLIPSE compatible. It now
acts on average connection water cuts instead of the maximum water cut amongst
the qualified connections.
SWFN, SGFN, Default value interpolation represented by 1* is supported by both families of
SOF2, SOF3, saturation table.
SWOF and SGOF.
Functionality changes in 2009.1

Screening geologic models
• Time of breakthrough (water cut above 0.9) is included as a well property in the fscat file. To generate
this file the keyword GEOFLOFS is needed in the RUNSPEC section.
Water flood management

• Zone Rate Control. When completions have been defined the Pattern Flood Management algorithm
will calculate injection rates for the completions. In previous release, these rates were accumulated for
the well and then applied. In FrontSim 2009.1 these zone based rates can be honored directly for the
completions. Through a new parameter in the WCONPAT keyword you can decide whether to use these
zone based rates or the accumulated rate for the well.
• An output file can be generated that includes SCHEDULE keywords with the targets that the PFM
algorithm calculated from the time that the WCONPAT keyword was activated to the end of the
simulation. This file can later be included in a prediction using either FrontSim or ECLIPSE
simulators.
Dual Porosity
• Dual Porosity regions. FrontSim 2009.1 now honors the DPNUM keyword. You can, in a Dual Porosity
model, specify regions within the reservoir to be treated as single porosity only.
New Reports
• PORV (at reservoir conditions) is included in the restart file if the RPORV mnemonic is specified on
the RPTRST keyword
• The keyword RPTALLOC has been slightly changed, new mnemonics have been introduced and others
retired.

239
• When Pattern Flood Management is activated FrontSim will by default export all PFM rates to the
PFM_SCHED file using WCONPROD/ WCONINJE keywords. DATES keywords are also included so
this file could be automatically be included into ECLIPSE (or FrontSim). By default all wells are
controlled by RESV, this can be changed by setting item 66 in the OPTIONFS keyword.

• Injection Limits for Pattern Flood Management injectors are supported in the same way as for other
injectors. To revert to old behavior, set item 57 in the OPTIONFS keyword.
• Multi Zone Waterflooding is now turned off by default. To turn it on (or to revert to pre-2009.1
behavior) set item 9 in the WCONPAT keyword to ON. Multi Zone will only affect models where the
injectors have completions defined.
Well management
• In some cases where the surface rate targets are very sensitive to the saturation solution in previous
step the solution might differ slightly from previous releases.
Performance
Multi core parallel Option
In FrontSim 2009.1 the MultiCore shared memory has been further developed and the key developments
are:
• The Streamline Tracing algorithm is parallel
• A parallel Front Tracker for two phase problems
• All parallel features are available on Linux (not Windows PC) only.
See "Multicore Parallel Option" for more information about this option.

GRID section
The following new keywords have been added:.
Keyword Description
DPNUM Identify extent of dual porosity region
SUMMARY section
The following new vectors have been added:.

240
Vector Description
F/G/WOPTH Oil Production Total History
F/G/WGPTH Gas Production Total History
F/G/WWPTH Water Production Total History
F/G/WLPR Liquid Production Rate
F/G/WLPRH Liquid Production Rate History
F/G/WLPT Liquid Production Total
F/G/WLPTH Liquid Production Total History
WMCTL Mode of control for well
FMF*R Field Matrix to Fracture flow rate (* V = total reservoir, W/O/G at surface)
FMF*T Field Matrix to Fracture total (* V = total reservoir, W/O/G at surface)
WPMF*R Pattern Matrix to Fracture flow rate (* V = total reservoir, W/O/G at surface)
WPMF*T Pattern Matrix to Fracture total (* V = total reservoir, W/O/G at surface)
CPMF*RL Pattern Matrix to Fracture flow rate (* V = total reservoir, W/O/G at surface)
CPMF*TL Pattern Matrix to Fracture total (* V = total reservoir, W/O/G at surface)
Table 32.22: Summary Vectors

Keyword Description
WCONPAT Added item 9 for turning on Multi Zone
RPTRST Added mnemonic RPORV
Developments in 2008.1 and 2008.2

Developments and updates for 2008.2
FrontSim 2008.2 was a maintenance release and focused on corrections and quality improvements. In
particular it improved the usability for geological screening workflows through the GEOFLOFS
implementation and continued to improve the pattern flood management workflow facilities.
New features in 2008.2

• GEOFLOFS type 3 run supports OPF as a compatible grid format.
• GEOFLOFS generates GRID and INIT files by default.

241

Further enhancements have been done for the FrontSim Pattern Flood Management (PFM) module. PFM
currently assists in optimizing the performance of waterfloods.
• Pattern Flood Management (PFM) injector honors RATE control mode.
• PFM.ALLOC reporting for OFM supports reservoir condition rates by default with InjEff column
removed. Surface condition rates are output by setting OPTIONFS (60) for backward compatibility.
• PFM.ALLOC reporting for OFM outputs the allocation fractions in a different way. Namely injection
fractions are output for producer based patterns, and production patterns for injector based patterns. In
this way, the pattern production is computed by multiplying the production fractions with well (either
historical or observed rates in an OFM project) production rates.
• PFM.ALLOC reporting by completions is enabled using the CMPL mnemonics, and selective outputs
of injector and producers based data can be output by WPBASIS mnemonics
Solver
FrontSim is able to run a simulation without storing streamlines on a single core run, with an exception on
a multi-core run when the SaveStreamlines mnemonic has to be set to YES in the TUNEFSSA keyword.
Well modeling facilities

FrontSim supports THP calculations if this is specified in the WCONHIST keyword.
Performance enhancements
Memory consumption is decreased due to the following efforts:
• Reduction of memory usage in streamline module.
• Reduction of memory usage in well model.
Documentation improvements
• Multiple keywords TRANX/Y/Z, MULTX/MULTZ-, PERMX/PERMY/PERMZPERMXY/PERMZZ, KRO /
KRORW/KRORG are listed separately for clarification see the "Keywords" section in the "FrontSim
User Guide" for the new keyword entries.
• The Pattern Flood Management documentation is improved

• PFM.ALLOC rates reporting are consistent at the completion, the well-pair and the pattern levels. This
change can slightly affect the pattern flood management results due to changes in injection efficiency.
• PFM supports minimum bundle oil rate constraint in the CECONINJ keyword
• PFM.ALLOC reporting includes the start well-name to 'P-edge', previously the start well-name is only
included to 'I-edge'.

242
Initialization
• The JFUNC keyword works with models with inactive cells. Prior to 2008.2, JFUNC only worked on
models that had no inactive cells.
• The SWATINIT saturation initialization is constrained by the SWL. This is inconsistent with the
ECLIPSE behavior.
• The improved PVTO data consistency check aims to reduce possible run time problems.
• The MULTPV and PORV keywords are expected to work. Prior to the 2008.2 these keywords could be
nonfunctional.
Restarts
• FrontSim will restart a live oil model by default using RPTRST keyword. Previously mnemonic
RESTART had to be specified in order to restart such models.
Reporting
• The number of reported contacts to the PRT file correctly reflects changes made by transmissibility
multipliers.
• The LINES mnemonics of the RPTSLN keyword works instead of defaulting to 300 lines. This is how
a user specifies the output of number of streamlines in each timestep.
• RPTLINFS works in a mode compatible with the ECLIPSE RPTONLY keyword. The RPTLINFS
keyword should normally be used with GEOFLOFS type runs, or runs that can be made with one
single large timestep. See the GEOFLOFS keyword for information on this type of run. The RPTLINF
keyword does not necessarily support non-GEOFLOFS type runs by default.
• Various errors have been fixed for historical rates reporting in RESTART runs.
• It is possible to convert OPF file format to GRID file format by performing a FrontSim NOSIM run.
• GEOFLOFS type 3 and 4 runs no longer output FSCAT reporting file.
Well Model
• Improved GCONPROD group control on individual well rate limit and well water cut limit with
appropriate actions.
• WEFAC works at individual well level.
• WECON works on water pattern flood or PFM runs.

PROPS section
The following new keywords have been added:
Keyword Description
ENKRVD Relative permeability end point versus depth tables

243

• OPTIONFS(60) provides backward compatibility to support .OFM style ALLOC output in the surface
condition.
New features in 2008.1

• A new keyword GEOFLOFS has been introduced to make it easy to setup and run incompressible
simulations on geologic models.
• Standard reports useful for analyzing geologic models are produced by default. The default reports
include additional streamline-based information provided by way of new summary vectors, a points
data file containing dynamic connectivity information that can be loaded directly into Petrel, and
tabular time-of-flight data in the print file.
• When run on shared memory multicore Microsoft Windows platform hardware all cores will be used
to improve computational efficiency. This facility for use of unlimited cores is only available with
GEOFLOFS, all other simulations will require parallel multicore licenses to execute on multicore
machines.

Various important enhancements have been done for the FrontSim Pattern Flood Management (PFM)
module. PFM currently assists in optimizing the performance of waterfloods.
• A new keyword WCONPEND has been introduced to provide an option to switch off PFM and return to
normal well management as required during a run.
• It is now possible to assign separately an injection capacity for groups of injectors taking part in PFM.
The injection capacity can be assigned and changed during the course of a run. The WCONPAT
keyword has been modified to accept injection capacity as input.
• PFM is applied on group of injectors defined using well lists. PFM now spontaneously reacts to well
list modifications caused by adding or removing injectors.
• PFM balances production-injection pattern in an iterative manner at the Newton level. Previously, this
was done across separate timesteps.
• The ability to restart and apply PFM on ECLIPSE history matched models with minor differences in
grid properties has been improved.
• An important aspect of waterflood management is reservoir surveillance and correction using history
matched reservoir models. A new keyword RPTALLOC has been introduced to enable the use of
streamline modeling based production allocation information to be transmitted to OFM (Oil Field
Manager). This keyword reports production/injection allocation and volumetric information in a
spreadsheet format for easy linking as an external table to the OFM database. The model based data
can be used to plot injection efficiency or other useful surveillance plots for comparing with observed
production data and detecting exception behavior.

• A new keyword CECONINJ has been introduced to enable injection well workover. The keyword
triggers shut-in of injection well completions based on completion injection efficiency.

244
• The ECLIPSE keyword WTES has been implemented. The keyword controls the testing and opening
of shut-in wells based on various criteria. The FrontSim version of the keyword includes a subset of
the ECLIPSE functionality.
• Well model convergence under regular group or PFM control has been improved
New reports
• RPTALLOC - this keyword controls the formatted output of allocation/bundle information to the .ALN
-file for better connectivity to OFM or MS EXCEL.
• GEOFLOFS - this keyword uses the Petrel format for storing points data (.fscat files). Point data is
created at the grid surface location for every well. This can be used to produce maps in Petrel. For
multiple realizations mean and variance maps to represent uncertainty can be created.

• WCONPAT accepts only well list names. This is the only way to specify groups of injectors for PFM.
• Item 12 of the WCONPAT keyword now accepts a value for injection capacity for a group of wells
defined using a well list name. Previously, this item controlled the time interval or frequency at which
PFM allocation computations are to be done. PFM allocations are now done at every timestep till the
end of the simulation or WCONPEND is used to switch it off.
• If wells do not converge during regular well management or PFM an extra 3 newtons iteration will be
applied by default to update the well rate targets. This is in addition to the default number of iterations
or that specified in the TUNEFSPR keyword.
Restarts
FrontSim will restart from ECLIPSE models with different number of active/inactive cells whenever
feasible. A report is provided in the print file on differences detected and actions taken. You may wish to
continue with the restart simulation or refresh the grid. Previously FrontSim stopped with an error message.
Solver
• Some changes have been done in the 1D EXPL saturation solver including the gravity segregation
solver. The change will affect cells where saturation is close to critical saturation and decreasing. The
accuracy in this situation has been improved. In Dual Porosity models this change have reduced the
need to tune the local timestepping in the 1d saturation solver (TUNEFS1D - parameter 4 and 5) to
avoid mass balance errors. A backward compatibility switch is available in OPTIONFS parameter 59.
• In the case of the explicit 1Dsolver the default setting for TUNEFS1D parameter number 4 is now
consistently 0.1. In previous version this parameter was defaulted to 0.34 if the keyword TUNEFS1D
was not set by the user and 0.1 otherwise (keyword used but parameter number 4 defaulted).

RUNSPEC section

245
Keyword Description
GEOFLOFS Setup Simple Simulations for Flow Analysis
SUMMARY section
The following new vectors have been added:
Vector Description
FOE Field Oil Recovery
Table 32.26: Summary Vectors
• New Field, Region and Field, Group and Well tracer quantities.
• New Field, Region and Field, Group and Well temperature quantities.
The following summary vectors are produced by default when GEOFLOFS is used. Application outside
GEOFLOFS should be done with care.
Vector Description
WPDRAIN Fraction of oil drained by producer from its pattern.
WPFLOOD Fraction of oil swept by injector from its pattern
EOPR Edge oil production rate
EOPT Edge cumulative oil production.
EWCT Edge water cut.
EWIR Edge water injection rate
EWIT Edge total water injection.
Table 32.27: Summary Vectors for GEOFLOFS
SCHEDULE section
Keyword Description
WCONPEND Switch Off Injection Rate Optimization
CECONINJ Economic limits for injection well
RPTALLOC Controls on output to the .ALN file
WTEST Instructions for periodic testing of closed
Table 32.28: SCHEDULE keywords


246
Keyword Description
WCONPAT Item 1 only supports wells list names formed using WLIST.
Item 12 now reads injection capacity.
OPTIONFS Parameter 54, 59.
New developments for 2007.1 and 2007.2

Functionality
Pattern Flood Management
A separately licensed well management option is available. This option can be used to easily enhance water
flood simulations by automatically allocating injection and production to increase volumetric sweep
efficiency, improve utilization of injected water and reduce water re-cycling. The new keyword WCONPAT
is designed for this purpose.
See "Pattern Flood Management" for more information about this option.
Dual Porosity
.A dual porosity option for three phase, compressible and black oil fluids is now available in FrontSim as a
separately licensed option. The option uses the conventional matrix-fracture transfer function and supports
expansion and imbibition recovery processes. (Gravity drainage recovery from matrix blocks is not
currently supported). The option is available with the EXPL saturation solver only. The feature is ECLIPSE
compatible and supports the following keywords: DUALPORO, DPGRID, SIGMA, SIGMAV, NODPPM.
See "Dual Porosity" for more information about this option.

• WECONINJ has been implemented to honor economical limits for injectors
• CECON has been implemented to honor economical limits for producer well connections.
• WLIST can now be used with well target keyword as well as with WCONPAT. All operators NEW,
ADD, MOVE and DEL are implemented.
Aquifers
FrontSim will now connect aquifers to split cell faces if at least one part of the cell face is connected to an
inactive cell or the boundary.
Allocation information is available separately for each aquifer in the Allocation reports (see below).
End Point Scaling

FrontSim now supports the Leverett J-function to scale capillary pressure curves from rock properties for
initialization purposes. Currently the JFUNC keyword supports only oil-water capillary pressure curves.

247
Direct input of water saturation using SWATINIT is now available. In addition more general methods of
capillary pressure scaling using PCW and PPCWMAX are available.
Reports and Output

A number of enhancements have been made to the output available from FrontSim.
The RPTRST keyword now supports a set of mnemonics for output to the restart files. This will allow users
to exercise control over the size of these files. See the keyword description for more information.
INIT file
• To illustrate the aquifer connections FrontSim now outputs the AQUIFERA vector for analytical
aquifers and AQUIFERN for numerical aquifers.
• Output of PCW is available for capillary pressure endpoint scaling.
Summary reports
• A new set of summary vector output for use with the Pattern Flood Management option is available.
• When COMPLUMP (completions) is used there are pattern property summary vectors available for the
completions.
• Support for producing separate run summaries(.RSM) is provided through SEPARATE, RUNSUM and
EXCEL keywords.
• The TIMESTEP summary vector is now supported to report the size of timesteps.
Allocation reports
• Allocation bundle properties are now available on completion level. This requires the usage of the
COMPLUMP keyword. When COMPLUMP is used FrontSim will output completion bundles
information in the Allocation reports as a separate section. Aquifers are handled the same way as
completions and will appear in the same section in the Allocation reports.
• Pore volume weighted as well as hydrocarbon weighted pressures are available in the Allocation
reports and as summary vectors (WPPR and WPHCPR).
Behavioral changes
Saturation solver
• The discretization for the 1d finite volume solver (EXPL solver) has been improved to better track
large discontinuities in saturation. Extra points in the 1d grid are added to maintain the discontinuity
and reduce numerical dispersion.
• The EXPL solver is now available for two-phase models as well as for three-phase (TUNEFS1D). It is
the default solver for three-phase and the only solver that can handle Dual Porosity. The front-tracking
solver is not available for dual porosity models and the EXPL solver must be used for two-phase dual
porosity models.

248
Performance
Multicore parallel Option
Parallel execution in a shared memory environment is available as a separately licensed extension to
FrontSim. In FrontSim 2007.1, this is only available for Windows PC platforms and limited to use with the
EXPL saturation solver. The option is ideally suited for multicore workstation and desktop PC’s and laptop
computers providing extremely good performance to price benefits. The new keyword THREADFS controls
this option.
See "Multicore Parallel Option" for more information about this option.
New keywords
RUNSPEC section
DUALPORO Activates dual porosity option (licensed)
THREADFS Activate multicore parallel option (licensed)
PERFORM FrontSim performance tuning
GRID section
DPGRID Make matrix cell properties for fracture cell
JFUNC Activates the Leverett-J option
NODPPM No dual porosity multiplier
SIGMA Dual Porosity matrix-fracture coupling
SIGMAV Dual Porosity matrix-fracture coupling
PROPS section
PCW Sets the maximum Oil Water capillary pressure.
PPCWMAX Sets the maximum Oil Water capillary pressure that can result from the Leverett JFUNC
calculation.
SOLUTION section
SWATINIT Sets the capillary pressure scaling based on initial water saturation
SUMMARY section
TIMESTEP Summary vector for size of timesteps
EXCEL Summary output will be done in Excel format
RUNSUM Tabulated output of summary data at the end of the print file.
SEPARATE Summary output to separate RSM file.
COMPLUMP Completion level vectors for pattern flood management

249
SCHEDULE section
CECON keyword for economic limits for connections
WECONINJ keyword for economic limits for injector wells
WCONPAT keyword for Pattern Flood Management
Altered keywords
OPTIONFS
• Item 51. Controls output for the PFM option

250
B
Bibliography
1. Aavatsmark, I., Barkve, T., and Mannseth, T. “Control-Volume Discretization Methods for 3D
Quadrilateral Grids in Inhomogeneous, Anisotropic Reservoirs,” paper SPE 38000, Society of
Petroleum Engineers Journal (1998) 3, No. 2, 146-154; also presented at the SPE Reservoir
Simulation Symposium, Dallas, Texas, USA (June 1997).
2. Anthony, J. L. and Meggs, A. J. M. “An approach for the determination of economically optimum
injection and production rates in a Large Multi-Pattern Waterflood,” paper SPE 16957, presented at
the SPE Annual Technical Conference and Exhibition, Dallas, Texas, USA (27-30 September, 1987).
3. Aziz, K. and Settari, A. Petroleum Reservoir Simulation, London, UK, Applied Science Publishers
(1979) 398.
4. Bratvedt, F., Bratvedt, K., Buchholz, C.F., Holden, L., Holden, H., and Risebro, N.H. “A New Front-
Tracking Method for Reservoir Simulation,” paper SPE 19805, SPE Reservoir Engineering (1992) 7,
No. 1, 107-116.
5. Bratvedt, F., Bratvedt, K., Buchholz, C. F., Gimse, T., Holden, H, Holden, L., and Risebro, N. H.
“FRONTLINE and FRONTSIM. Two Full Scale, Two-Phase, Black Oil Reservoir Simulators Based
on Front Tracking,” Surveys on Mathematics for Industry (1993) 3, 185.
6. Bratvedt, F., Gimse, T., and Tegnander, C. “Streamline Computations for Porous Media Flow
Including Gravity,” Transport in Porous Media (1996) 25, 63.
7. Carter, R. D. and Tracy, G. W. “An Improved Method for Calculating Water Influx,” Transactions of
AIME (1960) 219, 215-417.
8. Chakravarty, A., Liu, D.B., and Scott Meddaugh, W. “Application of 3D Streamline Methodology in
the Saladin Reservoir and Other Studies,” paper SPE 63154, presented at the SPE Annual Technical
Conference and Exhibition, Dallas, Texas, USA (October 1-4 2000).
9. Chik, A. N., Elias, M. R., Selamat, S., Wakatake, M. T., White, J. P. and “Guntong Field:
Development and Management of a multiple-Reservoir Offshore Waterflood,” Journal of Petroleum
Technology, (1996) 48, No. 12, 1139-1143.
10. Coats, K. H. “Simulation of Gas Condensate Reservoir Performance,” paper SPE 10512, presented at
the Sixth SPE Symposium on Reservoir Simulation, New Orleans, Louisiana, USA (February 1-3
1982).
11. Crane, M., Bratvedt, F., Bratvedt, K., Childs, P., and Olufsen, R. “A Fully Compositional Streamline
Simulator,” paper SPE 63156, presented at the SPE Annual Technical Conference, Dallas, Texas,
USA (October 1-4 2000).
Appendix B Bibliography
251
12. Crowe, C. M. and Nishio, M “Convergence Promotion in the Simulation of Chemical Processes - The
General Dominant Eigenvalue Method,” American Institute of Chemical Engineering Journal (1975)
23, No. 3, 528-533.
13. Dafermos, C.M. “Polygonal Approximation of Solutions of the Initial Value Problem for a
Conservation Law,” Journal of Mathematical Analysis (1972) 38, 33-41.
14. Dennis, J. E. and Schnabel, R. B. “ Numerical Methods for Unconstrained Optimisation and
Nonlinear Equations,” Classics in Applied Mathematics (unabridged and corrected ed.) Society for
Industrial and Applied Mathematics (1996), first published by Prentice-Hall, Englewood Cliffs, New
Jersey, USA (1983).
15. Emanuel, A.S. and Milliken, W.J. “History Matching Finite Difference Models with 3D Streamlines,”
paper SPE 49000, presented at the SPE Annual Technical Conference and Exhibition, New Orleans,
Louisiana, USA (September 27-30, 1998).
16. Fetkovich, M. J. “A Simplified Approach to Water Influx Calculations - Finite Aquifer Systems,”
Journal of Petroleum Technology, (1971) 23, No. 7, 814-828.
17. Flanders, W.A. and Bates, G. R. “Optimizing Reservoir Surveillance by Using Streamlines and the
Microcomputer,” paper SPE 16482, presented at the Petroleum Industry Application of
Microcomputers, Lake Conroe, Texas, USA (23-26 June, 1987).
18. Ghori, S. G., Jilani, S. Z., Al-Huthali, A. H., Krinis, D. and Kumar, A. “Improving Injector
Efficiencies Using Streamline Simulation: A Case Study in a Giant Middle East Field,” paper SPE
105393, presented at the SPE Middle East Oil and Gas Show and Conference, Kingdom of Bahrain
(11-14 March, 2007).
19. Giordano, R.M., Redman, R,S., and Bratvedt, F. “A New Approach to Forecasting Miscible WAG
Performance at the Field Scale,” paper SPE 36712, SPE Reservoir Evaluation & Engineering (1998)
1, No. 3, 192-200. First presented at the SPE Annual Technical Conference and Exhibition, Denver,
Colorado, USA (October 6-9, 1996).
20. Grinestaff, G.H & Caffrey, D.J “Waterflood Management: A Case Study of the Northwest Fault Block
Area of Prudhoe Bay, Alaska, Using Streamline Simulation and Traditional Waterflood Analysis,”
paper SPE 63152, presented at the SPE Annual Technical Conference and Exhibition, Dallas, Texas,
USA (October 1-4, 2000).
21. Grinestaff, G.H. “Waterflood Pattern Allocations: Quantifying the Injector to Producer Relationship
with Streamline Simulation,” paper SPE 54616, presented at the SPE Western Regional Meeting,
Anchorage, Alaska, USA, (May 26-27, 1999).
22. Gunasekera, D., Childs, P., Cox, J., and Herring, J. “A Multi-Point Flux Discretization Scheme for
General Polyhedral Grids,” paper SPE 48855, presented at the International Oil & Gas Conference and
Exhibition, Beijing, China (November 2-6, 1998).
23. Haaland, S.E. “Simple and explicit formulas for the friction factor in turbulent pipe flow,”
Transactions of the ASME, Journal of Fluids Engineering (1983) 105, No. 1, 89-90.
24. Kazemi, H., Merrill JR., L. S., Porterfield, K. L., and Zeman, P. R. “Numerical Simulation of Water-
Oil Flow in Naturally Fractured Reservoirs,” paper SPE 5719, Society of Petroleum Engineers Journal
(1976) 16, No. 6, 317-326.
25. King, M. J. and Datta-Gupta, A. “Streamline simulation: A current perspective,” In Situ (1998) 22,
No. 1, 91-140, 1998.
26. Kozlova A., Bratvedt, F., Bradvedt, K., and Myasnikov, A. “A Three-Phase Compressible Dual-
Porosity Model for Streamline Simulation,” paper SPE 102549, presented at the SPE Annual
Technical Conference and Exhibition, San Antonio, Texas, USA (September 24-27, 2006).
252
27. Lolomari, T., Bratvedt, K., Crane, M., Milliken, W.J., and Tyrie, J.J. “The Use of Streamline
Simulation in Reservoir Management: Methodology and Case Studies,” SPE 63157, presented at the
SPE Annual Technical Conference and Exhibition, Dallas, Texas, USA (October 1-4, 2000).
28. Martin, J. J. “Cubic Equations of State-Which?” I and EC Fundamentals, (1973) 18, 81.
29. Michelsen, M. L. “The isothermal flash problem. Part I. Stability,” Fluid Phase Equilibria (1982) 9,
1-19.
30. Milliken, W.J., Emanuel, A.S. & Chakravarty, A. “Applications of 3D Streamline Simulation to Assist
History Matching,” paper SPE 63155, presented at the SPE Annual Technical Conference and
Exhibition, Dallas, Texas, USA (October 1-4, 2000).
31. Pollock, D. W. “Semianalytical Computation of Path Lines for Finite Difference Models,” Ground
Water, (1988) 26, No. 6, 743-750.
32. Prévost, M., Edwards, M.G., and Blunt, M.J. “Streamline Tracing on Curvilinear Structured and
Unstructured Grids,” paper SPE 66347, SPE Journal (2002) 7, No. 2, 139-148; also presented at the
SPE Reservoir Simulation Symposium, Houston, Texas, USA (February 11-14, 2001).
33. Rian, D.T., & Hage, A. “Automatic Optimization of Well Locations in a North Sea Fractured Chalk
Reservoir Using a Front Tracking Reservoir Simulator,” paper SPE 28716, presented at the
International Petroleum Conference and Exhibition, Veracruz, Mexico (October 10-13, 1994).
34. Smoller, J. Shock Waves and Reaction-Diffusion Equations, New York, Springer Verlag (1983).
35. Sovold, K, Rian, D.T., & Sandvik, A. “Front Tracking Applied to the Simulation of Water Flooding in
a Braided River System,” paper SPE 21084, presented at the SPE Latin America Petroleum
Engineering Conference, Rio de Janeiro, Brazil (October 14-19, 1990).
36. Stone, H. L. “Estimation of Three-Phase Relative Permeability and Residual Oil Data,” Journal of
Canadian Petroleum Technology (1973) 12, No. 4, 53-61.
37. Stone, H. L. “Probability Model for Estimating Three-Phase Relative Permeability,” paper SPE 2116,
Journal of Canadian Petroleum Technology (1973) 22, No. 2, 214-218.
38. Thiele, M. R. and Batycky, R. P. “Using Streamline-Derived Injection Efficiencies for Improved
Waterflood Management,” paper SPE 84080, SPE Reservoir Evaluation & Engineering (2006) 9, No.
2, 187-196; also presented as “Water Injection Optimization Using Streamline-Based Workflow” at
the SPE Annual Technical Conference and Exhibition, Denver, Colorado, USA (October 5-8, 2003).
39. Tyrie, J.J., Gimse, T. “Some Powerful Reasons for Adopting Front Tracking Simulation,” paper SPE
30444, presented at Offshore Europe, Aberdeen, UK (September 5-8, 1995).
40. Todd, M. and Longstaff, W. “The Development, Testing and Application of a Numerical Simulator for
Predicting Miscible Flood Performance,” paper SPE 3484, Journal of Canadian Petroleum
Technology (1972) 24, No. 7, 874-882.
41. Welty, J.R., Wicks, C.E., and Wilson, R.E. Fundamentals of Momentum Heat and Mass Transfer,
New Jersey, USA, John Wiley and Sons (1984).
253

Front Sim Technical Description

Загружено:

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

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

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

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

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

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

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

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

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

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

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

Front Sim Technical Description

Загружено:

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

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

FrontSim

Trademarks & Service Marks

An asterisk (*) is used throughout this document to designate other marks of

2 Allocation factors ......................................................................................... 7

3 Aquifer modeling facilities ........................................................................ 12

5 Dual porosity .............................................................................................. 30

6 Equations of state ...................................................................................... 34

7 File handling in FrontSim .......................................................................... 41

8 Geologic model screening ........................................................................ 44

9 Initializing the study .................................................................................. 54

The equilibration algorithm ............................................................................................ 55

11 Local grid refinement ................................................................................ 62

13 Saturation functions .................................................................................. 72

14 Saturation table scaling ............................................................................ 81

15 The streamline concept ............................................................................. 89

16 Streamline tracing ...................................................................................... 96

17 IOR tracer logic guide .............................................................................. 100

18 Tensor permeability ................................................................................. 144

Orthogonality error ....................................................................................................... 146

19 The Oil/Water Front Tracking Saturation Solver ................................... 148

20 The pressure equation ............................................................................ 155

21 Parallel multicore option ......................................................................... 158

22 Pattern flood management ...................................................................... 161

23 Solvent model .......................................................................................... 173

24 Three-phase saturation solver ................................................................ 198

25 Total compressibility checks .................................................................. 203

26 Tracer tracking ......................................................................................... 206

27 Transmissibility calculations .................................................................. 209

28 Well inflow performance ......................................................................... 211

29 Well Modeling Facilities .......................................................................... 214

31 Units .......................................................................................................... 222

A FrontSim development history ............................................................... 225

B Bibliography ............................................................................................. 251

About this manual

Individual well controls

Determine allocation factors

Allocation factor reports

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

PV not visited by any streamline: 0

Allocation factor usages

Allocation information to OFM or MS EXCEL

Aquifer modeling facilities

PERMX i is the permeability of aquifer cell i

XSECT i its cross-section

LENGTH i its length.

ka is the aquifer permeability

φ is the aquifer porosity

μw is the viscosity of water in the aquifer

Aquifer modeling facilities

Ct is the total (rock + water) compressibility

c 1 is 0.008527 (METRIC); 0.006328 (FIELD);

β = c 2 hθφCt ro2 Eq. 3.3

h is the aquifer thickness

c 2 is 6.283 (METRIC); 1.1191 (FIELD).

Qa is the aquifer inflow rate

pa 0 is the initial pressure of water in the aquifer

p̄ is the average water pressure on the aquifer/reservoir boundary.

Aquifer modeling facilities

Δ pai is the pressure drop pa 0 + ρg (di -da ) - pi ( t + Δt )

PI D ′ is the derivative of PI D with respect to tD

αi is the area fraction for each connection.