3dpresdm.pdf

3D Prestack Depth Migration

This chapter explains key processing steps, flowrequirements, and usage guidelines of the ProMAX® 3DPrestack Depth Migration (3D PreSDM).

In This Chapter

➲ 3D Prestack Depth Migration Overview

➲ 3D Prestack Depth Migration Workflows

➲ 3D Travel Time Grid Definition

➲ 3D Travel Time Grid Definition from Headers3014

➲ 3D QC Travel Time Plot 3020

➲ 3D Travel Time Generator 3026

➲ 3D Prestack Depth Migration

➲ Access 3DPSDM Checkpoint File30340343034

Other Docs Known ProblemsSearch Page

Overview1706 ProMAX® Reference

Overview

This overview discusses the requirements and guidelines forrunning the 3D Prestack Depth Migration package. We willdiscuss in detail the following topics:

➲ Dataset Requirements

➲ Velocity Model Requirements

➲ Preprocessing Requirements

Statics

Muting

Filtering

Binning

NMO

DMO

Deconvolution

Scaling

➲ Flow Requirements

➲ Usage Guidelines

Imaging Options: Target vs. Volume

Target Oriented 3D Volume

Defining the relationship between the grid, traveltimes, and the migration

Determining sparse gathers parameters for velocity analysis

Using 3D QC Travel Time Plot

Using Save Depth and Restart

Comparing Original gathers and Image gathers

➲ Post Processing Guidelines

Post Migration Statics

Post Migration Muting

Post Migration Filtering

Post Migration Scaling

The ProMAX® 3D Prestack Depth Migration product isdesigned to be a fast, efficient, and flexible process for targetoriented 3D prestack migrations. Output targets include:



• Selected Inlines

• Selected Crosslines

• Sparse gathers for quality control or velocity analysis

• Target oriented volumes

The 3D Prestack Depth Migration product consists of severaladditional processes to the ProMAX® 3D processing system;three out of four are required to prestack depth migrate yourdata and one is an optional process. These processes mustrun in a series of steps to prestack depth migrate yourdataset. We have included the following requirements andguidelines to help you get the best results from 3D PrestackDepth Migration.

• Dataset Requirements

• Preprocessing Requirements

• Flow Requirements

• Usage Guidelines

• Postprocessing Guidelines

Dataset Requirements

There are several requirements that must be met beforetrying to 3D prestack depth migrate your data:

• You must create a 3D velocity model.

• You must have enough disk space to store traveltimefiles.

• You must have an SMP machine running threads, suchas IBM-Power PC, SGI-Sgimips4, Sun-Solaris to runmulti nodes.

Velocity Model Requirements

You must create a 3D depth/interval velocity model. Thismodel must to be hung from a flat datum higher than thehighest point on the line, not a floating datum (See 3DTravel Time Generator).

Note: Because 3DPSDM migrates from topography, thevelocity between the flat datum and topography does not



matter, but in practice the velocity should be close to thesurface velocity.

Migration from Topography.

If your depth/interval velocity model is converted fromstacking/RMS/DMO velocities via Dix, the interval velocitymodel is probably hung from a floating datum. This cancause errors if there is topography. Marine surveys do nothave this pitfall

B

Topography

A

Flat Datum

Figure A is the true earth model and flat datum abovetopography that will be used.

Figure B is the velocity model hung from the flat datumabove topography.

Since the source and receiver elevations are in thedatabase, traveltimes are determined from topography.Traveltimes are not generated between the flat datum andtopography (X). The velocity in region X is not used, thuscan be any value, but in practice is the should be close tothe surface velocity, as displayed in figure B.

X



Stacking velocities from a floating to a flat datum.

When RMS velocities are picked, you will have an RMS velocitymodel as seen in figure D. If this model is then converted directlyto a depth/interval model, via Dix without correction to a flat datumand used in 3DPSDM, the migration will use the velocity model asseen in figure E.

Topography

Correct Answer

RMS velocities are often picked from a floating datum

For this example the trueearth velocities dip tothe right(A).

A floating datum is determined(B), then all subsequent velocitiesare picked relative to the floating datum(C).

A

