Computers and the Petroleum Engineer
Authors: Reichardt T.A. 
Published: December 2007

This paper was prepared for the 43rd Annual California Regional Meeting of the Society of Petroleum Engineers of AIME to be held in Bakersfield, Calif., Nov. 8–10, 1972. Permission to copy is restricted to an abstract of not more than 300 words. Illustrations may not be copied. The abstract should contain conspicuous acknowledgment of where and by whom the paper is presented. Publication elsewhere after publication in the JOURNAL OF PETROLEUM TECHNOLOGY or the SOCIETY OF publication in the JOURNAL OF PETROLEUM TECHNOLOGY or the SOCIETY OF PETROLEUM ENGINEERS JOURNAL is usually granted upon requested to the Editor PETROLEUM ENGINEERS JOURNAL is usually granted upon requested to the Editor of the appropriate journal, provided agreement to give proper credit is made.
Discussion of this paper is invited. Three copies of any discussion should be sent to the Society of Petroleum Engineers Office. Such discussions may be presented at the above meeting and, with the paper, may be considered for publication in one of the two SPE magazines.

Abstract
Computers have been available to the petroleum engineer for general purpose computer work for about 15 years. During these years the typical petroleum engineer's use of computers has been limited. More effective utilization has been hampered by the combination of hardware/ software systems available, remote office locations and common working habits. However, the past few years have seen significant advancements in hardware/software systems and a recognition that engineers working habits must be accommodated rather than changed. The past mode of computer utilization and the attendant problems will be reviewed, the current mode of operation and its effect will be discussed and a short projection of the future direction will be given.

Introduction
Let us consider the typical petroleum engineer as someone such as a production, reservoir or drilling engineer working in one of his company's division or district offices. In this paper his office will be considered remote in terms of not being in the immediate proximity of the computer to which he presumably proximity of the computer to which he presumably has access. The computer may be across the country or just across town in another building, but it is generally not in his office. At this point it really does not matter whether the engineer is employed by a major, independent, consultant or regulatory agency as in all cases he should have access to some "remote" computer.
Until a few years ago the computer available to the engineer was characterized by limited core storage and limited peripheral auxiliary storage devices (magnetic tapes, disks, etc.). As a result of the limited computer facility and certainly less sophisticated programming languages, the programs available were usually stand-alone programs which performed one function and did not interface with other programs which performed other functions.
During this earlier era, the engineer would manually code the necessary data for a program on a keypunch form and mail it to the computer center where it would be punched and run and then the output mailed back to the engineer. While the computer ran these problems in seconds or minutes, the entire procedure would require days. The slow turnaround was very disruptive to the normal working rhythm of the engineer who would need the results of a submitted run before he could proceed to the next step in his analysis. Any processing requiring interaction between the engineer and computer, such as history matching, was virtually impossible in this environment.
The limited peripherals and stand-alone programs largely precluded passing data from programs largely precluded passing data from program to program. program to program.