2D Processing Tutorial

This tutorial is being developed on the fly with interested FreeUSP users. If there is something you would like covered in this section please post to freeusplist@freeusp.org and we will see if we can include it. This is a work in progress and will progress as user demand and my ability to apportion time to the exersize dictates. Also, when I get a few hours to pound out a new section I am moving pretty fast. If you see me come off the rails, please chime in. The faster we correct any mistakes, the better for everyone involved....Paul G. A. Garossino

Corrections and contributions from:

Fernando M. Roxo da Motta [Dec 15, 2005]

Introduction

Conversion to USP Format

Merge Survey Data

Initial Signal Analysis and Quality Control

Initial Velocity Analysis

Brute Stack

Noise Suppression

Residual Statics

Improved Velocity Analysis

What Else

Erata

USP Scripts

Introduction

Feb 13,2005
Feb 20,2005

Conversion to USP Format

Feb 24, 2005

Merge Survey Data

Mar 11, 2005
Mar 24, 2005
March 27, 2005
April 12, 2005

Initial Signal Analysis and Quality Control

April 24, 2005
May 29, 2005
Oct 9, 2005

Initial Velocity Analysis

Before we can get into the next phase of noise suppression, which involves filtering in all three sort domains, shot [CSP], receiver [CRP] and common mid point [CDP], we need to do something to increase leverage between primary reflected events and the massive amount of linear noise associated with this acquisition. Normal moveout provides a method to achieve this, but with the data in its current state it will be very difficult to utilize velocity semblance spectra to derive a set of stacking velocities.

If you would like to see how desperate things are, sort the data to CDP, find a gather where you think you can identify something other than noise and generate a velocity semblance spectra for that record. I have done exactly that using:


sisort -N denoise_4ms_CDP_nmo_CSP_fft2da_poly_back \
       -n sort_table -D \
       -O denoise_4ms_CDP

velspec -N denoise_4ms_CDP \
        -O velspectra -vmin 500 -vmax 5000 -nvel 300 -A

I have then loaded the spectra and gathers into our vxos velocity picker. It is not possible to contemplate using this tool with the data in its current shape. I will leave description of it's use for later. Note that the S/N of the data is so poor that picking a stacking velocity trend is problematic to say the least.

Lets try another approach, that is more amenable to poor S/N data. We can generate a suite of constant velocity stacks over a range of likely velocities and hope to see something in the data that we can key on to generate a rough stacking velocity field. I create the required constant velocity stack dataset using:


#! /bin/sh -f
#
file="denoise_4ms_CDP"

for velocity in `cat vellist`;do

bdnmo -N ${file} -cv ${velocity} -E |\
mute -R |\
pstack |\
utop -R 1 -L 1282 |\
apend -O VelocityAnalysis/cvstack_dataset

echo done ${velocity}

done

echo finished
exit

which uses the file vellist which simply contains a set of velocities, one per line, for the process. For each velocity in the file the data will be moved out, stacked and added to the accumulating dataset. Once the job is finished I can load the entire dataset into xsd as a movie and pick a cursory stacking velocity function set manually. When loading the movie you can utilize xsd server parameter options to have the record number turn up on each frame as the velocity of that frame. To do that simply make the Delta for the record entry correspond to the delta v from your vellist file. The Origin would then be the first velocity in the file less the delta.

Luckily for us, the S/N of the constant velocity stacks is easily adequate to allow us to define a stacking velocity function along the line. The power of stack allows us to clearly see events come to focus at varying velocities, thus allowing us to catalogue those time,velocity entries as a spatial stacking velocity function:


1950 m/sec
2450 m/sec
2950 m/sec

I derived a stacking velocity function at several locations along the line and stored them in a file in the flat file format required by our velocity input routine velin. In this file the first column is time in milliseconds, the second is velocity in the units of the data while the last column is the record number which in our case is the sequential CDP gather number associated with that location in the stack. Once I have this file defined I can generate a velocity volume to fit the stacked data using:


velin -N denoise_4ms_CDP -v cvstack_velocity_function_picks -flat -R -O velusp

Which performs a linear interpolation between functions and between function elements to flush out a velocity volume with a single velocity trace for each gather of the input CDP dataset. This velocity dataset can be plotted in xsd for a quick QC.

