Version: V1.2
This module contains post-stack migration processes for Lynx Traceprep seismic processing. The two migration techniques implemented are Kirchhoff Summation and Finite Difference - see Migration Principles
KIRCHHOF MIGRATION Main setup page
CURVE APERTURE
APERTURE FROM REFRACTION
POINTS APERTUREFINITE DIFFERENCE MIGRATION Main setup page
Parameter setup
Process ID
(type string) Traceprep process identifierProcess title
(type string) User title for these parametersVelocity file type
(type option, Lynx3S, Lynx TAX,VDB,CSV )
see velocity file formats belowDefault Vel Filename
(type option, Yes, No)
"Yes" - velocity file name is the same as the input filename, with the appropriate extension. For example, when using VEL files, if the input file is C:\data\seismic\line1.tr3 the velocity file would be C:\data\seismic\line1.VEL"No" - name the velocity file to be used in the next field. This option can be used whenever a single velocity file is to be used to migrate a batch of trace files. If a single velocity function (control point) is to be applied to a batch of lines, it is advisable to use Reference by Trace, with a velocity control point set for trace 1. In the case of VDB a single velocity database file name will always be specified.
Velocity File Name
(type filename) Select the velocity file to be used for migration. Horizontal velocity control point reference should be the same as in "reference by" field belowReference by
(type option, Trace, Shotpoint)
Trace - the Velocity Control Points (VCPs) in the velocity data file are referenced by trace. When using this option, remember that changing the trace numbers for the input file, e.g. by deleting or inserting traces, will require corresponding changes to the trace numbers of the VCPs in the velocity file.
Shotpoint - the Velocity Control Points in the velocity data file are referenced by shotpoint.VCPs should be stored in ascending order of trace, or shotpoint, within the velocity file, even when shotpoint increment for the trace file is negative (shotpoint numbers decreasing with increasing trace number). The shotpoint numbers must be monotonically increasing or decreasing - if they are not, then trace numbers shoud be used. If the shotpoint numbers are discontinuous, two VCPs should be placed adjacently on either side of shotpoint discontinuities.
Velocity %
(type single, limits 1.0 to 100.0) Scale the velocity field by this percentage prior to migration. The scaling is applied to all the velocities from the.VEL file containing the velocity definition. If these velocities were derived from the stacking velocity tables at the top of the original section, this factor should represent the difference between stacking and true average velocity. A value in the range 90 to 100 percent is normally used. See also notes on velocity interpolationTrace spacing
(type single, limits 1.0 to 10000.0) The subsurface trace spacing, in metres or feet, see units below. Must be compatible with the velocity units. If the velocities are in metres per second the trace spacing should be in metres.
X Units
(type option, Feet, Metres) Units for the velocities and trace spacing
first Tr/SP
(type single, limits -100000.0 to 100000.0) First trace or shotpoint to migrate
last trace/SP
(type single, limits -100000.0 to 100000.0) Last trace or shotpoint to migrate
T min
(type single, limits -1000.0 to 20000.0) migration start time in msec. Data above this time on the unmigrated section will be ignored.T max
(type single, limits -1000.0 to 20000.0) migration end time. Data below this on the input section will be ignored
RMS i/p level
(type single, limits 0.1 to 20000.0) Expected root mean square amplitude of input data. If you don't know what the input level will be, precede the migration with an RMS process which adjusts the level to the value entered here.Aperture type
(type option, Curve, Dip, Points) corresponds to one of three ways of defining the aperture shape - CURVE, POINTS or DIP. See pages below.
Aperture Mode
(type option, Fixed, Mute, Vels)
This enables the aperture shape to be fixed across the section or whether it "follows" either the water bottom mute, or the first velocitiy (usually the water bottom velocity) specified in the velocity time-velocity functions.
The aperture defines the width, in traces, of the diffraction hyperbola at a given time. The aperture will normally increase from a few traces at shallow times to tens or hundreds of traces at deep reflection times of several seconds.
The aperture at a given reflection time determines the maximum dip which can be migrated. The aperture should be sufficiently large that the maximum gradient of the diffraction hyperbola is at least as great as the dip of the events.
If the aperture is too big, particularly at shallow reflection times, spatial aliasing may occur. This happens when the dip, at a given frequency, reaches approximately half a wavelength per trace. You can often see the effect of aliasing above the water bottom in marine data. If a lot of noise appears above the water bottom, the start aperture is probably too big.
The true aperture is the product of the aperture in traces and the trace spacing in metres (or feet). If the trace spacing is 25m, twice as many traces will be needed to achieve the desired maximum dip as when the trace spacing is 50m.
Start Aperture
At the start of the data, the diffraction patterns will be steep and only a small aperture will be required to image the data. Bear in mind also that small errors in velocity will have a large effect on the shape of the hyperbola, so that the beneficial effect of increasing the aperture may be neutralised. An aperture of 2-10 traces will usually suffice.
It may be worth increasing the start aperture further for very deep water bottoms. Bear in mind that the combined effect of the source and receiver arrays and NMO stretch will effectively limit the maximum dips seen in the shallow section.
End Aperture
A given event on the section will be imaged by the migration process when it is tangential to a diffraction hyperbola. At the time level of the event the aperture must be large enough that the maximum dip of the hyperbola exceeds the maximum dip of the event, otherwise the event will not appear on the output section.
Surprisingly, if the aperture is too small, the output will appear "mixed" - this is the opposite of what might be expected from summation over too few traces.
On most data, with a trace spacing of 50m, an aperture of about 80 to 120 traces will be needed at 5 seconds. If the data are flat lying, you will be able to use the smaller value.
For 25m trace spacing, at 5 seconds the aperture will need to be twice that required for 50m data - usually at least 200 traces and probably more if velocities are high or dips are steep.
Most illustrations in books and publications show a concave aperture (shape factor > 1.0). The reason for this is probably that the ray determining the outer limit of the aperture refracts outwards as the velocity increases with depth. Logic also suggests that as the reflection time increases and the data become more noisy it would be sensible to restrict the aperture rather than increase it. That would entail a shape factor of less than 1.0 (convex aperture).
Lateral velocities
If only one velocity control point is enabled, its velocities will be used across the whole section. If more than one velocity control point is enabled, traces prior to the trace number on the first enabled velocity page will be migrated using the first velocity page. Traces in between enabled velocity control points will be migrated using velocities interpolated from the nearest two on either side. Traces after the last enabled control point will use the velocities from that point.
Vertical velocities
In the time direction, velocities are interpolated in a piecewise linear fashion. In the horizontal direction the delta T values defining the summation hyperbolas are interpolated linearly, between the velocity control points.
Velocity control is fully time and space variant. MIGKHF assumes that the lateral velocity changes are fairly gradual. If they are not, the CDP assumption will probably have broken down and the data are likely to be somewhat three-dimensional. Also remember that the more rapidly the true velocities change laterally, the less reliable the stacking velocity data will be.
The parameter setup allows for up to twenty sets of time vs velocity pairs. The velocity is the RMS velocity from the surface to the two way time position. The velocity percentage field on the migration parameters page allows all velocities to be multiplied by a constant factor. When using stacking velocity information direct from the velocity tables on the stacked section, it is normal to use a factor between 90% and 100% (often 95%).
Aperture at start, traces
(type long integer, limits 1 to 1000) is the number of traces in the summation at the first migrated sample in the trace. The first migrated sample is determined by the earliest time on the nearest Velocity control points.Aperture at end, traces
(type long integer, limits 1 to 1000) is the number of traces in the summation at the last migrated sample in the trace.Aperture profile shape
(type single, limits 0.1 to 3.0) This parameter controls the shape of the aperture (see below). >1.0 gives a concave shape to the aperture, <1.0 gives a convex shape and =1.0 gives a linear variation of aperture with time.
The aperture shape parameter gives some control over the rate at which the aperture A(t) changes with time. When calculating t, the first Time Velocity pair is used as the minimum aperture reference point.
For marine data, if the first (minimum time) velocity at each control point is specified as the water bottom time, the aperture will be approximately constant along the water bottom. For a deep water bottom this will improve the consistency of the character of the water bottom event.The aperture at time t is given by:-
A(t) = Amin + ((t - Tmin)/(Tmax - Tmin))S * (Amax-Amin) where:
s is the shape factor
Tmin is the time for minimum aperture (the first time in the T-V table)
Tmax is the time for maximum aperture (the end time for the Output data)
Amax and Amin are the maximum and minimum apertures.When s is less than 1.0, the aperture profile is convex.
When s is equal to 1.0, the aperture profile is a straight line.
When s is greater than 1.0, the aperture is concave, ie it increases more rapidly at high reflection times.
For a given trace, the aperture is calculated by ray-tracing a ray departing from the surface, using the velocity function at that point, assuming a horizontally layered subsurface.
Surface Departure Angle
(type single, limits 0.0 to 90.0) The angle at which a ray, defining the outer limit of the aperture, departs from the surface. Typically up to about 25 degrees.
The points aperture is entered as a set of time-aperture pairs, specifying the aperture in traces at specified times. The Apertures above the first time will be set equal to that at the first time. Apertures below the last time will be set equal to that at the last time.
Process ID
(type string) Traceprep process identifierProcess title
(type string) User title for these parametersVelocity file type
(type option, Lynx3S, Lynx TAX,VDB,CSV )
see velocity file formats belowDefault Vel Filename
(type option, Yes, No) "Yes" - velocity file name is the same as the input filename, with the appropriate extension. For example, when using TAX files, if the input file is C:\data\seismic\line1.tr3 the velocity file would be C:\data\seismic\line1.TAX"No" - enter velocity file name below. This option can be used whenever a single velocity file is to be used to migrate a batch of trace files. In the case of VDB a single velocity database file name will always be specified. If a single velocity function (control point) is to be applied to a batch of lines, it is advisable to use Reference by Trace, with a velocity control point set for trace 1.
Velocity File Name
(type filename) Select the velocity file to be used for migration. The horizontal reference used for the velocity control points in the file, i.e. trace or shotpoint, should be the same as in "reference by" field belowReference by
(type option, Trace, Shotpoint)Trace - the Velocity Control Points (VCPs) in the velocity data file are referenced by trace. When using this option, remember that changing the trace numbers for the input file, e.g. by deleting or inserting traces, will require corresponding changes to the trace numbers of the VCPs in the velocity file.
Shotpoint - the Velocity Control Points in the velocity data file are referenced by shotpoint. Use "regular" shotpoints, i.e. the trace file first SP and SP increment parameters will be used to determine the shotpoint fo a given trace. SEGY derived data are used, make sure that the input file contains valid first-SP and SP-increment. This will normally be the case for SEGY files generated from LEASSV, but not for standard SEGY. If you are using SEGY data from a foreign tape, use TraceFix to make sure that the first SP and SP increment are correct.
Irregular shotpoints - (not implemented in this version - use Trace option and modify velocity file accordingly). Shotpoints will be read from bytes 21-24 of the trace headers. The shotpoint numbers must be monotonically increasing or decreasing - if they are not, then trace numbers shoud be used instead. If the shotpoint numbers are discontinuous, two VCPs should be placed adjacently on either side of shotpoint discontinuities.
In the velocity file, VCPs should be stored in ascending order of trace, or shotpoint, even when the shotpoint increment for the trace file is negative (shotpoint numbers decreasing with increasing trace number).
Velocity %
(type single, limits 1.0 to 100.0) Percent scalar to apply globally to velocity field. All velocities are multiplied by this number / 100 so that a value of 100 does not change the velocities. The velocity field for finite difference migration is as interval velocities. Input stacking (or rms) velocities are converted to Dix interval velocities and interpolated to an nx by ntau grid, where nx is the no. of traces and ntau the number of time/depth steps (see ptau parameter below).
Vel smooth CDPs
(type long integer, limits 1 to 1000) Calculated interval velocities are smoothed over this number of traces.
Trace spacing (type single, limits 1.0 to 10000.0) distance between successive cdp's This must be in the distance units specified below
X Units
(type option, Feet, Metres) distance units to be used. Velocities should be specified in these unitsfirst Tr/SP (type single, limits -100000.0 to 100000.0) First trace or shotpoint to migrate.
last trace/SP
(type single, limits -100000.0 to 100000.0) Last trace or shotpoint to migrate. MIGFD will try to adjust its buffer size to the maximum of this size and the expected number of input traces.Tmax msec
(type single, limits 100.0 to 10000.0) maximum time in msec to migrate. Minimum time is set to zero. If input data do not have a zero time datum, be careful to adjust the velocities to the same datum.Domain (type option, time, depth, dtime) Only time domain is supported in this version
Algorithm
(type option, implicit, explicit, superimp) Type of finite-difference algorithm to use.Implicit. The implicit algorithm is an implementation of Claerbout's "45 degree approximation". This preserves steep dips up to 45 degrees, but may result in a markedly "smearier" section than the explicit algortihm.
Explicit. Claerbout's "15 degree" approximation. Preserves dips up to about 15 degrees, disperses steeper events. This may not be such a disadvantage as it sounds, because steeply dipping noise and random noise spikes tend to be attenuated.(super implicit) The explicit and implicit algorithms will be familiar.
The super implicit is also exact at the spatial Nyquist - an improved version of the implicit algorithm.
Taper, traces
(type long integer, limits 0 to 1000) This number of traces will be added to each end of the input profile, prior to migration. Enables data which migrate up dip towards and perhaps off the end of the section to be observed. Also enables edge effects to be assessed.
ptau, samples
(type long integer, limits 4 to 120) Enables a trade-off to be made between high accuracy (small ptau) and fast execution (large ptau). 16msec works well in many cases.Absorb
(type option, Yes, No) Enables or disables absorbing boundary conditions. This controls the way waves reflect off the side of the computational grid. Without absorbing boundary conditions, events at the edges will be reflected back into the section, causing "smiles".
TPMig supports 4 velocity file formats. Both Kirchhoff and Finite Difference methods require that velocities are input as "Velocity Control Points" or VCPs referenced either by shotpoint, or by trace.
VCPs should be stored in ascending order of trace, or shotpoint, within the velocity file, whatever type of file is being used. For traces outside the trace/shotpoint range of the VCPs in the velocity file, the nearest VCP is used, without spatial extrapolation. The time velocity pairs within each VCP must be ordered by ascending time, for each control point and the data for a given profile should be contiguous. The migration program searches for a match with the desired line name in the first column, so the file may contain more than one profile and complete profiles can be in any order.
Formats
- Lynx 3S velocity .VEL file legacy format. This format is supported so that legacy migration projects, which used it, can be reprocessed. Devised for Lynx's original 3S Kirchhoff migration, the VCPs are always referenced by trace. (although the .VEL format has provision for shotpoints to be used, this was never implemented).
- Lynx TAX file format. The Trace Auxiliary file was devised as a way of collecting all the information for a trace file in a single file (e.g. velocities, shotpoint inserts, XY coordinates and mutes). See Taxedit - trace auxiliary file editor..
- Lynx VDB format is a velocity database, using the open source Firebird/Borland Interbase format, to aggregate all the velocity data for a project in one file. See Velprep - Velocity Preparation and Modelling. This enables modelled velocities to be used in future versions of TPMig.
- CSV, the ever popular comma separated value format, enables velocities to be manipulated in an Excel spreadsheet before they are used for migration, as below
CSV Files
CSV files can be used in "default file name" mode , i.e. there is a csv file for each trace file to be migrated, or all the velocity data for all lines can be combined in one CSV file. In either case, the CSV file must contain four columns for Profile,TrSP,Time2,VRMS, where the (optional) column headings areProfile TRACE Time2 VRMS (for Reference by Trace)
Profile SP TIME2 VRMS (for Reference by shotpoint)
Profile is the line name identical to that in a trace file to be migrated
TrSP is the trace number for a velocity control point, or the shotpoint number, depending on the Reference by parameter.
if the VCPs are referenced by Trace, then the column heading is TRACE, if shotpoint then the column heading is SPTime2 is the two way time for a time-velocity pair in the control point
VRMS is the RMS (stacking) velocity for a time velocity pair
Example of spreadsheet table data output to csv file, for line 01-87-CB-001. There are 3 velocity control points at shotpoints 10, 32.5 and 53.25.
PROFILE SP TIME2 VRMS 01-87-CB-001 10 1020 2300 01-87-CB-001 10 2540 2500 01-87-CB-001 10 5000 4200 01-87-CB-001 32.5 0 2000 01-87-CB-001 32.5 700 2300 01-87-CB-001 32.5 2220 2400 01-87-CB-001 32.5 2700 2700 01-87-CB-001 32.5 5000 4200 01-87-CB-001 53.25 0 2000 01-87-CB-001 53.25 850 2260 01-87-CB-001 53.25 1920 2400 01-87-CB-001 53.25 3040 3580 01-87-CB-001 53.25 5000 4200
Traceprep implements two types of migration, Finite Difference, Kirchhoff. Frequency-Wavenumber (also known as "phase shift") is currently not implemented.
Finite-difference (FD) migration is one of the most often used standard migration methods in practice. The merit of FD migration is its ability to handle arbitrary laterally and vertically varying macro velocity fields. The well-known disadvantage is that wave propagation is only performed accurately in a more or less narrow cone around the vertical. This shortcoming originates from the fact that the exact one-way wave equation can be implemented only approximately in finite-difference schemes because of economical reasons. The Taylor or continued fraction expansion of the square root operator in the one-way wave equation must be truncated resulting in an approximate version of the one-way wave equation valid only for a restricted angle range.
The most serious competitors of FD migration are phase-shift- and standard Kirchhoff migration (Gazdag, 1978; Schneider, 1978). These approaches do not suffer from this angle restriction. Wave propagation is in principle correctly performed up to 90º. In contrast to FD migration the macro velocity field is allowed to vary only with depth. Lateral variations cannot be taken into account. For more complex velocity variations, Kirchhoff migration methods have to use ray tracing to compute the diffraction traveltime surface along which summation takes place. These high-frequency methods also represent an approximation to the problem, in this case imposing special requirements for the smoothness of the velocity field and neglecting effects caused by finite frequencies.
Kirchhoff migration, also known as "diffraction stack" migration, was the first migration technique to be implemented commercially for post stack seismic sections. It is also conceptually simpler than the other two main methods, Finite-Difference and Frequency-Wavenumber (F-K).
Kirchhoff's integral for a scalar acoustic wave field relates the pressure (or particle displacement) at a point to its value over a closed surface surrounding the point.
Because of the finite propagation speed of acoustic waves, the disturbance at the point will be delayed according to the distance of the surface and the propagation velocity. On a seismic section, this delay results in the familiar hyperbolic summation "path" used in the Kirchhoff method. (Larner and Hatton, 1990). In order to honour the scalar wave equation more closely, the simple "diffraction stack" is followed by a phase /frequency compensation filter and a time variant scaling. (Newman 1990)
Another way of looking at the Kirchhoff method is to think of each point in the subsurface as producing a hyperbolic diffraction pattern on the seismic section. To "migrate" the section we have to construct a suitable 2 dimensional filter which will transform a hyperbola to a point, placed at the apex of the corresponding hyperbola. The filter must, of course, be both time and space variant in order to allow for the change in shape of diffraction hyperbolae with velocity and time.
The Kirchhoff method is relatively economical in its computer memory requirements. The memory needed is directly proportional to the maximum aperture. In this implementation, the input trace file is migrated trace by trace, using a velocity function interploated linearly from the nearest VCPs on iether side. The aperture (number of adjacent traces summed in to the output trace) is time variant as determined by the aperture setup. The diffraction curves are hyperbolic (symmetric about the output trace position), lateral velocity variations over the width of the aperture are not compensated (this would require ray tracing and a more sophisticated velocity model than is generally available).
In the F-K method, this filter is applied by a 2-D transform of the seismic section to the frequency - wavenumber domain, multiplication by an appropriate set of complex filter coefficients and inverse transformation back to the time-space domain. Most of the complication in the F-K method relates to the time and space variation of the filter, which is difficult to implement. The advantage of this method is that it is extremely quick, but it needs relatively large amounts of memory.
The Finite Difference method uses a recursive 2-D filter to achieve the same effect. Recursive filters can be made truly time and space variant but are not intuitively easy to understand, as anyone who has read Jon Claerbout's work will testify. The Finite Difference method needs comparitively large amounts of memory, as the whole section is held in memory
In the early days of digital migration, say around 1975, the main emphasis in the literature was on the relative merits of the different algorithms in respect of their accuracy and noise characteristics. Over the years we have learned that this quest for accuracy is frustrated in the real world by the shortcomings of the CDP stack, 3 dimensional structures investigated with 2 dimensional profiles and our lack of knowledge of the velocity field to be used for migration.
The MIGTEST process enables families of diffraction hyperbolae to be generated, for a given Velocity field and aperture. NOT YET IMPLEMENTED
Traceprep packages comprise one or more DLLs and an INI file which must be present in the LEA system directory (usually C:\LynxSysx).
The package files for seismic migration are
TPMig.DLL
TPMig.INI
FDMigLib.DLL
TPMig.HTM (this file)For Traceprep to recognise the Seismig package, the file Traceprep.INI [packages] section must contain the line
TPMig=version
where version is the package version number, obtained from the TPMig.INI file, e.g.
TPMig=V1.00
An aperture was negative. In Kirchhoff migration, a negative aperture was specified. Check the aperture parameters.
Aperture must increase with time - In Kirchhoff migration, apertures must increase monotonically with two-way time. Check the aperture parameters.
Aperture too big - In Kirchhoff migration, the aperture exceeded the maximum allowed number of traces (3000).
Migration completed - the migration has completed. Check the process log listing for messages.
First velocity control point at trace=nnn - In Kirchhoff migration, the first velocity control point was found at trace nnn. Traces with numbers <nnn will be migrated using the velocity funtion found at that point.
Kirchhoff migration failed to intitialise - An error was found in the parameters of velocity file during Kirchhoff migration initialisation.
Last velocity control point at trace=nnn - In Kirchhoff migration, the last velocity control point was found at trace nnn. Traces with numbers >nnn will be migrated using the velocity funtion found at that point.
Memory required for migration - This gives an indication of the amount of RAM required to do the migration. This is not usually an issue with current PC hardware, but if the PC has insufficient memory, the migration may run slowly.
Migration starting - Parameters and velocities successfully loaded - starting the migration process.
New velocity control point at trace=nnn - The Kirchhoff migration sends this message every time a new velocity control point is reached. Remember that VCPs must be stored in the velocity in increasing shotpoint or trace order.
No active velocity points found - The velocity file contained no VCPs, or there were VCPs but they were flagged as inactive (VEL and VDB formats)
No velocity points found in file - The velocity file contained no valid velocity control points. The VDB file contained no data for the current profile. The TAX file did not contain velocity data.
Using velocities from file ffffff - The velocities used for migration are taken from file ffffff.
Velocity file not found - ffffff - The requested velocity file ffffff was not found.
Velocities wrongly referenced by trace/SP - The velocity file was not referenced (by shotpoint or by trace) in the same way as specified by the "Reference by" parameter.
Warning - no overlap with velocity trace/SP range - The trace or shotpoint range of the seismic trace data did not include any of the VCPs in the velocity file. The migration will use the nearest VCP in the velocity file to migrate the traces (with no spatial velocity variation)
Velocities, Time-Imaging and and Depth Imaging in Reflection Seismics. Etienne Robein. EAGE Publications Inc 2005 ISBN 90-73781-28-0.
Larner, Ken and Les Hatton. "Wave Equation Migration, : two Approaches". First Break, Vol 8 No.12, December 1990, p433.
Newman, Paul. "Amplitude and Phase Properties of a Digital Migration". First Break, Vol 8 No.11, November 1990, p397.