B C

D E

Floating datum

Flat Datum

Figure E, does not have dipping velocitiesas in figure A, and the velocities attopography are wrong. By properlydatumizing from a floating to a flat datum,the velocity model in figure F can beobtained.

See the 3D Prestack Depth MigrationWorkflows for the methodology tocorrectly datumize your velocity model.

F



If your velocity model is not hung from a flat datum, see the3D Prestack Depth Migration Workflows for themethodology to change from a floating datum to a flat datum.

Preprocessing Requirements

3D PreSDM requires good quality seismic data in order toobtain good results. Below are some processing suggestionsand requirements that can help prepare your seismic data for3D PreSDM.

Statics

Statics may be applied for determining an RMS velocity fieldand other processes. However, all statics except for residualstatics should be removed from the input before using 3DPrestack Depth Migration. Datum statics are not neededbecause the migration images from source and receiverelevations that are stored in the Database; not necessarilyfrom a flat datum.

Muting

Do not mute off steep dips, especially deep in the section.

Filtering

Determine and apply a filter to the prestack data as youwould for standard processing.

Binning

The prestack data must match the database. DMO binning orFlex binning is not recommended because it will change theprestack data relative to the Database.

NMO

NMO may be applied to the data for multiple removal, statics,and other processes. However, you must back out NMO fromthe input prior to using 3D Prestack Depth Migration.

Caution: If NMO is applied in complex areas, you may affectyour data without noticing it due to non-hyperbolic moveout.



DMO

Do not apply DMO to the data because it is a partial prestacktime migration. The input data must be completelyunmigrated prior to using 3D Prestack Depth Migration.

Deconvolution

Determine deconvolution parameters and apply as you wouldfor standard processing.

Scaling

The amplitudes on the input data to should be equalizedbefore migration. A long window AGC, spherical divergence ortrace balancing should scale the data properly.

Flow Requirements

The 3D Prestack Depth Migration product consists of severaladditional processes to the ProMAX ®3D processing system;three are required to prestack depth migrate your data andthe rest are optional processes. These processes must run ina series of steps and each step has an effect on the next.

1. 3D Travel Time Grid Definition defines all possibletraveltime locations and the maximum data area used in3D prestack depth migration. This stand alone process isused when trace headers match the database.

2. 3D Travel Time Grid Definition from Headers definesall possible traveltime locations and the maximum dataarea used in 3D prestack depth migration. This process isused when trace headers do not match the database.

This process needs a data input process such as DiskData Input, preceeding it in the flow and a data outputprocess such as Disk Data Output following it.

3. 3D QC Travel Time Plot is an optional step thatcalculates 3D traveltimes for one shot using an Eikonalsolver. The output is a ProMAX® data file. You can viewthis file in Trace Display to quality control the fidelity ofthe traveltime calculations.

This process is a data input process and, therefore, needsa data output process such as Disk Data Output or TraceDisplay following it in the flow.



4. 3D Travel time Generator calculates and stores on disk3D traveltimes using an Eikonal solver. The 3Dtraveltimes are used in the imaging step of 3D PreSDM.

This is a stand alone process.

5. 3D Prestack Depth Migration performs Kirchhoffmigration by applying a precomputed Green’s function(traveltimes) to each requested CDP location.

This process needs a data input process such as DiskData Input, preceeding it in the flow and a data outputprocess such as Disk Data Output or Trace Displayfollowing it.

Usage Guidelines

3D PreSDM offers many ways to migrate your data. Below areguidelines for key options that will let you obtain the bestresults.

• Imaging options: Target vs. Volume.

• Target oriented 3D Volume

• Defining the relationship between the grid, traveltimes,and the migration

• Determining sparse gathers parameters for velocityanalysis

• Using 3D QC Travel Time Plot

• Using Save Depth and Restart

• Comparing Original gathers and Image gathers

Imaging Options: Target vs. Volume

Choosing between the Target option and the Volume option inthe 3D Travel Time Generator and 3D Prestack DepthMigration can be a tough decision. The target option isefficient for outputting target inlines and crosslines. It is alsoeffective for small volumes. However for migrating entirevolumes, or where you need to limit the inline/crosslineaperture, the volume option can save run time.

