Notes on processing 468 channel data from MGL1112

Given ~6000 segd files plus an UKOOA p190 navigation file.
Sioseis scripts.
Step 1 - plot some shots.
Note that there are a bunch of bad traces.  Trace 30 must be leaking (lots of 60Hz)
and gets worse as the trip progresses.  There are also some traces with low amplitude.
Step 2 - kill the bad traces and gather (sort by rp).
Kill (weight by 0) the traces before gather because killing by range
is impossible because the ranges change when using UKOOA p190.

weight twp 30 0 169 0 186 0 192 0 294 0 301 0 343 0 349 0 377 0 396 0 
          408 1.25 409 1.25 427 1.5 428 1.5 429 1.5 430 1.5 437 0 end end
geom  dbrps 6.25 type 19 navfil /home/Paul/data/mgl1112/MGL1112MCS--04.p190 end end

(see below:  traces 188, 257, and 344 are also quite noisey at times and killed on the gathers)

See trace_edit for a discussion of finding bad traces.
Automatic trace killing based on low maximum value might work 
(despike mintype absval minval 5).


save every 500th rp to a separate file
The entire gather file is ~80GB and sioseis can't do random access on
files > 2GB.

Step 3 - QC (quality control) the gathers
See script pltg for stepping through a gather file.
Sioseis bug reading the .p190 files has been corrected

Step 4 - gather using the LDEO realtime GPS and assumed streamer geometry.
  
geom   dbrps 6.25 type 9 ggx -12.5 gxp 468 -220 end end
File dfls.txt contains a list
of shots and dfls (distance from last shot).
Sioseis geom parameter SETBACK should be used to make the stacked segy files
contain the correct lat/long.

Step 5 - pick velocities using vpick script
There's a modified vpick script in scripts.
Slightly different plotting parameters as well as velocities.  Also added
a couple of lines to set the size of the Matlab contour plot.
I made a separate file of gathers for velocity analysis (every 500) in order to reduce
the disk I/O
See directory mgl1112vels for some plots. 
(Best if each is opened in a new browser window).
Looking at plots of the gathers during this step showed that trace 188 (range 3720)
and trace 344 (range 1770) have substantial 60Hz and should be killed.

Step 6 - QC and adjust the velocity picks
I changed my interpretation of the velocity spectra after picking many.
Two major considerations or data interpretation are needed:
1)  Is there a low velocity layer below several high velocity layers, or is
there an internal multiple of some sort?
2)  Several high velocity layers may cause the ray to exceed the critical angle 
and become refractors or something besides a reflector.

Is the frequency change due to nmo stretch or geology?

E.g.   rp 5200, event at 2.9, ranges 220-1600 have different frequency and 
curvature than ranges 1700-6000.  Note the refractor emerging at 4.4s.

rp 7200 looks like there are two layers with different curavture and frequency
around 3s, which is below the multiple at 2.5s.   
(Remember that sioseis does not gather dead/killed traces).
The event at 2.95s is a multiple of the event at 1.7s.
Note the "high velocity" event at 2.5 as well as the multiple at 2.5s.
****    rp 7200 would be excellent for trying various multiple removal techniques.
****    Try over-nmo, flfilt, movein, the normal nmo stack etc

The spectra of rp 16700 shows a low velocity (1560m/s) at 3.7s
beneath a higher velocity (1600m/s) at 3.2s.
Is this an internal multiple?  (the 3.2s reflects up, then back down at the water
bottom at 2.7s)
****   This would be a good gather to examine after nmo (like 19200).

Look at rp19200, rp19200nmo, and shot4003.
The traces with ranges greater than 3km have nmo stretch on the events
down to 3.6s.  The events at 3.7 and 4.0 are not straight and are
probably not be hyperbolic or reflectors (converted waves?).

rps 21700 & 22200 also have conflicting velocity picks at 3.2s

Step 7 - Pick mute times
I like to "hang" mute times from the water bottom using ADDWB YES.
I used process WBT VEL 1470 to convert the multibeam water depths into
water bottom.  Unfortunately there are numerous bad bottom depths
which caused significant incorrect mutes.  Furthermore, the 
multi-beam reported significantly different depths from the seismics
presumably because the seismic water bottom reflector was off-line
(side swipe).

Step 8 - Pick the water bottom time manually.
No wbt auto picker worked perfectly.
Could have used program SIOPLT, but it was on the cygwin machine,
so I simply picked rp number and times off the screen plot.
The water bottom time will be useful for hanging an exponential gain
later on.
Remembr to use WBT parameter PRESTK YES on gathers.

Step 9 - WEIGHT NMO MUTE STACK
Weight three additional bad traces to 0.

Step 10 - Finite Difference migration
Done in 9000 trace segments since there are more than 16383 traces.
Save the output for input to Kingdom Suite (which can filter,
scale and plot).
Remember that the location (lat/long) is off.

Step 11 - FILTER GAINS PLOT
fdmigr1.png - Plot of day 264, 1330z to 1835z (rp 5200 to 14200)
fdmigr2.png - Plot of day 264, 1805z to 2315z (rp 13200 to 22200)

fdmigr1.png Comments:
1)  Note the event start at 1330z at 2.5s and very strong at 1435z and seem to die out.
2)  Note event at 1745z-1755z at 3.5s.   Magma layer?
3)  Likewise, event between 1725z and 1730z at 3.88s might be the same (magma?)
4)  The event at 2.6s 1735z and 2.7s at 1720z 
5)  What is the event at 3.35s at 1530z?   wb=1.3s, multiple =2.6s.  
    Has to be an internal multiple.  Note that it has higher frequency than earlier event.

fdmigr2.png Comments:
1)  Event at 4.9s at 1845z is low frequency and opposite slope of water bottom.
    (water bottom multiple is higher frequency!).
2)  I think I changed how I was picking velocities (favoring lows over highs)
    in the latter part.  Velocities are obviously wrong for migration.

Things to try
1) Repick the velocities ignoring the "low velocities" in order to
   bring out any deep (fast) events.  Do in conjunction with #2(?)

2) For multiple elimination, try over correcting in NMO, then
fk filter, inverse NMO, regular NMO.

3) Inner mutes

4) Shorter streamer (2km, 3km, 4km).  Would eliminate the low
frequency "events".  Would eliminate turning waves.

5) Use a low pass filter (5x50?)