Académique Documents
Professionnel Documents
Culture Documents
Abstract
Data from a wide variety of sources are required for reservoir
simulation. Simulation itself produces large quantities of data.
Yet, good data management practices for reservoir simulation
data are typically neither well-understood nor widely
investigated. This paper presents a specific architecture to
manage reservoir simulation data, discusses experiences from
six years of global use, explains adjustments to support
changing workflows and outlines challenges that lie ahead.
The architecture consists of a Database Management System
(DBMS) and files in managed file directories, called Reservoir
Input Output System (RIOS). All simulation input data and
results are maintained by a Data Management System (DMS).
The reservoir simulator reads input files written from the
DBMS to RIOS and writes results to files in RIOS. DBMS,
RIOS and integrated management tools (DMS) make up the
data management environment.
The environment has been in use inside ExxonMobil since late
2000 and now supports close to 500 users (85% of reservoir
engineers). There are over 30 individual databases containing
2TB of online data and about 6TB of online RIOS data. The
environment itself introduces some additional work. Support
staff is required for maintenance of databases, RIOS areas and
problem resolution. Direct user manipulation of data is not
permitted and additional tools are required to access and
interpret data.
The environment provides many benefits. While it insures
data integrity, security and consistency, it also automatically
updates defaults, limits, associations, types, etc. This allows
running of older simulations and generation of aggregate
statistics and usage audit trails.
SPE 106075
connections.
Example facilities are wells, platforms,
separators, terminals and the pipelines that connect them. All
facilities have attributes and constraints that describe them and
their behavior. For example, all facilities have a name and
active state and all wells have a rate or pressure limit.
A key feature distinguishing ExxonMobils current reservoir
simulation system from its predecessors is its use of an
extended surface facility network model that is fully integrated
with the reservoir. This key feature contributes greatly to the
complexity of the data model. All facilities in the network are
directly accessible and can be manipulated by the reservoir
engineer for maximum flexibility. In addition, users can add
their own attributes and procedures to a given facility type.
This capability is extremely important. Assume, for instance,
that the reservoir engineer wants to model submersible pumps
in a way that the current simulator version does not support.
The needed variables and functionality can be added to the
well facility type by the engineer and made a part of the
timestep calculation. This flexibility is very powerful and
allows rapid prototyping of new functionality.
Well Management Logic
Facilities are the most dynamic part of reservoir simulation.
In EMpower, they are managed at runtime with user defined
logic called Well Management Logic. This is part of the input
data but it is such a distinctive concept that it deserves a more
detailed description. The timeline of a reservoir simulation is
usually divided into two segments. The first is history
matching while the second is prediction. During history
matching, the goal is to design a model that will match
historical rates and pressures. During prediction, reservoir
engineers want to experiment with various scenarios in order
to approximate a good production profile for the field. For
instance, the engineer wants to test if it is sufficient to reduce
high GOR wells and increase production of low GOR wells in
order to maintain a given oil-production plateau while keeping
the fields gas production in check, or whether it is necessary
to work-over some wells. While it is theoretically possible to
hard-code scenarios like this, it is impossible to pre-conceive
every possible strategy a reservoir engineer might want to try.
Allowing the engineer to define such strategies using a
programming environment greatly enhances the flexibility and
utility of a reservoir simulator while complicating the data
management environment.
Data Management System
In EMpower, the DMS is the central work environment for the
simulation engineer. It is the single point of entry for
preparing, running and analyzing simulations and therefore, it
has several distinguishing characteristics and requirements.
First, it is data driven; all dialogs work from data definitions.
Some can display the three data types (arrays, granules and
facility network data) without knowledge of actual data
content. Second, user access is controlled by login and data
access is controlled by user, group and world permissions. It
is possible to completely hide projects, models and cases from
other users and it is also possible to setup a project, model or
case for use by a specific group of users. Third, the DMS
SPE 106075
Data Mining
Potentially the greatest benefit of managing reservoir
simulation data, though, is the capability for data mining. The
amount of data generated for and by simulation is significant.
It is not easy to analyze results just for one study, let alone
across many. However, with well-defined data management,
automated tools can scan and analyze data areas to generate
overall statistics and trends; this capability is known as data
mining. Data mining enables quick overview of just what
kind of models are being worked on as well as providing
insight into the type of problems users run into, etc. This
improves quality control and opens the door to a self learning
system.
Architecture of the Data Management Environment
The simulation environment has been implemented as a
heterogeneous,
distributed,
three-tier,
client-server
architecture. The DMS is the client software at end user
workstation. All reservoir simulation data are stored in the
second tier consisting of a database and file directories in a
mass storage area called RIOS. The simulator running on
different compute servers is the third component and
represents the server side.
Figure 3 summarizes this
architecture.
SPE 106075
SPE 106075
RIOS
The RIOS concept was developed to enable sharing of data
between the DMS and the simulator, as the simulator was
designed to be independent of the database. Every case has a
RIOS directory with a unique name. The database case
objects know about their RIOS directories. Every RIOS area
is associated with a specific business unit. Access can be
controlled in a fashion similar to database permissions with
system level owner, group and world permissions. It is
possible to completely hide a certain RIOS area by allowing
only a specific group ownership and access to it. RIOS areas
can be network accessible or local. When local, unless public
access is granted explicitly by the user, the RIOS is only
accessible by local simulation jobs.
A RIOS directory contains two types of files: (1) a collection
of files that contain input, restart and results data and (2) a set
of log files that store per timestep runtime information and
user requested output generated by well management logic.
Input, Restart and Results Files
As explained earlier, before launching a simulation, the DMS
generates an input file for the simulator with all the input
granule, array and facility network data in the case RIOS
directory. As the simulator is running, it appends its complete
state information to this file at the restart times requested by
the user, or the user may request a set of restart data be written
on demand at any point during the run. The simulator also
writes specified arrays, granules and facility data to the results
file at user requested times. These results can be monitored
while the simulator is running.
The input/restart and results files are self-referencing files;
they can refer to data within the same file or file A can refer to
data in file B or vice versa. They can be ASCII or binary and
are completely portable. The format and structure of these
files have been developed in-house over many years and are
proprietary.
Log Files
The log files record timestepping information, convergence
parameters, well performance data and information on
problem nodes. The presentation of log file data is extremely
sophisticated with a web style interface that displays highly
detailed tables, charts and graphs. The power of this interface
is further enhanced with its ability to present user messages
written from well management logic in these formats as well.
A screenshot of this tool is presented in Figure 4.
When a case is run, the DMS deletes any existing RIOS files
first. When a case is restarted, all RIOS files are truncated to
restart time. The DMS accesses results arrays, granules and
facility data from RIOS files directly.
Figure 5: The Front-End is the main entry point for
users to the data management environment. It presents
the filtered project/model/case hierarchy, the data items
for the current case, and ability to manage the data items
for both input and results.
Archiving
One of the crucial tools available in DMS is the archiving
capability. Models, which are self-contained, can be archived
with or without their RIOS data to a selected destination, such
as a LAN drive, a DVD drive or a local disk. The archive file
is in XML format and is therefore completely device and
application independent. This data can eventually be migrated
to off-line storage. The model can be deleted from the
database as well as the associated RIOS data to free up disk
space. This process is crucial because it guarantees problemfree access to data even years later, regardless of version of
the DMS, database schema or VAR, by applying all relevant
changes necessary to upgrade the data at the time of restore.
Deployment and Usage
The data management environment was first released in late
2000 along with the deployment of ExxonMobils EMpower
reservoir simulator. It has been in use inside ExxonMobil
since then and now supports close to 500 users. There are 32
individual databases containing 2TB of online data and about
6TB of online RIOS data corresponding to about 5,000
models. The environment has been successfully deployed in
eight countries on five continents outside the United States
including Europe, Asia, Australia, Africa and South America.
The system has gone through three major, five minor and three
patch releases. Not including the simulator, there are
approximately nine million lines of software code (with six
million lines of 3rd party vendor code and over half a million
lines of database related code) and 25,000 files (18,000 of
which are 3rd party vendor source code files).
SPE 106075
SPE 106075
Database Migration
The biggest data challenge came when business drivers
demanded change of the database vendor. This was a big
undertaking, especially since object databases are not
standardized like relational databases and the code was not
developed with a distinct, database independent data access
layer. However, the design was adequate and a distinct
separation of database transactions from other code is in place.
This huge effort was brought to a successful completion and
also ushered in the XML archiving scheme, which enabled
archive and restore of models independent of database vendor,
with backward compatibility. Upgrading older data schema
models to new data schema using archive/restore turned out to
be a natural extension.
Today, the database provides a secure and consistent
repository that works in a collaborative environment.
However, it is an ongoing project that requires continuous
improvement to support increasing data and flexibility
requirements.
User Perspective
Users of the reservoir simulator are as varied as the simulation
data. There are engineers who are new to the company and
who are trying to use reservoir simulation for the first time;
there are experienced engineers who use simulation only now
and then; there are geoscientists who do studies of different
dimensions and then there are the experienced, hard core, day
to day users who know the simulation process inside and out.
It is not possible to meet all the desires of this diverse set of
users when building a system. Less experienced users prefer
rigidly defined workflows that rely heavily on graphical user
interfaces, while more experienced users find the graphical
user interface limiting and want to do their own analysis using
tools like SAS, Excel and MatLab. The data management
environment, initially designed to be all encompassing and
self-contained, is now asked to be more open. Some progress
has been made to this end. Many functions of the DMS can
now be driven from scripts and a new API is being made
available for accessing input and results/restart data. Further
developments are in progress to connect the DMS with other
applications using Windows Workflows.
Database/RIOS as Integral Part of Work
One of the most visible results of the data management
environment is awareness of database and RIOS usage by both
users and administrators. Consolidation of all relevant
simulation data to these areas has clearly brought to light the
quantity and nature of data that has to be managed. Disk
space for both database and RIOS areas is cost allocated to
business units; therefore, there is a constant check for overuse.
Users must always be aware or are reminded when they fill up
the database or RIOS.
Help System
One of the least talked about but most appreciated components
of the DMS is the online help system based on Microsoft
HTMLHelp.
All functionality within DMS is clearly
documented and explained. For many users, this is their first
point of support. The help system is context sensitive and
SPE 106075
until
and
The
been
Acknowledgments
The authors wish to acknowledge B.L. Beckner, B.A. Boyett,
T.K. Eccles, J.D. Hindmon and C.J. Jett for their valuable
assistance to this paper. The authors also acknowledge the
management of ExxonMobil Upstream Research Company for
permission to publish this paper.
Windows is a registered trademark of Microsoft Corporation
in the United States and other countries.
References
1. Huang, A.Y. and Ziauddin, Z.: Use of Computer
Graphics in Large-Scale Reservoir Simulation, SPE
20343, presented at the 5th Petroleum Computer
Conference of the Society of Petroleum Engineers,
Denver, Colorado, June 25-28, 1990, 145-150.
2. Kreule, T., Good, P.A., Hoff, A.H.F.B. and Maunder,
R.E.: RISRES A State-Of-The-Art Hydrocarbon
SPE 106075