Rubis is a game-changing, data-centric, bottom-up, history-matching (HM) tool. Snappy title it is not. Snappy and important tool it is. The decision to build Rubis came from looking closely at the way today’s engineers were working, the massive but often disjointed and under-used data available, the restrictions on time and budget and the demand to still describe the reservoir, define the reserves, optimize and forecast the production, and still seek opportunities… every working day.

Managing a reservoir is not an academic exercise, it is brutally commercial so, at the core of the build philosophy is the premise that if a simple solution solves the problem, as it very often does, then use it. If the problem has greater complexity make the tools intuitive, get them to talk to one another to build the problem, and hence approach the solution, incrementally and using all data evidence available. And, as you are going to need this thing on a daily basis, have it fast and flexible enough to adapt to changing evidence. A simple single well field could, potentially, be managed with an old-fashioned single decline curve. If it works, so be it! But as fields deplete, interfere, change PI and generally misbehave we are being presented with disjointed data that form the pieces of a jigsaw puzzle. The evidence of misbehavior is always real and is in the data and this needs to be incorporated quickly into the model and acted upon. There is no point building a huge, clever static model that is not influencing our daily engineering decisions. The data is there, we ‘just’ need a way of synchronizing and correlating it, a kind of model by proxy.

In v4.12, one can directly import a reservoir geometry from GRDECLTM and CMGTM files. Gas desorption for unconventional gas (coalbed methane and shale gas) has been added. It is also possible to extract a sector of a Rubis model and then send it to Saphir where it can be run in full 3D, 3-Phase with gravity.

Rubis evolved from the numerical heart of Topaze, a product where Production Analysis (PA) was greatly enhanced in turn by using modern Pressure Transient Analysis (PTA) tools. PA and PTA have their limits particularly in the 3D, multiphase environment and Rubis provides the next simple, logical step.

As a result KAPPA has chosen to be diametrically opposed to the development of the next generation of simulators which can handle billions of cells with massive parallel processing, with results that are often generated too late to be useful in any case. The objective is to match the production data, as often, and as quickly and simply as possible by modular integration, using the pieces of the jigsaw puzzle from the different methodologies. It is a tool that sits somewhere between single cell material balance and massive simulation models, it replaces neither but does much of the work of both.

It is now possible to build simple 3-phase, 3D numerical models, intuitively with no special training. The focus is on interactively building the field as it looks and then the grid builds automatically inside this. The engineer can then concentrate on the problem, keep it updated and not worry about how to construct the tool itself.

Last but not least the final consideration was economic. Rubis has been built as incremental and integral to the existing Ecrin suite and that is good news for the managers who hold the purse strings.

The Voronoi numerical model is at the heart of the Ecrin suite and this is covered in some detail on the analysis of dynamic data page. As this model is common to PTA, PA and History Matching (HM) the process in building is identical up to the point of departure into 3D. The model is built interactively and the grid forms automatically and with the minimum number of cells. As the model in Rubis needs to be more flexible to accurately account for elements such as gravity, phase contacts, and layering the option taken was the vertical Cartesian accumulation of 2D unstructured layered grids with local 3D refinement when demanded by the well geometry. In the simplest cases, the Rubis grid could therefore be exactly the same as in Saphir, with the exception of very near the wellbore where it could afford to be less refined.

A happy consequence of this compatibility between the PTA and the simulation grids is that we can jump between the build-up and the production data on a grid that differs only at the wellbore. Another plus is that the transient analysis refined grid, already calibrated by its coherence with the analytical models, can be (and is) used in turn to calibrate the well index of the coarse grid. This is exploited in v4.12 with the new Rubis Sectors facility.

Rubis carries no legacy technology and as such does not use keywords. All actions are interactive and it has no compatibility whatsoever with any grid of any simulator in the industry. However, Rubis will read geometry files such as GRDECL, PVT, vertical lift from Amethyste (WPA) and other ASCII files to define the physical problem, but the compatibility stops when the grid starts.

The fluid can be characterized with Black-Oil or modified Black-Oil models. The Rs and rs relations are turned internally into a composition ratio, providing the grounds for a compositional formulation. Internal correlations can be used and tuned to match measured values or, alternatively, tables can be loaded.

