Petroleum Experts RESOLVE - .::FANARCO::. • Index page · CHAPTER 1 – INTRODUCTION PETROLEUM...

Petroleum Experts

RESOLVE

October, 2003

USER GUIDE

The information in this document is subject to change as major improvements and/or amendments to the program are generated. When necessary, Petroleum Experts will issue the proper documentation. The software described in this manual is furnished under a licence agreement. The software may be used or copied only in accordance with the terms of the agreement. It is against the law to copy the software on any medium except as specifically allowed in the license agreement. No part of this documentation may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or information storage and retrieval systems for any purpose other than the purchaser's personal use, unless express written consent has been given by Petroleum Experts Limited. All names of companies, wells, persons or products contained in this documentation are part of a fictitious scenario or scenarios and are used solely to document the use of a Petroleum Experts product. Address: Registered Office: Petroleum Experts Limited Petroleum Experts Limited Spectrum House Spectrum House 2 Powderhall Road 2 Powderhall Road Edinburgh, Scotland Edinburgh, Scotland EH7 4GB EH7 4GB Tel: (44 131) 474 7030 Fax: (44 131) 474 7031 Email: [email protected] Internet: www.petroleumexperts.com

1 - 3 TABLE OF CONTENTS

1 Introduction ....................................................................................................................................................1 1.1 Contacting Petroleum Experts ...............................................................................................................1 1.2 System requirements.............................................................................................................................2 1.3 Overview of RESOLVE..........................................................................................................................2

2 Methodology ..............................................................................................................................................1 2.1 How RESOLVE Works ..........................................................................................................................1

2.1.1 Step 1: Load and query application case......................................................................................1 2.1.2 Step 2: Connect individual sources and sinks from client applications .........................................1 2.1.3 Step 3: Create a schedule ............................................................................................................1 2.1.4 Step 4: Run the simulation............................................................................................................2

2.2 Application Architecture.........................................................................................................................3 2.3 Driver Registration.................................................................................................................................4 2.4 Connection Rules ..................................................................................................................................5 2.5 Composition Tables...............................................................................................................................7

3 Step by Step Guide....................................................................................................................................1 3.1 Getting started - step by step example ..................................................................................................1

3.1.1 Step 1 - Initialise new case ...........................................................................................................2 3.1.2 Step 2 - Load the Reveal case......................................................................................................3 3.1.3 Step 3 - Load the GAP case .........................................................................................................3 3.1.4 Step 4 - Make the connections between the cases.......................................................................4 3.1.5 Step 5 - Configure the cases ........................................................................................................6 3.1.6 Step 6 - Enter the schedule ..........................................................................................................6 3.1.7 Step 7 - Run the simulation...........................................................................................................7 3.1.8 Step 8 - Extracting and viewing the results ...................................................................................7

4 Menu Commands.......................................................................................................................................1 4.1 Overview................................................................................................................................................1

4.1.1 Menu: File .....................................................................................................................................1 4.1.2 Menu: Options ..............................................................................................................................2 4.1.3 Menu: System...............................................................................................................................3 4.1.4 Connection Wizard........................................................................................................................4 4.1.5 System Properties.........................................................................................................................5 4.1.6 Menu: Module ...............................................................................................................................7 4.1.7 Menu: Schedule............................................................................................................................7 4.1.8 Timestep control ...........................................................................................................................8 4.1.9 Scripting control ............................................................................................................................9 4.1.10 Menu: Run ..................................................................................................................................11 4.1.11 Menu: Results .............................................................................................................................12 4.1.12 Menu: View .................................................................................................................................12

PETROLEUM EXPERTS LTD

TABLE OF CONTENTS 2 - 3

Appendix A Sample Files..............................................................................................1 A1 Sample Files..........................................................................................................................................1

Appendix B..............................................................................................................................................................1 B1 Distributed Applications .........................................................................................................................1

Appendix C Hysys Link ................................................................................................1 C1 Use of the Hysys Driver .........................................................................................................................1 C2 Setting up a case in Hysys ....................................................................................................................2 C3 Loading and Editing a Case ..................................................................................................................3 C4 Other Functions .....................................................................................................................................3

Appendix D GAP Link...................................................................................................1 D1 Driver Configuration...............................................................................................................................1 D2 Loading and editing a case....................................................................................................................1 D3 Other functions ......................................................................................................................................2 D4 Setting up a case in GAP ......................................................................................................................2

Appendix E REVEAL Link.............................................................................................1 E1 Driver Configuration...............................................................................................................................1 E2 Loading and Editing a Case ..................................................................................................................1 E3 Other Functions .....................................................................................................................................2 E4 Setting up a case in Reveal ...................................................................................................................2

Appendix F Developer Instructions for Resolve ...............................................................................................1 F1 Template code.......................................................................................................................................1 F2 Startup ...................................................................................................................................................1 F3 Build and register the stub code ............................................................................................................1 F4 Notes on the driver code .......................................................................................................................2 F5 Data flow................................................................................................................................................2

SEPTEMBER 2003 RESOLVE MANUAL

3 - 3 TABLE OF CONTENTS


F6 Driver Source Code ...............................................................................................................................2 F6.1 DriverStub.cpp / DriverStub.h............................................................................................................3 F6.2 ExtShared.h ......................................................................................................................................3 F6.3 ExtDllEntry.cpp..................................................................................................................................3 F6.4 ExtInterface.h ....................................................................................................................................3 F6.5 ExtModel.cpp / ExtModel.h................................................................................................................3 F6.6 RVLRegistry.cpp / RVLRegistry.h .....................................................................................................3

F7 Conclusion.............................................................................................................................................3

RESOLVE

1 Introduction Chapter 1: Overview of RESOLVE Chapter 2: System requirements - hardware and software requirements Chapter 3: Getting started - basic commands and step-by-step example Chapter 4: Menu commands - dropdown menu commands Appendix A: Sample files - description of sample files supplied with installation Appendix B: Distributed Applications Appendix C: Hysys Link Appendix D: GAP Link Appendix E: REVEAL Link

1.1 Contacting Petroleum Experts We encourage feedback and if you have problems or questions using RESOLVE, please send an e-mail to [email protected] with the following information.

1 Include the keyword 'RESOLVE' in the e-mail subject. 2 RESOLVE version and build number - use the menu option Help|About RESOLVE... to

obtain this information.

3 Description of the problem or question.

4 Include a REVEAL archive (*.rvl) file where possible. Check that this file is not too large (>2MB). If it is large, then run the simulation for one timestep and save the file, this will eliminate potentially large quantities of graphical output data.

CHAPTER 1 – INTRODUCTION

PETROLEUM EXPERTS LTD 2 - 2

1.2 System requirements RESOLVE supports all Windows-certified drivers that are shipped with Windows. The list of devices, software and hardware supported by Windows is included with the documentation of your copy of Windows. Hardware and software requirements - minimum requirements recommended for RESOLVE. Pentium II class PC (Windows 95, 98, NT or 2000) 500 MHz processor (1GHz recommended) 256 Mbytes of memory (1Gbytes recommended) 5 Gbyte hard disc space for temporary files 1280 by 1024 minimum display size with high colour (16 bit) resolution CD drive if the software is installed from a CD Licenses - RESOLVE can be run using a single user (stand-alone) license or on a network. In either case, a special security key is needed. The security key is called Bitlock for stand-alone licenses, and Hardlock for network licenses. The security key is provided by Petroleum Experts. For a stand-alone license, the security key (Bitlock) must be attached to the parallel port of the PC. For a network installation, the security hey (Hardlock) can be attached to any PC communicating with the network. You should refer to the separate installation procedure for a network Hardlock sent with the purchase of a Hardlock license.