Caution: Selecting Volume when migrating targets or smallvolumes without limiting the aperture can increase run timeby an order of magnitude.



The following are a few of the differences between the twooptions:

In this example, assume 3D Travel Time Grid Definition wasrun and grid nodes are located as seen below; also assumeonly inlines are to be migrated.

Grid Node Locations.

Target generates and later migrates only the followinginlines, without rerunning the 3D Travel Time Grid Definitionand shifting the starting point (If minimum Inline=1, forsecond run, it will need to be set to 2).

Volume migrates all of the inlines in one run of themigration.

Iln12

Iln14

Iln16

Iln18

Iln20

Xln

5

Xln

10

Xln

15

Xln

20

Xln

25

Inline direction

Xline direction

= Defined Grid Node location#

#

#

#

#

#

#

Every 2nd Inline is displayedEvery 5th Xline is displayed



Target vs. Volume possible outputs.

Target and Volume options also differ in the amount of dataallowed into each migrated location.

• Target migrates every trace in the entire 3D onto anyoutput location.

• Volume allows you to define an inline and crossline aper-ture, which only allows data from a specified number ofinlines and crosslines away to image onto a specific out-put location.

Iln12

Iln14

Iln16

Iln18

Iln20

Xln

5

Xln

10

Xln

15

Xln

20

Xln

25

Inline directionX

line direction


#

#

#

#

#

#


Possible Output Inlines in 1 run: TargetVolume &

Target only outputs inlines (or crosslines)on lines with grid nodes.

Volume interpolates traveltimes betweengrid nodes, thus every line can be output.

Volume should only be used on larger vol-umes or where inline/crossline aperturecan be used, otherwise runtimes canincrease by an order of magnitude.



Inline/Crossline aperture comparison: Target vs. Volume.

If the Volume option is selected, several database attributesneed transferred to the trace headers. Please See the 3DPrestack Depth Migration documentation or the 3DPrestack Depth Migration Workflows for the exactattributes and header names.

Iln12

Iln14

Iln16

Iln18

Iln20

Xln

5

Xln

10

Xln

15

Xln

20

Xln

25

Inline directionX

line direction

#

#

#

#

#


Iln12

Iln14

Iln16

Iln18

Iln20

Xln

5

Xln

10

Xln

15

Xln

20

Xln

25

Inline direction

Xline direction

#

X

X

X - Imaging point

- Traces that contribute toimaging point

Target Option

Volume Option

For the Target option, the apertureis set to the entire 3D survey, or putanother way, every trace in the 3Dcan contribute to any given imagingpoint.

For the Volume option, only traceswithin the aperture limits defined inthe 3D Travel Time Generator menucan contribute to any given imagingpoint.

If the aperture is set to the entiresize of the 3D survey, as in the tar-get option, you will get the sameresults, but take much longer tocomplete.



Target oriented 3D Volume

You can 3D prestack depth migrate an entire 3D volume.However, due to time and cost restrictions, you shouldconsider a target oriented 3D prestack depth migration. Bytarget oriented, we mean that you can focus on a subset ofthe 3D volume.

Each process can create subsets of the data from theprevious step.

1. 3D Travel Time Grid Definition or 3D Travel Time GridDefinition from Headers defines the grid for traveltimecalculation and delimits the data to your target.

2. 3D Travel Time Generator calculates traveltimes on allor a part of the subset survey from step one. Traveltimescannot be generated on locations that do not have a gridnode from step one.

3. 3D Prestack Depth Migration migrates onto all or asubset of the traveltimes calculated in step two. Data maynot be migrated onto inlines or crosslines that have nothad traveltimes calculated from step two.

See the 3D Prestack Depth Migration Workflows for themethodology to output a target volume.

Target oriented 3D volume from process to process.

Entire 3D survey

3D Travel Time Grid Definition

3D Travel Time Generator

3D Prestack Depth Migration

Target Oriented 3D survey after:

Each step can define a subset equal to or smaller thanthe previous step. Each step cannot define a subsetlarger than the previous step.

(Selected Output InlineTravel Times only)

