Traces and Fault Zones

Introduction to Traces

Any TransGen model contains a number of object types, for example cells (grid-blocks) and fault connections. The location of a cell location is defined by its XYZ position in the model and the location of a fault connection by the XYZ positions of the two cells it links. Each object has a number of properties which are either included in the TransGen run (via the Included data page in WizGen, e.g. PERMX and NTG of cells) or are calculated automatically by TransGen (for example fault connection permeability). Each type of object may additionally have sub-types, e.g. a fault connection has an average connection property (in the "PERM" and "THICK" plugins) denoted by the "c." prefix, but also has between 3 and 6 corners (vertices) denoted by the "v." prefix.

Much of the new functionality in the TransGen version 3.2 is associated with a new type of TransGen object called a faulted trace. A faulted trace is a 2D object defined by the XY location of the edge of a stack of cells. Hence a trace defined by [I, J, `DIR_X'] contains all connections between cells [I,J,Z1] and [I+1, J, Z2], where Z1 and Z2 can take any values.
For example, the simple 2*2*2 faulted model shown below contains 8 cells ([1,1,1], [1,2,1], [2,1,1], [2,2,1], [1,1,2], [1,2,2], [2,1,2], [2,2,2]), 3 fault connections ([1,2,1][2,2,1], [1,2,2][2,2,1] and [1,2,2][2,2,2]), and one fault trace ([1,2,`DIR_X']).

Like fault connections, fault traces are recognised automatically by ViewGen from the geometry of the input model and a number of properties are calculated and stored for each one. A fault trace contained explicitly in the parent model geometry is termed a system trace or an explicit trace: the two terms are equivalent.

New functionality allows new traces to be added to a TransGen model and for existing traces to be modified, without the need for modifying the underlying geometry of the simulation model. For clarity, the unaltered input model is termed the system model and a model containing modifications the user-defined model. The objectives of the new functionality is to calculate appropriate properties and connection transmissibilities for the user-defined model, but to output these at the resolution of the system model.

For example, the user-defined model geometry shown below derives from the parent model shown above. The system trace [1,2,`DIR_X'] has had its throw modified, while a new trace ([1,1,`DIR_Y']) has been added. Any new trace added in this way is termed a user-defined trace.

The user-defined trace [1,1,`DIR_Y'] has added one non-neighbour connection ([1,1,2][1,2,1]) to the model, and has influenced the transmissibilities of the two, originally unfaulted neighbour connections [1,1,1][1,2,1] and [1,1,2][1,2,2]. The resultant across-fault transmissibilities associated with these connections will be calculated and output by TransGen using the Eclipse NNC and TRANY keywords respectively. The across-fault transmissibility associated with the modified non-neighbour connection on the system trace (i.e. connection [1,2,1][2,2,2])will be included as a transmissibility multiplier in the EDITNNC file, with the faulted transmissibility calculated from the modified model (Fig 2), and the no- fault rock transmissibility calculated from the unaltered parent model |(Fig 1). For the two faulted neighbour connections on the system trace, the faulted transmissibilities calculated in the modified model (Fig 2) will be included in the TRANX file.

Figure 3 (below) shows a more severe modification to the same model (Fig 1). In this example, only two across-fault connections are present; the non- neighbour connections [1,1,2][1,2,1] on the user-defined trace and [1,2,1][2,2,2] on the system trace. Since neither of the connections exist in the unaltered parent model, the faulted transmissibilities associated with them will be output into the NNC file. Additionally, five connections that existed in the parent model do not exist in the modified model. The effect of losing these connections will be included in the simulator input by setting two TRANY values (connections [1,1,1][1,2,1] and [1,1,2][1,2,2]), two TRANX values (connections [1,2,1][2,2,1] and [1,2,2][2,2,2]) and one EDITNNC (connection [1,2,1][2,2,2]) to zero.

Trace Properties

A number of properties are calculated automatically for each trace in the model, the most important of these are the length, width, aveThrow and dragRatio of the trace. The first two are used to calculate other properties (in particular the maximum size of a relay ramps that a trace can contain) but cannot be altered by the user. The second two can be redefined in a number of ways by the user, and define the final fault juxtaposition geometry used to calculate across- fault connection transmissibilities. Up to 10 user-defined trace properties can also be defined and used. The Table below lists the main properties attached to fault traces and indicates how these values may subsequently be modified during the TransGen workflow.

Trace Length and Width

These Trace properties are defined in the Figure below for a fully 3D model in which none of the coord lines defining the cell edges are parallel to each other. Note that only the upper three layers of this five- layer model are faulted (Fig 4a), and therefore fault connections (Fig 4b) are only present in the upper region of the model. Despite this, since it is a 2D object, the fault trace (Fig 4c) extends from the footwall side of the uppermost layer to the hangingwall side of the lower- most layer.

The trace length is defined as the minimum value of the XY projection of the length of the trace measured in each layer in the model in the cells on both sides of the trace. In this example, therefore, the trace length is governed by the hangingwall cell of the upper layer, since this cell has the shortest faulted face (Fig 4d).

The trace width is defined as the minimum value of the XY projection of the distance between the centre of the faulted cell face and the centre of the cell, measured in each layer in the model in the cells on both sides of the trace. The width of this trace is therefore controlled by the footwall cell of the lowest layer, since this cell is narrowest (Fig 4d). The reason for using minimum distances in the definitions of trace length and width is so that fault zone components, which are defined geometrically by length and width terms, can always be contained on the trace they are assigned to. This is discussed further in the section on Fault zone properties.

Trace Average throw

The aveThrow value of a trace is the summation of the system throw and the user-defined throw and can take either positive or negative values depending on whether the cell closer to the origin is on the footwall or hangingwall side of the fault. In the example shown above (Fig 4), the cells closer to the origin are on the footwall side, and the throw of the trace is negative. Fault throws can be different in a particular layer at each end of the trace (defining a horizontal displacement gradient), and can also vary between different layers in the model (if vertical displacement gradients are present). For each trace an average value is calculated. This is a simple average of the values of each end of the trace in each layer. Note that if, as in this example, certain layers are unfaulted, these will still be included in the averaging.

In certain instances system traces describing complex geometries are assigned throws of zero. These are if the trace is a scissor fault (i.e. the sense of throw is different at the two coord lines as shown in Fig 5a) or if the sense of throw changes over the height of the trace (as shown in Fig 5b).

Introduction to Fault zones

A fault zone is a new kind of TransGen (version 3.2) object associated with traces. Each trace in a model may have a single fault zone associated with it, but a fault zone has no meaning except with reference to a trace. Fault zones allow inclusion in the simulation model of the transmissibilities associated with locally paired slip surfaces which may have very different juxtapositions to the single slip surface present on the trace in the parent model.

Fig 6 shows an example for a simple 5 layer model. Fig 6a shows the cells in the cell stacks adjacent to the fault trace in the parent model. A fault zone (in this case, a breached relay ramp) is attached to the trace, defining the high resolution paired slip surface geometry illustrated in Fig 6b. The new functionality associated with fault zones constructs the high resolution geometry and calculates the transmissibilities of all possible flow routes between every pair of cells in the model. These are then output at the resolution of the parent model (Fig 6a).

In this example the parent model does not contain a connection between the second layer in the footwall stack and the top layer in the hangingwall stack. In the high resolution model there are 6 possible flow paths between these two cells. These are:-

TransGen calculates the transmissibility associated with each of these flow paths and outputs the combined transmissibility at the resolution of the parent model (in this example using the NNC keyword, since the connection in question does not exist in the parent model.)

Note that vertical non-neighbour connections can also be produced by fault zones. In this example the relay ramp in the uppermost layer provides a connection between the top layer and third layer in the hangingwall cell stack. Transmissibilities associated with vertical non-neighbour connections are also calculated and output.

Exactly the same procedures are used to calculate across-fault transmissibilities associated with fault zones as are used in the rest of TransGen, i.e. the same FSP and fault rock permeability and thickness calculations defined in the PERM and THICK plugins used elsewhere in the model are repeated in the Fault Zone calculations. Certain restrictions on usage in the PERM and THICK plugins arising from the new functionality are discussed under Implications of the new functionality in the section on C++ functionality in DRAG & FZONE plugins.

Fault zone properties

Fault zones can be attached to traces by:

Placing them manually using the TGFZONE keyword (see Including data when using the new Fault Trace and Fault Zone functionality).

Placing them stochastically using the WizGen tool (using Assign hierarchical zones on the Hierarchical fault zone definition page).

Placing them according to user-defined criteria using the FZONE plugin.

In addition to the location of the trace containing the fault zone, a set of eight properties need to be set for each zone (as shown in the Table below). Between them, these give a full definition of the geometry of the zone.

Fault zone dimensions

Figure 7 (below) demonstrates the construction of the fault zone components for dipping cells with orthogonal plan- view geometries. The length (LT) of the trace is the minimum plan-view distance parallel to the fault between cell corners, and the width (WT) is the minimum plan- view distance at the cell edges perpendicular to the trace (i.e. the minimum of W1A, W1B, W2A, and W2B. (Fig 7a). The ramp dimensions are defined by a length (LR) and width (WR ) which are also distances in the XY plane: a dipping ramp is therefore longer than LR (Fig 7b).

A fault zone component in a particular model layer is composed of five elements; two parent cells, two stub cells and one ramp (Fig 7b). The two stubs and the ramp are of a constant plan-view width WR. The ramp is placed in the centre of the trace, and is of plan-view length LR. Stub A always forms an unfaulted connection with Cell 1, and stub B with Cell 2 (Fig b). The Stubs have no dip component perpendicular to the trace, and their depths at the two edges of the model are equivalent to the depths of the parent cells at the ends of the trace. The dip of the Stubs parallel to the trace is equal to the plunge of the trace. This ensures that, although Cells 1 and 2 (Fig 7b) are narrower than the parent cells (Fig 7a), displacements DA, DB, DC, and DD (Fig. 7c) are identical to those at equivalent positions in the parent model (Fig 7a).

Throws on the zone-bounding faults

The depths of the eight corners of each layer in the ramp are defined by the four ratios r1, r2, r3 and r4. These are described with reference to the four fault displacements d1, d2, d3 and d4 indicated on Fig 7c. As discussed above, the displacements at each end of the ramp (DC and DD, Fig 7c) are calculated from the geometry of the parent cells. The four ramp displacements are then given by:-

d1 = r1 DC
d2 = (1-r2) DC
d3 = (1-r3) DD
d4 = r4 DD

Fault zones are constructed so the same ratios (r1, r2, r3, r4) generate a ramp with the same geometry irrespective of the direction of the trace (`DIR_X' or `DIR_Y') or the sense of displacement on the fault, i.e. whether or not the cell stack closer to the origin is on the upthrown (a negative sense of throw) or a downthrown (a positive sense of throw) side of the fault. These four cases are shown in Fig. 9, using r1 = 0.7, r2 = 0.8, r3 = 0.3 and r4 = 0.2.

Fault zone permeabilities

The properties of the Stub cells are inherited from the parent cells, i.e. Stub A has the identical properties to Cell 1, and Stub B has identical properties to Cell 2 (Fig 7d). All properties with the exception of the two horizontal permeabilities in the ramp are the arithmetic average of the two cells. The permeability in the ramp perpendicular to the trace (KperpA) is given by the harmonic average of the two cell permeabilities (Kperp1 and Kperp2), multiplied by the fault zone variable damage_perp, while the permeability in the ramp parallel to the trace (KparaA) is given by the arithmetic average of the two cell permeabilities (Kpara1 and Kpara2), multiplied by the fault zone variable damage_para. These two variables can therefore be used to include effects on permeability of minor faults in the ramp.

Plausible and Implausible fault zone geometries

The ratios r1, r2, r3 and r4 can be used to define ramps with both plausible and implausible geometries. Examples of each are shown in Figures10 and 11.

In general, the following inequalities must be satisfied for a ramp to have a plausible geometry:-
r4 >= 0.0
r4 <= r3 <= r2
r4 <= r1 <= r2
r2 <= 1.0

The relationship between r3 and r1 is flexible - provided r4 is the smallest value present, and r2 is the largest value present, r1 and r3 can take any values to give a valid geometry. If r1=r2 and r3=r4 all the ramp dip is parallel to the trace (i.e. a relay-ramp geometry fig 10b), if r1=r4 and r2=r3 all the ramp dip is perpendicular to the trace (i.e. a lens, fig 10c), and anything in between gives rotations in both directions (Figs 10d & e).

If a fault zone is included with an implausible geometry using the TGFZONE keyword, ViewGen will issue a warning, but since it is conceivable that the implausible geometry is intentional, the fault zones will be processed in exactly the same way as ones with plausible geometries.

The examples shown in Figures 7 to 11 are for models with vertical faults and vertical coord lines. Faults zones, however, are constructed in the same way for more complex 3D model. Figure 12, for example, shows an unbreached relay on a more complex trace. The ramp is of constant length through the thickness of the model, but the length of the trace in this example is defined by the lowest cells in the model. Hence the stub cells are shorter in layer 5 than in layer 1. The internal checking in TransGen ensures that, irrespective of input, a ramp is contained within the trace to which it is assigned.

Traces and Fault zones

Introduction to Traces

Fig 1. Example of a fault trace

Fig 2. Example of a User-defined model derived from the parent model

Fig 3. A second example of a user-defined model derived from the parent model in Fig 1.