1.3 Overview of RESOLVE RESOLVE is the sixth member of Petroleum Experts Integrated Production Management (IPM) suite of software. RESOLVE is a tool to allow connectivity between arbitrary Petroleum Engineering packages.With RESOLVE the user can: - load and query cases of client applications - connect corresponding sources and sinks from client applications using the graphical

interface - perform optimised or non-optimised runs with connected applications - implement condition-based scheduling of events

RESOLVE is essentially a high-level framework that allows engineering data to be passed between applications. The data that is passed is fixed and should be general for all potential client applications: see the methodology section for more information. RESOLVE is built around an 'application-driver' scheme that allows users with specific connectivity requirements to build their own connections. See the architecture section for more information. RESOLVE runs on a PC (Windows 95, 98, 2000, NT) with a single interface to all functionality.

RESOLVE

2 Methodology

2.1 How RESOLVE Works This section describes briefly the steps that are used to make connections between separate applications.

2.1.1 Step 1: Load and query application case When a case of a client application is loaded into RESOLVE, RESOLVE will create a slave instance of that application and will load the case (which may be a single file) into the application. RESOLVE will then query the case for its sources and sinks - these are the inputs and outputs from the system. In the case of GAP, for example, the sinks in the system are production wells and injection manifolds, whereas the sources are injection wells and separators. In simulators, wells can be sources or sinks depending on whether they are production or injection wells. As far as RESOLVE is concerned, the application is a black-box calculator that has inputs and outputs according to the sources and sinks it exposes. For details as to what sources and sinks are exposed by an application, see the help file for the individual driver in question.

2.1.2 Step 2: Connect individual sources and sinks from client applications

Before connections are made the individual cases have to be modeled satisfactorily in their separate applications. Once they are loaded into RESOLVE, equivalent sources and sinks can be connected together graphically. For example, wells in a REVEAL (reservoir simulator) model can be connected to their equivalent wells in GAP (surface network analysis package).

2.1.3 Step 3: Create a schedule Before a simulation can be run, a schedule must be set up to tell RESOLVE how long to run for and how often to optimise. In addition, it is possible to write a more detailed schedule (in the form of a script) that will schedule events based on the prevailing conditions within the system (for example, a water front can be monitored in a reservoir to allow a well to be shut in before a breakthrough occurs).

CHAPTER 2 – METHODOLOGY

2.1.4 Step 4: Run the simulation When a simulation is run, RESOLVE collects and passes data between all the connected applications. The data passed in all cases is an inflow table - this is a table of node pressures against phase rates, composition, temperature, and mass flow rate. If compositional data is to be passed, composition tables are set up at start of the run. The application that receives the inflow data does not have to use all of it - for example, an economics package would not necessarily be interested in the delivery pressures. RESOLVE will perform the following steps:

1. Reload and initialise all cases 2. Broadcast to all clients to calculate inflows at all sources 3. Pass the generated inflows to the connected sinks 4. Broadcast a Solve command to all the connected modules. This may be

accompanied by a flag to determine whether the solve should be optimised.

5. Pass the optimised results back to the objects that generated the inflow relation

6. Broadcast to all clients to perform a timestep of the requested length

7. Return to step 2.

Note that this procedure is performed in stages, moving from downstream to upstream. The individual modules are grouped together as groups where calculations can be performed in parallel. The grouping is determined by RESOLVE from what RESOLVE knows of the application types (e.g. reservoir simulators are run before process simulators) but the grouping can be edited by the user. For example, consider the case where two reservoir simulations 'sim1' and 'sim2' are connected to different wells of a surface network 'network', which in turn is connected to a process simulator 'process'. The data can be passed from the simulators to the network model entirely independently, and so the grouping 'Network~sim1~sim2' is formed. When a RESOLVE simulation is run, data will be passed between the modules of this group first, and Solve commands will be broadcast to the module 'network'. RESOLVE will then pass the data from the network model to the process simulator, as it recognises the system 'Network-process' as a separate grouping. RESOLVE is the master controller application - at each of the above steps the command (to perform a timestep, etc) is broadcast to all the client applications simultaneously. This allows multiple simulations (for example) to run in parallel, perhaps over a network. See also: application architecture, driver registration, connection rules, scripting.



2.2 Application Architecture RESOLVE is built around an 'application-driver' architecture as follows:

The functionality of the program is split into two parts. 1. The executable, RESOLVE.exe. This is responsible for providing a user interface and for collecting and passing data between applications. It also performs other basic tasks such as file I/O, data validation, and reporting. The scheduling is also part of the executable. 2. The drivers. The drivers, in the form of dynamic link libraries (DLLs), are the implementations of the linkage. Each driver implements the connection with that product by communicating with the application in question and by passing on requests for data from RESOLVE. The form of communication with the application is irrelevant to RESOLVE - in general, Petex programs will use OpenServer, other PC packages (such as Hysys, above) will tend to use DCOM, wile other programs may use PVM or CORBA, for example. Drivers must be registered in RESOLVE before they can be used: this can be done from the RESOLVE front screen (see Registration). To illustrate further, consider the events that occur when a case of an application is loaded into RESOLVE. RESOLVE will tell the driver to create an instance of the required application (e.g. GAP) and then tell the driver to load the case into the application. RESOLVE will then ask the driver for the details of the sources and sinks exposed by the case - this request will be passed on to the application and returned to RESOLVE to display on the screen. The structure of the drivers is 'Open Source'. This means that users who would like to develop their own linkage can develop and build their own drivers to load into RESOLVE. For more information, see the developer notes that are distributed with the software.



2.3 Driver Registration A driver is a software component (dynamic-link library, or DLL) that is used by RESOLVE to implement the link to a particular piece of software. For example, there are currently drivers (that are distributed with RESOLVE) to control the links to the Petex products GAP and REVEAL and the Aspentech process simulator Hysys. See the section on Application Architecture for more information. In order for RESOLVE to use a driver it must be registered with the RESOLVE system. A new installation of RESOLVE will automatically detect and load new drivers (or more recent drivers than the currently registered set); however, there are some circumstances in which you may wish to register the drivers by hand. To register RESOLVE drivers, go to Options | Register on the main screen. The following screen is invoked:

The column titles are as follows: App Module: This is the name of the driver as it will appear in RESOLVE when an instance is created. DLL Path: This is the path to the dynamic link library that implements the link. Application Type: This is an identifier given to RESOLVE, supplied by the driver, that determines the nature of the application that is being linked. It is used by RESOLVE to guess the 'upstream' and 'downstream' components of a system. This guess can be overridden by the user before the system is executed so this identifier is not crucial to the running of RESOLVE. Requires composition Can produce composition: These flags determine whether an application is compositional (i.e. requires EOS data to run) and whether it is able to produce EOS data. For example, GAP, although not currently fully compositional (the hydraulic calculations are based on black-oil



properties), is nevertheless able to produce compositional data through the compositional tracking function. These flags form part of the rule base for determining connections that can be made. Ver: The driver version number. Description: This is a brief decscription of the driver functionality, including the appropriate versions of the connected software with which the driver works. The action buttons are as follows: Register: Use this to register a new driver. When this is pressed, a screen will be presented allowing you to browse for the required driver. Once selected, RESOLVE will check that the file has the correct format for a RESOLVE driver, and will then add it to the above list. Unregister: Unregister currently registered drivers by highlighting them in the list and then clicking Unregister. Configure: This will bring up a configuration screen appropriate to the driver. For example, the GAP driver will invoke a screen allowing you to select the path to the correct version of GAP on your PC.

