Including Drag/Hierarchical Fault Zones

Including the new TransGen version 3.2 functionality to model user-defined and stochastically generated fault zone structure and to include the effects of these sub-resolution geometrical fault characteristics in the flow simulator inflences the ViewGen workflow. These revisions to the ViewGen workflow are illustrated below in the form of ViewGen messages printed to screen for a model using most of the new functionality (highlighted in red).

Reading the include data

Steps 1 to 22 are unchanged. Once the coord (Step 7) and zcorn (step 8) keywords have been read, the geometry of the parent model is constructed and any problems with cell geometries are reported.

Steps 24 to 27 are associated with the four new TransGen keywords (added to the TGDATA run file via the Included Data page of WizGen in Flexible project mode) allowing input, on a trace by trace basis, of:-

• User-defined fault throws which are later added to existing throws on system traces or used to create user-defined traces (TGTHROW)


• Fault throw multipliers which operate on system or user-defined traces (TGDRAG)


• User-defined fault zones (TGFZONE)


• Up to 10 user-defined trace properties (TGTRACE).

As each of the files included for these new keywords is read, various error checking is performed.

If the format of the keyword is incorrect, a fatal error will be written and the run will stop. These can take a variety of forms, e.g.

**** ERROR ****
CORRUPT DIRECTION STRING FOR KEYWORD TGFZONE (SHOULD BE 'DIR_X' OR 'DIR_Y')

Other conditions that can generate fatal errors are definition of a trace that lies outside the model region, e.g.

**** ERROR ****
TRACE 123 12 DIR_X LIES OUTSIDE THE GRID DIMENSIONS IN KEYWORD TGTHROW

Warnings are issued if the same trace is referred to twice, e.g.

**** WARNING **** DUPLICATION OF INPUT IN KEYWORD TGDRAG - SEE TGPRT FILE
! Drag definition for trace 2 1 DIR_X duplicated - most recent value used

Duplications are treated differently in the various files. For duplications in the TGTHROW keyword, the throws associated with each instance of the trace are added together. This is because it is plausible that two different sub-resolution faults might be aliased onto the same trace during discretisation. For duplications in the other three keywords, the la st instance of the keyword replaces earlier ones.

Warnings are also issued in conjunction with implausible fault zone definitions in the TGFZONE file, e.g.

**** WARNING ****
SOME USER-DEFINED FAULT ZONES HAVE IMPLAUSIBLE GEOMETRIES IN KEYWORD TGFZONE - SEE TGPRT FILE
! User-defined fault zone 3 1 DIR_X has an implausible geometry.
! It does not satisfy r4 >= 0.0, r4 <= r3 <= r2, r4 <= r1 <= r2 and r2 <= 1.0

Plausible and implausible values of r1, r2, r3 and r4 are discussed elsewhere (see Plausible and Implausible fault zone geometries).

Reading the remaining instructions and the plugins

Steps 28 to 39 process the remaining settings specified in WizGen. Steps 37 and 38 (READING TGDRAGACTION and READING TGFZONEACTION) refer to the two new WizGen pages which define methods for applying automatically fault drag and fault zones on each trace in the model (see Drag applied to fault traces page and/or Hierarchical fault zone definition page in WizGen).

Alternatively, and allowing much more flexibility, user-defined drag and fault zone plugins can be used to model these properties. These new plugins are read by the system at the same place as the other existing plugins (Step 34) - see DRAG & FZONE plugins.

Provided a plugin has been "built" in the WizGen plugin editor, there should be no problems at this stage. However an incorrectly written plugin which has not been checked in WizGen and, for example, refers to a non-existent trace property, will generate a C++ error message and will cause ViewGen to quit.

Processing the Parent model and applying the new Keywords

Steps 40 to 43 are unchanged. All faulted connections in the model are identified (Step 40), and the unfaulted transmissibilities of each connection is calculated (Step 43). These unfaulted transmissibilities are identical to those calculated by the flow simulator, and are therefore those on which the transmissibility multipliers calculated by TransGen will operate.

Identifying System traces

Construction of system (or explicit) traces occurs next (Step 44). System traces are identified and assigned throw values. A trace is recognised provided that:-

(a) at least one layer has a fault offset across the trace, and
(b) at least one cell from each cell stack adjacent to the trace is active, and
(c) All cells in both cell stacks have valid geometries.

If condition (c) is not satisfied, ViewGen issues a warning:-

**** WARNING **** SOME EXPLICIT TRACES COULD NOT BE CREATED - SEE TGPRT FILE
! Unable to create trace 12 14 DIR_Y because of cell geometry

Processing user-defined traces

The list of user-defined traces included in the TGTHROW file are then combined with the list of explicit traces identified in the previous step.
If a user-defined trace overlies an explicit trace a warning is issued, and the throw value from the user-defined trace is added to that of the explicit trace.