Brute Stack

To obtain a brute stack of the data making use of the above stacking velocity dataset we first apply normal moveout to the CDP data using:


bdnmo -N denoise_4ms_CDP -v velusp -E -O denoise_4ms_CDP_nmo

We can plot a selection of moved out gathers from the output dataset, pick a typical one and generate a post normal moveout mute for the data. Once the mute is picked in xsd, use the save trc header option to save out the picks along with DstSgn. This allows us to use the distance muting option in bdmute to apply that profile to all gathers of the volume. We can then mute the data and generate a brute stack using:


bdmute -N denoise_4ms_CDP_nmo \
       -P mute_header_picks -M diston -O denoise_4ms_CDP_nmo_bdmute
pstack -N denoise_4ms_CDP_nmo_bdmute -F Stack_FOLD |\
counter -ssam \
        -O denoise_4ms_CDPSTACK

Examination of the brute stack shows that we are starting to see subsurface upgoing energy. If we interleave the stack with the fold stack generated by pstack, we can see how the signal content relates to the number of samples stacked at any given sample location in the data.

So, we are getting somewhere, but we have a long way to go. This stack, though showing something of the subsurface, still suffers from many areas where surface static busts are evident, areas where the linear noise in the data is so strong it is hard to make out the upgoing energy and areas where it looks like our stacking velocities are wholly inappropriate. In addition, there are several zones where the post NMO mute needs to be adjusted. We can do much better than this.

Noise Suppression

To understand a little more about the coherent noise present on this acquisition it is useful to observe the data in both end point domains, shot and receiver, as well as the midpoint domain, CDP.

Consider the CDP gathers responsible for our brute stack. Notice that with normal moveout applied, even using the cursory stacking velocities derived above, we can see evidence of flat-lying upgoing primary reflections. These reflections are swamped in a sea of spatially aliased noise. Most of this noise is backscattered energy travelling around in the near surface and hence traveling across the receiver array linearly at a pretty low velocity. The CDP trace spacing is about 100 meters which is why the noise looks so spatially aliased in this domain; it is.

If we sort this data back to the receiver domain using:


presort -N denoise_4ms_CDP_nmo_bdmute -O cdp_sisort_table
sisort -N denoise_4ms_CDP_nmo_bdmute -n  cdp_sisort_table -G -O ../Receiver/denoise_4ms_CDP_nmo_CRP

we see that at a trace spacing of about 50 meters some of the backscattered noise is now coherent and unaliased.

If we sort instead, to the shot domain with a trace spacing of about 25 meters using:


sisort -N denoise_4ms_CDP_nmo_bdmute -n cdp_sisort_table -S -O ../Shot/denoise_4ms_CDP_nmo_CSP

we see that a lot more of the backscattered energy is unaliased.

Now that we can start to see some of the signal separation that we were looking for, lets see if we can do something about preferentially attenuating the noise component. We can transform the shot sorted data into F-K space using:


fft2da -N denoise_4ms_CDP_nmo_CSP -O denoise_4ms_CDP_nmo_CSP_fft2da

The more experience among you may start to see the separation of noise and signal in this F-K image. Without a lot of experience in this area it is tough to guess the relationship between event trajectories in T-X and those in F-K. Luckily in the USP arsenal is a routine ich which allows one to pick events in T-X in xsd, convert the picks into a model complete with the trace header structure of the real data, and then transform the model to the F-K domain using:


ich -N denoise_4ms_CDP_nmo_CSP -P ich_picks -S -O denoise_4ms_CDP_nmo_CSP_ich
fft2da -N denoise_4ms_CDP_nmo_CSP_ich -O denoise_4ms_CDP_nmo_CSP_ich_fft2da

This approach allows us to see where the selected primary events lay and more importantly where the picked linear noise is located in F-K space. Armed with this knowledge we can digitize a polygonal filter to pass the signal and eradicate the noise. Once the polygons have been picked for a decent selection of shots we can apply the filters using:


polymute -N denoise_4ms_CDP_nmo_CSP_fft2da -P fft2da_picks_4ms -M out -nxtaper 5 -nztaper 5 |\
fft2da -R -O denoise_4ms_CDP_nmo_CSP_fft2da_poly_back