2.4 Connection Rules RESOLVE is an interface to allow disparate applications to be connected together. This requires a set of rules (or 'rule base') to be set down to determine which nodes in the RESOLVE system can be connected to which other nodes. The rules are, in fact, very straightforward and logical and are explained below. RESOLVE node descriptions When a model is loaded into RESOLVE, RESOLVE considers the model as a black box calculation engine which exposes inputs and outputs (sources and sinks) to the outside world. These sources and sinks are called 'nodes'. There are various types of nodes, and these types determine the connections that are possible from one node to another. Source/Sink node: ( - source) ( - sink) Nodes are described as sources or sinks depending on the direction of fluid flow from upstream to downstream. For example, a well in GAP can be a sink for a production well or a source for an injection well. Nodes can also be undefined withe respect to their being sources or sinks. In this case they take the description from the item to which they are connected (e.g. a well



in a simulator becomes an injector if connected to an injector in GAP). This is denoted by the icon. Data providers/data acceptors: In addition to items being described as sources and sinks, items can be data providers or data acceptors. This determines the data flow in a RESOLVE system as opposed to the notional fluid flow. For example, a simluation well will generally be a data provider, as it generates inflow data that is passed to a corresponding data acceptor (a GAP well, for example). A data provider is indicated in the interface by a small dot above the icon. Uni-directional/bi-directional links: When the RESOLVE system is run, a node is allowed to generate a table of inflow data or a single point of inflow data. In the former case, the data acceptor will calculate an operating point on the table (which may or may not be optimised, see the Schedule screen) and that operating point will be returned. This is a bi-directional link. In the latter case, the data transfer is entirely one way from data provider to data acceptor. Nodes that generate tables of data are indicated with a red bar over the icon. Compositional/non-compositional nodes: Each driver that is registered with RESOLVE indicates whether it is able to generate EOS data, and also whether it requires EOS data to perform its calculations. For example, a process simulator may require EOS data, whereas GAP will be able to provide EOS data while still using black oil calculations internally. See driver registration. The connection rules:

the source/sink type must be different between connected nodes. • • •

•

•

data providers must be linked to data acceptors. nodes producing tables of data must be connected to nodes accepting tables of data (bi-directional), or nodes producing a single data point must be connected to nodes accepting a single data point (uni-directional). nodes which accept data and require compositional data for their calculations must be connect to nodes that can supply compositional data.



2.5 Composition Tables If a RESOLVE system is built which consists of applications which require or generate EOS compositional data, it is necessary that there is a 'continuity' in the compositional data throughout the system. This means that, for example, the composition passed to RESOLVE by one application must map exactly to the composition required by the connected application: although the component names can differ, there must nevertheless by a one-to-one correspondence between each component passed between each application. This is achieved by using a composition table. When a compositional case is run for the first time, RESOLVE queries the client modules for their base composition. It then generates the following screen:

Module connection list: This is a list of the applications in the RESOLVE system that are connected together. Note that in the above example the module GAP (Dev) is connected to two modules: one called 'mixer', the other called 'cooling'. Each connection in this list must have




their compositions mapped together correctly. The red cross indicates that, for this connection, the mapping is not yet complete. Component lists: The component lists on either side of the screen list the base compositions for the two modules that are highlighted in the module connection list. Add Individual Connection: To map a component from one list to a component of the other, highlight the components in the two lists and click this button. For example, in the above screenshot, the user could highlight 'C1' from the GAP list which clearly corresponds to 'Methane' from the separation list (this is a module of Hysys). When the button is pressed the connection appears in the Composition connection list at the bottom of the screen. Add All: If the compositions displayed in the two lists already 'line up', then this button will automatically generate the links between the components. Remove Link: To remove an existing component mapping, highlight the entry in the list and press this button. Once this mapping has been set up it will be saved with the RESOLVE (.rsl) file. This means that this screen will not be displayed on subsequent runs. If you wish to edit this mapping before a run, you can go to Run | Edit Composition Tables from the main menu. When the run is carried out, RESOLVE will cross-check the current base compositions of the client modules against the compositions saved with the file, and will re-display this screen if necessary.

RESOLVE

3 Step by Step Guide

3.1 Getting started - step by step example This section is a guide to setting up a simple connection between a GAP case and a REVEAL case. The emphasis is on how the user interface can be used to enter basic information and form the connection rather than the engineering content of the model. Before you start: 1. You must already have the software and licenses for GAP and REVEAL installed on the local machine. A valid software protection key ('dongle') should be connected to the machine. 2. Check that you have drivers for GAP and REVEAL installed in RESOLVE. From the RESOLVE front screen, go to Options | Register and check that these drivers appear in the list. In general, RESOLVE will attempt to install these drivers the first time it is run. If they are not installed, then you must install them before proceeding. Go to Registration for more information. 3. Check that the drivers are configured correctly. To configure the GAP driver, double click on the driver in the list as invoked in the previous step. From the resulting screen, browse to the directory in which GAP is installed. Repeat for the REVEAL driver. 4. You should already have extracted the sample files. Go here for more information. RESOLVE should now be ready to use. In this example we are going to connect the Reveal and GAP cases provided as part of the 'gapex' sample file. Step 1 initialise new case Step 2 load the Reveal case Step 3 load the GAP case Step 4 make the connections Step 5 configure the cases Step 6 enter the schedule Step 7 run the simulation Step 8 view the results

CHAPTER 3 – STEP BY STEP GUIDE

3.1.1 Step 1 - Initialise new case Start RESOLVE, and open a new project (File|New), or use the icon . Select Options|Units and set the input and output units to Oilfield, then select OK.

Now is a good time to save the file using File|Save As..., and enter a file name (e.g. example1.rsl).



3.1.2 Step 2 - Load the Reveal case The next step is to create instances of the cases that we wish to connect on the front screen. You should already have the drivers for REVEAL and GAP installed. From the main menu, go to System | Create instance or select the icon. From the resulting menu, select 'Reveal'. The cursor, when held over the main screen, will change to indicate that an instance of the application can be made. Click on the main screen where you would like the Reveal icon to be, and give the case a label (say, 'Reservoir'). Double-click on the resulting icon - a screen appears allowing you to browse for a case name and to select a machine on which you would like the case to run. Leave the 'machine' field blank so that the application runs locally. For the case name, browse to the file 'smartwell.rvl'. When you press OK, RESOLVE will take a few moments to start REVEAL and load the required case. It will then query the case for its sources and sinks and will display these on the screen. In the case of REVEAL, the driver extracts well and completion data - in this case, it determines that there is a single well in the model which is completed in four places. You can go into REVEAL to confirm this.

3.1.3 Step 3 - Load the GAP case Repeat the previous step to create an instance of GAP on the RESOLVE front screen. Label the GAP case that you create 'Network'. Browse for the case 'smartwell.gap'. As before, RESOLVE will take a few moments to load GAP and query the case. It will find four production wells (sinks) and a separator (source) which it will display on the screen.



3.1.4 Step 4 - Make the connections between the cases At this stage we connect the applications together graphically. Background information: We are attempting here to model an 'intelligently completed' well (sometimes called a 'Smartwell'). The REVEAL model consists of a single well with four completions. The GAP model consists of the four completions with pieces of tubing between: thus GAP is to take responsibility for calculating the wellbore pressure drops and for calculating the choke settings on the individual completions. The completions in REVEAL can therefore be connected directly to the wells in GAP. This will mean that Reveal will generate individual inflows for each completion. The other mode in which REVEAL can be run is by connecting at the well head. In that case, REVEAL would take responsibility for the pressure drop calculations in the well bore. You may note that the completions are modeled as wells in the GAP model. In fact, the wells have 'null' lift curves in which the manifold pressure is equal to the bottom hole pressure at all rates - effectively, the wells are simply inflow objects and the lift curves are implicit in the surface network. Moving the icons: Before we make the connections, we will move the icons on the screen to make the connections clearer. 1. Select the 'Move' icon ( ). 2. Click and drag the mouse over the REVEAL well and its four completions. They will then appear is selected (with a blue circle). 3. Click on the screen near the icons and drag the selection to a point above the REVEAL icon. 4. Unselect the REVEAL well by right clicking on the well icon and selecting Toggle Select | this item from the resulting menu. 5. The completions should still be selected. Move these above the REVEAL well in the diagram. 6. Further movement of individual icons is possible by clicking into the icon and dragging it to the required position while in this mode. 7. Unselect all the selected items by pressing the icon. Repeat as required for the GAP wells. The screen should look similar to the following capture:



Connecting the icons: To connect the systems, go to 'link' mode by pressing the icon. Connect the cmp_1 icon in REVEAL to comp1 in GAP by clicking into the first icon and dragging the connection to the second. Repeat this for all the icons: cmp_2 to cmp_4. At the end the system should resemble the following picture:

Note that it is possible to make the connections using the connection wizard. This is obtained by invoking System | Connection Wizard under the main menu.



3.1.5 Step 5 - Configure the cases Before the simulation is run, you may wish to make some further changes to the configuration. In this example, we will change the simulator wells to be run as fixed rate wells. When GAP optimises its system, it will return the result as an operating point for the well on the inflow relation that REVEAL passed for that completion, i.e. a node pressure and rate. REVEAL will then have to control that completion with that fixed rate or pressure for the duration of the following timestep. Double-click the REVEAL icon on the main screen. Select the 'Associated Data' tab. Select 'Fixed Rate' from the selection box at the top of the screen. Note that it is possible to commence the REVEAL run from a restart using this screen.

3.1.6 Step 6 - Enter the schedule Before the simulation is started, it is necessary to give RESOLVE a schedule with which to run. Resolve scheduling is divided into two parts: 1. Basic scheduling - timestep length and overall duration 2. Advanced scheduling - using a script, condition-based scheduling can be implemented. For the purposes of this example, we will concentrate on the basic scheduling only. Invoke the schedule screen from the main menu using Schedule | Timesteps. Select a duration of 500 days with a timestep length of 50 days. Note that the timestep length is the RESOLVE timestep length. When a timestep is required RESOLVE will broadcast the request to all the connected clients, and those applications that have a time dependency will take as many internal timesteps up to the RESOLVE timestep as they require. When they have completed their timesteps, they will pause and wait for further instructions from RESOLVE. This is important for synchronisation purposes - if there are many simulation models connected to a surface network (for example) then these models must be synchronised before inflow data is passed. On this screen it is also possible to set the optimisation frequency. The default of '1' means that RESOLVE will attempt to optimise at every timestep. It may be desirable (for performance reasons, for example) to perform unoptimised solves at some timesteps. This number can be changed to optimise at every 'n' timesteps.




3.1.7 Step 7 - Run the simulation The simulation is now ready to be run. Invoke Run | Start or press the icon to start the simulation. A validation window will appear immediately. This is warning that there is a separator in GAP that is unconnected. In principle, this could be connected to a further module such as a process simulator. The validation message is only a warning so you may press OK to continue. GAP and REVEAL will now be controlled by RESOLVE. REVEAL will take 50 day timesteps as set in the schedule, and at the end of each timestep GAP will perform an optimisation. You can observe this behaviour in the main windows of these programs.

3.1.8 Step 8 - Extracting and viewing the results Results can be obtained in two ways using RESOLVE.

1. It is generally possible to view all the results of a simulation for any of the client applications in the application itself.

2. RESOLVE has a limited set of results that it keeps from the run. The results from the client applications are best viewed when the run has completed or is paused: this is because RESOLVE is controlling the application and it is possible that viewing application results will interfere with the control. For this reason, application user interfaces are disabled while the run is proceeding. RESOLVE will keep a basic set of results for each connected sink. These can be

observed by invoking Results | Sink Results, or by clicking on the icon. From this screen results can be plotted and reports generated. For this case, try to plot the results for comp1 and comp3 of the GAP model from RESOLVE. Note how:

1. The GOR and water cut evolve due to coning from gas and water layers in the REVEAL simulation.

2. GAP chokes the completions to limit the gas through the system. GAP does not necessarily shut in the gassy completion as gas lift is desirable to lift the fluids as the water cut increases.

This tutorial has only touched on the functionality of RESOLVE. For more information, see the help sections that refer to the menu and toolbar commands.

RESOLVE

4 Menu Commands

4.1 Overview For more detail, follow the links below. File - basic I/O Options - unit systems and driver registration System - creation of client applications and manipulation of icons Module - commands specific to client applications Schedule - timestep and event driven scheduling Run - runtime commands Results - results and reporting View - user interface preferences

4.1.1 Menu: File These are the commands that can be accessed from the 'File' menu. New The current system is cleared and all connected clients are closed. A new blank file is created. Open A RESOLVE case can be loaded from disk. This will in turn load the client applications that this case refers to - there is no need to have the client applications already open. Save Saves the current RESOLVE project. The connected applications will be stored in the file to be reopened when the case is reopened. Save As As above, except to a new file name. Broadcast Save Broadcasts a 'save case' message to all the connected clients. Open (results only) This will open a case without opening the connected clients, i.e. the connections will be displayed and the results of the run can be accessed, but a new run can not be performed as the clients will not be active. This is useful as the opening of client applications can be time consuming in cases where you only wish to observe the results. Data directory Set the default directory that will be displayed when File | Open is invoked.

CHAPTER 4 – MENU COMMANDS

Print commands Commands for printing the system, configuring the printer driver, and previewing the print job.

4.1.2 Menu: Options These are the commands that can be accessed from the 'Options' menu. Units Displays a screen with the current sets of input and output units that RESOLVE will employ. Register This invokes a screen that can be used to register and configure additional drivers for RESOLVE. When RESOLVE is started for the first time, it will attempt to load a default set of drivers that come as part of the software distribution. These will include drivers for Petex products (GAP and REVEAL) and possibly other products for which Petex have built drivers (e.g. Hysys). You can use the registration screen to configure these drivers, change to different versions of the drivers, or add drivers of your own. The available options from this screen are: Register: allows the user to browse to a new driver DLL. When you have selected the driver, RESOLVE will ensure that it is suitable and then display its properties in the list with the other drivers. Unregister: if a driver is highlighted, 'Unregister' will remove it from the list. Configure: some drivers may require additional configuration information. This will depend on the driver: further details can be found in the driver help files. An example of configuration data may be the location of the application exectuable on the hard disk. See driver registration for more details.



4.1.3 Menu: System The commands available from the system menu are generally those that are used to create and manipulate icons on the main screen. These are the commands that can be accessed from the 'System' menu. Create Instance This will invoke a menu with a list of the available drivers. To create an instance, click on the application that you would like to load and click onto the front screen at the location at which you would like the icon to be displayed. Link Enters 'link' mode for linking connected sources / sinks together. Select Enters 'selection' mode for selecting icons for later manipulation (e.g. moving). Selection can be done per icon (by clicking into the icon) or by dragging over a rectangle which will toggle the selection state of all the icons within the rectangle. Selected icons are marked with a blue circle. Move Enters 'move' mode for moving icons. Icons can be moved individually by clicking into the icons and dragging with the mouse, or collectively by clicking near a group of selected icons and dragging to the new location. Delete Enters 'delete' mode for deleting clients. Source and sink icons can not be deleted individually as these are properties of the client application cases. The clients can be deleted in this mode by clicking onto the main icons. Select / Unselect all items Enters select or unselect mode. Once items have been selected they can be moved en block. Show / Hide all sources / sinks For clarity in complex systems it may be desirable to hide all the sources and sinks of a client application - when they are hidden a small plus (+) sign appears in the bottom corner of the case icon. These menu options toggle the states of all the client applications. Connection Wizard Invokes the Connection Wizard. Icon Sizes Allows the user to change the icon sizes on the screen. This may be useful if a system is fairly complex and is looking cluttered. Properties Invokes the system properties screen. This allows various options relevant to the simulation to be set, as well as some graphical preferences (e.g. screen fonts).



4.1.4 Connection Wizard The 'connection wizard' may be used to generate connections between nodes in the Resolve system. This can also be achieved graphically, but this can be quite arduous when generating connections over a large system. When invoked, the following screen is produced:

Module lists: The drop down list boxes at the top of the screen contain all the client modules in the Resolve system. Select the two modules that you wish to make connections for from the lists on the left and right of the screen. The sources/sinks that correspond to the module are then listed in the list boxes below. Sorting options: The lists of nodes can be manipulated in various ways. Nodes can be selected in the lists and removed by clicking the Remove Selected button. The lists are, by default, sorted alphabetically (as it is normal to connect items with common names), but the



sorting can be reversed by clicking <Reverse Sort>. The Reset button will display all nodes sorted alphabetically. Display Filter: Use the checkboxes to determine which items appear in the list. By default, data providers and data acceptors (i.e. all items) are listed. Click on the checkboxes to apply a filter to the list, and then click Apply. Connections can then be made by highlighting the individual sources and sinks in the list and clicking on Add Individual Item. If the lists have been sorted and filtered to align the nodes that are to be connected, then Add All can be used to form automatic connections between the node lists. The resulting connections are displayed in the list box at the bottom of the screen.

4.1.5 System Properties This screen allows certain properties of the system display and runtime mode to be changed. When Options | System properties is invoked from the main menu, the following screen is invoked.



System title: This controls the display of a system title on the main screen. To give the system a title, enter the title in the text box supplied. The font for the title can be changed by pressing the 'Font' button. The system title information is saved with the Resolve file. Label fonts: Press the 'Font' button to change the font that is used to label the icons on the main Resolve screen. Runtime options: Stop on non-fatal validation errors: If this is checked, Resolve will present a screen at run-time that will display any non-fatal validation errors in the system. Such an error would be a node that is not connected to another node: this is not going to stop the system from running, but could be a reminder to you that the system is not complete. Reload modules at start of run: Normally, it is a good idea to reload modules with their models at the start of a run. In some cases, the models can be changed by the run itself, and so they should be reloaded at the start of a run to ensure that they are correctly initialised. However, in some cases where the models do not need to be re-initialised, the reload procedure is just time-consuming and can be skipped. Perform calculations in parallel: In general, it is preferable to perform calculations in parallel wherever possible. For example, if two reservoir simulators were connected to a surface network, it would be desirable to run the simulation timesteps in parallel. This option can be used to force the calculations to run in series.



4.1.6 Menu: Module The 'Module' menu is generated dynamically with a list of the loaded client applications. For each client, the following menu options are available. Change Label The alias that was set when the object was created can be changed here Edit Case Equivalent to double clicking on the icon in question, this invokes the 'Edit Case' screen to allow the user to change the case being studied. In general, this will result in the current connections being lost as the new case is loaded in. Reload Broadcasts a message to the client application to reload the case from scratch into the application. Save Broadcasts a 'save' message to the client application to save the case. Update query Often used in conjunction with the reload, this will update the sources and the sinks displayed with the current contents of the case. There may be other options available for some drivers - these depend on the driver itself and more details can be found under the help for that driver.

4.1.7 Menu: Schedule The commands available from the schedule menu are those that are used to set event scheduling for the simulation. These are the commands that can be accessed from the 'Schedule' menu. Timesteps This will invoke a screen that allows the user to set a timestep length and schedule duration for the RESOLVE run. See timestep control for more information. Script This is a function that allows advanced condition-dependent scheduling to be implemented. See scripting for more information.



4.1.8 Timestep control In a Resolve system, Resolve is the master controller and all the attached clients are slaves of the Resolve process. As such, Resolve coordinates the timesteps of the time-dependent applications and ensures that the applications are appropriately synchronised. See How Resolve Works for more information. The timestep lengths (the times between synchronisation of the modules) are set from this screen.

On the left hand side is a list of concurrent schedules. The buttons at the bottom of the list allow schedule records to be added, removed, and inserted, or the entire list can be cleared. When a schedule in the list is highlighted, that schedule timing and duration is displayed at the top of the screen. Timestep duration in Resolve can be fixed, or individual timestep lengths can be set. Regular/fixed timesteps: If this option is selected, the schedule duration and timestep length only need to be set. When Resolve performs a simulation, it broadcasts 'Solve' commands to all the modules that accept data from a connected module. In the case of a bi-directional link (where data is passed back to the original provider) the Solve command will be accompanied by a flag indicating whether the 'Solve' is an optimised solve or a simple system calculation. Resolve does not know whether the module in question will 'understand' the optimisation request but the command will be sent anyway: in



the case of GAP (for example), systems can be optimised by adjusting lift variables, setting chokes, etc. The 'Optimise every ...' field allows the user to specify how often the 'optimise' command is sent. User defined timesteps: Timestep durations can be entered individually in the grid on the right of the screen. The grid can be generated automatically using a linear or geometric sequence.

4.1.9 Scripting control Resolve implements a scripting control that allows event-driven scheduling to be performed during a Resolve run. To use this facility, a basic knowledge of Visual Basic and programming will be required. Examples of how scripting can be used are included in the sample files. To create or edit a script, go to Schedule | Script from the main menu. The following editor is invoked:

Several functions ('entry points') are called by Resolve at predefined parts of the simulation. Use the drop down lists at the top of the screen to select the function that you wish to implement. Declarations: This is not a function that is called, but this section allows variables to be set up and instantiated with initial values. The three functions that are called are: PreSolve: (as in the above example). This is called by Resolve just before the Solve command



is sent to a group of connected modules, after the data has been passed between the applications. The argument to the function (ModuleList) is a string that is a delimited list of the modules that form the group, the delimiter being a tilde '~' character. For example, in a simple Resolve system consisting of two modules ('Simulator' and 'Network') that are connected together, PreSolve will be called with an argument 'Simulator~Network'. The argument can be used to check exactly which part of the Resolve system is currently being solved. PostSolve: This is also called with a ModuleList argument. It is called after the Solve command and after the data has been passed back to the receiving module. Finish: Called at the end of the simulation, to allow post-processing, tidying of data, etc.



4.1.10 Menu: Run The menu items under 'Run' are used to control a simulation run as it proceeds. The options are: Validate This performs the 'pre-processing' of the run without doing the run itself. It can be used to perform a simple validation of the system. Start Commences a run (from scratch or following a pause). If it is starting from scratch, RESOLVE will validate the system beforehand and display any validation errors. Stop Terminates a run Pause Pauses a run. During a simulation, the client applications user interfaces are disabled - pressing pause will reenable the applications and allow the user to view results, etc. Do One Step Single-steps through a simulation. Edit composition tables Composition tables are required when compositional data is being passed between applications. Each application will have its own set of compositions which may have unique names across the RESOLVE system (e.g. methane in one package may be referred to as CH4 in another). The composition tables map the compositions from different applications onto each other. See the composition table screen for more information. Edit calculation order For more complex systems RESOLVE breaks down the calculations into several parts. For example, consider the case where a reservoir simulator is connected to a surface network model, which is in turn connected to a process simulator. In this example, it is necessary to calculate first the production of the fluids from the reservoir to the surface network, and then solve the connection between the surface network and the process. RESOLVE will make a guess as to the required order based on the client types. The calculation order can be changed manually using this screen. Debug Logging Turn the debug logging on or off. The debug logging will generate a detailed record of all the data that is passed between applications during a run which will then be saved with the RESOLVE file. It allows cases to be debugged remotely without necessarily having access to all the drivers or applications. Debug file view / export Utility functions to view the above debug file or to export it as an ASCII file.




4.1.11 Menu: Results This allows the simulation results to be accessed. Sink Results This invokes a screen with a basic set of results for all the sink objects in the system. They are grouped by application: for each application total quantities are also recorded. From this screen plotting and reporting functions can also be performed. Generate ASCII file This simply generates an ASCII file of the results in the current working directory. The file has the same name as the resolve file except with an .rsr extension. Log Window Displays the log window. The log window can be written to by script commands (see scripting for more information), which is potentially useful for debugging purposes. The log file is saved with the RESOLVE file - this menu item can then be used to display the currently saved log file.

4.1.12 Menu: View Menu items to display / hide the toolbar (at the top of the main window), the status bar (at the bottom of the main window), and the infoviewer (to the left of the main window) are available here.

Appendix A Sample Files

A1 Sample Files The following is a brief description of the sample files included with the installation. Depending on where RESOLVE was installed, they may be found in C:\Program Files\Petroleum Experts\IPM #\Samples\resolve, where # is the IPM (Integrated Production Management) release version number. The sample files are all based on connections between REVEAL and GAP. Check the information in the step-by-step guide: getting started before attempting to load a sample file. To extract the sample files: The sample files are distributed as GAP archives (.gar files). Take the following steps: 1. Extract the archive using GAP. Start GAP. Make sure that the version of GAP that you start is the same as the version of GAP that RESOLVE will run. Select File | Archive | Extract from the GAP main menu and browse to the .gar file that you extracted from the original zip file. 2. Follow the on-screen instructions to unpack the .gar file to the subdirectory that you have created. Load the unpacked .gap file into GAP and check that all the associated paths (e.g. to lift curves, etc) are correct. You can check this from Edit | Edit project paths. 3. Close down GAP and start RESOLVE. You should now be able to open the .rsl file from RESOLVE. The RESOLVE file will have been generated with different paths to the linked cases: as the file loads, RESOLVE will prompt you to browse for the new case directories. 4. When the RESOLVE load is completed, save the .rsl file so that the new case paths are saved. Following is a brief description of the sample files: SMARTWELL This is a model of an intelligently completed well ('smartwell') in which a REVEAL well, completed in four places, is controlled on a completion-by-completion basis with GAP. GAS-SCHEDULE This is the same as Gapex, except that it implements a script that will test for a high GOR (> 25000 scf/STB) in the gas completion and shut it in if it exceeds this amount. This is illustrating the scripting capability of RESOLVE. VOIDAGE This is using a REVEAL model linked to a combined production and injection system in a GAP case. The production system is solved first, and the voidage is calculated by the script. This is then set as a constraint in the injection system which is then solved. This example is essentially implementing a voidage replacement scheme.

2 - 2 APPENDIX A – SAMPLE FILES


WATER-RECYCLING This is an example where REVEAL wells are connected at the wellhead to a GAP model that uses a lift curve to model the delta P to the manifold. The wells in this case are gas lifted. A script is included that can allow water to be recycled into the REVEAL model. In addition, the script calculates the saturations around the multilateral well bores in REVEAL and outputs a warning to the user when they exceed a certain threshold. WATER-RECYCLING2 This is the same as Gapex, except that it allows the produced water to be recycled back into the REVEAL model (up to a maximum of 4000 STB/d as set in the GAP model). It also contains a script that shuts in the water injector when the water saturations in the reservoir exceed a certain threshold.

1 - 1 APPENDIX B

Appendix B

B1 Distributed Applications This functionality is implemented as part of the driver code. However, in general, this is how to set up a remote machine to be able to launch IPM programs from RESOLVE. Windows 2000/NT 4.0/XP

1. As administrator, run DCOMCNFG.EXE. 2. Locate PXSERV document in the applications list.

3. Click on the PROPERTIES button.

4. Under the Location tab, select 'Run application on this computer'.

5. Under the Security tab, change the access and launch permissions to allow

you (as user) full access to the remote machine.

6. Under the Identity tab, select 'Interactive User'.

7. Press OK. You should now be able to create instances of PXSERVER and launch the IPM programs from RESOLVE on a remote PC.

Windows 98/ME Petroleum Experts is not able to support these architectures when RESOLVE is used remotely. RESOLVE is still supported when used as a local application on these operating systems. The reason for this is that the Microsoft implementation of DCOM on these systems does not allow remote applications to run interactively.


Appendix C Hysys Link

C1 Use of the Hysys Driver The Hysys driver allows instances of Hysys to be opened and controlled from Resolve. How to use HysysLink The driver first needs to be registered with Resolve. See the Resolve help for more information on how to do this. Once the driver is registered, it will be possible to create instances of Hysys in Resolve. - Create an instance of Hysys from the 'Create Instance' menu on the Resolve main screen. Click on the Resolve screen to create a Hysys icon. - Load a pre-modeled case of Hysys by double-clicking on the created icon and the browsing to the case in question. Note that it is possible to run Hysys on a remote computer over a network. To do this, DCOM security must be set up on the registered Hysys component on the remote computer. See your IT system administrator for this. - Click on the OK button. An instance of Hysys will be created in the background that will load the required case. - The driver will now determine the 'sources' and 'sinks' of the Hysys model for display on the Resolve screen. These correspond to the input streams and output streams of the model. - The Hysys streams can now be connected in Resolve to other sources and sinks from other applications. Note that the streams in Hysys are 'uni-directional'. This means that a single point is passed by the program that supplies the data to Hysys and Hysys returns no data back. The streams can only be connected to other uni-directional sources/sinks. - Resolve does not extract any reporting variables from uni-directional connections - it is necessary to set up the variables that you wish to monitor. Right click on the Hysys icon in Resolve, and click on 'Output variables'. From the resulting screen, browse to the variables that you wish to report. - As many cases of Hysys as you wish can be loaded into Resolve at one time. What the driver does When Resolve is run, it will query the individual cases for the compositional data that they are to run with - Resolve requires a common set of components to be present across the entire system. These components do not necessarily have to have the same names (e.g. pseudo-components may be named differently in GAP compared with Hysys, say) but it must be possible to map the different component sets together. This has to be borne in mind when setting up the Hysys model, i.e. the fluid package that is created must contain all the components that are to be expected from the connected package. Pseudo-component properties do not have to be known as these will be set by Resolve as part of the data transfer. When the case is run in Resolve, data will be passed to the connected input stream(s) in Hysys. This data will consist of a single point of pressure, temperature, mass flow rates, and black oil and compositional data. This data will be set at the input stream.

2-3 APPENDIX C – HYSYS LINK

The compositional data is set in Hysys by poking the data into the fluid package. This means that all streams that access the same fluid package will be affected. If more than one input stream is connected through Resolve, and these share a fluid package, then the compositional data of that fluid package will effectively be written twice, once for each stream. This is only a problem if the input streams arise from different sources with different properties. It is possible to set up different fluid packages for different streams in Hysys, but then a stream cutter (or some mechanism for mapping components between fluids) will be necessary in the Hysys model. Once the data has been passed, Hysys is allowed to solve the system. Data for the monitored variables (see above) are extracted. Also, the data for any output streams that are connected in Resolve are generated. Black oil data (that may be required for connection to black oil applications) is obtained from a series of flash calculations. See also: Notes on setting up Hysys cases.

C2 Setting up a case in Hysys For more information on the data that is passed by Resolve, and on how to set up a Resolve model, please see the Resolve help. Here are some other points that should be considered when creating the Hysys model. - The driver has been developed for use with steady state (non-dynamic) Hysys. Dynamic (time-dependent) behaviour is assumed to come from the connected models. - When the model is created, the fluid package must contain all the components that are expected from the connected model (e.g. GAP). The components can be pure or pseudo (hypo). They do not have to have the same names as in the GAP model as Resolve will map GAP components to Hysys components as part of the initialisation process. - When the compositional properties (critical temperature, pressure, etc) are passed, only pseudo-component properties can be changed in Hysys. Pure component properties are left unchanged. If you would like to pass the critical properties for a pure component, then this would have to be set up as a hypothetical component in Hysys. This would, however, mean that Hysys does not have any knowledge of the pure component that it is supposed to represent (for the purposes of enthalpy calculations, etc). - When compositional properties are set in Hysys, they are applied to the fluid package that is accessed by a stream. If the fluid package is shared across several input streams all streams will be affected by the changes. - This may also affect cases where more than one input stream is connected in Resolve. If the streams access the same fluid package, then the fluid package will be updated twice, potentially with different fluid properties. It is possible in Hysys for the input streams to access different fluid packages, but then a stream cutter or some other mapping will be required to map the different packages together in the Hysys model.


APPENDIX C – HYSYS LINK 3 - 3


C3 Loading and Editing a Case To access this double-click on the Hysys icon in Resolve. Hysys Filename: This is the Hysys case name (extension *.hsc). Machine Name: Hysys cases run from Resolve can be distributed over a network. Enter in this field the name of the machine on the network on which you would like the Hysys case to run. The machine name can be given as an IP address or a name in the DNS register (e.g. 'dave-8200'). Leave the space blank to run Hysys on the local machine. When entering file (case) names for remote machines, the file name entered should be relative to the local machine.

C4 Other Functions The following assorted functions are available in the Reveal driver. Save Case: Saves the Hysys case to the current file name Reload Case: Reloads the case from file (useful if the file has been edited). Resolve will always reload the file before a simulation run anyway, unless told otherwise in the simulation options. Updating the source/sink data (query): When a case is loaded or edited, Resolve queries the case for its sources and sinks. In some circumstances it may be desirable to repeat this operation without reloading the system. Output variables: Connections made to Hysys are uni-directional and as a result no results data is stored by Resolve by default. Use this option to set the variables that Resolve is to store as part of its reporting. When this option is selected, the Hysys model is interrogated for all available variables pertaining to both material streams, energy streams, and equipment. These are then available for reporting. Show case: This simply makes the case visible to the user. It is important that Hysys is not quit while Resolve is controlling it, as the connection can not be remade once it is lost without re-opening the Resolve file.

Appendix D GAP Link

D1 Driver Configuration Before the driver can be used effectively, it must be configured for use with GAP. The configuration screen can be accessed from the Resolve driver registration screen (Options | Register on the main menu). Click on the GAP driver in the list and press the 'Configure' button. The configuration options are: GAP executable path: In this field you should enter the directory in which the GAP executable is installed. If this is left blank, Resolve will attempt to start GAP in the same directory as the OpenServer executable (PXServer.exe) is running. For safety it is best to enter the directory. Application timeout: In case of difficulties, Resolve will wait a certain period when attempting to start up GAP. If it is not able to do so then Resolve will call an error after the timeout period. For most cases a timeout of 30 seconds should be appropriate. If you are running on a fairly slow machine you may want to make this value larger to avoid Resolve 'timing out' unnecessarily.

D2 Loading and editing a case To access this double-click on the Reveal icon in Resolve. GAP Filename: This is the GAP case name (extension *.gap). System: As well as the main system, GAP cases can optionally contain associated water and gas injection systems. This control can be used to select one of these systems rather than (by default) the main system. This is useful if you would like to connect separately to a GAP case and an associated system of a GAP case. Two instances of GAP can be created in Resolve, one of which points to the main system while one points to the associated system. Machine Name: GAP cases run from Resolve can be distributed over a network. Enter in this field the name of the machine on the network on which you would like the GAP case to run. The machine name can be given as an IP address or a name in the DNS register (e.g. 'dave-8200'). Leave the space blank to run GAP on the local machine.

APPENDIX D – GAP LINK 3 - 3


6. As with all calculations, quality checking of the model before the simulation is run is extremely important to check for errors at an early stage before adding extra complexity.

Appendix E REVEAL Link

E1 Driver Configuration Before the driver can be used effectively, it must be configured for use with Reveal. The configuration screen can be accessed from the Resolve driver registration screen (Options | Register on the main menu). Click on the Reveal driver in the list and press the 'Configure' button. The configuration options are: Reveal executable path: In this field you should enter the directory in which the Reveal executable is installed. If this is left blank, Resolve will attempt to start Reveal in the same directory as the OpenServer executable (PXServer.exe) is running. For safety it is best to enter the directory. Application timeout: In case of difficulties, Resolve will wait a certain period when attempting to start up Reveal. If it is not able to do so then Resolve will call an error after the timeout period. For most cases a timeout of 30 seconds should be appropriate. If you are running on a fairly slow machine you may want to make this value larger to avoid Resolve 'timing out' unnecessarily.

E2 Loading and Editing a Case To access this double-click on the Reveal icon in Resolve. Reveal Filename: This is the Reveal case name (extension *.rvl). Machine Name: Reveal cases run from Resolve can be distributed over a network. Enter in this field the name of the machine on the network on which you would like the Reveal case to run. The machine name can be given as an IP address or a name in the DNS register (e.g. 'dave-8200'). Leave the space blank to run Reveal on the local machine. When entering file (case) names for remote machines, the file name entered should be relative to that machine and not the local machine. Associated data tab: Well Control: When Reveal is connected through Resolve, the connected wells can be controlled by:

2-3 APPENDIX E – REVEAL LINK

Fixed rate (total liquid rate, or gas rate for gas reservoirs), Fixed bottom hole pressure Fixed manifold pressure The third option is available only when Reveal is connected to GAP, and is generally to be preferred as the lift curve will give some of the system response of the surface network and so will reduce the explicitness of the system. If fixed manifold pressure is selected, it is essential to include the same lift curves that are in the GAP model in the Reveal model. Run Reveal from: By default, Reveal simulations are started from t = 0. If a restart file has been saved in the simulation case, then this control can be used to start from the restart.

