In this section we describe the execution of the outlined strategy. We describe how we have structured our work such as to deliver the results presented at the end of this chapter and in Chapter 4. The structure of our work represents the actual execution of our strategy.
Work process structure. The background for this work is a collaborative effort between NTNU/IO Center and IO Center Industry Partner Total E&P Norge AS. Total E&P Norge AS is the Martin Linge field operator, and has provided a model of one of the Martin Linge field reservoirs for use in this project. For this work, we have developed a structure of work processes that extends our research methodology and yields an application to opti-mize the set of initial well locations in the test case provided by Total E&P Norge AS. The creation of this structure is the main effort to solve the second of the work targets (the one focused on end–point application), while the effort to solve the first target (dealing with research development) is mostly defined by the choices taken within this work process structure.
Motivation. The main motivation for this work has been to produce well placement re-sults that offer direct value to the current field development work process of our Industry Partner. The overall strategy has been to expand our core methodology for well place-ment and control optimization, i.e., the joint and sequential approaches, into a practical real field application. The application work includes not only expansions of the method-ology itself, but also work process issues such as collaboration efforts and the integration of results back into the information stream of the operator. Clearly, all these issues are in-terrelated. We have created a work process loop to help organize and allocate our efforts along these various types of application work.
Work process loop. To structure the work in this project, we developed a work pro-cess loop with four different parts, or stages. This work propro-cess loop is shown in Fig-ure 3.2. Each part consists of a different type of application work and a different mode of collaboration between the research team and Industry Partner. It was important to establish a clear work process structure since both the technical and collaborative type of efforts needed at one part could be quite different from the work efforts required at another part. The work process loop ranges from model transfer and validation work to problem design, optimization effort and solution testing. Mainly, the four parts represent
clear changes in work focus at different stages of the project. indus-try tools (e.g., Petrel) to adapt solution to comply to industry standards.
Figure 3.2: Work process loop.
Work process loop: first part. Every part of the work process loop consists of a set of technical and collaboration tasks, each generating a particular set of challenges. The first part of the work process loop deals with model transfer and validation work, and focuses on developing a work model that provides reasonably accurate fluid flow predictions to be regarded as trustworthy by the operator. Also, to efficiently serve as the computational engine underlying the optimization routine, the work model had to show a sufficiently fast and robust performance. The work model was implemented in a research reservoir simulator, which required several approximations from the original Eclipse model imple-mentation (the simulator, AD–GPRS, will be presented in further detail later). A substan-tial amount of additional work can be spent on this part of the work process loop since any change to the original model, e.g., in initial well configuration or grid geometry, or update of information, e.g., new relative permeability curves or gas lift tables, may re-quire a redo of model transfer and time–consuming validation work. In fact, because the industry reservoir model provided to us was regularly being updated and reworked during a period, this part did on several occasions during this project require costly supplemen-tary work. However, the frequency of such rework is likely to diminish as coordination with the industry work process of the operator is improved. We believe, e.g., that once the optimization effort is well–understood, an improved communication with the reservoir team will help determine which changes to the original model that warrant an update of the work model.
Work process loop: second part. The second part of the work process loop deals with problem definition, optimization scope and application design in general. This part can pose various difficulties, given the significant amount of information analysis required to understand and reformulate operator knowledge into an optimization problem and scope.
Changes to reservoir management strategy or base case configuration, for instance, are
likely to trigger updates in either problem definition, scope, or both, and may require substantial realignments of application development, and possibly loss of work. More-over, the actual progression of the problem definition can be challenging. Throughout the development of the problem definition we considered several simplifications to the work model to test whether we could use more abstract problem definitions. For example, models with simplified grid structures, or models where free gas was removed from the simulation to decrease runtime and accelerate the control optimization part of the proce-dure, were tested. Eventually, through several consultations with the reservoir team, most of these alternatives were reconsidered (though griding issues were addressed), since sev-eral of the implementations disregarded fundamental aspects for the production of the reservoir. Ultimately, this process was an important and very instructive part of the prob-lem definition, though it demanded a costly back–and–forth between this part and the first part of the loop (since some of the simplified models were extensively compared to the original model).
Work process loop: third part. The third part of the work process loop is concerned with implementing and running the designed application. Primary focus has been on accurate computation of original code with subsequent extensions, and on developing a robust optimization framework. Building a robust optimization framework entails successfully integrating the original code with new code additions and/or extensions (e.g., a new way of handling parallel objective function evaluations on server), and finally also with replace-ments, such as the introduction of the new model and reservoir simulator, all into one reasonably efficient and coherent whole. Apart from implementing the designed features, much of the framework development work was spent on handling challenges that emerged during optimization. This has resulted in a programming structure with a large amount of patches and ad hoc solutions, which may complicate possible future developments towards a more general–purpose implementation. Moreover, the rudimentary construction itself is likely to reduce overall performance. However, these type of problems can be readily solved if we use the expertise acquired during this first build to redesign and rebuild the complete optimization framework into a more efficient programming structure for further research.
Secondary focus for this part of the work process loop has been algorithmic perfor-mance of each of the structure elements (as opposed to overall framework perforperfor-mance discussed above). In order to efficiently produce solutions we need to tune the various el-ements that make up the structure. For elel-ements mainly dealing with optimization, central tuning parameters are those that control well placement search, e.g., the range of coordi-nate perturbation sizes (for the pattern search algorithm), and those that determine the ex-tent of the embedded control optimization routine, e.g., the maximum number of method iterations, and the cap on total number of simulations for the routine. Other structure el-ements deal mainly with computation, e.g., the reservoir simulator. For these elel-ements, tuning efforts are aimed at highest performance, but need to maintain accepted levels of accuracy, e.g., to achieve accurate produced volume calculations. Also, these efforts need to be configured to run at reasonable computational loads (given the limited amount of computer cores available). This involves tuning the extent of parallelization both at the lower reservoir simulation level, and at the upper level of the well placement algo-rithm. Ultimately, these type of tuning efforts need to be balanced against robustness in
cost function call execution. This means that an overall framework configuration needs to be found such that the work model simulations during optimization are able to efficiently handle (in the large majority of cases) any trial solution within a relative wide range of both well placement coordinates and controls. Principal configuration parameters in this respect are simulator solver tolerances, ranges of parallelization in each simulator run and for server job batches, and the establishing of a monitoring system to manage jobs and enforce kill–criteria for poor performance jobs, if necessary.
Work process loop: fourth part. Finally, in the fourth part of the work process loop, so-lutions from the optimization procedure are tested on the original reservoir model, and on a selected set of model realizations provided to us by Total E&P Norge AS. Essentially, solution testing involves adapting the solutions found by the procedure to the original model using standard industry tools, i.e., Petrel, and then running these new configura-tions using the original simulator, i.e., Eclipse. Solution testing is important because it enables us to communicate the results within the industry perspective of the operator, and it provides us with information about the effectiveness of the various work model approximations. Significant emphasis has been put on implementing all solutions using the original model. For this reason, Chapter 4 in this thesis performs somewhat compre-hensive presentations and analyses of each of the re–implemented solutions. It also tests the solutions for case configurations that were either approximated (e.g., production time frame) or out of scope (e.g., multiple realizations) during optimization. The overall inten-tion of this part of the work process loop is to provide potentially useful informainten-tion back to the work process of the operator. Beyond this purpose, an additional function of the set of analyses is to serve as a practical result–interface for communication with the reservoir team. By having solutions recreated using standard industry tools and results presented and analyzed in common formats, the purpose is to facilitate commentary and feedback on the results. This information can then be used to further align the problem and con-straints definitions to the business needs of the operator (thus starting a new iteration of the work process loop). Finally, a way of improving the communication task in this part of the work process loop could be to develop graphical user interfaces of core concepts of the problem definition. The function of these interfaces would be to serve as graphical representation of main features of the problem description, e.g., the different well place-ment constraints. Preferably, the re–modeling and adjustplace-ment of these interfaces would be a process performed directly on the graphical representation by the reservoir team, in interaction with the research team. Possibly, then, the use of these interfaces would fa-cilitate the translation of expert problem understanding into specialized input for, in this case, constraint parametrization.
Conclusion. The work process structure just described represents the execution of the strategy components described in the beginning of this section. At the engineering level, this work process structure joins model validation, problem definition, extensions of de-veloped methodology, and final testing of solutions on field case model, to solve for the second application target. The first target specified for this application work is addressed by the decisions and trade–offs considered during the design of the structure. IO Cen-ter Industry Partner Total E&P Norge AS has contributed to the development by provid-ing expert knowledge and the field case model for us to test our application, in addition to offering substantial feedback on the results obtained. Below we will see how the specific
research developments are realized in the procedure that deals with the optimization part of the loop. The optimization procedure, or framework, is the actual application of our methodology, and the engine producing the solutions within the entire work effort. This framework is described in the next section.