(Migrate and output every2nd crossline along inlines)



Defining relationships between grid, traveltimes, and migration

When determining the traveltime grid, keep in mind that theway you define the grid will effect the remaining steps. In the3D Travel Time Grid Definition or 3D Travel Time GridDefinition from Headers menu, the Spacing for Travel TimeFunctions between Inlines and Spacing for Travel TimeFunctions between Xlines parameters can impact results. Theexample below outlines this methodology.

For this example, grid nodes will be set at the intersection ofevery 4th inline and every 10th crossline.

Note: A grid node at every 4th inline and every 10th crosslineis being used for demonstration purposes. For productionwork, node spacing for every 2nd inline and every 2ndcrossline is recommended. Values less than 2 will increaserun time and disk space usage later when traveltimes arecalculated. Values greater than 2 will reduce both run timeand disk space usage but will also decrease the resolution inlater traveltime calculations.

If the Spacing for Travel Time functions between Inlinesparameter in the 3D Travel Time Grid Definition or 3DTravel Time Grid Definition from Headers menu is set at 4for inlines and 10 for crosslines, traveltimes can only becalculated at the intersection of those locations.



Grid Node Locations.

While traveltimes can be calculated for a subset of the abovegrid, for this example, let us use 3D Travel Time Generatorto calculate traveltimes on every grid node. The primarycalculation orientation for traveltimes, in this example, willbe inlines. Select Yes for the Output Inline traveltimesparameter. Next we will migrate inlines using 3D PrestackDepth Migration. If we migrate just the inlines, we canoutput inlines no denser than the spacing of the calculatedtraveltimes.

Iln12

Iln14

Iln16

Iln18

Iln20

Xln

5

Xln

10

Xln

15

Xln

20

Xln

25

Inline direction

Xline direction


#

#

#

#

#

#




Migrated Output.

The traveltimes are used in 3D Prestack Depth Migration tomigrate the data. For sources and receivers that are not onthe traveltime grid, 3D Prestack Depth Migration interpolatesthe traveltimes closest to the shot and receiver location.

Note: A grid node at every 4th inline and every 10th crosslineis being used for demonstration purposes. For productionwork, node spacing for every 2nd inline and every 2ndcrossline is recommended. Values less than 2 will increaserun time and disk space usage later when traveltimes arecalculated. Values greater than 2 will reduce both run timeand disk space usage but will also decrease the resolution inlater traveltime calculations.

Iln12

Iln14

Iln16

Iln18

Iln20

Xln

5

Xln

10

Xln

15

Xln

20

Xln

25

Inline direction

Xline direction

*

*

*

*

*

*

= Defined Traveltime location*Every 2nd Inline is displayedEvery 5th Xline is displayed

= Possible migrated output



Traveltime Interpolation.

Determining sparse gathers parameters for velocity analysis

Each process in 3D PreSDM needs a specific setup to obtainsparse gathers for either velocity analysis or quality control.The example below outlines this methodology.

This example will outline how to output a 3D prestack depthmigrated gather at every 50th inline and every 40th crossline.You should use 3D Travel Time Grid Definition to define agrid point at every 2nd inline and every 2nd crossline. Valuesless than 2 will increase run time and disk space usage whentraveltimes are calculated. Values greater than 2 will reduce

To migrate one trace to image point Q, a travel time isneeded from both the source, S, and the receiver, R.Since there is no traveltime at either S or R, the closestlocations will be used: B and E.

The traveltimes for the source to Q will now beinterpolated from the traveltimes B to C and B to D.Likewise, the traveltimes for the receiver to Q will nowbe interpolated from the traveltimes E to C and E to D.

Iln12

Iln16

Iln20X

ln5

Xln

15

Inline direction

Xline direction

*

*

*

*

*

*

*A B

C D

S

RR = Receiver

S = Source

= Travel Time LocationA-F

Q = Image Point

Q

= Inlines to migrate onto

FE



both run time and disk space usage but will also decrease theresolution in later traveltime calculations.

3D Travel Time Grid Definition

