Marine Processing - Part 10 | Migration (continued)

This sequence of blog posts will build up into a complete description of a 2D marine processing sequence and how it is derived. No processing sequence is definitive and techniques vary with   time (and software), however the idea is to provide a practical guide for applying seismic processing theory. The seismic line used is TRV-434 from the Taranaki Basin offshore New Zealand. It is the same marine line used in our basic tutorial dataset. The data are available from New Zealand Petroleum and Minerals, under the Ministry of Economic Development under the “Open File” System.

The processing sequence developed so far: Resample and Minimum Phase Conversion    Reformat from field data (in this case, SEGY) Apply a combined minimum-phase conversion and anti-alias filter Resample to a 4ms sample interval QC and Assign Geometry Assign 2D marine geometry; 12.5m CDP spacing and 60 fold gathers QC shots and near trace plots Amplitude Recovery Amplitude recovery using a T2 Spherical divergence correction Amplitude QC and Edit using peak and RMS amplitude displays Swell Noise Suppression Swell noise suppression using projective filtering Linear Noise Suppression Interpolation to 6.25m group interval, 480 channels to unwrap spatially aliased dips Tau-p transform 500ms robust AGC "wrap", 960 p-values and transform range from -1400ms -1 to +1400 ms-1 Tail mute to remove linear arrivals and linear noise Predictive deconvolution: 32ms gap, 480 ms operator Rho filter for low frequency compensation Inverse Tau-p transfrom Interpolation back to 25m group interval, 240 channels Picking Velocities Multiple Removal NMO correct with 90% of primary velocity Form 120-fold supergathers Parabolic Radon Demultiple Transform range -300ms to 500ms far-offset moveout;  200 p-values Multiple  removed from +24 to +500ms far-offset moveout Application from 1400ms onwards For 60-fold CDP gathers from supergathers Remove 90% NMO correction Re-pick Velocities

The last post really covered the theoretical basics of how to apply pre-stack time migration to the dataset, as well as the kinds of parameters you might encounter. In practice there are typically a few more things you will need to think about.

The first is to be aware that Kirchhoff pre-stack time migration is kinematic; that is to say the migration operator is going to redistribute the seismic energy across the seismic section. 

Depending on how the algorithm has been implemented you might need to remove the spherical spreading part of your amplitude correction prior to the migration, and then run a new sequence of amplitude recovery tests after the migration.

Pre-stack time migrated data from TRV-434. The panel on the left has had the spherical divergence correction removed before migration; the panel on the right has not. The cancellation of the migration operators is less effective where the amplitude correction has not been removed (red circled area) resulting in a noisier result with more artefacts

Another place where migration artefacts can be created is at the start and end of the seismic line, where we have incomplete summation of the migration operators. As we get to within one migration operator width of the edge of the data, the quality of the migrated image starts to deteriorate until at the very edge we only have artefacts.

This is most obvious in the “taper on” zone at the start of the line, however you will have similar effects at the end of the line, or where there are any gaps in the data.

The stacked section (left) and pre-stack time migrated section (right) from at the start of line TRV-434. Shooting direction is left-to-right. The “taper on” has been populated with migration “swings” where there is no more data to cancel out the un-needed parts of the operator (blue boxed area). The image will also be incorrectly formed where there isn’t a full migration operator to contribute to the data

These effects can be managed by scaling down the data at the start and end of the seismic line, using a function that is approximately the same shape as the operator. This is sometimes built into the migration routines as an optional pre-migration scaling. The scaling can also be approximated with a simple function that leaves the data un-scaled at full fold and ramps to zero amplitude at zero fold.

The next thing you need to think about is the offsets to use.

The pre-stack time migration works by forming the data into common-offset planes; we want to make sure these will be fully populated since gaps in the data will result in imaging artefacts.

In this case, we have data with 25m spacing between shotpoints and 25m between receivers - which means that the full 120 channels in each shot are divided up between two CDPs. 

There’s a full discussion of this here, which shows how adjacent CDPs will have the same number of traces (60) but different offsets.

We have two choices. We can either: (1) migrate to 120 offset planes corresponding to each offset present in the shot record, or (2) migrate to 60 offset planes corresponding to the fold of the CDPs.

