throbber
Ex. PGS 1047
`(EXCERPTED)
`
`
`
`
`
`

`
`
`
`Elernenrsflf
`3-I] Seisrnulngu
`
`Ex. PGS 1047
`
`

`
`Elements of
`3-H Seismulugu
`
`is
`
`.
`
`.
`
`.1 .-A;v:%.
`
`EX. PGS 1047
`
`Ex. PGS 1047
`
`

`
`Copyright © 1999 by Christopher L. Liner
`All inquiries should be referred to PennWel1 Publishing
`1421 South Sheridan/P.O. Box 1260
`Tulsa, Oklahoma 74101
`
`
`
`Cover Design by Matt Berkenbile
`Book Layout by Geoff Harwood with Stormgrafx
`
`All rights reserved. No part of this book may be reproduced, stored in a
`retrieval system, or transcribed in any form or by any means, electronic or
`mechanical, including photocopying and recording, without the prior written
`permission of the publisher.
`
`Printed in the United States of America
`
`12345040302010O
`
`iv
`
`EX. PGS 1047
`
`Ex. PGS 1047
`
`

`
`
`
`§ 1 E
`
`
`
`__._.4—.£-(x4:-~.Amu-.—.——-—-——-j<-—-——-——---
`
`<1?
`
`IElements of3-D Seismology
`
`CD
`
`GMP Fold
`
`For a 3-D survey to yield good data quality, the target fold should
`be about one-half of the fold required to shoot good 2-D data in the
`area. This is a result of migration and dip moveout which result in more
`mixing of 3-D data than occurs in 2-D.
`Some points on fold
`
`1. High fold costs more at acquisition time
`2. Low fold (< 10) 3-D has been successful
`3. Lower fold with right bin size may be better than high fold
`with too large a bin
`
`Spatial aliasing is an effect of trace spacing relative to frequency,
`velocity, and slope of a seismic event. With adequate trace spacing, the
`points along a seismic event are seen and processed as part of the con-
`tinuous event. When trace spacing is too coarse, individual points do
`not seem to coalesce to a continuous event, which confuses not only the
`eye but processing programs as well. This can seriously degrade data
`quality and the ability to create a usable image.
`Figure 7-6 shows one way of defining spatial aliasing. In this view
`spatial is based on trace-to-trace delay associated with a clipping reflec-
`tor. Since the delay is related to trace spacing, the issue is really one of
`midpoint interval. This, in turn, is related to shot and receiver interval.
`For 2-D data, mid oint s acin , A4,-, shot interval, Si, and receiver
`P
`P
`g
`group interval, R,-, are related by
`
`
`
`M, = % Mz'n(S,-, R,-)
`
`To avoid spatial aliasing on the stack section we require
`
`M, <
`
`4 fm Sz'n0
`
`
`
`(7.10)
`
`(7.11)
`
`EX. PGS 1047
`
`Ex. PGS 1047
`
`

`
`
`
`Chapter 7 Survey Predesignj(I)
`
`where um, is the interval velocity near (or immediately above) the target,
`fmx is maximum signal frequency and 0 is the physical dip angle of the
`reflecting bed. When interval velocity is not known, average velocity can
`be used. But this will give a bin size estimate that is smaller than
`required. The design condition is rightly based on maximum frequen-
`cy, but the dominant frequency is often used. This means high fre-
`quency components risk being aliased.
`Spatial aliasing is not difficult to recognize on real data, (Figure 7-
`7). The main problem with spatial aliasing is the detrimental effect it
`has on two very expensive processes: dip moveout and migration.
`Figures 7-8 and 7-9 give a migration example.
`We note for design purposes that diffraction limbs (Figure 7-4)
`appear as 0 = 90° events. The Sin6 term is sometimes invoked to justify
`a non—square bin in 3-D shooting. However, this increases risk of spa-
`tially aliasing the data, so the safe design rule is to use 6 = 90°. In this
`case, the midpoint spacing condition reduces to M < /\,,,,,,,/4. This agrees
`with the minimum bin size requirement, Adm/4, for a 3-D survey as dis-
`
`cussed in chapter 14.
`The unaliased midpoint interval grows with depth due to increas-
`
`ing velocity and decreasing frequency.
`Some points on spatial aliasing
`
`1. Safe direction is smaller
`
`2. Will be different for shallow and deep targets
`3. Use fma, and 6 = 90° for safest midpoint interval
`4. Smaller midpoint interval costs more at acquisition time
`5. Same equation for 2-D midpoint interval and 3-D bin size
`
`
`
`__.....__,..;5.n_=....4-45.4_
`
`
`
`EX. PGS 1047
`
`Ex. PGS 1047
`
`

`
`<13
`
`JElements of3-D Seismology
`
`(I)
`
`
`
`
`
`2-ll Suruev size
`
`This calculation shows how much disk space is needed to store a
`moderate 2-D seismic line in SEGY format:
`
`lsample value
`6 secs data @ .004 sec sample rate
`1,500 * 4 + 240(header)
`96 channel * 800 shots
`76,800 traces * 6,240" bytes/trace
`add line headers 3600 bytes
`479,232,000 / (1,024)"2
`
`=
`=
`=
`=
`=
`~
`
`4 bytes (floating point \#)
`1,500 samples/trace
`6,240 bytes/trace
`76,800 traces
`479,232,000 bytes
`479,235,600 bytes
`457 Mb
`
`From the typical RAM and disk storage numbers above, we con-
`clude that the 2-D seismic line can fit
`
`1. in RAM of a large wk or small sc
`
`2. on disk of a wk or pc
`
`The RAM issue is important because some processes (e.g.,
`prestack migration) want to hold the entire data set, plus work space, in
`RAM. If it can't all be stuffed into RAM, we are left with a significant
`
`data management problem.
`
`3-n Suruev Size
`
`Do things get better for 3-D seismic data? Hardly. Large 3-D sur-
`veys today can contain hundreds of millions of prestack traces. This cal-
`culation shows the size of a medium—sized 3-D data set composed of 500
`
`2-D lines like the one above:
`
`.
`
`.
`
`206
`
`EX. PGS 1047
`
`we
`
`._,|1i,
`
`Ex. PGS 1047
`
`

`
`Chapter 77 Computing NeedsJ(1)
`
`[38,400,000 traces!]
`
`500 2-D lines
`
`500 lines * 479,235,600 bytes/line
`2.39616*10"11 bytes
`228 515 Mb
`223 Gb
`
`12|||l
`
` (1)
`
`This amount of data will not fit in RAM of any existing sc (not
`even close), but we could probably find enough pasture for it on the
`disk farm.
`
`P|'0GESSiIl9 Sllflflll
`
`RAM and disk storage are part of the seismic computing bottle-
`neck; the other problem is processing speed. It is of little use to squeeze
`a mass of seismic data into computer RAM if, once there, it takes 2 or 3
`years to process it.
`The fundamental unit of processing is the flop. To confuse the
`uninitiated, the flop is both an operation, floating point operation, and a
`rate, floating point operations per second. Here is a table of processing
`speed units.
`
`t
`
`flop
`
`=
`=
`=
`sqrt()
`1 megaflop =
`1 gigaflop
`=
`1teraflop
`=
`1 petaflop
`=
`1 exaflop
`=
`
`floating point operation + */
`floating point operation per second
`10 15 floating point operations
`10"6 flop =1 Mflop
`10"9 flop = 1 Gflop
`10"12 flop =1Tf|op
`10/‘15f1op =1 Pflop
`10"18 flop =1 Eflop
`
`As with petabyte and exabyte, the last two terms are not yet in
`common use. We don't have machines that fast. The current world
`speed record for computer processing is around 1 teraflop in perform-
`ance.
`
`The alert reader will see inconsistent use of prefixes between
`megabyte and megaflop. A megabyte is 1,0242 bytes, but a megaflop is
`1,0002 flops.
`There are many different approaches to achieving high flop rates.
`None of them are cheap. Some typical, and not so typical, processing
`speeds are:
`
`
`
`EX. PGS 1047
`
`Ex. PGS 1047
`
`

`
`J Elements of3—D Seismology
`tin
`
`pc
`wk
`sc:
`
`=
`=
`
`10 Mflop
`60 Mflop
`
`(1 cpu)
`(1 cpu)
`
`Cray 2
`SGI Power Challenge
`Hitachi SR2201
`
`IBM SP2/402
`Cray T3D MC512-8
`lnte1XP/S
`SGI T3E900
`SGI T3E1200
`lnte1ASC| Red
`
`1.6 Gflop
`110 Gflop
`220 Gflop
`690 Gflop
`510 Gflop
`700 Gflop '
`800 Gflop
`900 Gflop
`1.3 Tflop
`
`(4 cpu)
`(288 cpu)
`(1,024 cpu)
`(402 cpu)
`(512 cpu)
`(3,680 cpu)
`(1,324 cpu)
`(1,084 cpu)
`(9,152 cpu)
`
`=
`=
`=
`=
`=
`=
`
`We should all realize that any list of supercomputer speed is
`extremely volatile. It certainly needs to be updated every 6 months or
`so. The list given here is a mix. Some machines (like the Gray 2) are no
`longer in production. The fastest machine listed (Intel ASCI Red) has
`been online since 1997.
`
`For the latest and greatest information on such things, visit the
`TOP500 web site which aspires to keep an up—to—date list of the world's
`fastest supercomputer installations. The URL is
`http://wvvw.netlib.org/benchmark/top500/top500.list.html
`
`Snead and 3-D Migration
`
`Prestack migration is the classic example of our need for this
`expensive speed. Assume that migration involves 10,000 floating point
`operations per data sample. This is the effort it takes to broadcast each
`input amplitude along an image surface that resembles a lumpy bowl.
`A major part of this work is tied up in calculating the exact geometry of
`the lumpy bowl.
`
`208
`
`EX. PGS 1047
`
`Ex. PGS 1047
`
`

`
`Chapter 77 Computing NeedsJ N(I)
`
`We can estimate how much time is required for 3-D prestack
`depth migration the medium-sized 3-D data set:
`
`Data size:
`
`Assume migration
`total floating point operations
`pc
`=
`wk
`=
`Cray 2
`=
`SGI Power Challange
`=
`SGI T3E1200
`=
`Intel ASCI Red
`=
`
`1,500 samp/trace * 38,400,000 traces
`= 5.76 x10"10 data samples
`= 10,000 operations/sample
`=5.76X10"14
`
`333 days
`90 days
`100 hours
`87 minutes
`9 minutes
`7.4 minutes
`
`(disk?,RAM?,speed?,i/0?,forget it!)
`(disk?,RAM?,speed?,|/0?,good luck!)
`(RAM?,|/O?,dedicated?)
`(RAM?,|/O?,dedicated?)
`(RAM?,l/0?,dedicated?)
`(RAM?,|/0?,dedicated?)
`
`The qualifier "dedicated" is added to highlight the fact that it is
`unusual to have a super computer working on only one problem at a
`time. More likely, jobs are queued up like traffic on a Los Angeles free-
`way, thus slowing work on any given job. There also are issues of disk
`storage, data transfer rates, and grossly insufficient RAM. We should
`therefore consider these estimates extremely optimistic.
`
`
`
`209
`
`EX. PGS 1047
`
`Ex. PGS 1047

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket