In the Shell Group, we have developed a state-of-the-art data managementsystem for the storage of resource (field, reservoir, etc.) related data. It iscalled RISRES (Reservoir Information System - REServoir module). First releasedin 1993, it is currently in operational use in eight Shell Group operatingcompanies around the globe. This article describes the specification andconstruction process, as well as various aspects of the system which make it apowerful resource data management system.
The ability to store, retrieve and share data relating to oil and gasreservoirs is critical to their efficient management. Inordinate amounts oftime are often spent collecting, verifying, storing, sharing, re-collecting andre-verifying data for the purposes of studies, analyses and reports.
RISRES is a state-of-the-art resource data management system which wasdeveloped to meet this challenge by addressing a set of business requirementsdescribed below. Features which make it state-of-the-art include:
- extensibility to store any data
- unambiguous versioning and time-stamping
- flexible definition of subsurface and reporting structures
- ability to store data in any form from numbers to document files
- auditing and security features
- transparent interfacing to applications.
These features, and others which position RISRES as a general resource datamanagement system both inside and outside the Shell Group, are discussed insome detail below.
Although it clearly satisfied the stated business requirements, introductionof RISRES to the majority of the Shell Group led to considerable initialresistance in the user community. These experiences are discussed, and theresulting set of data-organization and interfacing concepts, in particularclose integration with Shell Group petroleum engineering applications, are alsodescribed.
The data explosion has resulted in the need to handle ever-increasingquantities of data for life-cycle management of petroleum resources. In thelate 1980s it was observed that just the gathering and validation of data forreservoir-related studies occupied a significant fraction of each study'sresources, and that data gathering or analysis would often have to be repeatedbecause previous study data and results would get "lost".
One area of particular concern at this time was resource volumes. Companiesin the Shell Group were working with a combination of legacy systems andspreadsheets. The "old technology" legacy systems were generallyinflexible to the evolving requirements of resource classification and wereoften seen as a "black hole" into which data disappeared, never to beseen again. These problems tended to be addressed by the use of mainframe andPC based spreadsheets, or other "quick fixes", to fill in the gaps notcovered by the legacy systems, in some cases replacing them altogether.However, these spreadsheets and files were usually in disparate andundocumented locations on hard disks around the company offices, generallyincluded little or no validation, and often contained hidden errors. In short,they represented an inappropriately fragile audit trail for the main assets ofthe companies: their hydrocarbon resource volumes.
The Shell Group lacked a database to hold gathered, validated and processeddata, including hydrocarbon volumes, applicable at a resource level (i.e.fields, reservoirs, blocks, etc.). This led to the establishment of theReservoir Information Systems (RIS) project in 1990.
Advances of the "information age" have made vast quantities of technical information available through electronic media. Technical problem solving often involves transfer and handling of large blocks of data. For many, an impediment to successful technical data application is not data availability, but data accessibility. An electronically searchable database system was designed to allow access to proprietary environ- mental data by a large number of users located world-wide. Users are linked and data is transferred system-wide via Internet connections. This scheme also provides users with links to an immense and steadily growing number of external information servers.
This paper presents a step-wise approach to establishing a working database system. Included are system design criteria such as types of data desired and number and location of users, data collection techniques, and software applications for data organization. A description of data search engines and search scripts follows, with a discussion of appropriate hardware platforms for data storage and access. Remote data access from many locations via the Internet is discussed. In some cases it is necessary to restrict access to proprietary information. This database system has the capability to keep separate public and proprietary information. The paper addresses data security issues such as access restriction using software and hardware, technology exportation, and the necessity for technology licensing among co-owners.
Databases are "collections of data arranged for ease and speed of retrieval, as by computers." Computers generally handle the "ease and speed of retrieval" aspects of databases. Data arrangement, however, can have much to do with how easily and quickly data retrieval proceeds. Data distribution after retrieval is another important consideration of database design.
Any collection of data can be arranged in a database. Once data are collected, a variety of commercial software is available to aid in organizing data in a (usually) tabular format. Commercial software suitable for this purpose may be either database or spreadsheet applications. Making data retrievable, or "searchable," follows. Commercially available search software can be applied to many database and spreadsheet formats. A means of distributing data among users is then necessary.
A currently very popular means of data, and information in general, distribution is the Internet. More than 40 million worldwide users exist, and the number is steadily increasing. These users access information through more than 5 million hosts, on 45,000 networks, in 159 countries. This vast network of computers, the Internet, grows at about ten percent to fIfteen percent per month. Currently something in excess of twenty terabytes (twenty million megabytes) of information is transferred per month via the Internet.
Such a tremendous amount of information would be very unwieldy were it not for a group of software applications and sets of information transfer protocols and conventions. One such group, known as a client/server environment, is the Worldwide Web (WWW) The WWW is based on hyptext and hypermedia technology and allows "point and click" access to most of the Internet's resources. WWW server software is commercially available for most hardware and operating systems, including UNIX, Macintosh, and DOS/Windows. Use of readily available client/server products thus allows virtually unlimited information transfer without regard to numbers of users or their locations.
Planning and Data Collection
It is usually advantageous to carefully consider how a data-base will be used before data collection begins. In general, any data that can be arranged in tabular format can be searched and transferred by methods described herein.
In developing mission-critical, real-time applications, the authors have found historical testing methods to be inadequate for personal computers (PC's). A major problem is the myth of "PC compatibility"; i.e. the notion that all PC's are interchangeable and function independently of the software. The authors propose that the interactions between PC hardware and software are extensive and complex, and require that system specification and testing be modified to include integrated hardware/software testing.
One of the primary reasons for the widespread use of the personal computer in commercial applications has been the openness of the system, allowing many competing vendors to develop hardware and software components. This competition has produced surprisingly rapid advances in computer technology and in system capabilities. However, the main goal of application developers continues to be producing applications that are usable, reliable and cost-effective, both to develop and to support. The historical approach to application development has included independently specifying and testing the hardware and software components of the system. This has proven to be inadequate for mission-critical PC applications, due in large part to the fact that modern PC's are high-performance machines containing an array of specialized components. The open architecture of the PC, compared to the previous closed (proprietary) designs, creates the situation where each of these hardware and software components can come from multiple, independent sources, resulting in a neverending stream of possible combinations. The differences between PC's and the complex interactions between the software and various hardware components requires that specification and test procedures be modified to include rigorous testing of all hardware/software combinations. In addition, due to the continuing evolution and changes in PC hardware and in software development tools, these test procedures must continue in some form throughout the product's life cycle. This paper describes the authors' experience in developing and distributing PC-based applications, emphasizing practical solutions and anticipated future improvements.
Impact of the Compatibility Problem
The industry relies on personal computers to provide data acquisition, increases in personal productivity, and assistance with data analysis. We are increasingly dependent on these devices and their associated software. We have all been faced with mixed emotions when upgrading our personal computers to either new operating systems, new hardware or both. We welcome the prospects of an analysis taking 20 to 50% less time and in some cases doing things not possible at all a few years ago without massive investments in workstations, mainframes and specialized training. However, will our old applications still function in a predictable manner? Will we spend weeks on the phone in non productive time in an attempt to contact a living and knowledgeable technical support staff member or be relegated to a combination of voice and fax back hell? If the personal computer industry can build a device that operates 2500 percent faster than the original IBM PC, why can't all my applications still work? Sadly, the true answer is that computers do provide the desired benefits only after a start up learning curve. The game, therefore, becomes an effort to reduce this learning curve to a minimum, searching for the quickest answer to the question "The hardware has changed again; does everything still work?".
This paper describes the modeling, development, and implementation of a database for multiphase flow data from a large-scale research laboratory.
The outdoor laboratory facilities include a total of 1000 m pipe connected to fluid processing utilities, liquid pumps, and a 700 kW gas compressor operating at system pressures up to 90 bar. Normally, approximately 100 physical and virtual instruments are used, and at the moment more than 400000 measurements have been logged, processed, and stored in the database. The database communicates with systems for data acquisition and analysis, and researchers can access data from their workstations.
The database is implemented in a relational database management system (RDBMS) with SQL interface. Before the implementation of a database can start, it is important to develop a data model which represents the selected part of the real world in a way that satisfies the system requirements. The different aspects of the data model are treated thoroughly and include (1) experiment, (2) geometry, (3) instruments, (4) measurements, (5) fluids and fluid composition, and (6) project related data.
Entity-Relationship diagrams of the model are presented and explained. Timeseries are stored in the database using a specially developed C function. Other functionality is handled by database triggers and procedures stored in the database itself (written in a procedural extension to SQL), and UNIX shell scripts. Problems and advantages of data redundancy and reuse are discussed, as well as the need to avoid destroying the "history" in the database. The communication with the systems for data acquisition, analysis, and presentation is described.
During the past 10 years, thousands of large-scale two-phase experiments have been performed at the SINTEF Multiphase Flow Laboratory at Tiller near Trondheim in Norway.
Experiments have been performed in different pipe configurations; inclinations varying from -1 to +90 , diameters ranging from 0.1 m to 0.29 m, and at system pressures up to 90 bar. The laboratory has been operated with various hydrocarbon liquids such as diesel, lube oil, and naphtha, whereas nitrogen is used as gas phase.
The outdoor laboratory facilities include a total of 1000 m pipe connected to fluid processing utilities, liquid pumps, and a 700 kW gas compressor operating at system pressures up to 90 bar. The laboratory is performing advanced multiphase flow experiments for the oil and gas industry at near realistic field conditions, and the results are used in the development of pipeline transportation simulation software.
Experimental work with extensive instrumentation creates large amounts of data, often with a complex internal structure. When such experiments are carried out for many years, the need for a reliable database system with good performance is obvious. At the SINTEF Multiphase Flow Laboratory, the results were stored in an older database which lacked the required functionality and was expensive and time consuming to maintain. To utilize the advantages of a modem database system, a new database model was developed and implemented, together with necessary utility programs. A concern has also been the ability to store field data, and the possibility to retrieve the relevant input information necessary to run pipeline simulation software.
Normally about 100 physical and virtual instruments are used in an experiment, and at the moment more than 400000 measurements have been logged, processed, and stored in the database.
This paper describes the design of FLEX, an object-oriented, flexible grid, black-oil reservoir simulator helps in dealing with the complexity of this problem. This approach is particularly useful because of the difficulties associated with generation and use of flexible grid geometries (like Voronoi, median, boundary adapting grids, etc.).
The entire problem is divided into subsystems like geometry, gridnodes, gridnode connectivity, grid, reservoir fluid flow, and matrix. Each of these subsystems have objects which are closely related. The dependency of these subsystems is established. A detailed analysis of each subsystem leads to identifying the classes, which are a set of objects having similar behavior. Attributes and behavior of the classes are assigned. After establishing relationships between the classes, they are arranged into hierarchies. About one hundred major classes have been identified and designed to achieve the desired behavior from FLEX. The programming language used is C++.
Reservoir simulators are inherently complex. A simulator has to deal with issues such as reservoir and grid geometry, fluids, flow calculation, matrix computations, several well and production constraints, visualization, etc. The most important feature of FLEX, a black oil simulator, is its ability to handle complexities arising from flexible grids. Verma and Aziz (1996) give a description of flexible grids in reservoir simulation. The flexibility in grids increases geometrical complexities as well as complexities in flow calculation. These complexities need sophisticated data structures (and associated procedures) to simplify the problem. It is expected that FLEX will change with time to incorporate new features. One of the important considerations in designing the simulator is the ease with which the simulator can be expected to handle new problems. All these factors combined to make the development process of FLEX quite complex. This paper describes the advantages of using an object-oriented approach for the development of reservoir simulators. The philosophy followed in designing FLEX is that advocated by Booch (1994) and Cheriton (1995).
Basic Features of FLEX
FLEX solves flow equations based on the control volume formulation (see Verma and Aziz, 1996). It uses the Newton-Raphson method to iteratively solve for the variables. A connection-based approach is employed to form the Jacobian matrix and the residual vector (see Lim, Shiozer and Aziz, 1995 and Verma and Aziz, 1996). Presently the simulator is developed to handle only two immiscible phases.
The gridnodes can be located so that they represent reservoir geometry, wells, faults, etc. Figure 1 is an example of the flexible grid generation capabilities of FLEX.
An object-oriented approach was followed in the design of FLEX to handle the complexities associated with a flexible grid simulator, and to provide for future enhancements.
The existence of multiple processors on a network or a parallel machine enables sets of reservoir simulations to be performed. It is then possible to build up a model of the reservoir as a response surface. This can be a function of input variables related to symbols in the user's data definition. Controlling these variables by a master program and using experimental design methods in a series of runs we can model the behavior of the simulation. This would then predict its response to further engineering requests. Sequential designs are particularly relevant when a bank of available processors exists. Once the basic number of runs required to parameterize the reservoir response functions have been performed. additional simulations may be used to obtain error bars on quantities such as recoverable oil.
Once the response surface exists, both automatic optimization and large scale risk analysis predictions may be performed at high speed.
This approach combines well with multiple realization geological modeling. Running a number of geologies enables the error involved in the simulation of a given engineering scenario to be quantified - this can be used to predict the uncertainty on all the predictions of the study.
By monitoring the results of the simulations interactively, and measuring the quality of the history match obtained with each, it is possible to condition subsequent runs - for example by reducing the use of realizations which consistently yield poor matches.
We describe software to perform such multiple realization studies, acting as an interactive supervisor through a simple open PVM (parallel virtual machine) interface to a reservoir simulator.
Current reservoir simulation is addressing the problem of uncertainty. Errors in the basic description of the reservoir may be estimated by comparing more than one geostatistically generated realization of the rock property distribution. Performing a number of simulations gives us the possibility of assessing the errors involved in a study. We need a system for converting a number of runs using different geologies into an assessment of the risks involved in management and economic terms. Further, as we wish to engineer the field into the future, we wish to understand the response of the reservoir to factors which are under the engineer's control.
A way of doing this is to set up a parameterisation of the reservoir response. To investigate this we clearly need to perform a number of simulations - these may be regarded as numerical experiments. The choice of the set of variables which define these runs constitutes the experimental design. It is possible to use any sufficient set and extract some information. However, the following are clearly desirable:
This paper presents a new parallel ILU preconditioner. It is based on the technique of Sequential Staging of Tasks (SST) which overcomes the difficulty of recursiveness arising from ILU factorization. This new parallel ILU preconditioner is easy to reconstruct from the sequential version. The only requirement is to insert the synchronization codes of stages of tasks into the sequential version, and any other modifications to the original serial codes are not needed. The characteristic of matching various ordering schemes is still maintained, and the new merit of handling different numbers of processors is obtained. Numerical results were obtained using a thermal model with different grid system. The parallel speedup is satisfactory.
Simulation of thermal recovery processes using a fully implicit treatment of component concentrations, phase saturations, pressure and temperature requires solution of large systems of linear equations. Currently, the most robust techniques for solving this large system of linear equations are preconditioned conjugate gradient like methods such as ORTHOMIN which is widely used in traditional solvers for sequential computers.
The major computation of ORTHOMIN is vector inner product and is easy to be paralleled. However, the most robust preconditioners such as ILU factorization and nested factorization are not suitable for parallel computer because of their intrinsical recursiveness. It is difficult to parallel ILU preconditioner directly. At present, the general methods to parallel preconditioners are the use of new preconditioning methods such as parallel nested factorization preconditioning. These new preconditioning methods have high parallel efficiency in parallel computers, but also have limitations:
1. limited types of ordering schemes;
2. comprehensive modifications of the sequential codes;
3. slow convergence.
This paper presents a new parallel ILU preconditioner based on the technique of Sequential Staging of Tasks (SST). Using the SST technique, the new preconditioner exploits the small scale parallelism of ILU factorizations, and achieves a temporal, larger scale parallelism within certain computing domain, consequently obtains an applicable parallel preconditioner. The new parallel preconditioner maintains all the characteristics of the sequential version, and is easy to reconstruct from the sequential version. The new preconditioner is applicable to computers with different number of processors. The numerical experiments show that the parallel speedup is satisfactory. On an NP 1/52 Mini-Supercomputer System (produced by GOULD Co. in 1989, shared main memory, symmetrical operation system UTX/32) with two processors, the parallel speedup is 1.85.
Consider the linear system,
As a preconditioner of ORTHOMIN, ILU factorization provides a matrix M, a "good" approximation to coefficient matrix A and easy to factor, convergence may be accelerated by solving the equivalent system,
Such preconditionings should offset the added cost of factoring M and performing a forward and back solution with each matrix-vector multiplication by reducing the number of iterations substantially.
Main stages of ILU factorization are as follow:
1. A symbolic factorization, defining the non-zero structure of the incomplete factorization.
For k=l, NB Do
2. Inverting the main elements
The Problem: Automatic Downloading of Data
PanCanadian is in the process of migrating from mainframe based systems and databases to personal computers and network servers. The process has been underway for about four years now, and it will probably be at least as long again until all the mainframe systems have been replaced. Though data is increasingly available within the client server environment, much of the key data is still resides on the old mainframe. PanCanadian's in-house Information Systems group is primarily focused on the new client server workplace, and responsibilities for the mainframe systems have been out-sourced. Though the now out-dated mainframe reports continue to be available, these hard copy paper stacks are the only way that some of this data can be directly accessed.
The Solution: Spreadsheet Parsing of Mainframe Print Buffers
When a mainframe report is run a buffer file is created before the report is actually printed. This buffer file can be manually captured and file transferred from the mainframe environment to the PC workplace. In those instances where the report parameters are set sufficiently broad, the printed report represents an echo of the mainframe database -- albeit in text form. The captured file usually contains the line printer feed codes as well as job and page header information. To access this information within a spreadsheet or database application the text must be cleaned up and parsed into columns. Though Excel contains parsing or 'text to columns' commands, these are not sufficiently robust to handle most of the mainframe report formats encountered. To facilitate conversion of the text reports into spreadsheet format a general purpose parsing spreadsheet was developed.
The Opportunity: Direct Business Access to Data on a PC
Once mainframe data is in spreadsheet or database format it can be readily accessed and manipulated. Data can be cross correlated to yield additional information and identify patterns and dependencies not evident in the raw data alone. The business can use this information to measure performance and establish targets for improvement.
To evaluate the results of 1994 deep gas drilling within a district, data had to be brought together from a number of mainframe systems (Financial, Production and Reserves) as well as a server based completions database. A financial report was first used as the basis for identifying wells drilled as part of each project within the district. The report was converted from a purely text file into a spreadsheet file which honored the report layout, through use of the parsing spreadsheet. The spreadsheet file was then converted from a report layout into a database layout by means of some simple Excel look-up and index functions. A list of wells drilled was then extracted by project, and Authorization For Expenditure (AFE) descriptions were converted into well locations. Look-up and index functions were then used to link production data back to this well list. Subsequent data correlation (not illustrated) was then used to link completions costs and reserves data. Charts are shown for drilling outcome both by program type as well as by area. Completion success has been charted for those horizons identified at casing point as well as for subsequent completion attempts.
In this paper, we present a new approach to software development for solving engineering problems. The paper presents the possible solutions to the problems that we encounter during the development of engineering software where we incorporate different techniques and tools such as a database, case base, knowledge base, expert help, on-line help, multiple-applications, and guidance board/map. The paper also discusses the reusability of code that is derived for a different application. Finally, the paper illustrates how we use this approach to develop a comprehensive software system.
The paper concludes that engineering software must be versatile in nature. The software should be a working tool for industry experts and experienced engineers. The software should also be a training and learning tool for young and inexperienced engineers.
Petroleum engineers use software everyday to solve engineering problems. The petroleum industry invests substantial manpower and financial support to develop these engineering tools. During software development, several challenges are faced by the developer. These challenges include (1) offering appropriate technical help to users so that comprehensive data stets can be developed, (2) guiding the user to arrive at correct decisions and choices using proper engineering domain knowledge, expertise, and experience, (3) providing ample guidelines for the proper use of the software, (4) offering automatic data transfer mechanisms among different models, and (5) providing sufficient help and support to satisfy the different needs and requirements of the users. Developing software to address these challenges can increase engineering work efficiency and reduce software training and support costs.
The paper describes our approach to software development based upon our experience in developing a comprehensive system for the design of reservoir stimulation treatments. We have successfully addressed the five (5) challenges listed above. We conclude that although different technologies are used to solve different problems, they can all be integrated in a single package that contains engineering help, data transfer, and expert decision making mechanisms. In our software, we have used Artificial Intelligence technology to build knowledge bases that can help engineers make correct decisions. We have integrated the knowledge bases with sophisticated numerical simulators for the purpose of modeling well stimulation treatments. At the same time, the software provides easy avenues for the users to build comprehensive data sets with the use of databases, case bases, and built-in work sheets.
A design criterion is developed to select the optimum bottomhole rotary assembly configuration (drill collar size and stabilizer positions). This allows maximum correction in the hole inclination by changing the weight on the bit while drilling a section of a hole. A computer algorithm is written in FORTRAN code to optimize the bottomhole assembly configuration. This algorithm can be used with any BHA model that calculates forces at the bit under static or dynamic conditions. A case study is presented to explain the design algorithm.
Directional wells are usually kicked off from vertical by some type of bent sub/bent housing and downhole motor. When the hole inclination becomes sufficiently high, drilling may resume with a steerable system or a rotating system.
In conventional rotary systems a packed-hole assembly uses a sufficient number of stabilizers so that no significant change in hole angle occurs. Likewise, proper stabilizer positioning can increase the hole angle via the fulcrum principle, or it can decrease via the pendulum principle (1985). Conventional rotary systems are normally designed to drill holes with a constant rate of change of inclination. However, discrepancies between prediction and field results frequently occur. Therefore, experience and knowledge are necessary tools in the selection of such a drilling system.
Steerable systems are widely used in drilling horizontal and extended reach wells. This is mainly because, drilling direction can be changed in a more controllable way to follow a predetermined trajectory without the need of changing the assembly. The bottomhole configuration of steerable systems, however, creates major torque and drag problems while drilling highly deviated wells in the sliding mode. It becomes difficult to have even torque distribution on the bit which is essential to control tool-face. High drag can limits the ability of maintenance of a constant weight on the bit. This reduces penetration rate and makes it hard to control tool-face as the reaction torque at the bit varies. Furthermore, drag can limit the total horizontal displacement.