Seismic Data Geometry update by seismic unix

Oil and natural gas exploration -- geology and geophysics
Post Reply
liath Fahad
Silver Member
Silver Member
Posts: 23
Joined: Tue Mar 29, 2016 1:34 pm

Seismic Data Geometry update by seismic unix

Post by liath Fahad »

Receiver coordinats
Receiver coordinats
offset coordenats
offset coordenats
source coordenats
source coordenats
Hello
I have real 2D seismic line data it is already processed with another processing package ( i think Omega ). Now i'm try to reprocess the data by seismic unix , I reformat data from segy to su and it is done correctly. The problem is the geometry of data was not set their was three files of geometry with the data i could not update the geometry for the data even when i use sushw still same problem.

GuyM
VIP Member
VIP Member
Posts: 620
Joined: Sat Mar 24, 2012 11:35 pm

Re: Seismic Data Geometry update by seismic unix

Post by GuyM »

Those files are SPS format (See http://seg.org/Publications/SEG-Technical-Standards )

I did a quick google and found this, which might help :

https://github.com/JohnWStockwellJr/Sei ... ometry/SPS

liath Fahad
Silver Member
Silver Member
Posts: 23
Joined: Tue Mar 29, 2016 1:34 pm

Re: Seismic Data Geometry update by seismic unix

Post by liath Fahad »

GuyM wrote:Those files are SPS format (See http://seg.org/Publications/SEG-Technical-Standards )

I did a quick google and found this, which might help :

https://github.com/JohnWStockwellJr/Sei ... ometry/SPS
Thank you GuyM for your guide i do as I understand.
1- I use the awk to cut the required columns.
awk '{ print $8,$9 }' bs48_s.s > s1.hdr
bs48_s.s: is the file that contain source coordinates with .sps format
s1.hdr: is the file that contain just the required columns.

and same method do it for receiver coordinates file.

2- I convert s1.hdr to s1.bin binary format using the a2b.
a2b < s1.hdr n1=2 > s1.bin
same thing for receiver coordinates file.

3- I try to define the sx,sy for the dataset which is in su format.
sushw < bs.su infile=s1,bin key=sx,sy > bsg.su

then for receiver
sushw < bsg.su infile=s1,bin key=sx,sy > bsgg.su

4- view header values by.
suascii < bsg.su bare=2 > s3.txt
suascii < bsgg.su bare=2 > s4.txt

the data have 15744 traces. The result was
A- 165 traces sx,sy defined respectively takes 165 shot coordinates but actually it contain just one shot because each one shot have 96 traces so 15579 traces still without sx sy.
B- 430 traces gx,gy defined respectively takes 340 receiver coordinates but actually it contain just the NEW sweep geophones so 15314 traces still without gx gy.

GuyM
VIP Member
VIP Member
Posts: 620
Joined: Sat Mar 24, 2012 11:35 pm

Re: Seismic Data Geometry update by seismic unix

Post by GuyM »

I didn't look in much detail - just found how SPS data was being used in SU by others.

I use a different processing package - most commercial packages can read SPS data directly (or with a bit of effort if its badly formatted) and can build the geometry directly from there.

Did you check the files against the SPS standard? Its possible that there's a slight variation so you'd need to adjust the scripts.

Confused by your awk command though - you are splitting out the 8th and 9th columns from that file with that command.
Don't you want to split out the 7th and 8th column? They look more like X,Y cooordinates to me...

- I'd check the files you have against the SPS standard; are things in the right place? 'Standards' can be loosely interpreted
- check the files you are creating using the awk command - do they have the data in you want?
- you are only splitting two columns out of the S and R file; don;t you need to have some kind of reference to the seismic numbering to merge it?

In general :

the "S" file has the shot station locations
the "R" file has the receiver station locations
the "X" file has the information that likes the Field File ID number (FFID, or SHOTID or RECORD NUMBER) and the CHANNEL to their shot and receiver stations.

So generally speaking if you aren't using the "X" file then its hard to see how you can merge the seismic and survey data.

liath Fahad
Silver Member
Silver Member
Posts: 23
Joined: Tue Mar 29, 2016 1:34 pm

Re: Seismic Data Geometry update by seismic unix

Post by liath Fahad »

s3.txt
generated geometry file.
(1009.05 KiB) Downloaded 98 times
s3.txt
generated geometry file.
(1009.05 KiB) Downloaded 98 times
GuyM wrote:I didn't look in much detail - just found how SPS data was being used in SU by others.

I use a different processing package - most commercial packages can read SPS data directly (or with a bit of effort if its badly formatted) and can build the geometry directly from there.

Did you check the files against the SPS standard? Its possible that there's a slight variation so you'd need to adjust the scripts.

Confused by your awk command though - you are splitting out the 8th and 9th columns from that file with that command.
Don't you want to split out the 7th and 8th column? They look more like X,Y cooordinates to me...

- I'd check the files you have against the SPS standard; are things in the right place? 'Standards' can be loosely interpreted
- check the files you are creating using the awk command - do they have the data in you want?
- you are only splitting two columns out of the S and R file; don;t you need to have some kind of reference to the seismic numbering to merge it?

In general :

the "S" file has the shot station locations
the "R" file has the receiver station locations
the "X" file has the information that likes the Field File ID number (FFID, or SHOTID or RECORD NUMBER) and the CHANNEL to their shot and receiver stations.

So generally speaking if you aren't using the "X" file then its hard to see how you can merge the seismic and survey data.
I think when you see the file you will know the problem. The coordinates in UTM format so I think they are referenced.
Attachments
geometry
geometry

GuyM
VIP Member
VIP Member
Posts: 620
Joined: Sat Mar 24, 2012 11:35 pm

Re: Seismic Data Geometry update by seismic unix

Post by GuyM »

I'd agree that's not right as you say - however not sure how you can resolve it, I'm afraid.

liath Fahad
Silver Member
Silver Member
Posts: 23
Joined: Tue Mar 29, 2016 1:34 pm

Re: Seismic Data Geometry update by seismic unix

Post by liath Fahad »

GuyM wrote:I'd agree that's not right as you say - however not sure how you can resolve it, I'm afraid.
1-Is there any way to view the geometry just as projection ?
2-What do think about this method ?
Last edited by liath Fahad on Wed Dec 14, 2016 3:13 pm, edited 1 time in total.

GuyM
VIP Member
VIP Member
Posts: 620
Joined: Sat Mar 24, 2012 11:35 pm

Re: Seismic Data Geometry update by seismic unix

Post by GuyM »

The challenge is that you have to match :

- the shotrecord number to the right shot station number and update the header
- the channel number to the right receiver station number and update the header
- the receiver station to its X,Y coordinates and update the headers
- the shot station number to its X,Y coordinates and update the headers

This hard one is matching up the channels to the receiver station numbers as you have a split spread set up like this, where x is the shot location:

1 - 48 x 49 - 96

So in the screen grab of the X-file you sent, its shows that for shot record number 21:

Channel 1 is at station 1003
Channel 48 is at station 1050
The shot is at station 1052
Channel 49 is at station 1054
Channel 96 is at station 1101

When you have the station numbers assigned you can match these to the X,Y values and update the *those* trace headers.
Plus - you'll need to pick up the elevations from the file (after the X,Y values in the R file)

You might also need to load any static times or shot-hole depths as well...

liath Fahad
Silver Member
Silver Member
Posts: 23
Joined: Tue Mar 29, 2016 1:34 pm

Re: Seismic Data Geometry update by seismic unix

Post by liath Fahad »

Hello all , dear Guym I find that the navigation files ( SPS , else ) for my data not work or not stander formated . So I make relative geometry by using SUSHW order
sushw < bs.su key=sx a=2400 c=100 j=96 > bs1.su
sushw < bs1.su key=sy a=0 c=0 j=96 > bs2.su
sushw < bs2.su key=gx a=50 b=50 c=50 j=96 > bs3.su
sushw < bs3.su key=gy a=0 b=0 c=0 j=96 > bs4.su
sushw < bs4.su key=cdp a=1175 b=25 c=25 j=96 > bs5.su
sushw < bs5.su key=offset a=2350 b=50 c=50 j=96 > bs6.su

bs.su : my data
a= value on first trace
b= increment with in group
c= increment of the group
j= number of elements

Then I tested the geometry by plot gx Vs sx use the SUCHART order. I get a graph which could represent QC for geometry.

1. Is the geometry assumption correct ?
2. what is the possible QC for geometry in suismic unix ?
3. Is this graph which attached (or posted) correct ?
Attachments
gx,sx graph
gx,sx graph

GuyM
VIP Member
VIP Member
Posts: 620
Joined: Sat Mar 24, 2012 11:35 pm

Re: Seismic Data Geometry update by seismic unix

Post by GuyM »

Best way to QC the geometry is to plot the offset over the seismic data.

To convert the offset value to arrival time divide by a suitable velocity (and convert the sign to positive if needed) - - such as water velocity for marine or (say 2m/ms) for land.

The offsets should match the first break direct arrival very closely in the marine case, the land split spread case you are making sure the apex of the offset graph aligns with the data and refracted arrival event.

liath Fahad
Silver Member
Silver Member
Posts: 23
Joined: Tue Mar 29, 2016 1:34 pm

Re: Seismic Data Geometry update by seismic unix

Post by liath Fahad »

Hello all , thank you Guy M for your response I did not do what you told me in last post because i did not understand exactly what mean. So I start processing my data with the geometry that i make it. At the Velocity semblance step i get unexpected result that I could not explains it .!???
What do you think??
Attachments
velocity semblance
velocity semblance

GuyM
VIP Member
VIP Member
Posts: 620
Joined: Sat Mar 24, 2012 11:35 pm

Re: Seismic Data Geometry update by seismic unix

Post by GuyM »

I suspect your geometry is wrong.

Here's an example of marine geometry QC by plotting offsets over the data :

http://seismicreflections.globeclaritas ... al-qc.html

The geometry might be incorrect in terms of values - metres instread of decimetres and so on - or just applied incorrectly.

liath Fahad
Silver Member
Silver Member
Posts: 23
Joined: Tue Mar 29, 2016 1:34 pm

Re: Seismic Data Geometry update by seismic unix

Post by liath Fahad »

GuyM wrote:I suspect your geometry is wrong.

Here's an example of marine geometry QC by plotting offsets over the data :

http://seismicreflections.globeclaritas ... al-qc.html

The geometry might be incorrect in terms of values - metres instread of decimetres and so on - or just applied incorrectly.
Thank you GuyM for your guide I think now better this is screen shot of three cdp velocity semblance do think it is normal ?
Attachments
velocity semblance
velocity semblance

GuyM
VIP Member
VIP Member
Posts: 620
Joined: Sat Mar 24, 2012 11:35 pm

Re: Seismic Data Geometry update by seismic unix

Post by GuyM »

Ah - that's a lot better!

Or rather- that looks like a semblance plot to me - although a kind of messy one.

No while I don't know SU at all, but to me it looks like there's no far offset stretch mute being applied so the trend in the top two seconds is hard to see because the NMO stretch is messing with the semblance calculation - so you have some reasonable "bullseyes" to pick on between 2-3 seconds, but above and below that its hard. At depth the isseu is lack of structure and/or lack of offsets; the longer your offsets, the better your distribution.

So - you might get better results with some kind of mute applied (either in the calculation or before) and if you can "mix" the semblance (so that if you feed in gathers A, B, C, D, E the output at location C is a rolling average from A-E, weighted towards C)

Picking velocities just on semblance alone is really pretty tough; even when we worked on paper(!) we had more sophisticated approaches and diagnostics.
- we had semblance calculated in a "fan" around a central variable function with, which ignores velocity outliers and gives a cleaner repsonse
- we looked at "variable velocity ministacks" across 11-21 CDPs, each stacked up with one of the velocity trends in the "fan"
- we looked at "variable velocity gathers" on the central CDP, each NMO corrected with on of the veloicty trends in the "fan"

If you can get access to a dedicated velocity analysis tool its a lot easier, as all of that stuff is available interactively....

Some help on velocities and picking here:

http://seismicreflections.globeclaritas ... cking.html
http://seismicreflections.globeclaritas ... cking.html

liath Fahad
Silver Member
Silver Member
Posts: 23
Joined: Tue Mar 29, 2016 1:34 pm

Re: Seismic Data Geometry update by seismic unix

Post by liath Fahad »

GuyM wrote:Ah - that's a lot better!

Or rather- that looks like a semblance plot to me - although a kind of messy one.

No while I don't know SU at all, but to me it looks like there's no far offset stretch mute being applied so the trend in the top two seconds is hard to see because the NMO stretch is messing with the semblance calculation - so you have some reasonable "bullseyes" to pick on between 2-3 seconds, but above and below that its hard. At depth the isseu is lack of structure and/or lack of offsets; the longer your offsets, the better your distribution.

So - you might get better results with some kind of mute applied (either in the calculation or before) and if you can "mix" the semblance (so that if you feed in gathers A, B, C, D, E the output at location C is a rolling average from A-E, weighted towards C)

Picking velocities just on semblance alone is really pretty tough; even when we worked on paper(!) we had more sophisticated approaches and diagnostics.
- we had semblance calculated in a "fan" around a central variable function with, which ignores velocity outliers and gives a cleaner repsonse
- we looked at "variable velocity ministacks" across 11-21 CDPs, each stacked up with one of the velocity trends in the "fan"
- we looked at "variable velocity gathers" on the central CDP, each NMO corrected with on of the veloicty trends in the "fan"

If you can get access to a dedicated velocity analysis tool its a lot easier, as all of that stuff is available interactively....

Some help on velocities and picking here:

http://seismicreflections.globeclaritas ... cking.html
http://seismicreflections.globeclaritas ... cking.html
Thank you GuyM for illustrations but until now there is no progress to solve the problem.
At first the stretch image contain four ovals that my questions revolve around it.
1- As I understand NMO stretch it is like in oval 1. is it true ?
2- The ovals 2,3,4 is not like bullseyes why?
3- Is it this deviation from bullseyes in ovals 2,3,4 result because I did not correct the data by static correction?

I tried many ways to boost the trend from 0 second to 1.5 second but still not affected. So I continue the semblance and used the picked velocities for NMO correction to get the results as in NMO image, then the stack as in stack image. The should represent Fold limb.

GuyM
VIP Member
VIP Member
Posts: 620
Joined: Sat Mar 24, 2012 11:35 pm

Re: Seismic Data Geometry update by seismic unix

Post by GuyM »

In general you see an "oval" for any event on a semblance plot because you have more precision in Two-Way-Time than you do in velocity.

Stretch contributes to this, but its also a question of how accurately you can fit the NMO hyperbola to the data - the longer the offset (and steeper the dip of the event) the more accurately you can determine its velocity.

(see the "accuracy" section here : http://seismicreflections.globeclaritas ... cking.html )

Or rather :

- the precision in the velocity is determined by offsets; the longer the offset the better, as long as you are not spatially aliased
- this is true until other "far offset" factors come into play
- NMO stretch is really an issue in the shallower part of the section, typically down to 1-2 seconds
- the second limitation is the NMO correction; this is an approximation containing only the 2nd order (velocity) term
- beyond about 45 degrees you need to add a 4th order term to flatten the data
- some software supports this 4th order picking

In this case there's no statics issues (its a marine line!) - but statics can impact on the shape of a reflector making it non-hyperbolic, as can structure (dip); Ray path bending can also be an issue; the NMO process assumes a "straight rays" which means no refraction within a layer or at a layer boundary - which is NOT very geological at all(!)

- you may find that constant velocity (or variable velocity) stacks help you to determine the velocities better
- you may find that manually picking an NMO stretch mute simultaneously with your velocities helps.

On difficult land data I prefer to "layer strip" with small, windowed constant velocity stacked sections.

I start from 0-300ms TWT, with a "stack window" that takes into account (laterally) three velocity analysis locations. The software I use creates a series of overlaid "stack panels" that I can then animate, each with a constant velocity use to stack it. I also create constant velocity gathers in the same way based on the central CDP in the stack. The act of animating the data allows you to identify which parts are "well behaved" in an NMO correction snes, and which are not (and can't be picked); you can also define the far offset mutes while you pick.

I then work along the line, and shift the window down by 150ms TWT (so there's an overlap) paying careful attention to the Isovels plot while I'm picking; only pick away from the current "trend" if there is compelling evidence to do so.

Of course - I have software that allows me to do this; it was developed in part to deal with complex, rugged topography land lines and we've spent a lot of time "tweaking" it to add new functionality over the years.

liath Fahad
Silver Member
Silver Member
Posts: 23
Joined: Tue Mar 29, 2016 1:34 pm

Re: Seismic Data Geometry update by seismic unix

Post by liath Fahad »

Thank you the velocity analysis work good. The reflectors flatten as possible and I make stack. The stack section not satisfy me the horizontal resolution poor especially at right side of the section. I`m not sure if it related to problem in the processing follow. There is possible solution like random noise attenuation residual static correction or continue with migration.
Attachments
stack section
stack section
stack section
stack section

GuyM
VIP Member
VIP Member
Posts: 620
Joined: Sat Mar 24, 2012 11:35 pm

Re: Seismic Data Geometry update by seismic unix

Post by GuyM »

The sudden change in character that happens at about 1.4s on the left of the section looks odd to me; the RHS of the section looks more like I'd expect for land data...

- check the NMO stretch mute and velocities
If it is an automatic %age stretch mute then consider a manually picked one instead
It might also be a sudden change in velocity causing the stretch mute to vary - look at the interval velocities (Dix inversion etc) and compare those to the velocities you'd expect given the geology

What have you used for amplitude recovery?
Have you used linear gain with spherical divergence or a pre-stack AGC of some kind? Might be worth going back and looking at the gain functions applied

What pre-stack noise attenuation has been applied?
The deeper section seems to loose frequency content and resolution; might be the random noise attenuation (or indeed anti-ground roll) work has got out of control and is smearing out noise. What did you use? Did it have an "AGC wrap" (AGC applied before and then removed afterwards?"

liath Fahad
Silver Member
Silver Member
Posts: 23
Joined: Tue Mar 29, 2016 1:34 pm

Re: Seismic Data Geometry update by seismic unix

Post by liath Fahad »

GuyM wrote:The sudden change in character that happens at about 1.4s on the left of the section looks odd to me; the RHS of the section looks more like I'd expect for land data...

- check the NMO stretch mute and velocities
If it is an automatic %age stretch mute then consider a manually picked one instead
It might also be a sudden change in velocity causing the stretch mute to vary - look at the interval velocities (Dix inversion etc) and compare those to the velocities you'd expect given the geology

What have you used for amplitude recovery?
Have you used linear gain with spherical divergence or a pre-stack AGC of some kind? Might be worth going back and looking at the gain functions applied

What pre-stack noise attenuation has been applied?
The deeper section seems to loose frequency content and resolution; might be the random noise attenuation (or indeed anti-ground roll) work has got out of control and is smearing out noise. What did you use? Did it have an "AGC wrap" (AGC applied before and then removed afterwards?"
I use the pre stack gain with parameters.
1- Time power amplitude (tpow=2)
2- Signed growth power of sealed data (gpow=0.5)
3- qclip by quantil on absolute values on trace
4- Blance traces by clip and scale

Then I use two filters the band bass filter with frequencies f=10,15,45,50.
after that I applied the dip filter with slopes ( slopes: delta_t / delta_x ) the slopes=-0.95,-0.07,0.07,0.95.
The fourth stage I applied deconvolution with.
1- Maxlag=0.1
2- Minlag=0.02
3- Relative additive noise level equal 0.01

I did not apply spherical divergence or random noise attenuation.

GuyM
VIP Member
VIP Member
Posts: 620
Joined: Sat Mar 24, 2012 11:35 pm

Re: Seismic Data Geometry update by seismic unix

Post by GuyM »

I'm afraid the name of the SU modules doesn't help me much without knowing what they are trying to do and why you picked those parameters - but I'll interpret as best I can.
Usually in a processing sequence you give the process and domain (eg Dip filtering in the FK domain), not what this is called in the software you are using.
You haven't mentioned statics - elevation correction to a fixed/floating datum, refraction statics, residual statics and how many iterations - or where you did your velocity analysis.

Unless the data was very flat and the near surface very consistent I'd expect to see all of these statics types applied as part of the structural solution.

But - if you are happy with the structure (velocities and statics) it can be a good idea to revisit the signal processing side of things.

- the band pass filters look pretty narrow to me - a 15-45Hz band width isn't that great
==> to test filters I'd suggest looking at a whole combination of panels, for example:
Under 5Hz, 5Hz-10Hz, 10Hz-20Hz, 20Hz-30Hz, 30Hz-40Hz, 40Hz-50Hz, 50Hz-60Hz, 60Hz-70Hz 70Hz-80Hz 80Hz+
That will give you "upper and lower" limits where there's signal. It's important to remember that frequency filtering is a very crude tool (second only to just cutting the data out with a mute or edit) and so do as little as possible. You can rely on other approaches to address noise later in the sequence if you need to. Cutting back on frequencies early on will limit how effective those tools are.

==> the dip filter might be too harsh; you can "see" the response on the bottom of the stack
Dip filters are hard if you have spatially aliased datasets (you dont; say of it is FX, FK or Tau-P); if you are trying to hit ground roll you might be better off just working in the frequency domain but limiting the application to the "cone" where there is ground roll. Typically this means calculating a start time for the application in the same way you did the geometry QC on offset, but with a ground roll velocity (measure this from a shot record)
I'd suggest looking at the data with and without dip filtering carefully, as this may be part of the problem - there's a nasty "dip filtering" signature on the bottom of the stacks...
I'd also suggest a removable AGC around the dip filter; apply the AGC first storing the scalars, then remove the AGC after the dip filter

==> Not sure what those deconvolution parameters mean! I'd expect to see a deconvolution defined by:
- design gates (start and end), application gates (start and end), operator length, gap length.
- design these based on the autocorrelation function and frequency band; spiking deconvolution might be an idea
- you must avoid noise (direct and refracted arrivals, ground roll) in the design window
- use the autocorrelation functions to help with parameter deisgn

==> add some pre-and post-stack noise attenuation;
==> think about using time varying filters later in the sequence (ie post stack)

So - it might be that you have "over processed" the data at an early stage using harsh parameters, and going back and revising may help.

- use the lightest, broadest band width frequency filter you can at the start of the sequence
- check the amplitudes haven't "over cooked" things by looking at amplitude decay on the trace
- be cautious about using "clip" on the amplitudes; I'd favour manual editing of bad traces over this
- look at other approaches to address ground roll as well as dip filtering;
- use an "AGC wrap" on any dip filtre or multi trace process
- do your deconvolution design carefully; avoid any "noise" like direct or refracted arrivals in the design gate, for example
- test all parameters on a selection of shots, as well as looking at the stacks after each stage

Hope this all makes sense and helps...

liath Fahad
Silver Member
Silver Member
Posts: 23
Joined: Tue Mar 29, 2016 1:34 pm

Re: Seismic Data Geometry update by seismic unix

Post by liath Fahad »

I find it in A Course in Geophysical Image Processing with Seismic Unix which is written by John Stockwell in 2016 page 168.
Attachments
c1.PNG
c1.PNG (50.82 KiB) Viewed 3698 times

GuyM
VIP Member
VIP Member
Posts: 620
Joined: Sat Mar 24, 2012 11:35 pm

Re: Seismic Data Geometry update by seismic unix

Post by GuyM »

Funny - I happened to run into John at the EAGE conference at the start of June and we had a bit of a chat about teaching seismic processing and Seismic Unix - the processing world is very small.

I think the key thing is to make sure you understand *why* you are applying each stage and *when* it should be applied. There's not really a "fixed recipe" for seismic processing, but there are commonly used sequences.

In that example he's showing that you should mute out the wide angle reflections - while that's an option, its also possible to include them in your processing.

Similarly on marine data I have had a lot of success using Tau-P doman filters to remove the dipping direct and refracted (head-wave) arrivals, leaving the underpinning wide angle reflection in place. Now these require an extended form of the NMO correction to "flatten" them - the so called "4th order moveout" term, as well as the conventional second order velocity picking.

The plus side of having wider angle reflections comes if you want to start looking at AVO - amplitude variation with offset - and so on.

With mute, the main thing is that once the data is gone, its gone.

- always use muting as lightly as possible; you can make it tighter for QC stacks or the final product if needed
- remember muting is the *worst* and *least sophisticated* way to remove noise; its great if you are in a hurry, that's it
- if you can find another way to address the noise, its usually worth the effort to put it in place...

Post Reply
  • Similar Topics
    Replies
    Views
    Last post