Reservoir Simulation Newsletter

N°
N° 14
January
January 2007
2007

¶ Introduction
This first Newsletter of 2007 brings news of a new schedule for the Intersect project, and also of small delays to both
Petrel-RE and gOcad-RSI.
On a brighter note, the following remark was made in the canteen, in front of several witnesses, by a young Total
reservoir engineer on the eve of his first expatriation:
“If there is one thing I would take with me, it would be the transparencies from the
Reservoir Simulation training course.”
So don’t miss out! If you are going to be performing reservoir simulation studies, ask your line manager about
attending one of the new Reservoir Simulation courses (Basic or Advanced) during 2007. See the last edition of the
Newsletter, or contact Lisette Quettier or your training coordinator, for more details. Dates for the courses are:
• Reservoir Simulation – Basics (including EST): weeks 13 – 14 (26 March – 6 April) and weeks 38 – 39
(17 – 28 September).
• Reservoir Simulation – Advanced: weeks 24 – 25 (11 – 22 June).
Note that pre-requisites for the advanced course are to be familiar with the basics of reservoir simulation (the Basics
course plus at least 9 months experience, or equivalent), with EST (there is a session of the in-house course week 17)
and with the fundamentals of the PVT behaviour of hydrocarbon fluids (there is a session of the in-house
thermodynamics course week 11).
Other Eclipse-related topics covered in this Newsletter include the WAGHYSTR, IKU and 2-dimensional table entry
relative permeability models, use of the WPIMULT keyword, and how to re-inject only certain components of the
produced gas.
Finally, we would like to draw your attention to an interesting article on “Gridding rules for reservoir models” in our
sister publication “Reservoir Modelling Newsletter” (edition n°4, October 2006). This should be available soon on the
metier geology Intranet (“My Discipline” > “GSR – Géologie”). Since we’re mentioning the Intranet, we are aware
that a lot of the formatting of the reservoir simulation pages has been lost in the recent reorganisation, and we are
working to get it restored.

¶ Latest News on Intersect

The last edition of the Reservoir Simulation Newsletter went out in August. At that time, we were expecting to receive
a beta version of Intersect in Pau in September. However, at the beginning of September, Schlumberger (SIS) informed
us of a delay to the project. The main reasons for this were:

• Debugging and stabilization of "version 1" was proving to be difficult.

• An audit of the code, made by IBM at the request of SIS.
• It had become clear during testing that certain modules, notably those concerned with well modelling and
field management, would have to be substantially re-written for “version 2”.

At the end of August, the decision was taken by the Intersect Board (SIS and Chevron) to abandon “version 1” in order
to start as soon as possible on the “re-factoring” needed for “version 2”. The project leader was replaced and the new
leader requested two months to establish a new timetable for the first release. This new timetable was proposed to the
Board and consisted of:
 •A first commercial release, broadly equivalent to “version 2” in that it would include the heavy oil and
thermal (HOT) module in which Total is a partner, as well as the link with the surface network simulator
(GAP), for the second half of 2008.

•An optional, interim, non-commercial version, late in 2007.

So far as Total is concerned, this means a delay of over one year in the planning for internal deployment. First
application to studies will not be before late 2008, and deployment in the subsidiaries mid to late 2009.

Some good results have nonetheless been obtained: the Akpo data set that we supplied for test purposes now runs
significantly faster with Intersect than with Eclipse-300. The prototype HOT module is also progressing according
to plan and the code has been validated on some steam injection test cases.

¶ Eclipse Versions 2006.1 and 2006.2

The 2006.1 version of the Eclipse suite is now installed and in routine use at HQ. Compared to 2005a_1, most
Eclipse and E-300 data sets run in the same time with the same results. There are tighter controls on the use of API
Tracking, and some adjustment of the input data may be needed for models using this option.

We have encountered one or two cases that give different results, but these seem to be cases that have convergence
problems, and the differences arise because wells shut in with one version but not with the other. It is often not clear
which version is "correct", if indeed either one is. One or two cases have also been seen that take much longer to run
with 2006.1, but these have mainly been the same cases that gave different results.