In the 3D Travel Time Generator menu, it does not matter ifyou output either inline or crossline traveltimes, but there isno general need to output both. For this example, we willoutput inline traveltimes at every 50th inline location. Enter50 in number of inlines for the Increment Between Inlines toOutput parameter.

3D Travel Time Generator

In the 3D Prestack Depth Migration menu, enter 40 innumber of crosslines for the Output Spacing Between Xlinesparameter. When executed, a gather located at theintersection of every 50th inline and every 40th crossline willbe output.

InlineX

linedirection

directionOnly every 25th inlineand every 20th crosslineis displayed in thesefigures.

Generate travel times on every 50th inline



3D Prestack Depth Migration.

The above example calculates inline traveltimes, but thesame holds true if crosslines traveltimes were calculatedinstead of inline traveltimes.

See 3D Prestack Depth Migration Workflows for exactmethodology used to output sparse gathers.

Using 3D QC Travel Time Plot

3D QC Travel Time plot is an optional quality controlprocess that determines acceptable parameters for the 3DTravel Time Generator. 3D QC Travel Time Plot calculates3D traveltimes for a single shot or receiver location andcreates a “seismic” dataset where each sample in the datasetis a traveltime as a function of X,Y and Z.

3D QC Travel Time Plot flow

3D QC Travel Time Plot

Disk Data Output (Optional)

Disk Data Input (Optional)

Trace Display

See 3D Prestack Depth Migration Workflows for exactmethodology.

To view the traveltimes with Trace Display, set the DisplayMode to Color, the Trace Scaling Mode to Range-Limited, GetMin/Max Amplitudes From the Data to No, Specify minimumamplitude to display to 0 (zero) and Specify maximumamplitude to display to 4000 (You may run AmplitudeStatistics to get a better value for your data). The amplitudevalue seen in Trace Display is the calculated traveltime. Also,changing the color scale from the default spectrum to one

Output every 50th crossline along inlines

* * **

* * **

* * **

* * **that have had travel times generated

- Location ofmigrated output*gather



that has more obvious color breaks, like rainbow3.rgb, willbetter highlight the traveltimes.

Colormap Differences

Execute the process several times, varying the shot location.If you see irregularities through trial and error, change thefollowing parameters to reduce these artifacts: DepthSampling Interval of Output Traveltimes and ComputationDepth Sampling Factor. Once acceptable parameters aredetermined, transfer these parameters into the 3D TravelTime Generator menu.

Modified colormap(Rainbow3.rgb): With morecolorbreaks, the traveltimecontours are much easier tosee.

Travel Times displayed in Trace Display.Shot location is at crossline number 41

Default colormap: It is difficultto see the contours of thetraveltimes.



Looking at QC traveltimes

Using Save Depth and Restart

Traveltime datasets can easily become larger than theavailable disk space. For this reason, it is often necessary tocalculate traveltimes and migrate your 3D survey in pieces.You can do this by using the Restart from a Previous SaveDepth and Save Depth For Travel Time Functions parametersin 3D Travel Time Generator. This technique is also useful

- In this example a veryunreasonable parameter forOutput Travel Time DepthInterval was used to inducean artifact.

Colors are travel timesthrough a smoothbasically V(z) velocitymodel from a shotlocated at Inline 60, Xline150.

Figure A showsirregularities in the traveltimes.

Sometimes irregularitiescan be explained by acomplicated velocitymodel, however, herethey are caused by theOutput Travel Time DepthInterval beingunreasonably large.

By changing theparameters, the artifactscan be eliminated, figureB.

A

Output Travel Time

Computation depth

Depth Interval - 500

sampling factor - 2

Output Travel Time

Computation depth

Depth Interval - 50

sampling factor - 2

Irregularities

*

*

*B



in layer stripping. Once the velocity is determined to aspecific depth, you only have to migrate to that depth once,allowing you to work on the next deeper section.

If a non-zero value is used for Save Depth for Travel TimeFunctions, a slice of traveltimes will be saved. You can usethese saved traveltimes to calculate traveltimes deeper in thesection, overwriting the previous traveltime file. Byoverwriting previously used traveltime files, the disk spaceused is reused instead of doubled.