The build is identical to that of Saphir and Topaze and indeed may start from a drag-drop from another Ecrin module. For Rubis the number of layers is defined and the layer horizons and/or thicknesses assigned. Any one of those properties can be entered as a constant or as a data set, in which case Rubis will use spatial interpolation (Kriging) to build the final geometry. Then wells are, in turn, created, positioned and perforated in the reservoir. Vertical cross-sections can be viewed and moved interactively while building the wells.

The physical representation of the reservoir is split into petrophysical properties such as the permeability and porosity. Then the initial state is defined including contacts, initial pressure, saturation pressure versus depth and KrPc, these three groups forming a property subset. Any such subset can be redefined where a zone is either a layer, a region drawn in the 2D map, or the intersection of layers and regions. Inner faults can be represented as leaky, ie: barriers to flow, or conductive faults with infinite or finite conductivity. Non-Darcy flow is available, as well as double porosity and areal and/or vertical permeability anisotropy. Each segment of the reservoir boundary can be set individually to sealing, constant pressure, or connected to an aquifer. Classical water influx models and a numerical aquifer are available.

A well in Rubis may be either vertical, vertical with a hydraulic fracture, horizontal in a given layer ie: following the horizon of that layer, or slanted. Any number of perforations can be created and their opening/closing time defined individually. Each perforation may have a discrete Skin which may be constant, rate dependent or time dependent. Because a wellbore model can be coupled with options including classical empirical, mechanistic and drift flux models, the well definition is not limited to its actual path in the reservoir. It is therefore possible, although not essential, to define the complete well trajectory from surface.

Real well pressure and rate data can be loaded and edited. This, in turn, may be used in the well controls that are defined by entering a sequence of targets and constraint couples. An abandonment rate may be specified for each well.

After the grid has been built, the user can override the default time range, solver settings, list of output results and frequency of the simulation restarts. Simulation restarts are used to run animations of the simulation and restart the process after an interruption or change of the input problem. ‘Initialize’ then creates the relevant output plots, the pressure and saturation fields, and calibrates the individual well cells. The ‘simulate’ option executes the simulation, which at any time can be paused. Rubis either finishes the current time step or, if interrupted, immediately stops and returns to the previous time step. During the simulation, the lower message window displays information on the process, while all relevant plots are updated.

Individual well production and pressures, together with reservoir statistical information, are displayed on a dedicated vs. time plot and updated in real time during the simulation. In playback mode, a vertical line highlights the active replay time. Static fields such as permeability or porosity and dynamic fields, such as pressures and saturations, can be displayed in 3D or 2D with vertical, horizontal or cross-section truncation.

A simulated production log, per well, showing the contribution by phase and zone is generated and time stepped in playback mode. All data, input and stored, is organized in a hierarchical data browser. Any number of runs can be stored in a given session to enable what-ifs to be run. The browser can be used to dragdrop components between runs or between other Ecrin modules. In particular, numerical analyses made in Saphir or Topaze can be copied to Rubis by a single drag-anddrop. There is extensive user control over the viewing and output choice.

New in v4.12; a sector of a Rubis full field model can be exported and used in Saphir. This enables Saphir to simulate complex three-phase flow processes with gravity. The key element of this new integration step between the Ecrin modules is that the model is not simplified upon its transfer from the full-scale simulator model in Rubis to the PTA module Saphir. The full-scale simulation model is simply stored in Saphir and re-simulated from there. This approach is possible because the full-scale Rubis model contains, by design, the ability to simulate, accurately and precisely, transient flow responses due to the well upscaling feature. In short all Ecrin modules are calling the same numerical kernel, just with different settings.

New in v4.12; as in Saphir NL and Topaze NL, a desorption model is now available in Rubis to address issues related to shale gas and coalbed methane.

We often get asked this so let us finish with a few words on something with which most will probably never be concerned. <deep breath> Rubis is finite difference (finite volume to be rigorous). The interface of Rubis uses black oil PVT however a compositional formulation is actually implemented in the kernel. The solution method, and the modeling of fluid flow along the wellbore is fully implicit. The Rubis kernel is object-oriented and integrated in the application architecture. No hidden batch file is launched when the user clicks on simulate. <phew!>