So, what have we managed to accomplish here. To get an idea, let us look at the shot gathers before and after application of the filter:

[before] [after] [animation]

Quite a difference. One may argue that we have utilized too severe a filter at this early stage of the processing. That may well be true, but let us not forget that the goal here is to get to a decent statics solution, and then the first iteration of the stacking velocity derivation. To do both of those we need as clean a dataset as we can get. We can always back up later and reduce the attenuation associated with this filter. Although the filter looks a little severe when viewed in the shot domain, what has it done to the data in the other two sort domains? To sort the data to the CDP domain for this display we use:


sisort -N denoise_4ms_CDP_nmo_CSP_fft2da_poly_back -n sort_table -D \
       -O ../CDP/denoise_4ms_CDP_nmo_denoise_CSP_CDP

and here we see:

[before] [after] [animation]

So, even though the filtered data looked a little wormy in the sort domain in which it was applied, the same is not true of the CDP domain that is being stacked. Here we see a definite improvement in the S/N ratio of this data.

For completeness lets see what we have done to the stack:

[before] [after] [difference] [animation]

A not insignificant improvement, given the crudeness of the filter applied, and only in one domain. As you can see from the difference dataset, there is no indication of any primary event being attenuated in the stack.

And now, what have we done to the Receiver gathers:


sisort -N denoise_4ms_CDP_nmo_CSP_fft2da_poly_back -n sort_table -G \
       -O ../Receiver/denoise_4ms_CDP_nmo_denoise_CSP_CRP

[before] [after] [animation]

Again, an amazing amount of signal enhancement without the worminess seen in the domain where the filter was applied. We do notice however that there remains quite a bit of residual linear noise that could be attacked in this domain. That noise was not aligned when the data was sorted to the shot domain where the initial filter was designed and applied.

We will perform the same operation here, that is transform the receiver data to F-K space, pick a set of polygonal filters to reject as much noise a we feel is practical, apply those filters in the F-K domain to the receiver sorted data then transform back to T-X and see what we have accomplished.

Here are the processing steps involved:


fft2da -N denoise_4ms_CDP_nmo_CRP |\
polymute -Mout -nxtaper 5 -nztaper 5 -P fft2da_4ms_picks |\
fft2da -R -O denoise_4ms_CDP_nmo_CSP_fft2da_poly_back_CRP

sisort -N denoise_4ms_CDP_nmo_CSP_fft2da_poly_back_CRP -n presort_table_CRP -D \
       -O ../CDP/denoise_4ms_CDP_nmo_denoise_CSP_denoise_CRP
pstack -N denoise_4ms_CDP_nmo_denoise_CSP_denoise_CRP -O denoise_4ms_CDP_nmo_denoise_CSP_denoise_CRPSTACK

sisort -N denoise_4ms_CDP_nmo_CSP_fft2da_poly_back_CRP -n presort_table_CRP -S \
       -O ../Shot/denoise_4ms_CDP_nmo_CSP_denoise_CRP_denoise

Here are the results:

Receiver Domain
Shot Domain
CDP Domain
Stacks

So, although there is a significant amount of additional noise attenuated on the prestack displays, the stack shows very little improvement. Actually, the difference plot shows that we cut into the primaries just a little as you can see a faint imprint of the primaries trending across the difference stack. We'll have to go back and loosen up the constraints on the common receiver domain polygonal filters when we apply this process on the final pass through the data.

This is enough noise suppression for now. Later in the flow we will contend with other coherent noise problems, like multiple reflections and reverberation. Before we take a crack at deriving a better set of stacking velocities lets see if we can improve matters by including a residual static correction.

Residual Statics

I have actually done this work this weekend, but I have run out of time for documentation. My wife is giving me a knowing look as it is Sunday afternoon and I have been on this machine for way too many hours this weekend.....enjoy what I have added [or not] and I'll flush out the sections on statics and improved stacking velocity analysis next time in.........Paul

2D Processing Tutorial

Table of Contents

Introduction

Conversion to USP Format

Merge Survey Data

Initial Signal Analysis and Quality Control

Initial Velocity Analysis

Brute Stack

Noise Suppression

Residual Statics

Improved Velocity Analysis

What Else?

Errata

USP Scripts