One alternative solution which is growing in popularity, is to use unstructured grids. By allowing for cells with any number of faces, any geometry can be modelled, and at the same time keeping the total number of cells at a manageable level. (Figure 4.)

The organisation of the cell structure and computational challenges have to now not been completely solved, which is the main reason the “traditional” grids are still dominating the scene. We will henceforth concentrate on structured grids.

A structured grid is characterized by

1.All cells are six-sided with eight nodes, i.e. topologically equivalent to a cube.

2.The cells are logically organized in a regular scheme, such that each cell’s position in the grid is uniquely determined by it’s (I, J, K)-index.

The Corner Point Grid

A structured grid is uniquely determined when all eight corners of all cells have been defined. In Eclipse, the corners cannot be completely arbitrary, but are constrained in the following manner:

Coordinate Lines

A coordinate line is a straight non-horizontal line defined by two coordinates

(x, y, z)TOP and (x, y, z)BTM.

In the simplest and most common case the coordinate lines are vertical. For the regular cartesian grid the coordinate lines would be the vertical lines which in the XY-plane can be seen as the nodes, or the “meeting point” between four and four cells. The same principle is valid in general, although more complex. The coordinate lines form a skeleton of lines, each line identified by its index (I, J). Except for edge cells, any coordinate line is associated with four columns of cells. Refer to Figure 5, and confirm that coordinate line (I, J) is associated with the four cell columns (I-1, J-1, K), (I, J-1, K), (I-1, J, K), and (I, J, K). (K takes all values 1,...,NZ). Recall that each cell was defined by its eight corner nodes. In each of the associated cells, exactly two corners (one on the top face and one on the bottom face) are on the coord line. Denote the four associated cell columns C1, C2, C3, and C4, and let the corners lying on the coordinate line be N1A and N1B in cell column C1, N2A and N2B in C2 etc. (Ref.

Figure 6) The constraint defined by Eclipse is then that cell corners N1A, N1B ,..., N4A, N4B lie on the coordinate line for all layers K. A way of looking at this is to envisage the coordinate line as a straw,

and the corner nodes as beads on this straw. The beads can move up and down on the straw, but are restricted to stay on the straw, which by definition cannot be bended – coordinate lines must be straight lines.

Coord line (5,1)

Coord line (1,1)

Top

Coord line (5,4)

Btm

Figure 5. Cell indices and coordinate indices in a structured grid

21

A structured grid obeying the coordinate line restriction was originally called a corner point grid by the Eclipse development team. The Eclipse grid format is now a de facto industry standard, and corner point grids are used in a much wider context.

Examples

Ex. 1. Regular grid

The regular cartesian grid is obviously a corner point grid, and the coordinate lines are vertical. Each grid node (edge nodes excepted) is the meeting point for eight cells, and each of these cells has one corner equal to the meeting point. Since we required that all eight corners were defined for every cell, this means that in regular points like this, every node coordinate will be defined (and stored) eight times. (Waste of memory and hard disk space...)

Figure 6. Three of the four cells sharing a coord line, and some corner points

Ex. 2. Fault

Modelling of fault throws is the main reason for introducing the corner point concept. Figure 7 shows a cross-section view in the XZ plane of a fault, with upthrown side (footwall) to the left and downthrown side (hanging wall) to the right. One way to look at this is that the grid has been constructed in the same fashion as the fault itself. Starting with a continuous grid, the cells on the hanging wall side has been allowed to slide downwards along the fault plane, which is a coordinate line. Note how the corners on the downthrown side has moved along the coordinate line, such that the depths of associated nodes are no longer equal. It is easy to convince oneself that such a modelling of faults could not be possible without the general way in which all eight cell corners are handled individually.

X

Z

Figure 7. Cross-section view of a fault in a corner point grid

22

Notes:

•Since the coordinate lines must be straight lines, listric faults (curved) cannot be modelled2.

•Obviously, the coordinate lines must form a grid skeleton which is physically realisable. This means that Y-faults and other complex shapes are impossible to model, since it would lead to crossing coordinate lines.

•As modelled, faults are discontinuity surfaces. In reality all faults have volume, a fault core and a surrounding damage zone. Such features can be modelled, but in this context we stick to the Eclipse concept.

Ex. 3. Shaly Layer

A non-permeable layer is a non-flow unit, and inactive in the grid. As such, the layer does not need to be modelled at all. Eclipse allows for gaps in the grid, i.e. the top of one cell does not need to coincide with the bottom of the cell above3. Although such explicit modelling of gaps is rather rare in practice, it is an example that the grid doesn’t have to be continuous vertically, and hence the generality of all eight corners being handled individually is actually required (Figure 8).

Layer 1

2

34 Shale 5

Figure 8. A shaly layer modelled as a gap (non-grid) in a corner point grid

Degenerate cells

As defined, each cell in a corner-point grid is defined by its eight corners. If all corners are different, and the cell has a “normal” appearance (topologically equivalent to a cube), the cell is a standard corner-point cell. It is however permitted and useful to allow some corners to be coinciding, in which case we say that the cell is degenerate. A degenerate cell has fewer actual corners than the eight corners it is defined by. Typically, a degenerate cell will have one or more edge thicknesses equal to zero, e.g. a wedge-shaped cell used to define a pinchout zone. The most common example is probably zero-thickness cells. When a geological layer terminates, this must be modelled in a grid by defining part of the layer with cells with thickness zero, since the number of layers must be the same in the entire grid.

Defining a corner point grid in Eclipse

Eclipse always stores the grid in corner point format. I.e., on input we must either define the cell corners explicitly, or we must give sufficient grid data that eclipse can construct the corner points itself. In practice we will either define a regular simple grid as in the example in Chapter 1, or the grid will be constructed by suited software, such that the corner point data is supplied in a black box file. Hence, a user will never input corner points manually. It is, nevertheless, useful to know the format of the corner point input to Eclipse, which is defined by the two keywords COORD and ZCORN.

COORD is used to define the coordinate lines. Each coordinate line is uniquely defined by two points, and since the line cannot be horizontal, the two points are denoted top and btm (bottom). If the number of cells in x and y-direction are NX and NY, the number of coordinate lines will be NX+1 and NY+1.

The coordinate lines are then input in the book page format, line by line, with I running from 1 to NX+1 on each line:

2Actually, when Eclipse reads the grid, it doesn’t check that the coordinate lines are really straight. So if the grid could be constructed by non-eclipse software that permits listric faults, and if the resulting grid was edible by Eclipse, then Eclipse could be tricked to handle quite general grids. This is far beyond the scope of these notes.

3Eclipse doesn’t even object to overlaps, although this is obviously physically impossible.

23