With 120 offset planes, we’ll have gaps that need to be interpolated. We could do this pre-migration or allow the migration to fill in the gaps for us, accepting that it might create some noise artefacts which we will need to remove.

With 60 offset planes, we’d want to choose those that minimise the difference between the actual offset of any given trace, and the target offset plane it will contribute to. 

The simplest way to do this is to average the offsets that will make up each offset plane. In this case the first offset plane will be at 270.5m; half way between the offset for channel 120 (the near offset) and channel 119 (the next offset).

The biggest impact here is on run-time. If we take 120 offset planes and interpolate the data, the migration will take twice as long. Depending on time pressure, sometimes migrating to less offset planes than the fold (such as 30 planes, 100m apart) can be a good idea to get a result faster.

If there are any strong amplitude contrasts in the data – for example a noisy trace we missed in the edit stage – these are going to also cause problems in the migration. The migrated energy will not sum correctly and will leave an imprint of the migration operator in the data.

Pre-stack time migrated data from line TRV434;  the right hand panel has had a series of 7Hz Ricker wavelets added on the input data at CDP 1100, offset 1733m, which are approximately two orders of magnitude higher than the surrounding data. While these artefacts show through clearly, a single spike on a trace would be more subtle

Unlike other Pre-stack processing, you cannot avoid this kind of amplitude-based artefact with a removable AGC prior to the migration. This would prevent all of the amplitudes summing correctly and would create more noise. The only solution is to check the data carefully for high amplitudes as we did earlier in the sequence.

 

The extent to which you can afford to test all of the parameters and issues worked through here and in the previous post depends upon your time, project objectives, geological complexity and the resources at hand.

A good “baseline” to start off with is a 45-degree dip angle and a 3000m aperture, and migrating to at least as many offset planes as you have fold of coverage. With these limits the aperture will only start to restrict the migration operator around 2-3 seconds TWT.

It can also be worth looking at the approximate dips you want to image. Here there are dips of about 4ms/trace on a post-stack time migration, which (when I use the average interval velocity calculated from my velocity functions of 2750 ms^-1, and remembering that it is two way time) corresponds to 5.5m/trace, or an angle of ~ 24^o (tan^-1 [5.5/12.5]).

This 60-fold migration took 696 seconds to run on my humble laptop (4 x 2.6Ghz cores, multithreaded to 8); this was running in parallel using 5 processes so that I could carry on working (as multi-threading is not quite the same as having real cores.)

While all migrations used different algorithms and scale differently, here are some runtimes I got:

Fold	Angle	Aperture	Stretch	Run time
60	45 degrees	3000m	120%	696s
60	60 degrees	3000m	120%	799s
60	60 degrees	6000m	120%	1183s
60	75 degrees	6000m	120%	1204s
60	75 degrees	9000m	120%	1313s

As you can see, opening up both the angle and aperture starts to make a big difference to the run-time of the migration. The diagram in this entry shows how these interact and why adjusting only the angle makes little difference. It is also worth remembering in this case that the seismic line is less than 24km long, so wider apertures will only impact the centre of the line.

In these examples I have not modified the stretch mute or the degree of anti-alias filtering; these have an impact on the runtime as well as the image quality at higher angles and bigger ranges.

In this case it makes sense to focus on the central portion of the line – between CDPs 800 and 1500, and between 2000ms and 3500ms two-way-time – as this was the main structural target.

A section of line TRV-434 Pre-stack time migrated, with a 15^o (left), 30^o (centre) and 75^o (right) dip limit. Aperture is constant at 6000m

Running a full suite of aperture and dip limit tests can be time consuming and, as in this case, there is often a compromise on the dip limit in terms of image quality and introduced noise. Though I’ve not shown the full suite of tests here, the lower dip angles give a cleaner result - which makes sense when you look at the rough dip calculation above.

I have chosen a 30^o angle and a 6000m aperture as it seems to be the best compromise.

Line TRV434 stacked (top), and with Pre-stack time migration applied (bottom). Both sections have a 500ms AGC applied. Migration dip limits were 35^o and the aperture used was 6000m

With the migration completed - which as I mentioned in the last entry might include re-picking velocities and re-migration of the data – the bulk of the processing is now completed.

Post-migration processing is sometimes termed “finalisation” and usually includes some random noise attenuation, scaling, and filtering before creating a final SEGY output.

By: Guy Maslen