First Break - Volume 4, Issue 4, 1986

Borehole sonic logging to determine formation compressional wave slowness has been a routine procedure in the petroleum industry far many years (Summers & Broding 1952; Vogel 1952). However, the digital recording af the full waveforms from these surveys has only become a routine option in the comparatively recent past. Initially, the main motivation for the provision of full waveform sonic logs was the desire to obtain values of shear wave velocity. Nevertheless, the most cursory perusal of these data leads one to conclude that there is a great deal more infonnation to be extracted from the later arriving phases than a simple velocity estimate. This paper describes the interpretatian of full waveform sonic data with examples taken from a wide range of localities around the world. The main emphasis in this paper will be the identification of the principal phases in the microseismogram and the problems associated with the determination of formation shear velocity. In a subsequent paper (Astbury & Worthingtan 1986) other phases, identified as multiples, mode conversions and reflections, will be discussed. All the data presented were recorded with either a Schlumberger Long Spaced Sonic (LSS) sonde or a 1001 designed and operated by 'Société d Études de Mesures et de Maintenance' (SEMM). Both these tools have axially symmetric monopole sources.

I expect you're wondering what happened to Article VIII on graphics, devices, standards, usage and so on. So am I. In the meantime, I got bored waiting for me to start writing it and so I thought I would follow on from the fairly apocryphal portable benchmark article (Hatton 1985a), which evoked quite a response, and write Article VIII not on graphics, devices, standards, usage and so on, and talk more about seismic software architectures and how benchmarking can be done. The real Article VIII, or Article N where N is a large prime number inversely proportional to my interest at any one time, will have to wait until I can find something vaguely humorous to say about graphics. The problem is that programmers take it all terribly seriously-try communicating with any graphics expert, for example! In essence, seismic benchmarking attempts to estimate how much seismic data processing a particular software and hardware system can achieve. It causes more friction between normally rational geophysicists than almost anything else. A commonly used rule of thumb is the two-by-two rule. First, if the salesman gives a figure, divide it by two. This will generally give quite reasonable agreement with the programming staffs benchmark programs. However, in order to simulate the day-to-day catalogue of processing disasters, ('where's my plot gone? ... I never said that tape ... what tape? ... oh, just run it again ... I said 400 mill. Windows ... the wick in the CPU has gone out again ... '), a further factor of 2 reduction is necessary. This latter reduction is remarkably consistent and leads to an important physical invariant: The first law of benchmarking: Useful work+testing+bungling = 120% of available machine time or 30% of the estimated machine time. This paper will attempt: (a) to discuss efficiency from both practical and theoretical points of view, (b) to expand on the first FFT benchmark (Hatton-1985a), and enable a critical appraisal as to what the quoted figures mean, if anything, (c) to study host machine floating point performance compared with attached array processor performance. During the course of this I will bring the original results (Table l of Hatton 1985a) up to date with benchmark results of a number of computers from micro- to supercomputer which have been sent to me in the interim. Probably the most significant factor determining machine efficiency is that of software, both operating system and applications. I will discuss the applications category first.