We have also encountered a number of minor bugs in the pre- and post-processing tools, particularly Eclipse Office.
SIS tells us that most of these have been fixed in 2006.2, which has just been released but is not yet installed at HQ.

Advantages of the 2006.1 release were listed in the last Newsletter (see also the “New developments” chapter at the
beginning of the Eclipse Reference Manual).

Subsidiaries are encouraged to migrate directly from earlier versions to 2006.2, preferably by summer 2007. Please
let us know of any problems encountered. Installation of the licence manager is however not straightforward: if help
is needed, please contact Laure Castaing.

¶ Latest News on Petrel-RE and gOcad-RSI

The next release of Petrel (2007.1), including the RE (Reservoir Engineering) module, is now planned for March
2007. We will be evaluating it when it is available. Subsidiaries are still strongly advised to await our
recommendation before investing in the product.

The first commercial release of gOcad-RSI (Reservoir Simulation Interface) will be with version 2.2.1 of gOcad
which is planned for Q2-2007. A beta version will be available with gOcad-2.2.0 in Q1-2007. We have recently
tested an alpha version, partly to provide feedback to the developers and partly in the context of a student project to
test the interface with the streamline simulator 3DSL. Our overall impression was of slight disappointment in the
rate of progress and the number of bugs.

N°ASI - 0302ASI1G
 ¶ WAGHYSTR Relative Permeability Model in Eclipse

The WAGHYSTR keyword invokes a specific model for relative permeability hysteresis in WAG (water alternating
gas) injection cases. This model was originally developed by Norsk Hydro on the basis of limited experimental data.
It is known to be fairly optimistic because the gas relative permeability is reduced in each successive WAG cycle, so
gas breakthrough is delayed and oil recovery is improved. A potential negative impact is loss of injectivity when the
gas relative permeability is reduced.
Use of this model as the base case is not recommended, but it can be used as a sensitivity case.
We tested this option early in 2006 using a simple 1D reservoir model and the 2005a_1 version of Eclipse. Some
unexplained behaviour in the gas relative permeability was observed and reported to SIS. A bug was found and
fixed for the 2006.1 version. Tests made with the 2006.1 version appear to indicate that the option is now correctly
implemented. It has been used by the Bloc-32 team to run sensitivity cases. A large increase in cpu time was
observed in the simulation with this option (5 to 10 times longer). Predicted oil recovery increased by 1-2% OOIP.
To some extent, an increase in cpu time must be expected, because the relative permeability behaviour is much more
complicated and this can make it more difficult for the simulator to converge. It remains to be seen whether any
significant improvement can be made by SIS.

GAS
GAS RELATIVE
RELATIVE PERMEABILITY
PERMEABILITY vs.
vs. GAS
GAS SATURATION
SATURATIONIN
IN GRID
GRIDCELL
CELL 80
80
1D
1D TEST
TEST CASE
CASE WITH
WITH WAGHYSTR
WAGHYSTR OPTION
OPTION

TWO-PHASE
TWO-PHASE IMBIBITION-
IMBIBITION-
DRAINAGE
DRAINAGE CYCLES
CYCLES FIRST
FIRST THREE-
THREE-
PHASE
PHASE CYCLE
CYCLE

FIRST
FIRST
DRAINAGE
DRAINAGE

SECOND
SECOND THREE-
THREE-
PHASE
PHASE CYCLE
CYCLE

The WAGHYSTR option is not available in Eclipse-300, so it can only be used in black oil cases.

¶ IKU and Table Entry 3-Phase Relative Permeability Models in Eclipse

The classic 3-phase relative permeability models available in Eclipse are Stone 1, Stone 2 and the Eclipse default
model. Stone 2 is generally not recommended. Either of the other two methods may be used as the base case, and it
is recommended to retain the other as a sensitivity case whenever 3-phase flow occurs. When using Stone 1, it is
recommended to use SOMGAS or SOMWAT to set Sorm (the residual oil saturation in 3-phase flow).
All three models assume that water relative permeability depends only on water saturation and that gas relative
permeability depends only on gas saturation. Oil relative permeability depends on both water and gas saturation: in
3-phase flow it is determined by interpolation between the two sets of 2-phase data given as input
(oil-water and oil-gas).

