Petroleum Engineering Software: Making the Right Choice in the Late 90's
Authors: Michelotti G. 
Published: December 2007

Software development is today steered by developers rather than by engineers as a result of sweeping changes in our industry. Though this produced higher computational efficiency and more flexible GUI's, the applications often lack the robustness, transparency and accurate description of the physics of the old programmes. The professional profile of the user also changed: the expert has been replaced by occasional users who often lack a deep knowledge of the application and of its technical background. This is not entirely matched by an increased "engineering" expertise from the vendors nor by an effort to make the programmes more transparent and the users more informed. Choosing the right software therefore requires to go through a 3 step process, the critical one being an extensive test and validation. Selected examples from the Company's portfolio of programmes are presented to demonstrate the risks of introducing software without testing.

Examples of costs incurred in testing petroleum engineering software, from easy to complex applications, show that it is time consuming and expensive, mainly because it requires training of expert teams with the right mix of skills. The activity is difficult to justify when all what we do is scrutinized with a short term perspective to find areas for cost cutting. Centralizing the service in the Company headquarters is one option for containing the cost without compromising on the quality. Greater savings could possibly be achieved by insourcing back part of the software development and by setting alliances between client companies sharing the same interest.

Introduction

Petroleum engineers today have the option of choosing amongst several programmes developed by specialist vendors for various platforms. The days when they had to write and compile their own programmes in FORTRAN or Basic have since long gone. Significant progresses were achieved in terms of user friendliness, portability, integration and data management, all aspects that an engineer writing his own code did not, and could not, address. But what happened to the technical robustness and transparency of the old programmes? Did the vendors succeeded in providing the same level of improvement in this area as in all other IT areas ? Is the user provided with sufficient information to make the right choice and what are the screening criteria?

The answers to these questions are not straightforward nor are probably unique for all users. But whereas answering the first two will mainly involve an assessment of the programmes, the answer to the third requires an understanding of the technical profile of the current users, of the work process and of the data flow on the one hand and of the expertise, aims and resources of the software developers on the other hand. All this has dramatically changed in the last two decades and even greater changes are likely to occur in the next few years.

Review of the industry trends

The history. Engineers in the 70's were often writing their own software to help them in their duties. More complex programmes with thousands of code lines, such as reservoir simulators, were bought and maintained by few specialized vendors. Both of them were not user friendly, were run in batch mode, required time and patience to process and display in- put/output and were installed on the Company's single platform (mainframe). Porting to other platform was not an Issue and the integration was not sought for. These programmes, though technically robust, had a limited IT content: they were basically the coding of complex algorithms. In a four quadrant plot (Fig. 1) with the engineering aspects (reliability and robustness of algorithms and code, transparency) in the y-axis and the IT aspects in the x-axis, these programmes would be described by point. The availability of more powerful and faster computers along with the diffusion of software applications led to increasing the IT content: user friendly I/O utilities, interactive applications and the need of integration made it difficult for engineers to develop programmes accepted by their peers.

P. 141