The mobility term – upstream weighting

The other “troublesome” term, λi+1/ 2 = λ( pi+1/ 2 , Si+1/ 2 ) must be handled differently. The details are

beyond the scope of these notes, but averaging values for pressure and saturations from two neighbour cells is not a good solution. By arguing physically that mobility is a property that moves with the flow, λ is computed based on the values in the cell the flow is coming from to reach the cell edge. Hence for a one-dimensional case,

This is called upstream weighting.

(And yes, this can and does pose problems frequently.)

Averaging – smoothing

When we compute the cell average permeability, the actual permeability field is smoothened by the averaging, and the effect of local extreme values may be lost. When the simulator converts the input permeability to inter-cell transmissibilities, the data is smoothened yet another time. The permeability field that is used by the simulator is therefore typically considerably smoother than the original data. In some cases this effect can change the flow pattern such that we don’t get the results that were expected by logical physical reasoning. In such cases it is recommended to compute improved transmissibilities manually, and replace simulator-computed values by these in critical areas.

Inactive cells

An inactive cell is a cell that does not contribute to fluid volumes or flow in the reservoir. By default, the simulator will flag any cell with vanishing pore volume as inactive. In addition, the user may define active cells explicitly, by the keyword ACTNUM, where all cells are listed, the active ones as “1”, inactive as “0”. Note that a cell with zero pore volume will be inactive irrespective of the value it receives in ACTNUM.

Another source for inactive cells is the minimum pore volume option. Cells with very small pore volume will contribute insignificantly to flow or production, but exactly because they have a pore volume which is very different from typical values they can have a negative effect on the numerical solution, and total computing time can become (unacceptable) large. For this reason it is possible and advisable to define a minimum pore volume value such that cells with smaller pore volume than this value will be flagged as inactive. For Eclipse, see keywords MINPV or MINPVV.

An inactive cell between two active cells will be a flow barrier. But if a cell becomes inactive by the minimum pore volume option, it would obviously be wrong to treat it as a barrier, which would not be in accordance with the original layout. Eclipse therefore has a keyword PINCH which when used causes correct transmissibilities to be computed across cells made inactive by small pore volume.

Note that in this case the transmissibilities are not between neighbour cells, which they don’t need to be. General transmissibilities can be between any cells.

5. Fluid properties (PROPS section)

Tables in Eclipse

All functional dependencies are defined by tables in Eclipse. Values between tabulated points are found by linear interpolation when needed. If values extend beyond the range in the table, the first or last point in the table is used, i.e. no trend extrapolation. Note that in many cases Eclipse actually needs differentials calculated from the tables, hence not only should table data be sufficiently smooth, but also the derivatives. With this background we can put up some simple rules of thumb,

•Ensure that the table range covers all values that can occur in the simulation. If in doubt, extrapolate table roughly by hand (it’s going to be better than Eclipse’s constant extension).

•Use enough points that transitions between table points are “sufficiently smooth”. Avoid abrupt changes, e.g. don’t use a step function, but define some extra points which round off the corners a little. Since Eclipse interpolates linearly, check that the point spacing is dense enough that this is good enough. On the other hand don’t use too many points, as this may slow down the table lookup.

29

• Hysteresis will not be covered here, but if used it is recommended to define the two curves at a parting point such that the parting is smooth, with smooth derivatives.

In most cases the functional dependency that is tabulated has some physical constraints. Eclipse knows all about such constraints, and will check tables, and refuse to simulate an unphysical situation. (Typical monotonicity, consistency,...). Some violations will result in warnings, other in errors.

Relative permeability and Capillary Pressure

Two-phase curves (water – oil)

The standard way of defining relative permeability for an oil-water system is as a function of water saturation, krl = krl(Sw), l = o,w. The interesting range is the mobile fluid range,

0 ≤ Swc ≤ Sw ≤ 1 – Sor ≤ 1, where Swc is critical water saturation and Sor residual oil saturation. The endpoint relative permeabilities are,

kro' = kro (Swc ), krw' = krw (1−Sor )

The easiest way to input the curves to Eclipse is by the keyword SWOF. Each entry (line in the table) consists of four items,

Sw krw(Sw) kro(Sw) Pcwo(Sw)

Requirements:

Column1 is in increasing order.

Column 2 is non-decreasing

Column 3 is non-increasing

Column 4 is non-increasing

In the first column, the first entry is taken as connate water, and krw must be zero on this line,

while kro = kro’.

Sw = 1 – Sor at the first zero-value in the third column, while the last entry in the first column is taken as maximum occurring water saturation, Sw,max.

NOTE: Sw,max is used to initialise saturations in the water zone in the reservoir. Only in exceptional cases should this value be different from 1.0.

Some entries in columns 2, 3, and 4 can be defaulted (by 1*). Missing table values will then be computed by linear interpolation.

Figure 10. Typical two-phase relative permeability curves

30

Three-phase relative permeabilities

If we assume that any of the three phases can flow irrespective of the saturation of the two other phases, we will need a very complex description, that is not even agreed on in the industry. We therefore restrict ourselves to a simple model, and refer to other literature if a more realistic model is needed. The basic assumption is that the flow is in essence two-phase, with the third phase acting as a “dummy background”, but not contributing actively to the flow. Then the relative permeability curves for oil are either oil-water (no gas) or oil-gas (water at connate saturation). The input can be defined in several ways in Eclipse. We present only one, and refer to the manuals for alternatives.

Three phase relative permeabilities are input by the keywords SWOF and SGOF.

SWOF is identical to the two-phase case, except that column 3, krow, is now interpreted as oil relative permeability when only oil and water are present,

Sw krw(Sw) krow(Sw; Sg=0) Pcwo(Sw)

The data for keyword SGOF also consist of lines with four entries:

Sg krg(Sg) krog(Sg; Sw=Swc) Pcog(Sg)

We see that the first entry in column 3 is oil relative permeability at minimum water and gas saturation in both tables, so those two have to be equal. The last value in column 3 must be zero for both keywords. Pcog(Sg) must be nondecreasing.

Example 3. Three phase relative permeabilities using SWOF and SGOF

0.400.15 0.125 3.0

0.501* 0.065 1*

0.600.33 0.0048 2.0

0.100.022 0.33 0.5

0.700.813 0.00 3.5

0.78 1.0 0.00 3.9 /

PVT data

Eclipse, as most black oil simulators, assumes isothermal behaviour in the reservoir, i.e. the PVT relations are defined for constant reservoir temperature. This may be far from reality, as e.g. when injecting cold water into a warm reservoir, but this is a limitation we have to live with.

Although the simulator must relate to the fluids as they occur in the reservoir, we as observers can only measure fluid properties at the surface. It is therefore convenient, and standard in all reservoir simulators to define fluid properties at standard conditions (also called surface conditions, or stock tank conditions), i.e. at atmospheric pressure and temperature 15.5 °C. We will use subscript RC for

Reservoir Conditions and subscript SC for Standard Conditions.

32