Reservoir modeling has undergone a revolution in the last decade or so. Like all revolutions, it has had a long and difficult birth, with technical experts railing against the shortcomings of the existing methodologies, but unable to agree on the way forward. Breakthrough was achieved when modeling tools became available that allowed routine work to be conducted by field development teams rather than by experts from the research lab. Commercial pressure ensured the subsequent rapid development of software around the concept of the common, or shared, earth model. But like all revolutions, its progression is by no means homogenous. Some problems have had less widespread exposure than others. In some cases, such as automatic history matching, this may be due to the relative immaturity of the underlying science, but in others the reasons are to be found in lack of integration. Fracture modeling is an example of this second type.


Integration is critical to the development of a new reservoir modeling methodology. Before a method can be accepted as routine it is necessary that it fits comfortably with the usual workflow of the subsurface team. So if building a fracture model necessitates using several different software packages this will tend to discourage adoption of the methodology. There is good reason for this resistance. First, we have the inevitable data transfer problems. This sort of problem can range from the relatively benign formats issue, where some code needs to be written to change data formats used by one package into that used by another, to the more serious problem of data incommensurability. As an example of this second type of problem, discrete fracture network models (DFN), such as that shown in Figure 1, are often built in software that makes simplified assumptions about the reservoir structure and modeling grid. If these assumptions differ from those used in the main common earth model software, then it may be difficult, or even impossible, to transfer discrete fractures from one grid to the other such that fracture connectivity, dips and orientations are retained correctly. What may look like a good model in the specialist fracture modeling software becomes a poor representation in the earth model. Second, the extra complexity added to the workflow along with the potential lack of robustness tends to preclude non-specialists from participating in the model build. If the experts come from outside the subsurface team then this can cause some difficulties down the line when the model needs updating. Since fracture properties are often more uncertain than other types of heterogeneity we might expect more regular model reviews and/or an attempt to bracket uncertainty by building several scenarios. As such it is better that the model rests in the control of the subsurface team.

If software is to be useful in such an endeavor, then it must satisfy some criteria:

• It should work within the same structural framework as the main earth modeling software; It should have a well defined, straightforward workflow;
• It should be possible to produce a simple model quickly but be able to generate more complex models when needed;
• It should be able to condition to relevant input data including well data, geomechanical data, seismic data and well test permeability;
• It should be able to produce the parameters needed for flow simulation in a geologically meaningful way.

Roxar is currently developing software to meet these challenges. The software, which is currently implemented using the powerful RMSOpen toolkit, is now undergoing testing on a project for a major client. RMSOpen is a powerful way of extending the capabilities of the 3-D modeling system RMS by allowing external code access to most of the data in an RMS project in a controlled manner. The external code may make some calculations based on the RMS data and write the results back to RMS. This approach may be used for simple calculations through to large development projects such as the fracture development described here.


To model a fractured reservoir it is necessary to answer several questions. Which fractures need to be modeled? How are these fractures distributed spatially? How do we represent the fractures on an integrated 3-D modeling grid? How do we assign properties such as porosity and permeability to the fractures? How do we assign the matrix-fracture interaction term, or sigma factors, that are needed in flow simulation? The software invites the user to answer these questions offering a natural workflow through the modeling process.

Structural geology

The first two questions are the province of the structural geologist. At this point it is necessary to decide on the genesis of the fractures. The geologist does this by grouping the fractures into sets based on a common structural interpretation. For each set, it is necessary to make some hypothesis about the likely orientation and density fluctuations of that set in the reservoir. The structural geologist may speculate that these are indicative of a strike slip regime associated with an episode of faulting observed in the reservoir. It may be appropriate to try and estimate the fracture density and orientation trends in the reservoir by making a geomechanical model of the paleostress distribution associated with the observed faults. Such a model is shown in Figure 2, where the color represents the value of principle stress and the arrows indicate the most likely orientation of fracturing based on an application of the Mohr-Coulomb law. The stress models may, therefore, be used by application of the Mohr-Coulomb law to create fracture density and orientation trends for this fracture set. For other fracture sets it may be appropriate to use some other method to predict fracture trends. For example, extensional fractures associated with folding may be better predicted by curvature analysis.

The software provides the users with several tools to allow them to generate trends that are appropriate to the fracture sets that are to be modeled. This includes a distance to fault parameter, curvature calculation and a simple elastic stress model calculation. Any other trend may be used, whether generated within RMS or imported into RMS from some external source.

Fracture permeability

The number of fractures within a reservoir is often so large that it is impractical to model all of them with the memory resources of modern computers. On the other hand it is not usually necessary to hold all the fractures in memory at once. For some calculations, such as the matrix-fracture exchange, it is enough to have a local model of the fractures. For this reason the model works on a "generate on demand" approach, with fractures only being generated in a region when needed for calculation or inspection. For permeability calibration it is enough to get a measure of the capacity of the fracture model in each cell. In essence this capacity acts as a counter for the number of fractures and their orientations within a cell of the flow model. Because it depends on direction, this capacity is a tensor. The software does this by generating very many fractures but only storing the associated capacity. The capacity is then calibrated to well test permeability if sufficient data is available. Otherwise, a predictive model of permeability may be made by assigning apertures to the fracture sets. Indeed, it is not always necessary to explicitly model the fractures. As a rapid first pass model, or as a definitive model when the matrix fracture fluid exchange process is fast, it is possible to account for the effect of fractures as a permeability modifier alone. In these circumstances the software allows the fracture density trend model to be used as a proxy for capacity and it is calibrated directly to well test.

Matrix-to-fracture exchange

In classic dual porosity simulators the flow is considered to take place in the fractures only with the matrix acting as a supply of hydrocarbon to the fracture. This exchange is modeled in most flow simulators using a "shape factor" for each simulation cell. In Roxar's software, a number of shape factors are calculated within each simulator cell. In simulators that are capable of handling more than one shape factor per cell, such as the More simulator, this extra resolution may be carried to the simulation. The advantage of this can be seen in Figure 3 where the fracture pattern in two geological layers that end up in the same simulator layer are shown. The histogram of shape factors shows that the different layers have different shape factor responses. This allows the imbibition process to be modeled better within each simulator cell. Of course, if needed the software can calculate a single upscaled shape factor for conventional dual porosity simulators that only use one shape factor.

So what's different?

In many ways, the fracture modeling process is similar to modeling other forms of heterogeneity. Trends are produced and the heterogeneity is modeled to follow those trends. Permeability is assigned, if possible by calibration to well test. One difference for fracture modeling is the calculation of the shape factor. Another, more significant difference is that the levels of uncertainty are higher in fracture modeling. To feel comfortable with the model it is important to have the ability to play with the various parameters to help get an understanding of the uncertainty. For this it is essential that the fracture modeling tool is simple, fast and fully consistent with the 3-D reservoir modeling tool used.