**** WARNING ****
SOME USER-DEFINED TRACES COINCIDE WITH EXPLICIT TRACES - SEE TGPRT FILE
! user-defined trace '4 1 DIR_X' overlies an explicit trace: throws will be combined

Trace length and width calculations

The lengths and widths of each (system or user-defined) trace are calculated using the definitions outlined in the section on Trace Length and Width.

Placing fault zones

Next, fault zone defined in the TGFZONE file are placed on fault traces, using exactly the same process for explicit and user-defined traces. If a fault zone has been defined on a non-existent trace, a warning is issued and the fault zone is ignored:-

**** WARNING ****
SOME FAULT ZONES CANNOT BE ASSIGNED, MATCHING TRACES NOT FOUND - SEE TGPRT FILE
! fault zone 5 1 DIR_X ignored (no matching trace)

Running the DRAG and FZONE plugins

The DRAG plugin is called once per trace in the model, and is designed to calculate drag ratios following user-defined instructions. Following this, the FZONE plugin is called once per trace, and is designed to assign fault zones to traces that match user-defined criteria, and to calculate the geometry and properties of these zones.

The plugins are called for both user-defined traces and system traces, and, although not recommended, it is also possible to assign discrete values of throw (i.e. equivalent to the TGTHROW keyword) to traces in these plugins. It is, however, impossible to define a user-defined trace in the plugins since the plugins are not called for traces that don t exist. User-defined trace properties can also be calculated in the plugins.

Note that even if user-defined DRAG and FZONE plugins are not specified, they may still be created and run, since the WizGen drag and fault zone tools write their instructions to system-defined plugins.

Checking the fault zones dimensions

A fault zone cannot be longer than 95% of the length of the trace it is applied to, and cannot be wider than 95% of the trace width. In this step, the dimensions of all fault zones (included using TGFZONE or calculated in the FZONE plugin) are truncated to these limits if they are too large, and an warning is issued if this is the case:-

**** WARNING ****
SOME FAULT ZONES HAVE INAPPROPRIATE LENGTH OR WIDTH - SEE TGPRT FILE
! fault zone 2 1 DIR_X too large
! corrected dimensions are length (reset to 28.5) width (reset to 19)

Processing the faulted connections in the parent model

Steps 53 to 64 are unchanged since the previous version of TransGen, and concern the parent model with no geometrical modifications. Hence the faulted transmissibilities and transmissibility multipliers calculated in steps 62 and 64 are identical to those that would have been calculated if none of the new functionality were included. Note that these are the values visualised in the main ViewGen window.

Making a coherent geometrical model

All the traces with user-defined throw values (i.e. assigned in TGTRACE or - not recommended - set in the DRAG or FZONE plugin) are processed in Step 64, to produce a coherent geometrical model in which

(a) corner-point depths are modified only on traces for which a user-defined throw is specified, and
(b) fault throws change smoothly between fault traces.

These requirements imply that it is generally impossible to honour precisely the user-defined throws specified. For example, consider the following diagram of 4 cells. If no faults are explicitly defined in the grid at this locations, the four depths (za, zb, zc and zd) are equal to each other.

If the following two user-defined traces are included:-

TGTHROW
I1 J1  DIR_Y  3.0 /
I1 J2  DIR_Y  4.0 /
/

This implies different throw values across traces T2 and T3, which, if applied directly, would mean that depths za and zb are lowered by 1.5 and 2m respectively, while depths zd and zc are raised by these amounts. This would introduce offsets on traces T1 and T4 but no user-defined throws are specified on these traces. Hence all user-defined throw data are processed simultaneously to avoid this kind of introduction of unwanted fault offsets, while at the same time providing a coherent fault system with finite fault displacement gradients. A graphical example is shown in the description of the TGTHROW keyword.

A similar procedure is associated with the fault drag ratios. In this case, however, the coherent geometrical model is three-dimensional since the drag ratio can be applied to system traces as well as user-defined ones, and layers on system traces (unlike on user-defined traces) can have throws that vary vertically in the model.

Processing modified traces

Each trace which has been modified in any way by the new functionality is processed in turn. The entire workflow used to calculate faulted transmissibilities (steps 53 to 62) is repeated for each trace, using exactly the same FSP measures and connection plugins.
NOTE:- This part of the workflow can take a significant time to run, particularly for model with a significant number of modified traces (e.g. ones with Drag assigned to each trace using the WizGen tool). The progress of the run is reported to the screen (Steps 66 to 85).

ViewGen constructs so-called "minimodels" for each trace. In the case of a trace which doesn't contain a fault zone, a single minimodel is built reflecting the juxtapositions across the trace arising from the modifications to the throw on the trace.

In the case of a trace containing a fault zone, 8 minimodels are constructed, and the transmissibilities (including fault rock effects if appropriate) associated with each are calculated. These 8 minimodels are shown schematically in 2D below.

The objectives are to combine the transmissibilities associated with the minimodels into a list of transmissibilities of possible flow paths that exist in the parent model, i.e. between cells in the two stacks. This is done through the following steps:

• Step A: Combine transmissibilities from Model 3 and Model 7 to give transmissibilities from Stack 1 to ramp


• For all Stack1 to Stub1 connections:


For all Stub1 to ramp with the same Stub1 layer:Z_value:

Transmissibility = 1/(1/(trans1)+1/(trans2))
• Step B: Add these to the results from Model 1 (which are also values of connection transmissibility from Stack1 to Ramp). If a model 1 transmissibility and a Step A transmissibility are for the same connection (i.e. same pair of z-values in stack 1 and ramp), add them together to give a single value.


• Step C: Combine transmissibilities from Model 6 and Model 8 to give transmissibilites from Stack 2 to Ramp. Same procedure as Step A.


• Step D: Add these to the results from Model 2. Same procedure as Step B.


• Step E: Combine transmissibilities from Model 3 and Model 5 to give a list of transmissibilities from Stack 1 cells to Stack 2 cells.


• Step F: Combine transmissibilities from Model 4 and Model 6 to give more transmissibilities from Stack 1 to Stack 2. Add these to the list produced in Step E (i.e. add this transmissibility value to the Step E transmissibility value if they are for the same connection, or add an item to the list if they are for a connection that doesn't exist in Step E).


• Step G: Combine the stack 1 to ramp transmissibilities (i.e. the composite list from steps A and B) with the Stack 2 to Ramp transmissibilities(i.e. the composite list from Steps C and D) to give more transmissibilities from Stack 1 to Stack 2 - add these to the list generated in Step F (again, the new transmissibility values can either be added to an existing value if the connection already exists in the list, or can defined a new item in the list if not). This gives a complete list of transmissibilities for all possible stack 1 cells to stack 2 cells.


• Step H: Process the Stack1 to Ramp transmissibility list to derive a new list of stack1 to stack1 transmissibilities. NB vertical neighbour connections are ignored (i.e. connections that would be included in the simulator using TRANZ).


• Step I: Process the stack2 to ramp transmissibility list to derive a new list of stack2 to stack2 transmissibilities.

The result of these calculations are three lists associated with this fault zone:

• List 1. Connection trans missibilities from cells in Stack 1 to cells in stack 2.


• List 2. Connection transmissibilities from cells in stack 1 to other (non-neighbour) cells in stack 1.


• List 3. Connection transmissibilities from cells in stack 2 to other (non-neighbour) cells in stack 2.

For a trace without a fault zone, only list 1 is generated.

Preparing the output files

Once all modified traces have been processed, the results are merged into the output files (Step 86). Across fault connections (List 1), are compared with unfaulted transmissibilities calculated in the parent model (i.e. in step 43) and are assigned as follows:

• If a non-neighbour connection appears in both lists: calculate the multiplier and output as EDITNNC.


• If a neighbour connection appears in both lists: output the fault zone transmissibility using TRANX or TRANY.


• If a non- neighbour connection exists with an unfaulted transmissibility, but no fault- zone one, set EDITNNC = 0 for this connection.


• If a neighbour connection exists with an unfaulted transmissibility, but no fault- zone one, set TRANX or TRANY = 0 for this connection.


• If a non- neighbour connection exists in the fault zone list, but not the unfaulted transmissibility list, output the fault zone transmissibility using NNC.


• If a neighbour connection exists in the fault zone list but not the unfaulted transmissibility list, output the fault zone transmissibility using TRANX or TRANY.

Lists 2 and 3 contain only vertical non- neighbour connections that do not exist in the parent model. The faulted transmissibilities of these connections are therefore output for inclusion in the simulator using the NNC keyword. Note that the same vertical non-neighbour connection can arise from fault traces on different edges of the same cell. The transmissibilities associated with these are summed in the final output.

Writing the Output files

Files for connection variables are output in Steps 87 and 94 to 100. Of these possible output files (specified in the Output - derived and user-defined properties WizGen page) only the UFTRANS, FTRANS and TRMULT files have been modified to reflect the new functionality (see Changes to Connection property output in 3.2 release). All other files, including the FSP output, reflect the contents of the parent models.
A new set of five output files (steps 88 to 92) for fault trace properties (i.e. TGTRACE, TGDRAG, TGTHROW, TGFZONE and/or TGXTRACE) can also be defined on this WizGen page (see Derived Trace properties).

The modifications made to the output files for input into the Eclipse simulator model (Steps 101 - 104) are described in the section on Keyword Descriptions for EDITNNC, TRANX, TRANY and NNC.

Graphics

Additional graphics functionality for fault traces are available via the ViewGen Edit menu (see Show traces and Sub-resolution display options).