An alternative is therefore to model the aquifer by some artificial means. There are several ways to do this, but we will concentrate on the so-called numerical aquifers, which also can be modelled in Eclipse. The reasons for using a special model for the aquifer, are

•Practical: it saves memory space and computer time

•No loss of accuracy. Since aquifers are large one-phase volumes, the computations are simple, and as accurate on large grid blocks as on small.

•Detail water flow pattern is not needed in the water zone, only the energy (pressure) support from aquifer to reservoir, and water flux between the two are needed.

Actually, the flux and energy support can be computed with sufficient accuracy in a one-dimensional abstraction of the aquifer, which is how it is implemented. With this knowledge we see that a sufficient description of an aquifer doesn’t require shape, only volumes. However, the interface between the aquifer and the reservoir requires a shape definition, which is only logical.

Hence there are two aspects of setting up an aquifer, the aquifer definition (volume, properties), and how it interfaces to the reservoir.

Aquifer definition

The way Eclipse does it, ordinary grid cells in the reservoir are used to define aquifers. The cells will have all their properties redefined, but apart from that they are still part of the grid, and cannot be regarded as having been removed from the grid. E.g. connectivity between grid cells is not changed just because a cell is defined as an aquifer cell. This means that aquifer cells should be completely isolated from the rest of the reservoir, i.e. completely surrounded by inactive cells.

Most aquifers can be satisfactory defined by one grid cell only. However, if the aquifer properties and/or depth have large variation, it can be a good idea to try to capture this variation by using more cells to define the aquifer. More than three or four cells should seldom or never be necessary.

To verify this it is a nice exercise to build a simple grid including a large water zone which is explicitly modelled. Then model the water zone as a numerical aquifer using one, two, four and ten cells. Most probably, the results from these cases will be as good as equal.

Figure 20 shows some examples of ways to use grid cells to define aquifers, and the connectivity to expect.

D

Figure 20. Examples of use of inactive cells to define aquifers (grid viewed from above)

Cell A is a typical example of using an isolated inactive cell to define an aquifer. The cell has no connection to the surrounding world at all, so the necessary flow connections will be defined by the user.

75

Cells B1, B2, B3 are connected to each other, but isolated from the rest of the grid. The three cells can either be used to define a single aquifer, which obviously will have internal communication, or the cells could define two or three different aquifers, such that the aquifers communicate with each other. Cells C1 and C2 are isolated from each other, and from the rest of the world. They can be used to define two different aquifers. Using such a configuration for a single aquifer would be meaningless, as there would be no connectivity between the two different parts of the aquifer.

Cell D is not suited for use as an aquifer cell, since it is in direct contact with an active cell in the grid. In addition to the connectivity defined by the user, fluid in cell D will flow directly into the reservoir, which is probably not intended.

Having decided which (inactive) cells from the grid to use as aquifer cells, the keyword to define the aquifer is AQUNUM (numerical aquifer). The keyword data is comprised of arbitrary many lines, each line containing definition for exactly one aquifer cell on the original grid. The syntax for each line is,

AQ-id AI AJ AK X-sect_area Length Poro Perm Depth P_init PVT-table SatNum

AQ-id

an integer identifying the aquifer. If several lines are used to define the same aquifer, only the cell defined in the first line of definition will be in contact with the reservoir, as defined by the AQUCON keyword below.

AI AJ AK

The (I, J, K)-index for the grid cell to use as aquifer cell

X-sect_area Length

The gross volume of the aquifer cell is the product of these two numbers. Recall that the aquifer is modelled as one-dimensional – flow is assumed to be in the direction defined by Length, and flux out of the aquifer is through the cross sectional area defined by X-sect_area.

Poro Perm Depth

Normally we will define porosity, permeability and a typical depth for the aquifer, taken from known properties of the water zone. If these items are defaulted, the values will be taken from the grid cell as it is defined in the grid.

P_init

Initial pressure in the aquifer cell. It is recommended to default this value, whereby it will be computed from the fluid gradients and the depth defined above.

PVT-table SatNum

These items are best defaulted. (Ref Eclipse documentation if alternative is needed.)

Example.

We will define four different aquifers, corresponding to examples A, B, and C in Figure 20. Cell A has aquifer-id 1, aquifer-id 2 is used for cells B, and aquifer-id 3 and 4 for cells C. The view in Figure 20 is assumed to be the top layer (K=1), at the edge of the reservoir (I=1 at left end, J=1 at top).

Note that the dimensions, petrophysics, and depth of the aquifer cells bear no relation to what was defined in the grid originally at all.

Flow between the reservoir and aquifer 2 will only be to/from cell (3, 3, 1), since this cell is the first to be defined in the keyword. Also note the reason for using three cells for aquifer 2, to capture the depth increase (higher fluid pressure, larger compressive energy) and decrease in permeability with depth.

76