Concept of the Travel Time Save Depth and Restart.

See 3D Prestack Depth Migration Workflows for exactmethodology to use Save Depth and Restart.

Comparing Original gathers and Image gathers

Image gathers are a different way to bin the traces outputfrom 3DPSDM. Data binned with respect to the shot toreceiver distance are Standard or “Original” offset gathers.

- Migrated stacks are pictured. However,the same technique works for migratedgathers.

1. Calculate traveltimes to a specifieddepth and save bottom slice oftraveltimes, A.

2. Migrate to the bottom of thecalculated traveltimes, B.

3. Calculate traveltimes from Savedepth to next specified depth andsave bottom slice of traveltimes,overwriting the old traveltime file, C.

4. Migrate to the bottom of thecalculated traveltimes, D.

5. Repeat steps 3 and 4 until data ismigrated to the desired depth.

6. Add different migrations together toget final result, E.

A

C

A

Save depth travel time slices -

Migrated lines

B

D

E

**

Note: In the 3D Travel Time Generator menu, theSave Depth for Travel Time Functions value should beevenly divisible by the Depth sampling interval ofoutput travel times (ft./m) or errors will result near



Data binned with respect to the sum of surface distancesbetween the source to common surface location and receiverto common surface location are Image offset gathers

Original and Image Offsets

For flat dips, data is distributed on each type of gather thesame. However for dipping events, each gather isconsiderably different. The following figures show thesimilarities and differences of original gathers and imagegathers.

Image offset migratedtraces are binned to tracesbased on the distance fromthe source to the CSL tothe receiver (I).

A = CRP (Common Reflection

CSL = Surface location of the

RP =The ray path from theA

R = Receiver location

3D Perspective

S = Shot location

CSL

CSL

Top View Top View

O

S

R

CSL

R

S

S

R

RP

Original Offset = O Image Offset = I

CRP (CSL =CommonSurface Location)

source to A to the receiver

Original offset migratedtraces are binned to tracesbased on the distance fromthe source to the receiver(O).

I

I = I + I

I1

2

1 2

Point) location at depth



Original gathers and Image gathers with flat reflectors

When dips are flat and thevelocity is constant, Originalgathers and Image gathersmap data to the samelocation.

Cross section View

S3

CRP

S2

Reflector dips = 0 (zero)

Image Gather

Original Gather

R = Receiver locationS = Shot location

RS1 1 R 3R2

Near offset Far offset


Note: The maximum offset for image gathers is typically twice as largeas the maximum offset for original gathers



Original gathers and Image gathers with dipping reflectors

Velocity Analysis

Original gathers are similar to CDP gathers in that if thecorrect velocity is used, reflectors will be flat. A velocity thatis too fast or too slow will cause frowning or smiling along anevent. This familiar response makes original gathers well

With dipping reflectors,original gathers map dataacross all offsets. Imagegathers focus the energyonto a few offsets.

Image gathers map steeperdips onto farther offsets.Because of this, muting canact like a dip filter.

Cross section View

S3

CRP

S2 RS1 1 R2 R3

Reflector dips >0 (zero)

Image Gather

Original Gather

R = Receiver locationS = Shot location

Far offset


Near offset

Note: The maximum offset for image gathers is typically twice as largeas the maximum offset for original gathers



suited for Residual Moveout (RMO) velocity updatingtechniques such as layer stripping and Derigowski’s loop.

Image gathers display a similar behavior to velocities, in thatif the correct velocity is used, reflectors will be flat. A velocitythat is too fast or too slow will cause “frowning” or “smiling”along an event, but the smile and frown is not centeredaround the zero offset trace making it very difficult for RMOdependant velocity analysis techniques.

Velocity analysis techniques based on stack response, suchas Constant Velocity Half Space (CVHS) are very well suitedto both original and image gathers.

Stack Response

Original gathers distribute energy from reflectors on everyoffset, making it difficult to reject noise.

Image gathers focus dipping reflectors onto a few offsets.Because of this, top, bottom and surgical mutes can bepicked leaving all of the signal and eliminating most of thenoise that would be stacked in with original gathers. Thisleads to a very clean, relatively noise free stack.