N°ASI - 0302ASI1G
 Experimental data for 3-phase flow is never available. However, it has recently become possible to generate relative
permeability curves from Pore Network Model (PNM) simulations. The first such application took place in 2006 for
the Elgin reservoir. Curves were generated by Gérald Hamon (TG/COP) assuming an oil-wet porous medium. A
feature of these curves is that the gas relative permeability depends not only on the gas saturation, but also on the water
saturation. This dependence cannot be modelled with the classical 3-phase relative permeability models.

The question, then, is how to introduce these curves in Eclipse. The first idea was to use the IKU model available in
Eclipse-300. In this model the relative permeability of all three phases is allowed to depend on both water and gas
saturation. For each phase, two curves must be entered, corresponding to two different two-phase flow situations, and
an interpolation will be performed between these two extremes. The interpolation formula is different from those of the
classical models, and is basically a linear interpolation.

Preliminary tests showed that the IKU model seems to be correctly implemented in Eclipse-300. However, the
documentation is not very clear (SIS have promised to improve it for the 2007 release). In particular, note that the 2-
phase gas-oil relative permeability that is entered must correspond to 2-phase oil-gas flow in the complete absence of
water (not at irreducible water saturation). Unfortunately, in the Elgin case, the linear interpolation used by the IKU
model did not fit the PNM data, which showed considerable non-linearity.

Sg=1
Sg=1
S org
Entered here
S g=0.8
S og
S g=0.7
krg=0.4
S g=0.6

S g=0.5
krg=0.2
S omin krg=0.1
S g=0.4
S gro krg=0.05
S g=0.3

Somax

So=1 S w=1
So=1 S w=1
Sw,irr Sow S orw

IKU Model PNM Data

The second idea was to use the new keywords (SOF32D, SWF32D, SGF32D) in Eclipse-100 that allow water, oil and
gas relative permeability to be entered as two-dimensional tables depending on both gas and water saturation. This
option is available only in black-oil but that would have been sufficient for running sensitivity tests in the Elgin case.
However, it was found that these keywords cannot be used in the case of a gas reservoir with a gas-water contact.
Correct results were obtained on a simple 1D test case with no gas-water contact, but convergence problems prevented
Eclipse from completing a second test case with higher condensate saturation.

More generally, when water and gas relative permeability are entered as two-dimensional tables, the water-oil and oil-
gas capillary pressures must also be entered as two-dimensional tables (PCW32D and PCG32D keywords). The
capillary pressures are used to calculate initial saturation versus depth in the water-oil and gas-oil transition zones. In
the case that these two transition zones overlap, this calculation becomes complicated because interpolation within the
two dimensional tables is necessary. Currently, Eclipse does not allow the use of this option with over-lapping
transition zones. A side effect of this is that the case of a gas reservoir with a gas-water contact is not allowed either,
even though this case is not complicated.

N°ASI - 0302ASI1G
 ¶ Use of WPIMULT
WPIMULT is often used in simulation decks as a convenient way of modifying the inflow part of the well productivity.
Eclipse multiplies the connection transmissibility factors (CF) of the selected connections (or all completions
previously defined in COMPDAT) by the factor given in WPIMULT. There are some important rules to keep in mind:

1. If COMPDAT is reset (to open new connections for example), WPIMULT must be reset as well.

2. If WPIMULT is redefined at a later time period without resetting COMPDAT, the effect is cumulative:
CFFINAL = WPIMULT1 * WPIMULT2 * CFCOMPDAT

3. If WPIMULT is given several times for the same completion at the same DATE, only the last value is taken
into account.

4. For the computation of WBP, WBP5, WBP9 … the averaging over the different connected layers is
weighted by the connection factors corrected by WPIMULT. Remember that, although weighting by CF is the
default, you may change it with the keyword WPAVE (second item).