E3 Other Functions The following assorted functions are available in the Reveal driver. Save Case: Saves the Reveal case to the current file name Reload Case: Reloads the case from file (useful if the file has been edited). Resolve will always reload the file before a simulation run anyway, unless told otherwise in the simulation options. Updating the source/sink data (query): When a case is loaded or edited, Resolve queries the case for its sources and sinks. In some circumstances it may be desirable to repeat this operation without reloading the system. Test OpenServer This simply tests whether PXServer.exe is registered with the operating system and returns the full path of the registered application.

E4 Setting up a case in REVEAL Here are some brief notes on how Reveal cases can be set up for use with Resolve. In general terms, there are no special requirements that a Reveal model has to fulfill in order to be used by Resolve. The following points are worth bearing in mind, however:

1. The schedule as entered in Reveal is overridden by the schedule that is entered in Resolve. The only parts of the schedule that are not ignored are those relating to initial timestep sizes and timestep growth. Thus Reveal will take as many internal timesteps as required to reach the timestep set by Resolve.

2. In particular, the schedule set for the wells is ignored. Wells are set to fixed rate or pressure by Resolve depending on the setting in the Resolve file. Wells that are not connected in Resolve will be shut in.


APPENDIX E – REVEAL LINK 3 - 3


3. Lift curves in Reveal will be ignored unless the wells are controlled with a fixed manifold pressure.

4. Wells will be set to production or injection wells depending on the item that they are connected to. If a Reveal well is connected to a water injector in GAP, then it will become a water injector in Reveal.

Fluids that are injected into Reveal may not be at the same temperature as the reservoir. It is important in these cases to have a fully thermal PVT.

Appendix F Developer Instructions for Resolve

These notes are intended for developers wishing to build a custom driver to install into Resolve. Before starting it is recommended that you understand the architecture of Resolve and the flow of data that occurs when a Resolve simulation is run. Details can be found in the on-line help or the manual that comes with the software. Brief details are given below. It is also sometimes helpful to run some of the example files (that link Gap to Reveal and Gap to Hysys).

F1 Template code A driver template, coded in C++ and distributed as a zipped archive, is available from Petroleum Experts on request. This is the stub code for the Reveal driver. The stub driver code contains many comments and supplements this document.

F2 Startup Ensure that Resolve is installed and the default drivers (for GAP, Reveal, and Hysys) are registered with the application. You can check this from the Resolve menu. Go to Options | Register and check that the drivers are present in the list. Resolve should attempt to register these when it is started for the first time: if they are not registered, then click on the Register button and locate the drivers on your driver.

F3 Build and register the stub code The stub code was developed under Microsoft Visual C++ version 6.0, and is only verified on this platform. To build the stub (template) driver:

1. Load the project file (.dsp) into Developer Studio. 2. Build the driver – a DLL called DriverStub.dll will be created. 3. Register the new DLL using the main menu on Resolve: Options | Register as

detailed above. 4. The driver has the default App Name ‘user’.

2 - 3 APPENDIX F – DEVELOPER INSTRUCTIONS FOR RESOLVE

F4 Notes on the driver code Once the driver is registered, you are ready to start adapting it to create your own connection. To understand the functions that the driver implements it is necessary to understand the way Resolve works when it performs a simulation.

F5 Data flow The starting point for Resolve consists of having two or more systems modeled in the client applications that are ready to be connected. These are then loaded into the Resolve front screen:

1. An instance of the application object is created by the user invoking Create Instance | (app name) and then clicking on an arbitrary position on the front screen.

2. The user edits the case by double-clicking on the icon end entering some case details (in the simplest form this might just be a file name). The driver tells the application to load the case.

3. Resolve interrogates the driver for the case contents, i.e. the sources and sinks that the driver exposes. It then displays these as child icons of the main application icon on the front screen.

4. When more than one case is loaded, objects that generate inflows (drawn with a dot in the top left corner) can connect to objects that receive inflows. This is done graphically on the front screen.

The user now enters a schedule for the simulation: this may be just a schedule duration and a timestep length. Finally, the user presses ‘Start Simulation’. Resolve will now control all the client (connected) applications by broadcasting commands to all the client drivers. These commands may be ignored if they are not applicable to the application: for example, DoTimestep() is irrelevant to an application that is not time dependent and is just doing instantaneous solves. During a simulation, the following occurs:

1. Resolve commands the applications to initialise (allocate memory, equilibrate). 2. Resolve collects inflow data from all the inflow provider objects in the system. 3. This data is passed to the inflow receiver objects. 4. Resolve broadcasts a general Solve() command: this will cause GAP (for example) to

perform a solve and optimisation. 5. The solution data is passed back to the inflow objects (e.g. wells in a simulator). 6. The solution data is used as a control for the duration of a timestep that is now

executed. 7. Following the timestep, we return to point (2) where the inflow data is collected.

It should be possible to identify the above procedures in the code of the driver stub.

F6 Driver Source Code The next sections describe the contents of the various source code files that make up the driver. The .cpp files themselves contain fairly extensive comments to explain what each method should be doing. If you would like some more help, or a code sample of the driver for Reveal, then please contact Petroleum Experts.


APPENDIX F – DEVELOPER INSTRUCTIONS FOR RESOLVE 3 - 3


F6.1 DriverStub.cpp / DriverStub.h These just implement the application object and are standard, AppWizard, generated source files. Some configuration data can be stored here.

F6.2 ExtShared.h This is shared by all Resolve drivers. It contains some general definitions and the data structures that are passed between Resolve and the driver. It also contains the command ID #define’s that are broadcast by Resolve to the drivers.

F6.3 ExtDllEntry.cpp This is the main entry point of the driver DLL. It consists of five entry points:

1. ExtIdentify(). This identifies the driver to Resolve, passing a structure that contains fields for the application, driver description, and other options.

2. ExtCreateInstance(). This creates a new instance of the model in the driver. Each instance of the model is represented by a separate icon on the Resolve screen. These models should be able to be controlled independently by the driver.

3. ExtDestroyInstance(). Destroys an instance as created above. 4. ExtConfigure(). Allows the user to configure the driver. For GAP and Reveal drivers

this allows information such as the application executable paths to be stored. 5. ExtCmd(). The main message loop for the driver. A model handle is passed and a

command ID: the driver must call the requested command for the given model.

F6.4 ExtInterface.h This is the definition file for an abstract class that can (although it is not obligatory) be used as a template for a general model class. It contains virtual functions (and some pure virtual functions) for all the possible commands. These can be overridden in a subclass.

F6.5 ExtModel.cpp / ExtModel.h This is the model class derived from the above interface class. This is where all the work is done in communicating with the application and returning the data to Resolve. The ExtModel.cpp file in DriverStub is well commented and should provide you with a good idea of what the various methods are supposed to be doing.

F6.6 RVLRegistry.cpp / RVLRegistry.h Utility functions for storing information (such as configuration data) in the registry.

F7 Conclusion Please contact Petroleum Experts if help or advice is needed in the development of your driver. Source code of existing drivers is available. It may also be possible to make small changes to the interface to accommodate applications that do not fit neatly into the model outlined above.

Petroleum Experts RESOLVE - .::FANARCO::. • Index page · CHAPTER 1 – INTRODUCTION PETROLEUM...

Documents

Transcript of Petroleum Experts RESOLVE - .::FANARCO::. • Index page · CHAPTER 1 – INTRODUCTION PETROLEUM...