Note: To get the full benefit of migrated image gathers,muting must be done before stack.

Caution: must be used when muting image gathers. Mutingimage gathers is similar to dip filtering where muting off faroffsets can mute out steep dips.

For more on Original gathers and Image gathers, see theAppendix.



Stack Response.

Postprocessing Guidelines

After the data has been 3D prestack depth migrated, thegathers can be improved with post migration processing. Youneed to realize that the data is now in depth, not time.Because most processes in the ProMAX® processing systemare designed to operate on time series (time data) not on areflectivity sequence (depth data), you must be careful inprocessing depth data.

Most time processes will work on depth data but theparameters will be quite different than normal.

Typically a trace mute and a bandpass filter will clean up thedata enough to obtain a good stack, but for velocity analysisor quality control, the gathers usually require a bit moreprocessing.

Note: Remember that the data is now in depth, not time.

Image gather stackOriginal gather stack

Each stack was processed with comparable steps. Thedata was prestack depth migrated, muted and stacked.The only real difference is the way the migrated data wasoutput, original gathers vs. image gathers.

* **

NOTE: Muting after migration must be done to get fullbenefit of image gathers



Post Migration Statics

Trim statics may be applied to the migrated prestack data,but is usually not required.

Post Migration Muting

The migrated gathers will need a top mute to removemigration artifacts. A top mute on depth data is picked thesame way as time data using Trace Display to pick a muteand applying it with Trace Muting.

If Image Offset Gathers were created in the migration, abottom mute might also be needed. Because on image offsetgathers, energy from dipping events appears on longer offsetsthan that from flat events, caution needs to be exercisedwhen muting Image Offset Gathers so the muting does notact as a dip filter.

Post Migration Filtering

After a 3D prestack depth migration, the data will needfiltering, especially to remove low frequencies caused by themigration operator going to 90 degrees.

The most technically correct way to apply a time filter todepth migrated data is to depth-to-time convert the data,apply the filter, then time-to-depth convert the data back todepth.

Converting data from depth to time and back can take a lot oftime, disk space and is often not necessary. You can use timefilters on depth data and get very good results, but you mustadjust the filter points.

Typical time data will have filter points of 4-5-45-60, whiletypical depth data will have time filter points of 1-2-10-15.Depth data can be put into Interactive Spectral Analysis tohelp determine the filter points of the depth data.

Post Migration Scaling

Automatic Gain Control (AGC) is the most common postmigration scaling option used. AGC works the same on depthdata as it does on time data, but because the depth sampleinterval (~10 m/30ft.) is bigger that of time data (~4 ms), theoperator length needs to be adjusted.



While AGC operator lengths for time data is typically 500-1000 ms, operator lengths of 1500-3000 m (4500-5000 ft.)should be used for depth data.

APPENDIX

Data is binned differently for Original gathers and Imagegathers. The following stacking chart shows the differencebetween original and image gathers. Data for Original gathersis binned in a rectangular pattern as seen on the stackingchart. Data is binned in a circular pattern for image gathers.Stacking Chart of Original and Image Gathers **

Another way to look at original gathers and image gathers isto look at how the data is summed along a diffractionsurface. Original gathers are summed along constant offset,while image gathers are analogous to summing along circlesat constant depth.

** ** **Original Offset

CD

P

Image Offset

Original offsets are binned in rectangular pattern

Image offsets are binned in a circular pattern

For simplicity reasons, a 2D stacking chart is displayed

* - Source- Receiver

**

Comm

on S

hot



Original Gathers Summation

Image Gathers Summation

Displayed on the left is a diffractionsurface.

Original offset gathers, in 2D, arecreated by summing along theedge of the diffraction on constantoffset planes.

In 3D, diffractions are also summedin the Y direction.

Depth

X

Offset

Displayed on the left is adiffraction surface.

Image offset gathers, in 2D, areanalogous to summing alongthe edge of circles at constantdepth.

In 3D, by adding the thirddimension, image gathers areanalogous to summing alongthe edge of spheres.

Depth

Offset

X


3dpresdm.pdf

Documents

Transcript of 3dpresdm.pdf