5. It is recommended to check the CF values used by Eclipse by outputting them in the PRT file with
‘WELSPECS’ in RPTSCHED.

WPIMULT for all completions in a well is generally tuned to match the observed BHP (or THP if there are no BHP
measurements). This tuning should be performed after the reservoir pressure, water cut and GOR have been correctly
matched. A good first guess of the correction factor to apply is:

WPIMULT = CF2 / CF1 = (WBP-WBHP1) / (WBP - WBHP2)

where WBP is the reservoir pressure, WBHP1 is the un-matched value of the BHP and WBHP2 is the observed value.
This assumes that the flow rate and reservoir pressure will not be modified by the PI multiplier.

WPIMULT is also used to match PLT data, by applying different values to different completions. This is generally
done after adjusting the permeability of each connected layer to match the overall water cut or GOR.

The physical meaning of the WPIMULT is a modification of the skin. Once you have adjusted the multiplier to match
the BHP, it is recommended to compute the equivalent skin modification and to discuss the acceptability of this value
with the productivity department.

CF2 Ln( r0 / rw ) + S1
WPIMULT = =
CF1 Ln(r0 / rw ) + S 2

Here r0 is the Peaceman radius and rw is the radius of the well – half of the diameter given in COMPDAT (see
Newsletter n°8); you will find these both values in the table output with ‘WELSPECS’ in RPTSCHED. Different
multipliers applied to different layers to match a PLT must also be discussed.

Don’t forget to apply the same PI modifications to any equivalent infill wells added in forecast runs.

Finally, for gas wells, it is generally recommended to use a D factor instead of WPIMULT to take into account the
effect of rate variations in the quadratic skin:

Squad = D * Qg

N°ASI - 0302ASI1G
 ¶ How to re-inject specific components of a produced gas

This question came up recently in a study involving sour gas re-injection. The idea was that all the CO2 and H2S
would be separated from the produced gas and re-injected, while the rest of the gas would be exported. The amount of
CO2 and H2S produced should therefore dictate the volume to be re-injected, and the respective amounts of CO2 and
H2S produced should dictate the composition of the injected gas.

This can be simulated in Eclipse-300 with a combination of the GPTABLE, FIELDSEP, GINJGAS and GCONINJE
keywords. The basic idea is that an extra stage is introduced at the beginning of the separation process to separate the
CO2 and H2S from the rest of the produced fluid (using GPTABLE). However, both liquid and gas output from this
separator are immediately recombined and passed directly into the normal separation process, which now becomes
stages 2 to “n+1” in FIELDSEP. The first separation stage serves only to define a gas stream consisting only of the
produced CO2 and H2S. Once this stream has been defined, it can be re-injected by Eclipse-300.

CO2 + H2S : FG1PR

Feed GPTABLE
Stage 1

All Other FGPR

Components Real
Separation
FOPR
Process

A memo by Christophe Nogaret giving more details is available on request.

¶ Error in LBCCOEF Keyword Output by BEST

In case you missed the memo sent in October, or have forgotten it, an error was found in the LBCCOEF keyword
exported by the two latest versions of BEST. This keyword should include five coefficients to be used in the Lorentz-
Bray-Clark formula for calculating oil and gas viscosity in a compositional Eclipse-300 simulation. To check for this
error in an Eclipse-300 data set:

• If the LBCCOEF keyword is not present, there is no problem

• If the LBCCOEF keyword is present with 5 values, there is no problem

• If the LBCCOEF keyword is present with only 4 values, the viscosity calculation is probably wrong: the first
coefficient is likely missing. In the case where the problem was discovered, the error was a factor of 3 in the
gas viscosity and a factor of 10 in the oil viscosity.

To check the viscosity values calculated by Eclipse, use the keywords BVOIL and BVGAS in the SUMMARY section
and/or the mnemonics VOIL and VGAS in RPTRST.

Issued by : VDG/MET/SIM
Editor : John BARKER
Technical advisor : Lisette QUETTIER

N°ASI - 0302ASI1G