Optimising Through Integration: RESOLVE Allows Diverse Engineering Packages to be Solved as a Single System

David Hopkinson (DaveH@petex.com) of Petroleum Experts (http://www.petex.com) describes a new software application (RESOLVE) that allows diverse engineering packages to be connected together and solved/optimised as a single system; it also allows users of proprietary or self-developed software to plug into the functionality of an application such as GAP.

Introduction
Nowadays, petroleum engineers have access to many different classes of engineering software, as indicated in the following list:

• Reservoir simulators (e.g. Eclipse / VIP / Reveal / SURE, and others)
• Material balance calculators (e.g. MBal)
• Surface network / nodal analysis packages (e.g. GAP / PipeSim)
• Process simulators (e.g. Hysys / Pro II)
• Economics packages, databases, etc
• Numerous proprietary tools

To attain the goal of full field optimisation, it is clear that the modelling in isolation of the constituent parts of the field cannot be sufficient. A well-matched simulation model cannot be considered optimised if producing against a fixed tubing head pressure. Similarly, if the variations of tubing head pressure due to the effects of the surface network are considered, then we should also consider the arrival conditions at the process plant to optimise the production at the sales line. In short, we must have a means of connecting the constituent models to create an optimised whole.

As a company, Petroleum Experts develop a suite of tools (the "Integrated Production Modelling" suite, consisting of Prosper, MBal, GAP, PVTP and Reveal) that model from the reservoir to the separator. These tools are integrated to perform system optimisation at the separator / platform level. However, it is recognised that there are areas in which we do not have expertise and in which there are many good existing software packages; furthermore there are engineers who have preferences for other tools who may also wish to "plug in" to the functionality of GAP, for example.

This was the rationale behind the development of a new software package called RESOLVE.

Objectives
In the design of Resolve, the following conditions were set down at the start:

• It should be possible to connect arbitrary numbers of different engineering applications together in a single simulation model. Resolve will handle the transfer of data between the applications at each time step and ensure that the models are synchronised in time. We should not be limited to "point-to-point" connections.
• An advanced, event-driven scheduling tool should be implemented.
• It should be possible to distribute the various applications over a network to allow calculations to be performed in parallel. Thus it is possible to connect multiple simulation models that run on different machines with one or more surface network models.
• The means should exist for a user to plug in their own software to the Resolve system.

When a case of an application (e.g. a simulation model or surface network model) is loaded into Resolve, Resolve considers the case as a "black box" calculator that exposes only its sources and sinks to the outside world. Thus if a GAP case is loaded into Resolve, Resolve will disregard the contents of the model apart from the wells, inflow objects, and separators that it considers the input and output streams to the case. Similarly, a reservoir simulation model will be represented only by the wells. The graphical interface of Resolve will then allow sources from one case to be "linked" with sinks of the associated case. This is illustrated by the screenshot shown in Figure 1: in this case production and injection GAP systems are being connected to a single Reveal simulation case to model voidage replacement. Note that the separators and injection manifolds of the GAP system are available to be connected to a process simulation case.

Figure 1 (Click image for larger view)

The event flow of a Resolve simulation run is best illustrated with the example of a simple connection between a reservoir simulator or simulators (e.g. Reveal) and a surface network optimiser (GAP), bearing in mind that the discussion can be extended to other applications. When such a simulation is run, Resolve will first initialise all the connected applications (equilibrate or restart for a reservoir simulation, clear previous results data, etc). It will then allow GAP to optimise the system. This may involve the setting of chokes, pump parameters, or lift gas rates: these results must be passed back (through Resolve) to the connected simulator. All time dependent simulators are then run with the optimised results for a user-defined time step and then synchronised. The system is then optimised again on the prevailing reservoir conditions, and the process cycles until the Resolve schedule is completed. The flow of events and data is illustrated in Figure 2.

Figure 2 (Click image for larger view)

There are two levels of scheduling available. In simple cases it is possible to schedule events with time (e.g. start/shut wells). More generally, an event driven scheduling facility is implemented in which any application variable that is open to the outside can be interrogated to allow action to be taken in the connected systems. An obvious application is one in which saturation fronts are monitored in the simulation models to allow wells to be "pre-emptively" shut in.

The Resolve program is built around an "application-driver" model. The program itself is mostly responsible for basic tasks such as file handling, marshalling the data flow between applications, and providing a user interface. The work in communicating with the application in question and extracting the required data is carried out by a "driver" that communicates with Resolve. The drivers have a simple, common structure and data interface to allow users with proprietary applications to "plug in" to the Resolve functionality by developing their own driver.

Example: Connecting GAP to Simulation Models (Reveal)
In the development of the driver for GAP, the following had to be considered:

• GAP should be able to optimise the system at the tubing head (its traditional mode of optimisation) or downhole at the completion level (for Smartwell-type configurations).
• GAP should be able to run as a standalone optimiser with no time dependency, or in predictive mode. As such it should be able to mix existing connections to material balance models and decline curve tanks with connections to reservoir simulators.

This second point is particularly important. Many engineers have existing GAP cases consisting of a lot of well-matched and well-understood material balance models with only a small number of test reservoirs that need to be represented with full simulation models. It would obviously be extremely time consuming to replace all the material balance models with full simulation runs, both in terms of modelling and calculation time.

Figure 3 (Click image for larger view)

The first point is illustrated in Figure 3. On the left hand side the connection to Reveal is at the tubing head: Reveal uses its own internal calculations to calculate the pressure drops in the tubing between the completions. On the right hand side, the individual completions are represented in GAP as inflow objects (objects consisting of inflow data but no lift curve) and the tubing between these is part of the GAP model. The internal Reveal pressure drop calculations in this case are turned off. GAP is then free to calculate the pressure drops and set chokes at the completion level, thus simulating a Smartwell (a well with sleeving that can be adjusted to choke back individual perforations).

An example of GAP being used as a downhole optimiser is shown in Figures 4 and 5.

Figure 4 (Click image for larger view)

Figure 5 (Click image for larger view)

Figure 4 shows a schematic of a well, as modelled in Reveal, with four completed regions (in red). The uppermost region is close to the gas-oil contact, while the lower region is close to an aquifer: thus we expect to have gas and water coning problems that will impact on the performance of the surface network. Figure 5 shows a screenshot of the corresponding GAP model. The four completions are labelled comp1 to comp4. Note the lengths of tubing between the completions: this is the tubing of the Smartwell. The well is attached to a simplified surface network consisting of a riser and a long horizontal pipe.

Figure 6 (Click image for larger view)

Figure 7 (Click image for larger view)

The Resolve system in which the GAP and Reveal models are connected together is shown in Figure 6.

Finally, the results of a Resolve run (for the gas coning region only) with 50 day time steps are shown in Figure 7. The GOR in this region rises rapidly from the start of the simulation, as expected. At first, GAP does not attempt to control the gas as it provides useful lift in the riser. However, as the GOR increases frictional losses in the horizontal tubing become significant and so GAP applies a choke (the blue line in the plot) to the completion, which rises with the GOR. GAP does not shut the completion in completely, as the column of fluid in the riser becomes heavier with time due to the water coning from the aquifer. A steady state is finally reached when the GOR becomes very high.

This apparently simple system hides a lot of complexity. The feedback from the GAP model to the Reveal simulation is evident in the shape of the GOR curve: as the choking of the completion increases the rate of increase of GOR slows by more than would be expected in the unconstrained system. If the completion was allowed to shut in, the reservoir fluids could then settle, and this would result in the completion being brought back on line at a later time with a reduced GOR. Finally, note that GAP is choosing to produce water from the aquifer and is allowing this to be lifted with the gas: the penalty of high water production is compensated for by the oil production. If the water cut from the aquifer region were to increase further, or a constraint were placed on water production, GAP would have to decide to shut off this region and subsequently reduce the amount of gas in the system.

Conclusion
This article has described the functionality of Resolve and has discussed the reasons for its development. As well as attempting to encourage openness and connectivity in the engineering software community, we hope that Resolve will also encourage the emerging movement among petroleum engineers of study and modelling across disciplines.

Disclaimer: The material available on this website is designed to provide general information only. Whilst every effort has been made to ensure that the information provided is accurate, it does not constitute legal or other professional advice.
Please note: The Department of Trade and Industry cannot be held responsible for the contents of any pages referenced by an external link.